When attackers chain Cobalt Strike through trusted utilities such as MSBuild or rundll32, the malicious code often runs inside the memory space of a legitimate process. That makes sandboxing, allowlisting, and process-based triage much less reliable. Incident responders need to treat trusted binaries as possible launch points and inspect the full execution chain, not just the initial file.
What the technique changes in practice
When Cobalt Strike is launched through a trusted utility such as MSBuild or rundll32, the important change is not the payload itself but the execution path. The malicious activity inherits the legitimacy of a signed or commonly used binary, which can reduce friction in application control, blur process lineage, and make simple parent-child process checks less reliable. That is why defenders need to inspect the chain, not just the visible executable.
Once the payload is running in the context of a legitimate process, routine triage can miss the difference between normal admin activity and covert tradecraft. The process name may look harmless, while command-line arguments, script content, module loads, or unusual network behaviour reveal the abuse. This is a classic living-off-the-land problem: the trusted tool is the delivery mechanism, not evidence of trustworthiness.
For responders, the practical implication is that “allowed binary” cannot be treated as a safe endpoint. A legitimate loader may simply be the first stage in a broader intrusion path, which means the full execution graph, memory activity, and spawned child processes matter more than the initial file hash or allowlist status.
Why this defeats simple detection and triage
MSBuild and rundll32 are commonly present in enterprise environments, so their presence alone does not signal abuse. Attackers benefit from that ambiguity because many control stacks assume that trusted binaries are low-risk, especially when they are signed, preinstalled, or widely used by administrators. If detection is focused only on “unknown executable” alerts, this style of execution can blend into normal operations.
A second problem is visibility. Security tools that rely heavily on filename reputation, basic allowlisting, or shallow process trees may not show the original malicious source clearly enough. The payload can be injected or loaded in memory, which makes static file inspection less useful than behavioural inspection. This is why incident teams should correlate process creation, script interpreter activity, child process spawning, and outbound connections before concluding that the process is benign.
Because the technique abuses trusted software rather than replacing it, the defensive question becomes: what changed in the process behaviour, not what binary name appeared first. That is the key distinction that keeps analysts from dismissing an active compromise as ordinary system administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1218 — System Binary Proxy Execution | MSBuild and rundll32 are trusted binaries abused to execute malicious code. |
| Recommendation — Map sightings to T1218 and hunt for execution chains that abuse trusted binaries. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | The technique is detected through process, command-line, and memory-behaviour monitoring. |
| DE.AE — Anomalies and Events | Abuse is exposed by abnormal parent-child relationships and execution anomalies. | |
| Recommendation — Monitor process ancestry and behaviour for legitimate binaries executing suspicious payloads. Triage abnormal process trees and command patterns as potential compromise indicators. | ||
| CIS Controls v8 | 8 — Audit Log Management | Process creation, script, and network telemetry are needed to reconstruct the chain. |
| 9 — Email and Web Browser Protections | Delivered payloads often enter through user execution paths that require defensive scrutiny. | |
| Recommendation — Collect and retain process and command-line telemetry for trusted-binary abuse investigations. Block or inspect suspicious delivery paths that rely on user-triggered content execution. | ||
Practitioner Guidance
What to verify: Validate the full command line, parent process, module loads, and network destinations for any instance of MSBuild or rundll32 that appears in a suspicious chain. If the binary launched scripts, fetched content, or spawned unusual children, treat it as an investigative lead even if the file itself is legitimate.
What practitioners underestimate: Many teams over-trust process reputation and under-trust process context. The meaningful signal is often the execution pattern around the trusted binary, especially when the same host shows staging activity, encoded commands, or memory-resident behaviour that does not match normal administrative use.
Practitioner takeaway: The safest response is to treat trusted binaries as potential launch points for hostile activity until the surrounding chain proves otherwise.
Related resources from NHI Mgmt Group
- What happens when phishing is delivered through collaboration tools and SMS instead of email alone?
- Why do legitimate tools like form services make phishing harder to detect?
- What happens when a malicious MCP server is allowed alongside legitimate enterprise tools?
- What happens when an attacker enrolls a rogue device through a legitimate onboarding process?
