In this scenario, the Security Information and Event Management (SIEM) system at Forela has detected a series of alerts in a brief period, signaling potential Command and Control (C2) communication originating from an employee, Simon Stark’s, workstation. Despite Simon not observing any anomalies, the IT team conducted a preliminary investigation by reviewing screenshots of his task manager for any unusual processes, but found nothing out of the ordinary.
Despite the initial checks showing no apparent issues, the alerts regarding C2 communications continued, prompting the Security Operations Center (SOC) manager to take more stringent measures. The manager decided on two key actions: first, to contain Simon’s workstation to prevent any potential spread of a security threat within the network, and second, to perform a memory dump of the workstation for detailed analysis.
As a memory forensics expert, your role in this situation is crucial. You are tasked with collaborating with the SOC team at Forela to analyze the memory dump from Simon’s workstation. Your analysis aims to uncover any hidden or latent threats that were not visible in the initial task manager review. This could include identifying malware, rootkits, or other forms of sophisticated cyber threats that could be responsible for the C2 communication alerts.
A user launched an executable from their Downloads folder that carried the name of a core Windows system process. It looked unremarkable in Task Manager, which is why the first triage found nothing. The process opened an outbound TCP connection to an external host on a non-standard port within the same second it started, and it spawned a command shell that gave the operator hands-on execution. The binary was recovered from the memory image, hashed, and matched on VirusTotal, where it had been submitted by someone else about half an hour after it first ran.
mem in the commands below) → analyse with Volatility 3Timestamp note: Q5 and Q7 want
DD/MM/YYYY HH:MM:SS. Volatility reports UTC, and VirusTotal’s epoch converts cleanly withdate -u, so keep both in UTC and reorder the fields before submitting.
Start with the process list and look for system process names that are in the wrong place. Real svchost.exe lives in C:\Windows\System32 and is parented by services.exe. One svchost.exe is parented by explorer.exe, which means a user started it by hand. The command line pins it to the user’s Downloads folder, so this is a masquerading binary rather than a service host.
vol -f mem windows.pslistvol -f mem windows.cmdlineTip: Sort or filter on
PPID. Every legitimatesvchost.exeshares one parent, so the odd one out stands out immediately.
The Offset(V) column in windows.pslist is the virtual address of the _EPROCESS structure for the process from Q1. That is the value the task wants.
vol -f mem windows.pslist --pid 6812Gotcha:
windows.psscan --physicalalso prints an offset, but it is the physical one. The format mask is for the virtualOffset(V)value.
Hash the file as it sits on disk, not a rebuilt copy of the process. Find the Downloads\svchost.exe entry with windows.filescan, then pull its cached image section with windows.dumpfiles and run md5sum on the result.
vol -f mem windows.filescan | grep -i 'Downloads.*svchost'vol -f mem -o work/dump windows.dumpfiles --virtaddr <file object address from filescan>md5sum work/dump/*ImageSectionObject*svchost.exe*Gotcha:
windows.pslist --pid 6812 --dumpwrites a PE that Volatility reconstructs from process memory. Its MD5 differs from the file on disk and VirusTotal will not know it. Use theImageSectionObjectfromdumpfiles.
Search the Q3 hash on VirusTotal and read the History section’s first submission, then reformat it to the requested layout. The API reports the same value as an epoch (first_submission_date), which date -u converts.
date -u -d @1691668690 '+%d/%m/%Y %H:%M:%S'Gotcha: The hash has to be the on-disk file from Q3. The hash of the Volatility-reconstructed PE exists on VirusTotal too, with a much later first submission, and it is the wrong sample.
From Q1 we have the parent PID. Filter the process list for entries whose PPID is that value. A single cmd.exe hangs off the fake svchost.exe, which is the shell the operator used to run commands.
vol -f mem windows.pslist | awk '$3 == 6812'Two artifacts give the same second. windows.pslist shows the CreateTime of the process from Q1, and windows.netscan shows when its connection object was created. The process started and called out immediately, so one timestamp answers both halves of the question.
vol -f mem windows.pslist --pid 6812vol -f mem windows.netscan | grep 6812Tip: Volatility prints
YYYY-MM-DD HH:MM:SS. The answer mask isDD/MM/YYYY, so swap the date fields.
Run windows.netscan and filter on the Q1 PID. The process holds one ESTABLISHED TCP connection to an external address on a high, non-standard port. The foreign address and port together are the sweep indicator.
vol -f mem windows.netscan | grep 6812| Phase | Action |
|---|---|
| Execution | User runs a binary named like a system process from C:\Users\simon.stark\Downloads, parented by explorer.exe |
| Command and Control | The process connects out to an external host on TCP 8888 within the same second |
| Execution | A cmd.exe child gives the operator a command shell |
| Detection | Memory image taken; the fake process is found by parent and path anomalies |
| Analysis | On-disk sample extracted from the image and hashed |
| Intel | Sample already on VirusTotal, first submitted about 28 minutes after it ran |
| Type | Value |
|---|---|
| File path | C:\Users\simon.stark\Downloads\svchost.exe |
| MD5 | 5bd547c6f5bfc4858fe62c8867acfbb5 |
| C2 | 13[.]127[.]155[.]166:8888 |
| Technique | ID | Description |
|---|---|---|
| Masquerading: Match Legitimate Name or Location | T1036.005 | Malware named svchost.exe running from Downloads |
| User Execution: Malicious File | T1204.002 | Launched by the user, with explorer.exe as parent |
| Command and Scripting Interpreter: Windows Command Shell | T1059.003 | cmd.exe child of the malicious process |
| Non-Standard Port | T1571 | C2 over TCP 8888 |
Task Manager shows names, not paths or parents. The IT team saw a normal-looking svchost.exe and moved on. Triage should compare image path and parent: any svchost.exe outside System32 or not parented by services.exe is a high-confidence detection, and EDR rules for it are cheap.
Executables running from user-writable folders deserve an alert. Nothing legitimate starts a system-named binary out of Downloads. AppLocker or WDAC path rules would have blocked it, and a Sysmon process-create rule on \Downloads\ image paths would have flagged it.
Connect-on-start is a beaconing tell. The process connected out in the same second it was created, on port 8888. Egress filtering to known ports and alerting on user-folder processes making external connections would have caught it without the SIEM’s C2 signatures.
Dump the file the right way. A process-memory reconstruction does not hash like the original file, so it will not match threat intel. Carve the cached file from the image and hash that before pivoting to VirusTotal.
The operator got a live shell on a workstation by hiding in plain sight behind a trusted process name, and only memory analysis exposed it. The tell was never the name but the path and the parent.