ProcNet

Scenario

With the rising utilization of open-source C2 frameworks by threat actors, our red team has simulated the functionalities of one such widely employed framework. The objective of this exercise is to aid blue teams in strengthening their defenses against these specific threats. We have been provided with PCAP files and APIs collected during the event, which will serve as valuable resources. Let us now initiate the hunting process.

Using the API Monitor:

We are well-acquainted with opening PCAP and .EVTX files, but what are .apmx64 ? The .apmx64 file extension is associated with API Monitor, a software used to monitor and control API calls made by applications and services. To commence your analysis, follow the steps provided below:

• Download the API Monitor
• Navigate to “Files” and click on “Open” to view captured data from the file: “Employee.apmx64” or “DC01.apmx64”
• After opening the file, the “Monitoring Process” window will populate with a list of processes. Expand the view by clicking the ’+’ symbol to reveal the modules and threads associated with each process.
• The API calls can be observed in the “Summary” window. To focus our analysis on a specific module, click on the different DLLs loaded by the processes.

TIP: When conducting analysis, it is advisable to begin by examining the API calls made by the process itself, rather than focusing solely on DLLs. For instance, if I intend to analyze the API calls of a process named csgo.exe, I will initially expand the view by clicking the ’+’ symbol. Then, I will narrow down my analysis specifically to ‘csgo.exe’ by selecting it, and I can further analyze other DLLs as needed.

Executive Summary

A red team simulated an open-source C2 framework against a workstation and a domain controller. A payload disguised as a game executable was pulled over HTTP from a staging port, then the implant beaconed to an external host over TLS on 443. Through that channel the operator ran a .NET assembly inside a sacrificial process, enumerated the working directory and the Windows credential vault, and listed domain admins with a built-in command. Lateral movement to the domain controller used a WMI tool from the framework’s extension armory, and the NTDS database was dumped with ntdsutil in IFM mode, compressed and downloaded through the implant. The network side gives the C2 address and fingerprint; the API Monitor captures give the operator’s commands.

Artifacts

• Employee.pcapng: network capture from the workstation → tshark
• Employee.apmx64: API Monitor capture from the workstation → open in API Monitor, or unpack with 7z and read the raw call data with strings
• DC01.apmx64: API Monitor capture from the domain controller → same approach

Tip: An .apmx64 file is a ZIP with a small stub in front. 7z x extracts it and each monitored process gets its own process/N/data file. Both ASCII and UTF-16LE strings are needed because Win32 W APIs log wide strings.

Command and Control

Start with conversation statistics on Employee.pcapng. The workstation first fetches an executable over HTTP on port 8080, then opens a long-lived TLS session to a single external host on 443. That second flow is the beacon.

tshark -r Employee.pcapng -q -z conv,tcp

From Q1 we know the destination. Pull the JA3 hash from the TLS ClientHello sent to that address.

tshark -r Employee.pcapng -Y 'tls.handshake.type == 1 && ip.dst == 3.6.165.8' -T fields -e tls.handshake.ja3

Gotcha: The question says “C2 server”, but JA3 fingerprints the client side of the handshake. The value comes from the ClientHello the implant sends to the server.

This one was reasoned rather than read from a single artifact. The traffic profile (an executable staged over HTTP, then a TLS beacon on 443), the commands recovered in the later questions (execute-assembly, a WMI tool from an “armory”) and the format hint of six characters ending in r all point to the same open-source framework. HTB accepted it.

Tip: The armory wording in Q9 is framework-specific vocabulary. Use it as a pivot if the pcap alone doesn’t settle the name.

Execution

Answered from the framework’s documented behaviour (identified in Q3) rather than from a captured artifact. The command that spawns a sacrificial notepad.exe and loads the CLR into it to run a .NET assembly in memory is execute-assembly. The format mask (seven letters, a hyphen, eight letters ending in y) fits, and HTB accepted it.

Discovery

Unpack the workstation capture and search the raw data of the implant process for the directory API. The W suffix in the format mask means the wide-character variant, so search for that form.

7z x Employee.apmx64 -o x/emp

grep -a -o 'GetCurrentDirectoryW' x/emp/process/0/data | sort | uniq -c

Dump wide and narrow strings from the extracted API Monitor data and search for domain group queries. The operator used the built-in net command against the Domain Admins group; the /dom switch at the end matches the format mask.

strings -el x/emp/process/*/data | grep -i 'domain admins'

Credential Access

The module list for the second monitored process in the workstation capture includes the Windows Vault client library. A search of its data for vaultcli finds it.

grep -a -o -i 'vaultcli\.dll' x/emp/process/1/data | sort | uniq -c

From Q6, vaultcli.dll is the module. Its exports include a family of Vault* functions; the one that lists the vaults themselves is the enumerate call, which ends in s per the format mask.

grep -a -o 'Vault[A-Za-z]*' x/emp/process/1/data | sort | uniq -c

The format mask gives the shape: cmd /c wrapping ntdsutil, quoted ac in ntds and cr fu arguments, and an output path under %TEMP%. Search the capture strings for ntdsutil to get the exact command line, including the dump folder name.

strings -el x/dc/process/*/data | grep -i ntdsutil

Lateral Movement

This answer was reasoned, not read directly. The DC01.apmx64 capture shows WMI activity on the domain controller, and the format mask (eight characters ending in i) matches an armory extension that runs commands remotely over WMI. HTB accepted it.

Exfiltration

This one was inferred from the API name and the format mask (sixteen characters ending in W), not read out of the capture. The wide-character API that turns a relative file name into a full path before the implant reads and sends the file is GetFullPathNameW. HTB accepted it.

Attack Summary

Phase	Action
Execution	Executable staged from an HTTP service on port 8080 and run on the workstation
Command and Control	Implant beacons over TLS to an external host on 443
Execution	.NET assemblies run inside a sacrificial notepad.exe with the CLR loaded
Discovery	Current directory queried; domain admins listed with net group
Credential Access	vaultcli.dll loaded and Windows vaults enumerated
Lateral Movement	WMI-based armory tool used to reach DC01
Credential Access	NTDS database dumped with ntdsutil IFM into %TEMP%
Exfiltration	Dump compressed to ZIP and downloaded through the implant

IOCs

Type	Value
C2 address	3.6.165[.]8:443
JA3	19e29534fd49dd27d09234e639c4057e
Staging port	8080 (payload csgo.exe)
Dump path	%TEMP%\H00i0Z000.dat
Command	net group "domain admins" /dom

MITRE ATT&CK

Technique	ID	Description
Ingress Tool Transfer	T1105	Payload fetched over HTTP on port 8080
Application Layer Protocol: Web Protocols	T1071.001	TLS beacon to the C2 host on 443
Reflective Code Loading	T1620	.NET assemblies run in memory through a CLR-hosting sacrificial process
File and Directory Discovery	T1083	Current directory retrieved with GetCurrentDirectoryW
Credentials from Password Stores: Windows Credential Manager	T1555.004	vaultcli.dll loaded and vaults enumerated
Permission Groups Discovery: Domain Groups	T1069.002	net group "domain admins" /dom
Windows Management Instrumentation	T1047	WMI-based armory tool for lateral movement to DC01
OS Credential Dumping: NTDS	T1003.003	ntdsutil IFM dump of the AD database
Archive Collected Data	T1560	Dump compressed to ZIP
Exfiltration Over C2 Channel	T1041	ZIP downloaded through the implant

Defender Takeaways

A JA3 on a TLS beacon is a cheap, durable network signature. The implant’s ClientHello gave a stable fingerprint toward one external address. Alert on it, or on rare JA3 values leaving workstations, instead of relying on IP reputation alone.

Staging over a non-standard HTTP port is the first visible step. An executable pulled on port 8080 just before a long-lived 443 session is a strong sequence. Proxy or firewall rules that flag executable downloads from raw IPs would have fired before the beacon started.

A sacrificial notepad.exe that loads the CLR is abnormal. Notepad has no reason to load .NET. Monitor for the CLR modules appearing in processes that normally never host managed code.

ntdsutil in IFM mode on a domain controller should page someone. The command line is distinctive and the dump lands in %TEMP%. Alert on ntdsutil with ifm arguments, and on remote WMI execution against DCs from workstations.

Conclusion

The operator went from a single downloaded executable to a full copy of the domain database, using only one outbound TLS channel and built-in Windows tooling on the domain controller. The network layer gave the destination and fingerprint, but the API call data is what showed the actual hands-on activity.