KG Distribution

I Solved 13Cubed's KG Distribution Memory Forensics Lab - Here's the Full Walkthrough Hunting a Sliver C2 implant through a VMware memory dump with MemProcFS, one artifact at a time.

The two memory files we start with - WORKSTATION.vmem and WORKSTATION.vmsn] If you've ever wanted to get into memory forensics but didn't know where to start, this lab is the perfect on-ramp. KG Distribution is a beginner-friendly memory forensics lab built by @13CubedDFIR, and it walks you through analyzing two systems - a workstation and a server - entirely from their RAM. In this post I'll walk through exactly how I solved every question, the tools I used, and the screenshots from my own run so you can follow along. Let's dig in. The Scenario Patricia Bethel just started a new job at KG Distribution. During the usual onboarding chaos, she got an email from "IT Support" telling her to complete an important task. Trusting it, she followed the instructions to the letter. A few hours later, the SOC got an alert about weird behavior on one of the domain controllers. They grabbed volatile memory from Patricia's workstation and from anything that had recently talked to the DC in a strange way. It's after hours, nobody can reach Patricia, and the company doesn't want to pull the DC offline until they're sure something's actually wrong. That's where I come in. My job: figure out if this is a real incident, and if so, map out exactly what happened. Setting Up MemProcFS The whole lab runs on MemProcFS - a brilliant tool by Ulf Frisk that mounts a memory image as a virtual file system. Instead of memorizing dozens of Volatility commands, you literally browse processes, registry keys, and network connections like folders on a drive. My first attempt used the -memmap flag with the .vmsn file, but it threw an error trying to locate ntoskrnl.exe. Dropping that flag fixed it instantly: .\MemProcFS.exe -mount M -device WORKSTATION.vmem

MemProcFS initializing - first attempt fails with -memmap, second succeeds and detects Windows 10.0.22621] For the server, I ran it in forensic mode so MemProcFS would pre-generate timelines and run its built-in YARA scanner: MemProcFS.exe -device WORKSTATION.vmem -forensic 1 -license-accept -elastic-license-2.0 Mounting in forensic mode (-forensic 1) to generate timelines and run YARA] Once mounted, drive M: fills up with everything we need - conf, forensic, registry, sys, name, pid, and more.

Part 1 - The Workstation We start with WORKSTATION Patricia's machine. The first few questions are basic recon to establish what we're looking at.

Q1: What is the hostname of this device? Easiest possible start. I opened M:\sys\sysinfo, which gives a clean summary of the machine - computer name, boot time, OS build, hardware, the works.

[SCREENSHOT: sysinfo showing the Computer Name: BLD2-RM202-14] The naming convention (Building 2, Room 202, machine 14) already screams corporate environment. ✅ Answer: BLD2-RM202-14

Q2: What domain is this workstation joined to? The hostname is there, but the domain isn't in sysinfo. I found it in the registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History, in the MachineDomain value.

[SCREENSHOT: The MachineDomain registry value: kgdistribution.qm] ✅ Answer: kgdistribution.qm

Q3: Who is the primary user? Straight to M:\sys\users. One human account stands out.

[SCREENSHOT: users file - patricia.bethel with a domain SID ending in -1128] That SID ending in -1128 (well above 1000) confirms it's a real domain account, lining up with the kgdistribution.qm domain we just found. ✅ Answer: patricia.bethel

Q4: What IP is assigned to the device? Over to M:\sys\net\netstat. Every outbound connection shares the same source IP.

[SCREENSHOT: netstat - source IP 192.168.8.12 across all connections] ✅ Answer: 192.168.8.12

Q5: When did Patricia open the phishing email? This is where it gets fun. The lab uses Thunderbird, which stores opened messages as .eml files. So I loaded timeline_ntfs.csv into Eric Zimmerman's Timeline Explorer and filtered for .eml. And there it was - a beautifully on-the-nose phishing lure: [Action Required] IT System Upgrade.eml

[SCREENSHOT: The phishing email in the NTFS timeline - created 16:31:58, opened (RD) 16:32:14] The CRE timestamp is when Thunderbird saved it; the RD timestamp is the moment Patricia actually opened it. ✅ Answer: 2024-08-18 16:32:14

Q6: What remote admin tool gave the attacker a foothold? Less than a minute after opening that email, something landed in Patricia's Downloads folder: dwagent.exe - the agent for DWService, a legit remote-access tool. Attackers love legit RATs because they sail right past AV. I confirmed it two ways - in the NTFS timeline (downloaded to Downloads, then installed to Program Files) and in netstat-v with live connections out to 38.110.1.171:443.

[SCREENSHOT: netstat-v - dwagent.exe with ESTABLISHED connections to 38.110.1.171:443] ✅ Answer: dwagent.exe (DWService)

Q7: Earliest execution time of that remote admin process? Filtering the NTFS timeline for dwagent.exe and sorting by the earliest RD (read/execute) action gives the first execution.

[SCREENSHOT: timeline_ntfs filtered for dwagent.exe - earliest RD at 16:33:06] ✅ Answer: 2024-08-18 16:33:06

Q8: What file transfer tool downloaded the next-stage binary? Once they had DWService access, the attacker pulled down a second-stage payload. Checking prefetch and the timeline around 16:33–17:00 points to a built-in living-off-the-land downloader - curl.exe. [ ADD SCREENSHOT HERE: Prefetch/timeline view showing curl.exe execution around the compromise window ] ✅ Answer: curl.exe

Q9: The malicious binary that ran ~1 minute after download? Searching timeline_all.csv for the dropped payload turns up a wonderfully sketchy filename: OfficeUPgrade.exe**, sitting in C:\Windows\Temp. Random names + Temp folder = textbook malware.**

[SCREENSHOT: OfficeUPgrade.exe in the timeline - \1\Windows\Temp\OfficeUPgrade.exe] It even showed up in the AppCompat InventoryApplicationFile registry data, which is a great execution-proof artifact:✅ Answer: OfficeUPgrade.exe

Q10: Full registry path used for persistence? I checked the classic autorun location - HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Among the legit entries (SecurityHealth, VMware) there's an AzureArcSetup value that points straight at our malware in Temp.

✅ Answer:HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Part 2 - The Server (Domain Controller) Now the stakes go up. The attacker moved laterally to the domain controller, and this is where MemProcFS's forensic mode really shines.

Q1: PID of the malicious process? MemProcFS ships with a built-in YARA scanner. Its output lives in M:\forensic\findevil\findevil.txt - and it immediately flagged our binary as Sliver.

[SCREENSHOT: findevil.txt - rGARTERny.exe flagged as Multi_Trojan_Sliver at PID 4544] ✅ Answer: 4544

Q2: Full path of the malicious process? Same path we saw on the workstation, confirmed via the process artifacts and timeline cell contents.

[SCREENSHOT: Full path confirmed: C:\Windows\Temp\rGARTERny.exe] ✅ Answer: C:\Windows\Temp\rGARTERny.exe

Q3: What spawned it? I opened process.csv in Timeline Explorer, searched for PID 4544, and grabbed its PPID: 648.

[SCREENSHOT: rGARTERny.exe at PID 4544 with parent PID 648] Then I searched for 648 to see what that was:

[SCREENSHOT: PID 648 resolves to services.exe - our malware is running as a Windows service] ✅ Answer: services.exe

Q4: Name of the persistence mechanism (the service)? Since it's running as a service, I searched M:\sys\services for rGARTERny.exe. The service wrapping it has a deliberately boring, legit-sounding name.

[SCREENSHOT: services file - officeupgradeservice (PID 4544) pointing to c:\windows\temp\rGARTERny.exe] Notice it's set to DISABLED but still RUNNING - a sneaky way to stay alive while looking dormant to a casual glance. ✅ Answer: officeupgradeservice

Q5: Command line of the child process? MemProcFS gives every process its own folder. I went to M:\name\powershell.exe-2404\ (PPID 4544, so it's our malware's child) and opened win-cmdline.

[SCREENSHOT: Inside the process folder - win-cmdline holds the exact launch command]

[SCREENSHOT: The PowerShell command line spawned by the Sliver implant] powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF8Encoding]::UTF8 The -NoExit keeps the session alive, and forcing UTF-8 output is a classic trick to get clean command results back over a C2 channel - very Sliver. ✅ Answer: powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF8Encoding]::UTF8

Q6 & Q7: Second persistence path + binary? Digging into the forensic file carve, I found a second persistence spot - the Administrator's Startup folder.

[SCREENSHOT: Startup folder - OfficeUPgrade (15 MB) staged to run at every Administrator logon] The binary is OfficeUPgrade - another disguised Sliver implant, so even if rGARTERny.exe gets cleaned up, the attacker keeps access. ✅ Answer: Path: ...\Start Menu\Programs\Startup\ • Binary: OfficeUPgrade

Q8: The persistence tool the attacker used This was the hardest one in the lab, and honestly I got a little lucky. Inside the malicious process's folder there's a minidump - a dump of that process's memory. I ran strings over it and searched in Notepad++ for likely tool names and plaintext words. Eventually I hit a reference to SharPersist:

[SCREENSHOT: SharPersist v1.0.1 - C# Windows Persistence Toolkit by Brett Hawkins, found in the process minidump] Tip: when searching a minidump like this, look for strings of a specific length and plain English words you'd expect a tool's help text to contain. ✅ Answer: SharPersist

Q9: What C2 framework is in play? The YARA hit said it all. The detection name Multi_Trojan_Sliver_3bde542d breaks down as multi-platform / trojan / Sliver / rule hash.

[SCREENSHOT: findevil confirming the Sliver C2 framework via YARA] Sliver is Bishop Fox's open-source C2 - a popular free alternative to Cobalt Strike, and increasingly common in real intrusions. The PowerShell UTF-8 behavior and HTTPS C2 all corroborate it. ✅ Answer: Sliver

Q10 & Q11: Files staged for exfiltration Finally, the payload of the whole operation. In timeline_ntfs.csv I found the attacker touching two crown-jewel files via a Volume Shadow Copy - the SYSTEM hive and ntds.dit.

[SCREENSHOT: SYSTEM and ntds.dit accessed via shadow copy - full domain credential theft] Together, SYSTEM + ntds.dit let an attacker extract every password hash in the domain offline. SYSTEM is accessed first, then ntds.dit. ✅ Answer: First: SYSTEM • Second: ntds.dit  

Putting It All Together Here's the full kill chain we reconstructed, start to finish: 16:31:58 Phishing email lands in Documents 16:32:14 Patricia opens [Action Required] IT System Upgrade.eml 16:33:06 dwagent.exe (DWService RAT) downloaded + executed ~16:34 curl.exe pulls rGARTERny.exe into C:\Windows\Temp 16:33-34 rGARTERny.exe installed as 'officeupgradeservice' (Sliver) 17:27:43 OfficeUPgrade.exe beacons to C2 64.23.144.215:8888 17:47+ Lateral movement to the domain controller (.13:445) 18:11+ SYSTEM + ntds.dit staged for exfil via shadow copy

What started as one employee clicking one email ended in a full domain compromise in under two hours. The attacker used legit tooling (DWService), a real C2 framework (Sliver), reflective loading of a persistence kit (SharPersist), and finished by stealing the entire Active Directory database. Final Answer Key Workstation: BLD2-RM202-14 · kgdistribution.qm · patricia.bethel · 192.168.8.12 · email opened 2024-08-18 16:32:14 · dwagent.exe · first exec 16:33:06 · curl.exe · rGARTERny.exe · HKLM...\Run · 64.23.144.215:8888 Server: PID 4544 · C:\Windows\Temp\rGARTERny.exe · services.exe · officeupgradeservice · powershell -NoExit UTF8 · Startup folder · OfficeUPgrade · SharPersist · Sliver · SYSTEM · ntds.dit

Huge thanks to @13CubedDFIR for building such a clean, realistic lab. If you're starting out in DFIR, MemProcFS is an incredible tool to have in your kit - go try this one yourself.

Thanks for reading! If this helped, drop a clap and follow for more DFIR walkthroughs. 🔍