Focused on generalizable principles, not specific tools or targets
Applicable to authorized red team operations & penetration testing engagements
← → arrow keys · swipe · click arrows to navigate
00
Context — Before We Start
Why Operations Fail
"Most operations aren't burned by sophisticated detection. They're burned by predictable, avoidable mistakes."
Evidence that persists after the operation ends
Tools that require perfect operator execution every single time
Infrastructure that can be traced back to the operator
C2 behavior that deviates from expected baseline traffic
Cleanup that exists as a checklist instead of being automatic
Corner-cuts taken under pressure that become permanent fixtures
THE GOAL
Build operations where failure requires an adversary to be both skilled and lucky — not merely patient.
THE STANDARD
A forensic investigator should find nothing. Not "very little." Nothing. That is the only acceptable outcome.
01
Principle 01
Separate Your Working Environment
Keep engagement data, credentials, and tooling isolated from your daily machine and from each other.
Use dedicated VMs or machines per engagement — don't mix clients or carry data between ops
Store credentials, keys, and notes in encrypted vaults, not plaintext files on the desktop
Scope creep happens at the file system level too — know exactly what data you hold for each engagement
Clean up engagement artifacts when the op ends — don't accumulate client data indefinitely
Private keys and auth material should not live in the same place as your reporting drafts
THE PRACTICAL REASON
Mixing engagement data across clients or machines creates data handling risk — and a messy incident if your laptop is lost or your VM is compromised. Clean separation protects you and the client.
COMMON FAILURE
Verbose tool output prints full paths, credentials, and target names to a terminal session that gets screenshotted, screen-recorded, or logged. What's on screen during an op is part of your data handling posture.
02
Principle 02
Cleanup Is Doctrine, Not Afterthought
Self-cleaning tools are better than tools with cleanup steps. The best evidence is evidence that was never written.
Every deployed capability should know how to remove itself completely
Automate cleanup by time window, not by file path — catches what you forgot
Persistence that removes itself after triggering leaves no investigable artifact
Run two cleanup layers: automated time-window sweep, then manual log verification
Establish a fixed cleanup cadence during persistent access — hourly, not reactive
Patch the event writer, not the event log — never-written evidence can't be recovered
KEY DISTINCTION
Cleanup by file name requires remembering what you deployed.
Cleanup by time window removes everything changed in the last N hours — including what you forgot to track.
GOLD STANDARD
Persistence fires → executes payload → deletes the trigger, the payload, the persistence mechanism, and itself. A forensic investigator finds only the process — not how it arrived.
03
Principle 03
Map EDR Coverage. Operate in the Gaps.
Study detection rules before you arrive. Know what the SOC actually alerts on — not what you assume it alerts on.
Before the engagement: read published Sigma, Elastic, and Sentinel detection rules — they tell you exactly what defenders are actively monitoring
Passively identify EDR products via C:\Windows\System32\Drivers altitude numbers — each minifilter has a registered altitude; cross-reference against known EDR drivers without running a single enumeration command
Use BOFs (Beacon Object Files) for on-host recon — executes in the implant process, no cmd.exe, no PowerShell, no cross-process injection, no detectable parent-child chain
EDR userland hooks sit in NTDLL — direct syscalls bypass the hook before it fires; the event is never generated
COM, WMI, DCOM, and named pipes are consistently less covered than standard Win32 API paths
Validate in a lab with the target EDR before running techniques on the live engagement — find what trips it before it counts
Study MITRE ATT&CK evaluation reports for the target EDR — controlled-environment testing that shows exactly which techniques were detected and which were missed; more reliable than vendor marketing
Detection Rules (Sigma/Elastic) READ BEFORE OP
EDR Userland Hooks (NTDLL) BYPASS W/ SYSCALLS
ETW Telemetry Providers KNOW WHICH ARE CONSUMED
COM / WMI / DCOM LOWER COVERAGE
BOF In-Process Execution NO PROCESS CHAIN
ALTITUDE NUMBER RECON
C:\Windows\System32\Drivers listings reveal every installed minifilter. Each has an altitude in the 3xxxx–4xxxx range. Cross-reference against public altitude databases to identify CrowdStrike, SentinelOne, Defender, etc. — passively, before running anything.
04
Principle 04
Blend Into the Environment
The less you look like an attacker, the less you'll be detected as one. The disguise must be exact, not approximate.
Match binary metadata to existing legitimate tools exactly — company name, version, internal name, all of it
Use OS-native mechanisms: COM objects, services, WMI, scheduled tasks — not novel patterns
Store data in locations that are audited less aggressively than the obvious ones
Use opaque identifiers (GUIDs, version strings) — human-readable names stand out in audits
Traffic should be indistinguishable from expected background noise on that specific network
✗No disguise — trivially identifiable
~Approximate match — fails close inspection
✓Exact metadata match — passes casual audit
✓✓OS-native mechanism — no disguise needed at all
NAMING DISCIPLINE
Registry values that look like GUIDs, services named after real Windows components, exports named after legitimate DLL entry points. The investigator's eye skips what looks familiar.
05
Principle 05
Know Your Target Before You Act
Survey before you deploy. The environment determines what you use. Blind deployment is how engagements go sideways.
Enumerate security software before deploying anything — it changes your tool selection entirely
Understand the network topology and segmentation before establishing C2 paths
Real attackers may already be present — cohabitation on client networks happens, and your activity can interact with theirs in ways that alert defenders
Look for cohabitation signals: persistence you didn't plant (scheduled tasks, services, run keys, WMI subscriptions), unexpected outbound traffic patterns, suspicious DLLs in System32
If you find live malware: don't touch it, document it, and notify the client — proceeding risks conflating your activity with a real incident
Scope what you touch: triggering real malware or disrupting a live IR investigation creates serious out-of-scope risk that no ROE covers
COHABITATION IN PRACTICE
Red teams have landed on networks actively being worked by real threat actors. If you trigger their tooling, modify shared footholds, or appear in the same logs, the client's IR team cannot distinguish your activity from the real incident. Survey before you deploy — every time.
WHAT TO LOOK FOR
Odd persistent processes · standard persistence you didn't create · C2 beacon timing patterns from unexpected binaries · modified system files · known APT IOCs in running processes or network connections.
06
Principle 06
C2 Channel Discipline
The most detectable moment is first contact. Design every aspect of your C2 around defeating that detection window.
Use channels that blend with expected traffic — OS update services, approved enterprise protocols
Sleep before the first callback — the exploit→outbound gap is the primary behavioral detection window
Use your implant's SOCKS proxy for internal network recon — traffic appears as normal user web browsing from the endpoint, not scanner or tool-shaped connections
Accessing internal resources (SharePoint, wikis, intranet portals) through SOCKS blends with legitimate user activity — no new outbound patterns created
Assign unique per-deployment identifiers — concurrent operations need deconfliction
Route traffic through legitimate host processes, not the implant binary itself — parent process matters to every EDR
Mirror the installed browser's exact user-agent in your C2 HTTP profile — post-access, check the browser version; an anomalous user-agent string is a trivial detection signal that most operators miss
SOCKS AS COVER
Lateral recon through a SOCKS proxy looks like the compromised user browsing internal apps. Direct tool connections from your implant create new, distinct traffic signatures. One of these is invisible — the other is not.
THE SLEEP PRINCIPLE
A 10-second delay before first callback is invisible to a human analyst. It defeats every behavioral sandbox that flags on an immediate post-exploit outbound connection.
07
Principle 07
Build In Fail-Safe Mechanisms
Every capability you deploy needs an exit. Build it before deployment — not after something goes wrong.
Self-destruct must be one action — not a multi-step checklist that gets done partially
Time-limit all deployments: auto-terminate after N callbacks or T hours
Cryptographically authenticate commands — an implant that responds to unauthenticated commands can be commandeered
Include an in-place upgrade path — replace running implants without touching the target manually
Beacon count self-kill: an implant that can't terminate itself becomes evidence that persists indefinitely
Exposure timers prevent capabilities from lingering past their operational window
BURN SEQUENCE PRINCIPLE
One command → implant removes its persistence, its artifacts, and itself, then confirms completion.
If the burn requires more than one operator action, it will eventually be done only partially — under pressure, the last step gets skipped.
COMMANDEERING RISK
Without cryptographic command authentication, a discovered implant can be turned and used against you. Sign every command batch. Verify before executing.
08
Principle 08
Depth Over Speed. Patience Is a Technique.
Rushing recon creates behavioral signatures. Knowing the environment better than the defenders takes time — and that time pays off.
Red teams are not penetration tests — resist the fast-compromise mentality; depth of recon directly determines quality of access
Rushing generates detectable patterns: burst API calls, irregular enumeration timing, unusual request volumes all stand out against baseline
Establish a consistent rhythm early: beacons, cleanup, and collection on a fixed cadence that blends with normal user activity
Behavioral detection looks for deviations from baseline, not just individually suspicious actions — consistency is cover
Silence is a deliberate choice, not an absence of action — idle periods should match the user's normal behavior pattern
Tune timing per target and per user account: a service account beaconing at 3am is an anomaly; a user account at 9am is not
CADENCE IN PRACTICE
Automated hourly artifact sweep + manual log verification = two independent cleanup passes. The automated pass catches everything. The manual pass confirms the automated pass worked. Neither is optional.
CONFIGURABLE BY DESIGN
Sleep durations, beacon intervals, and cleanup windows should all be operator-tunable per deployment — not hardcoded. Different targets demand different timing postures.
09
Principle 09
Layer Everything.
No single point of failure. No single point of detection. Discovery of one component reveals nothing about any other.
Deploy multiple independent persistence mechanisms — if one is found, others survive undetected
Maintain multiple C2 channels — if one is blocked, operations continue through others
Components should not know about each other — compartmentation at the tool level, not just the operator level
Internal coordination happens via local inter-process communication, not through external C2
Discovery of one component should yield zero information about any other component
Redundant mechanisms at different layers mean no single defensive action neutralizes the operation
COMPARTMENTATION IN PRACTICE
If a network driver is detected and removed, the persistence mechanism should be unaffected — and vice versa. The investigator who finds the driver learns nothing about the persistence, and nothing about C2.
THE FRAMEWORK PRINCIPLE
Components coordinate locally. The operator sees results, not component state. The framework handles redundancy; the operator handles the mission.
10
Principle 10 — Before You Touch Anything
Pre-Access OSINT
Public data shapes the entire operation. The best recon happens before you send a single packet.
LinkedIn: org chart, who runs the SOC, CISO background, recent hires on the security team — know your defenders before you meet them
Job postings reveal the stack — "Senior CrowdStrike Falcon Engineer" tells you the EDR; "Splunk architect" tells you the SIEM; MFA admin postings tell you the auth provider
GitHub, Shodan, Censys, cert transparency: leaked credentials, exposed services, subdomains, legacy infrastructure the client forgot about
Acquisitions and subsidiaries often mean less-hardened environments with full domain trust into the parent — a softer path in
Business rhythm: patch Tuesdays, fiscal year-end, product launches — all change defender attention and on-call capacity
Study published Sigma, Elastic, and Sentinel detection rules before the engagement — they tell you exactly what the SOC is alerting on
Identify cloud sync services in use (OneDrive, Dropbox, Box) from job postings and LinkedIn — categorized, trusted domains that blend data movement with normal user activity
JOB POSTING RECON
"Senior CrowdStrike Falcon Engineer — must tune exclusions and manage policies" tells you: Falcon is deployed, actively managed, and has exclusions. "No prior EDR experience required" tells the opposite. All from a public listing.
LAB VALIDATION
Once you know the target EDR from OSINT, spin it up in a lab. Test your full toolchain before it runs on the engagement. A technique that trips CrowdStrike in the lab will trip it live — find out before it counts.
11
Principle 11 — Once You're In
Post-Access: Read the Environment
Every compromised host is an intelligence platform. Passive local recon gives you the full map before you move.
Driver altitudes (C:\Windows\System32\Drivers) — passively identifies EDR, AV, and security tooling without triggering any enumeration rules
PowerShell history and installed developer tooling (WSL, cloud CLIs, VCS clients, key/config files in home dirs) — reveals what this user can reach and maps lateral movement candidates
Browser bookmarks and history — maps internal resources: intranets, wikis, employee lookup portals, IT systems. Rarely monitored, extremely high signal
Communication app data (chat, email, calendar clients) — IT threads, password reset flows, MFA enrollment emails, active IR discussions. Local app caches persist even after session timeout
Help desk and ticketing systems accessed via SOCKS — service tickets often contain credentials, network diagrams, and infrastructure detail in plain text under the user's existing session
DNS cache — passive network map of what this host has recently talked to; reveals internal infrastructure without any active scanning
Honey documents and canary tokens — identify defensive traps before touching them; isolate suspicious files in a VM before opening
SOCKS FOR INTERNAL BROWSING
Use implant SOCKS to access SharePoint, Confluence, wikis, and intranet portals through the user's existing session. Traffic looks like normal user web activity — not tool traffic, not scanner traffic. Internal documentation often contains network diagrams, credentials, and infrastructure details that no enumeration script will find.
POST-RECON DECISION POINTS
Before moving: Is escalation worth the risk here, or is lateral movement quieter? Should C2 stay on this host or relocate? What pretext opportunities has this host revealed? Outlook metadata and Slack history answer all three.
12
Principle 12 — Cloud-Joined & Hybrid Environments
Cloud & Identity Reconnaissance
Modern environments authenticate through cloud identity layers. Understand the token infrastructure before touching anything.
PRTs (Primary Refresh Tokens) live in browser processes and LSASS on cloud-joined and hybrid hosts — extract them for seamless access to all Azure-integrated services without re-authenticating
Bearer tokens cached by desktop apps can be replayed directly — no password, no MFA prompt, no phishing required once you have the token
Microsoft Graph API reveals org structure, group membership, conditional access policies, and registered devices — available to any authenticated user, no admin privilege required
Cloud sync services as exfil staging — OneDrive, SharePoint, and similar are trusted, categorized domains; data transiting them is indistinguishable from normal sync activity
Determine if the host is cloud-joined, hybrid, or on-prem only early — this determines which token types are present and which attack paths are available
Azure AD / Entra ID audit logs have limited visibility into token reuse — authenticated API calls with a valid Bearer token often generate no SIEM alert
TOKEN REUSE PATH
Cloud-joined host → extract tokens from browser/app cache → request access to Graph, SharePoint, Teams, Exchange → full org recon under the existing user identity. Defender sees normal authenticated API calls, not exploitation activity.
GRAPH AS RECON
A standard user token can enumerate all users, groups, roles, device registrations, and conditional access policies via Graph API. No elevated privilege. No LDAP queries. No AD traffic. All HTTPS to microsoft.com — indistinguishable from legitimate app behavior.
13
Principle 13
Stay Hidden From EDR Telemetry
EDR visibility depends on telemetry pipelines. Understand those pipelines and you understand what gets seen — and what doesn't.
EDRs consume ETW (Event Tracing for Windows) providers — patching specific providers removes that telemetry from the EDR's view entirely
Direct syscalls bypass userland API hooks that EDR places on NTDLL — the hook never fires, the event is never generated
Timestamp matching at install time prevents filesystem timeline anomalies that DFIR investigators anchor on
Self-erasing persistence leaves no artifact for EDR to find after the trigger fires
Cleanup by time window is more robust than cleanup by filename — catches what you forgot to track
Cover tracks as you go, not at exit — reactive cleanup misses things, especially under time pressure
ETW PATCHING IN PRACTICE
Many EDRs rely on Microsoft-Threat-Intelligence and other ETW providers for process injection and shellcode telemetry. Patching the EtwEventWrite function in a specific process removes that process from the EDR's telemetry — without touching the EDR itself.
THE ANOMALY PRINCIPLE
DFIR works by finding things that don't fit. Timestamps out of order, DLLs loaded from temp paths, processes with no parent. Produce no anomalies and there is nothing to anchor the investigation.
⚠
Lessons From Failure
What Actually Burns Operations
These failure modes appear in real, sophisticated operations. They share a single common cause.
HARDCODED FALLBACK VALUES
A shortcut taken under time pressure — a jokey test string, a fixed default key — ships into production and stays there. Every deployment using that fallback is identically keyed.
VERBOSE OUTPUT DURING LIVE OPS
Debug-grade tool output prints full paths, hostnames, and credentials to a terminal that gets screen-recorded or logged. What's visible on screen during an op is part of your data handling posture.
CLEARTEXT OPERATIONAL NOTES
Target hostnames, credentials, and tactical decisions written to unencrypted notes on the operator machine. If the machine is lost or compromised mid-engagement, the notes hand the client a full record of the op.
INCONSISTENT HARDENING
95% of the framework is hardened. A single config file, a single default value, a single code path that was "good enough for testing" is the entry point for reversal or attribution.
OPERATOR HOSTNAME IN TARGET LOGS
RDP to a target logs your source hostname in Windows Security Event 4624. A VM named "KALI-PENTEST" or a personal MacBook hostname appearing in auth logs is direct attribution. Rename machines before every engagement — not after access is established.
THE COMMON CAUSE
Every failure mode above results from treating operational security as a preference that can be traded off under pressure — rather than as a non-negotiable constraint on every decision, at every stage.
↑
The Meta-Principle — Above All Others
Opsec That Depends on Memory Will Fail
The framework enforces operational security. The operator executes the mission. These are not the same job.
"Operations that succeed at scale succeed because failure is architecturally difficult — not because operators never make mistakes."
Self-cleaning tools > tools with cleanup checklists that depend on memory
Encrypted storage enforced by default > "remember to encrypt your notes"
Automatic timestamp matching at install > "don't forget to match timestamps"
Signed, authenticated commands > "only send commands through secure channels"
Built-in exposure timers > "remember to remove the implant when the op ends"
If opsec requires the operator to do the right thing every time, it will eventually fail
Quick Reference — All Principles
The 13 Principles of Adversarial Tradecraft
01
SEPARATE ENVIRONMENTS
Dedicated VM per engagement. Encrypted vaults. Clean up when the op ends.