A chain ransomware attack is hitting multiple companies internationally. The decryption key has already been retrieved — but the job isn't done. A thorough post-incident analysis is required to understand the full scope of the compromise, attacker TTPs, and persistence mechanisms.
We've been handed a raw memory dump from an infected Windows machine. Our mission: reconstruct exactly what happened inside this machine's RAM, identify the malicious process, trace its lineage, and surface all indicators of compromise.
The date is significant — May 12, 2017 is the exact date the WannaCry global outbreak began. This isn't coincidence. This is ground zero.
We start with the two foundational process listing plugins. pslist walks the active process linked list — which can be manipulated by malware. psscan scans raw memory for EPROCESS structures, surfacing processes that may be hiding from the standard list.
@WanaDecryptor@ — the name alone is a dead giveaway. This is the WannaCry ransomware payload masquerading under its own decryptor UI. PID 740, parent PID 1940.
Here's where it gets interesting. psscan revealed that the same process @WanaDecryptor@ was also running under PID 424 and PID 576 — but these were hidden from pslist. This is a classic DKOM (Direct Kernel Object Manipulation) evasion technique.
With PID 740 confirmed as our target, we use the dlllist plugin filtered on that PID to enumerate every loaded DLL and locate the main binary on disk.
C:\Intel\ivecuqmanpnirkt615\@WanaDecryptor@.exeC:\Intel\ is a well-known WannaCry staging location. The randomized subdirectory name (ivecuqmanpnirkt615) is generated per-infection to evade static detection.
Knowing the parent PID is 1940, we use pstree to visualize the full process hierarchy and identify who spawned the ransomware.
tasksche.exe is WannaCry's task scheduler component — it's the orchestrator that manages file encryption tasks and spawns the decryptor UI. Its presence as the parent process confirms the infection chain is fully established.
Notably, tasksche.exe itself spawned from explorer.exe, which suggests the initial infection vector likely involved user interaction — possibly executing a malicious file dropped via the EternalBlue exploit, which then injected into or launched from the Explorer context.
We dump the process memory for PID 740, generate a SHA256 hash, and look it up on VirusTotal. Matching our previous indicators (DLL load pattern, binary path, process name) confirms our identification.
Going back to the DLL list for PID 740 and cross-referencing each library reveals something key: ws2_32.dll (the Windows Socket API) was loaded by the decryptor process.
ws2_32.dll handles socket operations — raw TCP/UDP. A ransomware "decryptor UI" has no legitimate reason to need socket access. This indicates the process was performing network communication, consistent with WannaCry's known C2 check-in and lateral movement via SMB/EternalBlue propagation.
The final step: running the windows.handles plugin against the parent process tasksche.exe to enumerate all kernel objects it holds — files, registry keys, events, and critically, mutexes.
| Indicator | Value | Type | Confidence |
|---|---|---|---|
| Malicious Process | @WanaDecryptor | Process | HIGH |
| Process IDs | 740, 424, 576 | PID | HIGH |
| Binary Path | C:\Intel\ivecuqmanpnirkt615\@WanaDecryptor@.exe | File Path | HIGH |
| Parent Process | tasksche.exe (PID 1940) | Process | HIGH |
| Mutex | MsWinZonesCacheCounterMutexA | Mutex | HIGH |
| Network DLL | ws2_32.dll loaded by decryptor | DLL | MEDIUM |
| Evasion Technique | DKOM — process hidden from pslist | TTP | HIGH |
| Infection Date | 2017-05-12 (Day 0 of global outbreak) | Timestamp | HIGH |
pslist alone would have missed PIDs 424 and 576. Always run both, diff the output. Any process visible in psscan but not pslist is a major red flag for rootkit-level evasion.
Malware families reuse mutexes across campaigns. MsWinZonesCacheCounterMutexA is documented in threat intel for WannaCry — finding it in handles output closes the case conclusively. Always check mutants/mutexes via handles -t Mutant.
A "decryptor UI" loading ws2_32.dll is behaviorally anomalous. DLL analysis isn't just about finding the binary — it's about understanding what capabilities the process had at runtime.
The process name, the path, the parent, the DLLs, the mutex — no single artifact is conclusive. Memory forensics is about layering evidence until the picture is undeniable. Each plugin is a lens; use all of them.
imageinfo / windows.info — Profile detection & system metadatapslist — Active process list (can be evaded)psscan — Pool-tag scan; catches unlinked/hidden processespstree — Visualize parent-child relationshipsdlllist -p [PID] — Enumerate loaded DLLs + binary pathmemdump -p [PID] — Dump process memory for hashing/AV scanhandles -p [PID] -t Mutant — Extract mutexes from process handles