Malware Family Case Studies
Studying real malware families teaches implementation patterns that individual chapters can only describe abstractly. Each family represents a coherent engineering effort: specific architectural choices, evasion priorities, and operational constraints. This chapter dissects four representative families — Emotet (loader/botnet), Ryuk/Conti (ransomware), APT29 SUNBURST (supply chain APT), and LockBit 3.0 (ransomware-as-a-service) — focusing on the specific technical decisions and the detection implications of each.
A detection engineer is asked to build coverage for a new campaign. Threat intel reports the TTPs match Emotet loader behavior. Before building rules, you study the original Emotet codebase (analyzed samples circa 2021-2022) to understand which behaviors are family-defining versus operator-variable, so you build durable rules rather than IOC-specific ones.
Emotet — Architecture and TTPs
// Emotet bot_id computation (approximation from decompiled samples):
// bot_id = MD5(hardware_profile) where hardware_profile = volume_serial + hostname + OS_version
// Used as RC4 key prefix for C2 traffic → unique per victim, no shared key to extract
// Emotet C2 HTTP POST pattern (for proxy/IDS signature):
// POST /[2-4 random path segments] HTTP/1.1
// Host: [IP:PORT] (no SNI — direct IP, no TLS in older versions)
// Content-Length: N
// Content: RC4-encrypted binary blob, first 4 bytes = CRC key
// Detection: IP-only HTTP C2 (no domain name in Host header) is anomalous
// Combined with: regsvr32/rundll32 loading non-system DLL from %APPDATA%
Ryuk / Conti — Ransomware Chain
// RYUK (2018-2020) and CONTI (2020-2022) share codebase ancestry (Hermes ransomware)
// CONTI superseded Ryuk; both operated as ransomware-as-a-service (RaaS) with affiliates
// INFECTION CHAIN (Conti affiliate typical):
// 1. BazarLoader (initial access via phishing) → establishes beacon
// 2. Cobalt Strike (purchased or cracked) → lateral movement, AD recon
// 3. Exfil to Mega.nz or Rclone (double extortion: pay or data published)
// 4. Conti ransomware deployed domain-wide via GPO or PsExec to all hosts
// CONTI ENCRYPTOR BEHAVIOR:
// - Uses 32 worker threads with I/O completion port (like LockBit)
// - ChaCha8 per-file key (fast symmetric cipher for encryption speed)
// - RSA-4096 wraps ChaCha8 key (public key embedded in binary)
// - Prioritizes: office docs, databases, backups, VM images
// - Skips: Windows, Program Files (keep OS functional for ransom note display)
// - Deletes VSS: vssadmin delete shadows /all /quiet (via cmd, easy to detect)
// - Disables recovery: bcdedit /set {default} recoveryenabled No
// DETECTION PIVOT: Conti reconnaissance phase is loud:
// SharpHound.exe execution → BloodHound collection
// net group "Domain Admins" /domain
// nltest /domain_trusts
// adfind.exe — AD enumeration tool (almost never legitimate)
// Cobalt Strike named pipes: \\.\pipe\MSSE-*, postex_*
APT29 SUNBURST — Supply Chain Attack
// SUNBURST (2020): SolarWinds Orion platform update trojanized
// APT29 (Cozy Bear, Nobelium) inserted backdoor into legitimate SolarWinds build pipeline
// ~18,000 organizations received trojanized update; ~100 targeted for stage-2 compromise
// SUNBURST DORMANCY MECHANISM:
// - After load: check if process name is in blocklist (security vendor processes → abort)
// - Sleep 12-14 DAYS before any C2 activity (defeats sandbox analysis by time-out)
// - After dormancy: beacon to avsvmcloud[.]com via DNS CNAME chain
// subdomain = encoded victim identifier + status flags → APT29 selects targets
// PROTOCOL:
// DNS CNAME: victim_id.avsvmcloud[.]com → APT29 infrastructure
// Encoded victim_id contains: org domain hash + machine GUID hash
// C2 command: HTTP GET to seemingly legitimate Orion update URL path
// Payload: custom .NET implant "Teardrop" or Cobalt Strike
// KEY INSIGHT: SUNBURST was undetectable with standard IOC-based detection because:
// - It was signed with legitimate SolarWinds certificate (code signing)
// - It was loaded as part of legitimate Orion service (SolarWinds.Orion.Core.dll)
// - C2 domain mimicked SolarWinds telemetry (avsvmcloud.com → legitimate-looking)
// - 14-day dormancy bypassed all sandbox analysis timeouts
// - Traffic appeared as legitimate Orion product telemetry on proxy logs
// DETECTION: Only behavioral / anomaly detection worked:
// - Anomalous LDAP queries from SolarWinds Orion service account (not normal)
// - SAML token forgery (Golden SAML) — SolarWinds account generating Azure AD tokens
// - DNS queries from Orion service to unusual domains (not normal for monitoring software)
// - C2 DNS subdomain encoding: subdomain contained alphanumeric with specific bit pattern
// Sigma: detect avsvmcloud.com C2 domain (IOC-based; useful for retrospective hunting)
// title: SUNBURST C2 Domain Communication
// detection:
// selection: QueryName|contains: 'avsvmcloud'
// level: critical
LockBit 3.0 Technical Implementation
// LockBit 3.0 (Black): released June 2022; builder leaked September 2022
// Most performant ransomware encryptor as of 2022-2023 benchmarks
// 4-6 GB/min on NVMe — achieved via I/O Completion Port multithreading (ch199)
// ANTI-ANALYSIS:
// - Requires launch argument password: LockBit3.exe -pass PASSWORD
// - Without correct password: decoys, no encryption (defeats sandbox run without arg)
// - Intermixes encryption with anti-debug/anti-VM checks
// PROPAGATION (autonomous worm):
// - Enumerates network shares via WNetOpenEnum
// - SMB lateral spread via EternalBlue if MS17-010 unpatched (optional module)
// - Group Policy deployment via domain admin access
// LOCKBIT 3.0 ANTI-RECOVERY:
BOOL LockBitAntiRecovery() {
// VSS via COM (IVssBackupComponents — no vssadmin child process)
IVssBackupComponents* pVss = NULL;
CreateVssBackupComponents(&pVss);
pVss->InitializeForBackup();
IVssEnumObject* pEnum = NULL;
pVss->Query(GUID_NULL, VSS_OBJECT_NONE, VSS_OBJECT_SNAPSHOT, &pEnum);
VSS_OBJECT_PROP prop; ULONG fetched;
while (pEnum->Next(1, &prop, &fetched) == S_OK) {
LONG deleted; VSS_ID failed;
pVss->DeleteSnapshots(prop.Obj.Snap.m_SnapshotId,
VSS_OBJECT_SNAPSHOT, FALSE, &deleted, &failed);
}
// Disable Windows Recovery
WinExec("bcdedit /set {default} recoveryenabled No", SW_HIDE);
WinExec("wbadmin delete catalog -quiet", SW_HIDE);
return TRUE;
}
// LockBit 3.0 ransom note: !readme.txt dropped in every directory
// Wallpaper change: SetSystemParametersInfoW SPI_SETDESKWALLPAPER
// Victim ID: hex string derived from MAC+volume serial, embedded in ransom note URL
Family Comparison
| Family | Initial access | C2 protocol | Persistence | Key detection |
|---|---|---|---|---|
| Emotet | Malspam/maldoc, reply chain | HTTP POST to IP:port (no SNI) | Service or HKCU Run key | regsvr32 loading non-system DLL, IP-only HTTP POST |
| Conti | BazarLoader → Cobalt Strike | Cobalt Strike HTTPS | Domain-wide via GPO at ransomware phase | adfind.exe, SharpHound, ChaCha8 file encryption pattern |
| SUNBURST/APT29 | Supply chain (SolarWinds update) | DNS CNAME + HTTP GET | SolarWinds service (DLL sideload) | SAML token anomaly, anomalous Orion DNS, Golden SAML |
| LockBit 3.0 | Various (RaaS affiliates vary) | Cobalt Strike or custom | Ransomware phase not persistence-focused | VSS COM deletion, bcdedit, wallpaper change, file rename pattern |
Detection Engineering
title: Emotet — Regsvr32 or Rundll32 Loading DLL from AppData
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith:
- '\regsvr32.exe'
- '\rundll32.exe'
CommandLine|contains:
- 'AppData\Local'
- 'AppData\Roaming'
condition: selection
level: high
tags: [attack.execution, T1218.010, attack.malware.emotet]
title: Ransomware — VSS Deletion via COM (No Child Process)
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 18 # PipeConnected — COM IVssBackupComponents
PipeName|contains: 'vss'
condition: selection
level: critical
-- MDE KQL: ransomware file rename pattern (mass rename in short time)
DeviceFileEvents
| where ActionType == "FileRenamed"
| where FileName !endswith PreviousFileName // extension changed
| summarize renames=count(), extensions=makeset(extract(@"\.([^.]+)$",1,FileName),20)
by DeviceName, InitiatingProcessFileName, bin(Timestamp, 1m)
| where renames > 100
| order by renames desc
-- MDE KQL: SUNBURST retrospective hunt — DNS queries with specific subdomain entropy pattern
DeviceNetworkEvents
| where RemoteUrl endswith "avsvmcloud.com"
or RemoteUrl matches regex @"[a-z0-9]{16,32}\.avsvmcloud\.com"
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName
Q&A
The SUNBURST attack is frequently cited as a failure of detection engineering. What specific detection capability gap allowed it to persist undetected for ~9 months, and what data source enables detection of the specific technique APT29 used for privilege escalation within the compromised environments?
SUNBURST persisted for approximately nine months (March–December 2020) primarily because the predominant detection model at the time was signature-based and perimeter-focused. The trojanized SolarWinds DLL was digitally signed with a valid SolarWinds certificate — bypassing all code-signing-based trust controls and most endpoint detections. The 14-day dormancy before first C2 contact defeated every sandbox or detonation-based analysis tool, since sandboxes typically time out after minutes to hours. The C2 domain (avsvmcloud.com) was registered well before deployment and had a plausible-sounding name associated with SolarWinds telemetry, defeating domain-age and category-based filtering. Traffic volume was designed to mimic normal product telemetry. No individual behavioral indicator crossed the detection threshold on its own, and there were no signatures to match.
The underlying detection gap was the absence of identity-plane anomaly detection for service account behavior. APT29's post-exploitation technique within victim environments was Golden SAML: they extracted the Active Directory Federation Services (ADFS) token signing certificate from the compromised SolarWinds server (which had broad network access due to its monitoring role), then used that certificate to forge SAML assertions that claimed any identity — including global admin — to Azure Active Directory (now Entra ID). The forged SAML tokens appeared fully valid to Azure AD because they were signed with the legitimate ADFS signing certificate.
The data source that enables detection of Golden SAML is the Azure AD Sign-In log (now Entra ID sign-in log), specifically filtering for SAML token authentications from the ADFS source IP that claim unusually privileged roles or access applications that the originating account has never accessed before. The specific detection signal: SAML assertions that originate from the ADFS server's IP but claim identities that have not recently authenticated interactively to that ADFS server, or that access Azure management APIs and privileged applications within minutes of the ADFS sign-in. Microsoft Sentinel's UEBA baseline for this is the "anomalous ADFS authentication" detection. The lesson: identity telemetry (ADFS audit logs, Azure AD sign-in logs) was the correct data source, and it was either not collected or not analyzed with behavioral rules in most affected organizations.