Windows Memory Forensics: Analyzing Process Objects

Process examination in memory forensics extends well beyond image names and parent-child relationships. Detecting stealthier malware requires exhaustive scrutiny of the broader process footprint. A single process may reference hundreds of associated kernel objects; the theoretical per-process ceiling on kernel handles stands at $2^{24}$ (16 777 216), although practical ceilings are constrained by paged-pool availability and fall lower still on 32-bit platforms, leaving a potentially enormous set of artifacts for review. Discovery of an anomalous object within that set supplies critical context for assessing the trustworthiness of the process under examination. The following classes of artifacts merit systematic enumeration:

• Dynamically linked libraries: These modules define process capabilities. A requirement for HTTP communication, for example, typically results in the loading of wininet.dll. Malware frequently injects or maps its own malicious libraries to subvert an otherwise legitimate process.
• Handles: Each handle is a process-specific pointer into a kernel object. Of particular forensic value are:
  • File handles, which reveal the specific filesystem objects or I/O devices currently accessed.
  • Directory handles, which refer not to filesystem directories but to object-manager namespace directories (for example, KnownDlls, BaseNamedObjects, Callbacks, Device, and Drivers) that enable location of other kernel objects.
  • Registry handles, which identify keys under active read or write operations.
  • Mutex (kernel mutant) and semaphore handles, which enforce exclusive or limited access to resources; worms commonly create named mutexes as infection markers to prevent reinfection.
  • Event handles, which facilitate inter-thread signaling and occasionally appear with distinctive names or patterns characteristic of malicious tradecraft.
• Threads: A process functions primarily as a container; the threads it hosts perform the actual work and interact with the objects listed above.
• Memory sections: Every process maintains a collection of virtual-address ranges that hold mapped DLLs and files together with code and data. The Virtual Address Descriptor (VAD) tree records these allocations; private executable regions lacking file backing are classic indicators of code injection or other memory-resident techniques.
• Sockets: Network endpoints remain bound to specific processes, permitting attribution of anomalous connections even when modern TCP/IP stack structures have evolved beyond earlier address-object layouts.

Although the inventory above is not exhaustive, systematic review of these objects routinely surfaces the subtle indicators required to unmask advanced malware that would otherwise remain concealed behind benign image names and parentage.

By this stage in your examination, preliminary triage has typically already flagged one or more processes of interest. While image name, parentage, and creation timestamp may generate an initial suspicion of malice, forensic confidence demands far richer evidentiary grounding. Process-object analysis therefore entails a systematic descent into each candidate’s internal architecture, enumerating and evaluating its constituent artifacts. Volatility supplies an extensive suite of plugins for this purpose; the subset selected here prioritizes maximal diagnostic yield.

The windows.dlllist plugin enumerates modules mapped into a process address space. In Volatility 2, the same plugin also provided the process command line as ancillary output; that responsibility has since migrated to the dedicated windows.cmdline plugin. Complementary coverage is furnished by windows.getsids, which recovers the security identifiers (SIDs) attached to each process token, and by windows.handles, which surfaces the full spectrum of kernel objects—files, registry keys, mutants, events, and others—currently referenced by the process.

Analyze Process Objects: windows.dlllist.DllList

Windows processes depend heavily on mapped libraries to execute their intended operations. Enumeration of those libraries yields direct insight into process behavior and simultaneously serves as a high-value detection surface for maliciously injected modules. Each process maintains a Process Environment Block (PEB) that records the set of loaded DLLs. The corresponding _EPROCESS structure, by contrast, allocates only a truncated buffer—commonly fifteen characters—for the image name; recovery of the complete path and the full command-line string (including parameters) therefore requires examination of the PEB. The dedicated windows.cmdline plugin extracts precisely this command-line data from the PEB, making it the logical next step whenever a process listing appears truncated.

Two principal options govern windows.dlllist usage. Because the aggregate number of loaded modules across an entire system routinely reaches into the hundreds, practical analysis focuses on a narrowed set of processes of interest. The --pid argument restricts output to one or more specified process identifiers; under Volatility 3, these identifiers are supplied space-separated (Volatility 2 employed commas). The --dump switch extracts the modules themselves for offline inspection or anti-virus scanning and may be combined with --pid to constrain scope. Paging frequently impedes successful extraction, rendering portions of the process address space—or even critical PE headers—unavailable. Volatility 3 supplies the --single-swap-locations option to incorporate a pagefile.sys as an additional data source, although current testing indicates the feature remains imperfect and is expected to mature in subsequent releases. When extraction from a given process fails, the same module is often resident in other processes, offering alternate recovery paths. Should those avenues also prove unproductive, the more powerful windows.dumpfiles plugin can retrieve cached file copies still resident in memory. For each module, the plugin reports:

• Base address (the location within the process virtual address space, neither a system-wide virtual nor a physical address; this value is directly consumable by plugins such as the Volatility 2 dlldump),
• Module size,
• File name and full path,
• Load timestamp (available on Windows 7 and later).

The load-time field is particularly useful for identifying modules introduced after process start—behavior that, while not inherently malicious, can surface certain code-injection techniques. Because the plugin relies exclusively on PEB-resident lists, it cannot detect reflective DLL injection or other tradecraft that deliberately avoids updating those lists. Complementary plugins such as windows.ldrmodules and windows.malfind recover additional evidence of loaded or injected code and will be examined in a future post.

Critical scrutiny of the modules themselves remains essential. An analyst well-versed in ordinary import tables will immediately recognize anomalies—for example, a calc.exe instance that has mapped HTTP libraries such as winhttp.dll or wininet.dll. A final architectural limitation appears with 32-bit (WoW64) processes: the PEB tracks only a subset of loaded modules, predominantly the WoW64 compatibility layer. For these processes, the more comprehensive windows.ldrmodules plugin, which employs multiple independent discovery methods, supplies a fuller inventory.

There is no overtly malicious third-party DLL visible in this windows.dlllist output. Every entry is a legitimate Microsoft system library (except the process image itself):

• Core OS modules: ntdll.dll, kernel32.dll, USER32.dll, GDI32.dll, ADVAPI32.dll, RPCRT4.dll, MSVCRT.dll, etc.
• Supporting modules: SHELL32.dll, SHLWAPI.dll, ole32.dll, IMM32.DLL, USP10.dll, uxtheme.dll, etc.
• Cryptographic provider: rsaenh.dll (Microsoft Enhanced Cryptographic Provider)—commonly loaded by any process that performs strong encryption/decryption. Ransomware uses it, but the DLL itself is not malicious.
• Side-by-side assembly: comctl32.dll from the expected WinSxS path.
• All paths point to C:\WINDOWS\system32\ or the legitimate WinSxS directory. None are loaded from the suspicious C:\Intel\ivecuqmanpnirkt615\ folder (except the main executable).

LoadCount values and the absence of LoadTime data are normal for this older Windows image. WannaCry’s primary payload typically relies on the main executable + standard system libraries (especially cryptographic ones) rather than dropping and loading additional clearly named malicious DLLs that would appear in the PEB lists. That is why the dlllist looks relatively clean.

• windows.dlllist only shows modules recorded in the PEB loader lists. It will not reveal reflective DLL injection or PEB-unlinked modules.
• For this particular process the absence of exotic DLLs does not reduce suspicion. The process name + path are already high-confidence indicators of WannaCry.

All listed modules are legitimate Microsoft system libraries. The PEB lists contain no third-party or clearly malicious DLLs. Notable functional groupings are described in the table below:

Category	DLLs	Relevance
Core OS	ntdll.dll, kernel32.dll, msvcrt.dll, ADVAPI32.dll, RPCRT4.dll, Secur32.dll	Standard process foundations
GUI / UI framework	MFC42.DLL, USER32.dll, GDI32.dll, COMCTL32.dll, uxtheme.dll, MSCTF.dll, msctfime.ime	Heavy use of Microsoft Foundation Classes and common controls consistent with a graphical ransom-note application
Rich-text display	RICHED32.DLL, RICHED20.dll, msls31.dll	Used to render the formatted ransom note
Networking / HTTP	urlmon.dll, WININET.dll, WS2_32.dll, WS2HELP.dll, iertutil.dll	Enables network operations (payment instructions, onion links, or connectivity checks)
Shell / COM	SHELL32.dll, SHLWAPI.dll, OLEAUT32.dll, ole32.dll	Shell integration and COM support
Other	MSVCP60.dll, IMM32.DLL, LPK.DLL, USP10.dll, USERENV.dll, Normaliz.dll	Supporting runtime and localization libraries

LoadCount values are mostly -1 (early/static loads). LoadTime is unavailable (typical for this older Windows image). No modules were dumped (File output = Disabled).

• No “evil DLL” appears in the list. Like the earlier tasksche.exe process, WannaCry relies primarily on its own executable plus standard system libraries.
• The presence of MFC42 + rich-edit controls + networking DLLs strongly matches the expected behavior of the WannaCry decryptor GUI (displays the ransom note and may attempt network activity).
• The path and filename alone are high-confidence indicators of compromise.

Analyze Process Objects: windows.cmdline.CmdLine

Full path and command-line artifacts supply substantially richer context for anomaly detection than truncated image names alone. Volatility exposes this data through the dedicated windows.cmdline plugin, which recovers the complete command line directly from each process’s Process Environment Block (PEB). As previously noted, the _EPROCESS structure allocates only a short fixed buffer—commonly fifteen characters—for the image name; recovery of the untruncated path and arguments therefore requires examination of the PEB.

Output from this plugin forms a high-value hunting surface. Analysts should scrutinize results for anomalous executable names, atypical storage or execution directories, and malformed argument strings on otherwise legitimate system binaries. The SANS “Hunt Evil” poster remains an effective reference for expected command-line patterns of common Windows processes. Practical triage is aided by piping results through grep or by rendering the plugin in CSV format (-r csv) and importing the data into Timeline Explorer for rapid filtering and correlation.

A significant limitation remains: PEB contents are frequently unavailable once a process has terminated. In such cases, windows.psscan may still recover residual _EPROCESS structures, yet the full image path and command-line arguments—residing exclusively in the missing PEB—will be inaccessible.

The process with PID 1940 (tasksche.exe) was launched with no additional command-line arguments—only the full path to itself. The path matches exactly what windows.dlllist already showed: the executable is running from the randomly named directory C:\Intel\ivecuqmanpnirkt615\. The absence of extra arguments is typical; the malware usually relies on its internal logic and configuration rather than command-line switches once executed.

The process with PID 740 was started with a short name only (@WanaDecryptor@.exe), not the full path. This is different from the earlier tasksche.exe (PID 1940), which showed the complete path in its command line. This matches known WannaCry behavior: @WanaDecryptor@.exe is the graphical ransom-note/decryptor interface. It is typically launched by tasksche.exe (or a related component) from the same random drop directory (C:\Intel\ivecuqmanpnirkt615\). The short command-line form is common when a process is started via CreateProcess or similar, using just the executable name while the current working directory is already set to the malware’s folder.

Cobalt Strike Sacrificial Processes

Execution of exploit code or payloads through an active implant carries an inherent risk of process termination. Loss of that implant can sever access to an entire enterprise environment, which explains the frequent deployment of multiple concurrent backdoors during intrusions. As a defensive measure against catastrophic failure of a primary process, malware authors have adopted a technique originally refined in Microsoft tooling: the sacrificial process. Cobalt Strike’s Beacon implant relies extensively on this pattern to preserve operational continuity. The framework’s reputation for reliability and modularity stems in large part from this architectural choice and has contributed to its status as one of the most widely employed offensive platforms.

A sacrificial process is created as a short-lived child whose sole purpose is to host potentially unstable or detectable code. Beyond shielding the parent implant, the technique yields several operational advantages: it permits seamless selection of 32-bit or 64-bit execution contexts simply by spawning the appropriate architecture, supplies a disposable injection target, simplifies lateral movement of code across processes or hosts, and enables granular cleanup by terminating discrete child processes once their tasks conclude.

In memory analysis, these child processes frequently appear anomalous, especially given Cobalt Strike’s heavy reliance on PowerShell. A canonical pattern consists of powershell.exe spawning multiple instances of rundll32.exe. Regarding the choice of rundll32.exe, Cobalt Strike’s author Raphael Mudge observed that the specific binary is largely arbitrary; once selected as a default, it becomes a detectable signature because operators rarely modify framework defaults. Even when the default is altered, the resulting activity remains conspicuous: no legitimate Windows process routinely spawns multiple copies of itself beneath a PowerShell parent.

Closer inspection of these children routinely reveals further irregularities in command-line arguments, security identifiers, and network connections. Such artifacts illustrate how a detailed understanding of a tool’s internal mechanics converts otherwise opaque activity into high-confidence detection opportunities.

The Volatility 3 windows.cmdline plugin is applied here to examine PID 7100. This process attracted attention both because it appeared as an orphan and because rundll32.exe is a frequently abused binary. Inspection of the recovered command line immediately reveals a critical omission: rundll32.exe exists to load and execute code contained within a DLL, so a legitimate invocation must include at least the target module (and typically an exported function). The complete absence of any arguments renders this instance highly anomalous and consistent with a sacrificial process.

The logical next action is therefore to acquire a full process memory dump to identify the actual payload executing inside the process. It should be noted that rundll32.exe is merely Cobalt Strike’s default sacrificial host. Operators can readily substitute an alternative binary by modifying the framework’s artifact kit or malleable C2 profile. The figure above demonstrates the minimal configuration change required to replace the host with svchost.exe. In practice, however, virtually any substituted process will still exhibit behavioral or contextual irregularities that remain conspicuous to an analyst trained in memory forensics.

Analyze Process Objects: windows.getsids.GetSIDs 

Every process receives an access token inherited from the security context of the account that created it. An access token is an object containing a set of security identifiers (SIDs) that encode the user’s identity, group memberships, and assigned privileges. Systematic examination of these tokens enables both the detection of anomalous processes and the correlation of activity performed under the same compromised account.

Core system processes ordinarily operate under well-known system SIDs. Microsoft maintains authoritative documentation of these identifiers. A representative token recovered from a legitimate lsass.exe instance might appear as follows:

PID  Process    SID                          Name
700  lsass.exe  S-1-5-18                     Local System
700  lsass.exe  S-1-5-32-544                 Administrators
700  lsass.exe  S-1-1-0                      Everyone
700  lsass.exe  S-1-5-11                     Authenticated Users
700  lsass.exe  S-1-16-16384                 System Mandatory Level

The primary token (S-1-5-18) confirms that the process was started under the Local System account; the remaining SIDs reflect standard group memberships. This configuration is expected. Observation of the same process running under a user-level SID, however, is highly irregular:

556  lsass.exe  S-1-5-21-4251235867-3156790139-409172211-1001  Steve.Rogers

User SIDs are assigned exclusively to processes launched in a user context and should never appear on foundational system binaries such as lsass.exe.

Microsoft describes the mechanism as follows: "An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account associated with the process or thread. When a user logs on, the system verifies the user's password by comparing it with information stored in a security database. If the password is authenticated, the system produces an access token. Every process executed on behalf of this user has a copy of this access token".The Microsoft article “How Access Tokens Work” remains a definitive technical reference on token construction and evaluation.

The windows.getsids plugin attempts to resolve in-memory registry hives so that recovered account SIDs can be mapped to their corresponding account names. When the resolution succeeds, the account name appears alongside each SID (as illustrated in the preceding example). Resolution can fail, however, when the necessary hive data is unavailable or incomplete. In such instances, the analyst may perform the mapping offline by consulting the SAM or SOFTWARE hives extracted from the subject system.

Understanding Security Identifiers (SIDs) 

Security Identifiers (SIDs) are immutable values assigned by Windows systems and domain controllers to security principals. Internally, the operating system relies on these identifiers to locate specific accounts and to evaluate the privileges and access rights associated with them. SIDs are unique within a given Windows instance; domain SIDs remain unique across an entire enterprise.

In memory forensics, SID data is most frequently examined in the context of a running process. Every process carries an access token that embeds the user-account SID, the SIDs of every group to which that account belongs (including its primary group), and the privileges and discretionary access control lists (ACLs) tied to the account. Most critically, the token reveals the precise user context under which the process was launched. Group membership information further illuminates the effective permissions of that account—for example, whether it holds Domain Administrator rights or belongs to the Remote Desktop Users group.

The majority of core Windows system processes are started under built-in accounts. These accounts possess well-known SIDs that differ markedly in structure from ordinary user SIDs. The three most frequently observed system SIDs—LocalSystem, LocalService, and NetworkService—are documented by Microsoft, as are the well-known SIDs assigned to common groups. Observation of a longer, domain-style SID on a process indicates that a user account was responsible for its creation. Such a SID is expected on a browser such as Chrome.exe; its presence on a service host such as Svchost.exe is anomalous. A user SID is decomposed below for analytic clarity:

S-1-5-21-1004336348-1176238915-682003330-1004

• S – Marks the string as a SID.
• 1 – Revision level (still the original revision).
• 5 – Identifier authority; the value 5 denotes the most common issuing authority (NT Authority). Other authorities, such as World Authority (1) or Creator Authority (3), appear only rarely.
• 21-1004336348-1176238915-682003330 – Domain identifier unique to the domain that owns the account. Every domain within an enterprise receives a distinct identifier, and every domain account SID incorporates this value.
• 1004 – Relative identifier (RID) that uniquely distinguishes the account inside its domain.

The combination of domain identifier and RID is the value Windows uses to reference a specific user account. SIDs appear throughout Windows artifacts and are routinely encountered during forensic examinations of the Registry, event logs, and process tokens.

Both processes share an identical access token, confirming they were launched under the same user context.

SID	Resolved Name	Significance
S-1-5-21-602162358-764733703-1957994488-1003	donny	Primary user account SID (RID 1003)
S-1-5-21-602162358-764733703-1957994488-513	Domain Users	Standard domain group membership
S-1-5-32-544	Administrators	Elevated privileges (local Administrators group)
S-1-5-32-545	Users	Standard Users group
S-1-1-0	Everyone	World SID
S-1-5-4	Interactive	Logon type indicator
S-1-5-11	Authenticated Users	Authenticated principal
S-1-5-5-0-39677	Logon Session	Specific logon session identifier
S-1-2-0	Local	Local logon capability

Forensic significance

• Same compromised account: Both tasksche.exe (PID 1940) and @WanaDecryptor@.exe (PID 740) are running as the domain user donny. This strongly links the two processes as components of the same infection.
• Administrative rights: Membership in the Administrators group (S-1-5-32-544) indicates the malware is executing with elevated privileges—typical for WannaCry, which requires such rights to encrypt files across the system and perform other high-impact actions.
• Not a system account: Neither process is running as Local System (S-1-5-18), Local Service, or Network Service. Instead, they inherit a full interactive user token, which is expected when ransomware is launched from a user session (or after privilege escalation into that session).
• Domain context: The domain SID prefix (S-1-5-21-602162358-764733703-1957994488) shows the account belongs to a domain rather than a purely local machine account.

Analyze Process Objects: windows.handles.Handles

Handles represent critical process objects during memory analysis, yet their sheer volume often renders them secondary indicators rather than primary detection vectors. In the majority of cases, they are examined only after a process has already been flagged as suspicious. When applied in this confirmatory role, they prove highly effective for validating suspicions, differentiating malware families, and uncovering additional artifacts worthy of further investigation.

By default, the windows.handles.Handles plugin enumerates every open handle across all recoverable processes. The --pid parameter usefully restricts output to a targeted subset of processes of interest. Although numerous handle types exist, only a limited set routinely yields investigative value. File and registry handles are especially productive, frequently directing examiners toward secondary artifacts that support pivoting. Specialized handle classes such as named pipes and mutants will also be examined in this section.

The process handle table frequently contains substantial volumes of low-value data, making systematic filtering essential. Unnamed handles, for example, are typically created and consumed solely within the process itself and therefore hold little forensic interest. Volatility 2 provided a dedicated switch (-s) to suppress them; under Volatility 3, the same result is achieved in post-processing by discarding rows that contain an empty “Name” field. Filtering may be performed either on the command line with conventional utilities such as grep and awk or by rendering the plugin output in CSV format (-r csv) for subsequent analysis in external tools.

Handle table for PID 1940

Handle table for PID 740

Both processes share the same drop directory, the same user context (“donny”), and many of the same system objects. The handle tables supply strong corroborating evidence that they belong to the same infection.

Artifact	PID 1940 (tasksche.exe)	PID 740 (@WanaDecryptor@)	Significance
Drop-directory file handle	\Device\HarddiskVolume1\Intel\ivecuqmanpnirkt615	Same path	Both processes hold an open handle to the random WannaCry installation folder.
User registry hive	USER\S-1-5-21-...-1003	Same SID (+ _CLASSES variant)	Confirms both run under the elevated domain account donny.
BaseNamedObjects / KnownDlls	Present	Present	Standard object-manager directories.
ShimCacheMutex / ShimSharedMemory	Present	Present	Common Application Compatibility objects.
WinSta0 / Default Desktop	Present	Present	Expected for any process with UI interaction.

Notable differences

PID 1940 (tasksche.exe) – Orchestrator / dropper

• Holds the classic MsWinZonesCacheCounterMutexA / MsWinZonesCacheCounterMutexA0 mutants (frequently seen with WannaCry and IE-zone activity).
• Fewer CTF / Text Services Framework (MSCTF) mutants.
• Simpler set of registry handles focused on the user hive and MACHINE.

PID 740 (@WanaDecryptor@) – Ransom-note GUI

• Extensive CTF / MSCTF mutants and sections (CTF.TimListCache..., CTF.Compart.Mutex..., MSCTF.Shared.MUTEX..., etc.). These are characteristic of a process that loads the Text Services Framework (common in GUI applications that handle rich text or input methods).
• Additional Internet Explorer / zone-related registry keys (FEATURE_PROTOCOL_LOCKDOWN, Internet Settings).
• Winsock2 catalog keys (PROTOCOL_CATALOG9, NAMESPACE_CATALOG5) — consistent with the networking DLLs previously observed in its dlllist.
• Self-referential process handle (@WanaDecryptor@ Pid 740).
• More WMI-related handles (WMIDataDevice, WmiGuid).

The handle tables reinforce the earlier conclusions:

1. Both processes are actively interacting with the same randomly named drop directory under C:\Intel\.
2. Both inherit the elevated token of the domain user donny.
3. The GUI process (@WanaDecryptor@) shows the expected richer set of UI, text-services, and networking handles, while the orchestrator (tasksche.exe) remains leaner.

No uniquely named “WannaCry marker” mutex (such as the well-known Global\MsWinZonesCacheCounterMutexA variants beyond what is already visible) stands out as a sole indicator, but the combination of path interaction + shared elevated user context + process names is already definitive. When reviewing handle tables for suspected ransomware, prioritize:

• File handles pointing at unusual directories,
• Registry handles tied to the same user SID recovered by getsids,
• Named mutants that appear in both processes or match known malware families.

These two tables supply exactly that corroboration.

Once processes of interest have been identified, the subsequent investigative step is a detailed examination of their associated objects. Handles in particular supply valuable contextual insight into process behavior. The figure below is drawn from a system compromised by SolarMarker (also known as Jupyter), an information stealer that targets stored browser credentials, credit-card data, and cryptocurrency wallets. SolarMarker employs multiple defense-evasion techniques, rendering it a useful case study.

Consider the selection of powershell.exe (PID 5352) and msiexec.exe (PID 6192) as candidates for closer scrutiny—both binaries are routinely abused in living-off-the-land attacks. Experience quickly teaches that PowerShell processes frequently maintain extensive handle tables; in this instance, PID 5352 held 724 handles. After discarding unnamed entries and restricting attention to file and registry-key handles, the set contracted to 140. Even then, the randomly named registry key highlighted in the image is easily overlooked. It blends into the surrounding noise and requires familiarity with the expected structure of the CLASSES key to recognize its anomaly. When that key is correctly identified, however, it reveals the malware’s persistence mechanism: a series of randomly named registry keys used to store scripts and data. This fileless technique has become increasingly common, making atypical key names a high-priority hunting target.

The anomalous handle belonging to msiexec.exe (PID 6192) is more readily apparent. The process maintained only sixteen file handles; given that msiexec.exe exists to install .msi packages, the presence of a handle referencing flash_installer.msi immediately indicates the package that was executed. Both the filename and its storage location proved significant and ultimately permitted recovery of the original infection vector.

Analyze Process Objects: Named Pipes & Cobalt Strike

Named pipes form a core communication channel in a wide range of advanced offensive frameworks. Tools such as PsExec, Metasploit, TrickBot, HyperStack, Empire, Covenant, and Cobalt Strike routinely use named pipes to enable inter-process or remote communication while reducing overhead and the likelihood of detection by conventional network monitoring. Because pipe traffic does not appear in the output of utilities such as netstat, it offers a quieter alternative to opening an explicit network socket over SMB.

Pipe names are arbitrary and therefore frequently difficult to distinguish from legitimate activity. Occasional naming conventions, however, leave detectable traces—for example, the inclusion of IP addresses or process identifiers. PsExec characteristically embeds identifiable markers, producing names of the form \Device\NamedPipe\psexecsvc-<hostname>-<PID>-stdout. Many frameworks retain fixed default pipe names that serve as reliable indicators of compromise. Cobalt Strike, in particular, ships with the following defaults (several of which, such as postex_ssh and msagent, are immediately conspicuous to an experienced examiner):

• MSSE-####-server
• msagent_##
• status_##
• postex_ssh_####
• \\.\pipe\####### (seven to ten random characters)
• postex_####

Although these names can be altered through malleable profiles or artifact-kit modifications, operators frequently leave the defaults intact. Once a Beacon binary has been recovered, its embedded pipe strings can be extracted and used as additional hunting signatures across the estate.

The figure below depicts a Cobalt Strike deployment that retained the stock pipe names; the string MSSE-####-server appears in both the System process and a PowerShell instance, rendering identification straightforward. Within Volatility, named pipes surface as File-type handles. Consequently, analysts can usefully restrict handle output to the File type (or post-filter with grep for the substring “pipe”) when hunting for these artifacts.

In our wcry.raw memory dump, the resulting list is dominated by legitimate Windows system pipes. No Cobalt Strike defaults (MSSE-####-server, postex_####, msagent_##, etc.), no PsExec-style pipes, and no other classic offensive-framework pipe names appear.

The dump contains no suspicious or attacker-controlled named pipes. WannaCry itself does not rely on named pipes for its core C2 or propagation; it primarily uses SMB (EternalBlue/DoublePulsar) and its own encryptor components. The earlier processes of interest (tasksche.exe PID 1940 and @WanaDecryptor@.exe PID 740) do not appear in this filtered list, confirming they hold no named-pipe handles of interest.

Analyze Process Objects: Mutants 

Mutants (also termed mutexes) appear as another class of object within a process handle table. Their legitimate function is to serialize access to a shared resource, ensuring that only one thread or process may hold the resource at any moment. Malware, however, rarely employs them for synchronization. Instead, adversaries create named mutants as infection markers: the presence of a specific mutant signals that the host has already been compromised, allowing subsequent instances of the malware to abort and thereby avoid reinfection.

Because a mutant name must be unique to serve this purpose, the string itself becomes a high-fidelity indicator of compromise. Reverse-engineering a sample typically reveals the exact name that is created and tested. Two well-documented illustrations are the destructive ransomware WannaCry (discussed in previous sections of this post), which employs the mutant pair MsWinZonesCacheCounterMutexA/A0, and the point-of-sale scraper BlackPOS, which uses nUndsa8301nskal.

In the above example, a mutant named Mtx was recovered from the previously flagged process PID 2164. Open-source reporting associates this exact name with the CozyDuke remote-access tool, simultaneously confirming the malicious nature of the process and identifying the responsible malware family.

It is important to recognize that an examiner will seldom isolate a malicious mutant by simple visual inspection of a handle list; names are arbitrary and frequently chosen to appear benign. The practical workflow is the reverse: once a sample has been analyzed and its mutant signature extracted, that signature can be used—manually or through automated IOC scanners—to locate additional compromised hosts rapidly.