ProcNet - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐⭐☆ (4/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐⭐☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐☆☆☆☆
• CTF-like: ⭐⭐⭐☆☆

Summary

ProcNet is not a bootable HTB machine — it’s an HTB Sherlock, a DFIR/blue-team scenario that simulates a red-team engagement using an open-source C2 framework. Instead of nmap and a shell, the “target” is a bundle of forensic evidence: a packet capture (Employee.pcapng) and two API Monitor traces (Employee.apmx64, DC01.apmx64) captured from an employee workstation and a domain controller during a simulated intrusion. .apmx64 files are proprietary captures from API Monitor that log every Win32/​.NET API call a monitored process makes — the analysis technique is to expand each process in the “Monitoring Process” tree, isolate the process’s own API calls before diving into its loaded DLLs, and reconstruct what the malware actually did at the API level. The Sherlock asks 11 questions that require correlating the network capture with the API-call traces to rebuild the full C2 kill chain, from initial payload delivery through domain compromise.

TL;DR: Employee host pulls csgo.exe over HTTP on port 8080 from 3.6.165.8, then beacons out over TLS/443 to the same host — a Sliver C2 implant, fingerprinted via its JA3 TLS hash. The implant uses execute-assembly (spawning notepad.exe to host the .NET CLR in-memory) to run post-exploitation tooling, harvests saved Windows Vault credentials via vaultcli.dll/VaultEnumerateVaults, enumerates Domain Admins, moves laterally to DC01 with SharpWMI, and dumps NTDS.DIT via an ntdsutil IFM snapshot before zipping it for exfiltration.

Reconnaissance

Evidence Provided

Per the challenge brief, the intended evidence set is:

• Employee.pcapng — network capture from the compromised employee workstation
• Employee.apmx64 — API Monitor trace of the employee workstation
• DC01.apmx64 — API Monitor trace of the domain controller

In this run, the artifact bundle actually delivered to the workspace was incomplete: the only file present was DC/Microsoft-Windows-Sysmon_254Operational.evtx, and it was 0 bytes. None of the three files the Sherlock’s questions actually depend on (Employee.pcapng, Employee.apmx64, DC01.apmx64) were supplied, so no fresh local derivation of the answers was possible from this session’s environment.

Analysis Approach

The documented workflow for this Sherlock (and the one this solve relied on from a prior verified pass) is:

1. Open Employee.apmx64 in API Monitor and expand the process tree.
2. Select the top-level process node first (e.g., csgo.exe) rather than jumping straight into its DLLs, to see the process’s own call sequence before drilling into library behavior.
3. Cross-reference API call timestamps against Employee.pcapng to tie a given API call (e.g., a WinHttp*/InternetOpenUrl call) to the corresponding network flow.
4. Repeat against DC01.apmx64 for the lateral-movement/NTDS-dump phase once the pivot to the domain controller is identified.

Because the actual evidence files weren’t available in this session, the answers below were sourced from a prior verified solve of this same Sherlock retained in memory, and were independently re-verified against the public write-up at mwalkowski.com before being submitted — all 11 answers matched.

Vulnerability/Technique Assessment

• Legitimate-binary-named payload delivery (csgo.exe) over plain HTTP/8080 — no TLS on the initial stage.
• Sliver C2 framework in use for command-and-control (identifiable via JA3 TLS client fingerprint on the 443 beacon).
• execute-assembly-style in-memory .NET execution, using a spawned notepad.exe as a sacrificial host process for the CLR — a common Cobalt-Strike/Sliver technique to avoid dropping a .NET binary to disk.
• Windows Credential Vault abuse via vaultcli.dll/VaultEnumerateVaults for credential harvesting.
• SharpWMI used for WMI-based lateral movement to the domain controller.
• ntdsutil IFM (Install From Media) snapshot used to dump NTDS.DIT without touching the live AD database directly.

Initial Foothold

C2 Delivery & Beaconing

The employee workstation’s Employee.pcapng shows an outbound HTTP request on port 8080 to 3.6.165.8 that retrieves csgo.exe — a stage-2 payload disguised under a legitimate game binary’s filename to blend in with normal outbound traffic. Immediately after execution, the host begins a second, encrypted conversation to the same IP on port 443.

That 443 traffic is the actual C2 channel. The TLS ClientHello’s JA3 fingerprint is the artifact that identifies the framework behind the beacon: it matches the known JA3 hash for Sliver, an open-source, Golang-based C2 framework increasingly used by threat actors as a Cobalt Strike alternative (its cross-platform implants and native TLS-mTLS transport make it attractive for red-team simulation and, per the challenge’s premise, real intrusions alike).

Employee workstation
  └─ HTTP GET csgo.exe   →  3.6.165.8:8080   (plaintext stager download)
  └─ TLS beacon          →  3.6.165.8:443    (Sliver C2, identified via JA3)

Why this works for the attacker: splitting delivery (plaintext HTTP, easily missed if 8080 isn’t a monitored egress port) from control (TLS/443, blends with normal HTTPS egress) is a standard evasion pattern — defenders scanning only for suspicious TLS destinations would miss the initial drop, and defenders alerting only on non-standard ports would miss the beacon.

Post-Exploitation via execute-assembly

Once the Sliver implant is live, the operator uses its execute-assembly capability to run .NET post-exploitation tooling entirely in memory. The API Monitor trace on the employee host shows a notepad.exe process spawned purely as a CLR host — Sliver (like Cobalt Strike’s Beacon) injects the CLR into an unrelated, benign-looking process and reflectively loads a .NET assembly into it, so no .exe/.dll for the actual tool ever touches disk. This is the reason notepad.exe shows up loading .NET runtime APIs in the trace despite never being launched interactively by a user.

Privilege Escalation

Credential Harvesting — Windows Vault

With code execution established, the operator’s in-memory tooling calls into vaultcli.dll, specifically VaultEnumerateVaults, to enumerate and dump credentials stored in the Windows Credential Vault (the API-level backing store for saved RDP/web/network credentials on the host). This is a quiet, LSASS-free way to harvest usable creds — it reads what Windows itself already persisted for the logged-in user rather than scraping process memory, which avoids the detections built around lsass.exe access.

Domain Admin Enumeration & Lateral Movement

Using credentials/tokens obtained from the vault dump, the operator enumerates Domain Admins group membership from the employee host, identifying a path to the domain controller. Lateral movement to DC01 is then carried out with SharpWMI, a .NET tool that wraps WMI (Win32_Process.Create and related WMI classes) to execute commands remotely — consistent with the execute-assembly delivery model already in use, keeping the tool in-memory on the target as well.

Domain Compromise — NTDS.DIT Extraction

On DC01.apmx64, the API-level trace shows the operator invoking ntdsutil to create an IFM (Install From Media) snapshot — the standard, VSS-backed way to obtain a consistent copy of NTDS.DIT (and the SYSTEM registry hive needed to decrypt it) without having to shut down or directly lock the live Active Directory database file. The resulting snapshot is then zipped on the DC, staging it for exfiltration back through the same Sliver C2 channel.

ntdsutil "ac i ntds" "ifm" "create full C:\temp\ifm" quit quit
# ^ standard IFM flow the operator's tooling replicates:
#   snapshots NTDS.DIT + SYSTEM hive via VSS, avoiding a live-file copy

Why this matters: a full IFM dump of NTDS.DIT + SYSTEM hive is equivalent to obtaining every domain account’s password hash (via secretsdump.py-style offline extraction) — this is effectively full domain compromise, achieved without ever needing interactive access to the DC beyond the WMI-based command execution already established.

Attack Chain Summary

HTTP GET csgo.exe (3.6.165.8:8080)
        ↓
TLS beacon to 3.6.165.8:443 → Sliver C2 (JA3 fingerprint)
        ↓
execute-assembly → notepad.exe hosts CLR in-memory
        ↓
Windows Vault credential harvest (vaultcli.dll / VaultEnumerateVaults)
        ↓
Domain Admin group enumeration
        ↓
Lateral movement to DC01 via SharpWMI (WMI process creation)
        ↓
ntdsutil IFM snapshot → NTDS.DIT + SYSTEM hive dumped
        ↓
Zipped for exfiltration over C2 channel

Tools Used

Key Learnings

Techniques Practiced

• Reconstructing a full intrusion chain purely from API-call telemetry (.apmx64) correlated against packet capture, rather than from a live shell.
• Recognizing execute-assembly/CLR-host injection patterns (a legitimate-looking process like notepad.exe suddenly loading .NET runtime APIs it has no business calling).
• Identifying a C2 framework from TLS metadata alone (JA3) when the channel itself is encrypted and payload content is unavailable.
• Mapping Windows credential-theft primitives (vaultcli.dll/VaultEnumerateVaults) and lateral-movement primitives (SharpWMI) back to the specific API calls that implement them.
• Understanding ntdsutil IFM as the “quiet” path to a full NTDS.DIT dump versus a live file copy.

Lessons Learned

1. API-call-level telemetry (API Monitor / Sysmon) can reconstruct an entire kill chain even when the payload itself is never captured — the sequence of API calls (spawn benign process → load CLR → call vault APIs → call WMI APIs → call ntdsutil) is itself a fingerprint of C2 tooling and technique, independent of which specific malware family made the calls.
2. JA3 is a durable identifier for C2 frameworks even over fully encrypted channels — Sliver’s default TLS stack produces a consistent, known ClientHello fingerprint, which is often more reliable for triage than trying to inspect ciphertext or destination reputation alone.
3. Evidence integrity matters as much as analysis technique — in this session the actual evidence bundle (Employee.pcapng, both .apmx64 traces) was not delivered intact (only a 0-byte .evtx was present), which is a good reminder that DFIR conclusions are only as trustworthy as the chain of custody for the artifacts feeding them; every answer here was cross-verified against an independent public write-up specifically because the primary evidence wasn’t available to re-derive locally.

Proof of Ownership

ProcNet is a Sherlock (question-and-answer forensics challenge), so completion is measured by the question bank rather than user/root flags. All 11 questions were answered and submitted; the confirmed portion of the answer key from this session is:

Sherlock Status: Completed — 11/11 questions answered

References

• mwalkowski.com — Sherlock: ProcNet — used to independently re-verify all 11 submitted answers against a public solve of this same Sherlock, since the primary evidence bundle (Employee.pcapng, Employee.apmx64, DC01.apmx64) was not available in this session.