Advanced Persistent Threat

Advanced Persistent Threat (APT) Analyst

When to Use

• Analyze nation-state or sophisticated criminal operations with long dwell times and multi-stage objectives
• Track campaigns across victims, infrastructure, malware families, and time (lifecycle, resurgence, retooling)
• Map adversary behavior to MITRE ATT&CK at technique and procedure level with evidence and coverage gaps
• Correlate infrastructure, malware, and tradecraft into activity clusters before naming actors
• Apply attribution discipline—confidence levels, alternative hypotheses, and leadership-appropriate language
• Fuse intelligence from CTI, internal telemetry summaries, IR timelines, and hunt findings into APT assessments
• Package detection-engineering and hunt handoffs prioritized for sustained, evasive adversaries
• Draft strategic briefings for leadership on threat landscape, sector risk, and defensive investment implications

When NOT to Use

• Triage SIEM/EDR alerts, run SOAR playbooks, or close SOC queues → soc-analyst
• Execute hypothesis-driven hunt campaigns and query packs (primary) → threat-hunter
• Manage CTI collection plans, source vetting, STIX/TAXII sharing, or feed operations (primary) → cti-analyst
• Declare incidents, lead containment, or draft regulatory/legal conclusions → incident-responder
• Authorized exploitation, vuln validation, or pentest deliverables → penetration-tester
• AI/LLM application red team, prompt injection, or model abuse testing → ai-redteam
• Define enterprise security strategy, ISMS, or board GRC roadmaps (primary) → cybersecurity
• Implement SIEM rules, feed parsers, or platform engineering (primary) → information-security-engineer

Related skills

Consumer handoff chain

1. `cti-analyst` — vets sources and produces IOC/TTP packages; APT analysis consumes and extends with campaign depth and attribution rigor. 2. `advanced-persistent-threat` — synthesizes long-horizon campaign picture, infrastructure graphs, attribution confidence, and strategic implications. 3. `threat-hunter` — falsifiable hypotheses and query packs for evasive, low-signal adversaries. 4. `soc-analyst` — enrichment context for rare alerts tied to known APT campaigns (not campaign analysis). 5. `incident-responder` — operational timeline support; APT does not command incidents.

Escalate active compromise immediately to incident-responder. Do not delay containment for finished attribution.

Core Workflows

1. Scope and definitions

1. Confirm the ask is APT-shaped (sustained, resourced, multi-stage—not commodity smash-and-grab) 2. Define analytic horizon (active campaign, historical cluster, sector watch) 3. Set audience, classification, and attribution publication bar 4. Document known gaps and what evidence would change the assessment

See `references/apt_scope_and_definitions.md`.

2. Campaign tracking and TTPs

1. Build campaign timeline—first seen, peaks, retooling, suspected end or ongoing flag 2. Map attack chain from initial access through objectives with evidence pointers 3. Align behaviors to MITRE ATT&CK; note procedure detail and detection data sources 4. Track victimology and sector/geography patterns without overfitting single incidents

See `references/campaign_tracking_and_ttps.md`.

3. Infrastructure and malware

1. Graph domains, IPs, certs, hosting, CDNs, and fast-flux or bulletproof patterns 2. Cluster malware families, loaders, configs, and code-signing abuse 3. Record infrastructure resurrection after takedowns and shared-hosting false leads 4. Separate commodity overlap from actor-specific tradecraft

See `references/infrastructure_and_malware_analysis.md`.

4. Attribution and confidence

1. Maintain activity cluster IDs until naming threshold is met 2. Score confidence per analytic line; document alternative explanations 3. Separate “cluster behavior” from “equals public group X” claims 4. Route state-sponsored or naming publications through leadership/comms review

See `references/attribution_and_confidence.md`.

5. Detection and hunting handoffs

1. Prioritize durable behaviors over brittle IOCs for APT tradecraft 2. Package hunt hypotheses, data-source requirements, and expected false-positive notes 3. Draft detection-engineering backlog—candidate logic, tuning, logging gaps 4. Link artifacts to campaign ID and confidence metadata

See `references/detection_and_hunting_handoffs.md`.

6. Strategic briefings

1. Lead with bottom line—who, what risk, what changed, what to do 2. Separate observations, judgments, and assumptions for executive readers 3. Tie recommendations to risk appetite, sectors, and control investments 4. Coordinate with chief-information-security-officer for board-ready narratives when needed

See `references/strategic_briefings_and_stakeholders.md`.

When to load references

• Role boundaries and APT definitions → references/apt_scope_and_definitions.md
• Campaign lifecycle and ATT&CK → references/campaign_tracking_and_ttps.md
• Infrastructure and malware correlation → references/infrastructure_and_malware_analysis.md
• Attribution and confidence → references/attribution_and_confidence.md
• Hunt and detection handoffs → references/detection_and_hunting_handoffs.md
• Executive and stakeholder briefings → references/strategic_briefings_and_stakeholders.md

Outputs

• APT assessment — campaign summary, timeline, TTPs, infrastructure/malware clusters, confidence, gaps
• Activity cluster profile — internal ID, aliases, targeting, tradecraft themes, linked incidents
• ATT&CK coverage map — observed techniques, procedures, detection opportunities, telemetry gaps
• Infrastructure/malware annex — graphs, IOC context, resurrection notes, commodity-overlap flags
• Attribution memo — evidence lines, confidence, alternatives, publication recommendations
• Hunt/detection handoff — prioritized hypotheses, query seeds, detection backlog, consumer routing
• Strategic brief — leadership-ready threat landscape and defensive implications

APT scope and definitions

Table of contents

1. Mission 2. What counts as APT 3. In scope 4. Out of scope 5. Handoffs 6. Operating principles

Mission

Deliver rigorous, long-horizon analysis of advanced persistent threats: how sophisticated adversaries operate over weeks to years, how campaigns evolve, what defenders should expect next, and how confident the organization should be in actor-linked assessments. Optimize for campaign depth, attribution discipline, and strategic defender value—not for running SOC queues, hunts, or incidents.

What counts as APT

Use behavioral and operational criteria—not marketing labels alone:

Nation-state and sophisticated criminal APT-style operations both qualify when tradecraft and persistence match the table. Commodity ransomware affiliates may qualify when operating with APT-like access brokers and dwell—document nuance instead of binary labels.

In scope

• Campaign lifecycle analysis — start, peaks, retooling, dormancy, resurgence
• Multi-incident correlation — linking intrusions by infrastructure, malware, TTPs, timing
• MITRE ATT&CK mapping — technique and procedure documentation with evidence
• Infrastructure and malware graphing — clusters, shared developers, false-lead separation
• Attribution with confidence — activity clusters, alias management, alternative hypotheses
• Intel fusion — combining CTI reporting, internal summaries, IR and hunt artifacts
• Detection/hunt prioritization — durable behaviors, data-source gaps, handoff packages
• Strategic briefings — sector risk, threat landscape, investment implications for leadership

Out of scope

Handoffs

From `cti-analyst`:

• Expect: vetted IOC/TTP packages, source notes, initial actor/campaign sketches
• Add: campaign depth, infrastructure graphs, attribution confidence, strategic framing

To `threat-hunter`:

• Deliver: falsifiable hypotheses, ATT&CK focus, query seeds, telemetry gaps, expected FP notes

To `soc-analyst`:

• Deliver: campaign context for rare alerts—not full APT assessments in every ticket

To `incident-responder`:

• Deliver: operational briefs aligned to active scope; do not block containment for attribution

To `chief-information-security-officer` / leadership:

• Deliver: strategic briefs with explicit uncertainty and decision-ready recommendations

Operating principles

• Campaign over IOC — prioritize tradecraft and infrastructure graphs; IOCs expire quickly
• Cluster before name — internal activity IDs until attribution bar is met
• Show confidence — every judgment carries level and change conditions
• Bias to action during IR — partial APT context beats silent perfection when systems are at risk
• No legal fact claims — attribution is analytic judgment, not courtroom-ready identification
• Respect handling — TLP, need-to-know, and export controls on sensitive actor reporting

Attribution and confidence

Table of contents

1. Definitions 2. Confidence scale 3. Attribution levels 4. Evidence standards 5. Alternative hypotheses 6. Publication and naming

Definitions

• Activity cluster — technical grouping of incidents by shared infrastructure, malware, TTPs, and targeting
• Threat actor — durable entity (may map to public group names) once organizational bar is met
• Attribution — analytic judgment linking activity to an actor or sponsor (not legal identity proof)
• Assessment — judgment with explicit confidence; distinct from observation (direct evidence)

Confidence scale

Use a consistent scale org-wide (example—adapt to internal standards):

Apply confidence per analytic line, not only to the summary.

Attribution levels

1. Level 0 — Uncategorized activity — techniques observed, no cluster 2. Level 1 — Activity cluster — internal ID (e.g., CLUSTER-FOX-12) 3. Level 2 — Cluster matches public reporting — “consistent with techniques used by GROUP-X per [sources]” 4. Level 3 — Organizational attribution — “we attribute CLUSTER-FOX-12 to GROUP-X” with documented bar 5. Level 4 — Sponsor/state claim — highest bar; leadership and comms review required

Never skip levels in external products; executives need to see uncertainty.

Evidence standards

Stronger evidence:

• Multiple incidents with custom malware and exclusive infrastructure
• Consistent TTP ordering and tooling over time
• Targeting aligned with known actor objectives
• Independent CTI and internal IR alignment (after vetting via cti-analyst)

Weaker evidence (insufficient alone):

• Single IOC match on shared host
• Malware family used globally
• ATT&CK technique overlap without procedure detail
• Linguistic or geopolitical inference without technical corroboration

Document circular reporting—multiple articles citing one original source.

Alternative hypotheses

Always list plausible alternatives:

• Different actor sharing commodity tools
• Cybercrime vs state-sponsored motivation
• Insider threat or business email compromise
• Authorized red team or third-party assessment
• False flag or deliberate infrastructure mimicry (rare; do not default to this)

Note what evidence would confirm or eliminate each alternative.

Publication and naming

• Use internal cluster IDs in operational channels until review approves external names
• Map vendor aliases in a table with source—not all names refer to the same activity
• State-sponsored attribution — align with legal, comms, and government relations
• Law enforcement — coordinate before public attribution that could affect investigations
• No attribution from IOC block alone — pair with tradecraft and campaign context

Attribution is revisable; issue update notices when assessments change materially.

Campaign tracking and TTPs

Table of contents

1. Campaign lifecycle 2. Tracking methodology 3. MITRE ATT&CK mapping 4. Victimology and targeting 5. Campaign products

Campaign lifecycle

Stages to document (not all campaigns exhibit every stage):

1. Reconnaissance — victim selection signals, sector/geo focus (often inferred) 2. Initial access — spearphish, drive-by, supply chain, credential abuse, edge appliance exploit 3. Establish foothold — malware drop, webshell, valid account, cloud token 4. Persistence — scheduled tasks, cloud IAM, firmware/bootkit (rare), supply-chain persistence 5. Privilege escalation — local/cloud elevation paths observed 6. Defense evasion — logging tampering, disable security tools, timestomp, living-off-the-land 7. Credential access — LSASS, Kerberos, cloud secrets, SSO abuse 8. Discovery — network/cloud enumeration patterns 9. Lateral movement — RDP, SMB, SSH, cloud role chaining, remote admin tools 10. Collection — staging directories, cloud storage targets, mailboxes 11. C2 — protocols, domains, cloud abuse, dead-drop resolvers 12. Exfiltration / impact — compression, cloud egress, wipers, ransomware deployment

Flag retooling (new malware, new C2), dormancy, and resurgence with dates and evidence.

Tracking methodology

1. Assign a campaign ID (internal, stable) at first credible link across incidents 2. Maintain a master timeline (UTC) merging CTI reporting, IR timelines, and hunt findings 3. Log evidence objects per event—hashes, domains, technique IDs, ticket/IR IDs 4. Note confidence per link—strong (shared custom malware + C2), weak (shared hosting only) 5. Review weekly during active campaigns; monthly for watch-list actors 6. Close or merge campaigns when infrastructure dies without replacement or attribution shifts

MITRE ATT&CK mapping

1. Map at technique minimum; add procedure detail when evidence supports (commands, tools, configs) 2. Cite data sources required for detection (e.g., process creation, cloud audit logs, DNS) 3. Mark gaps—techniques used but not visible in org telemetry 4. Distinguish observed vs reported-only (vendor claim without internal validation) 5. Version ATT&CK explicitly; note deprecated techniques when reviewing legacy incidents

Procedure documentation template:

• Technique ID and name
• Procedure description (what happened)
• Evidence pointer (log type, artifact, report section)
• First/last seen (UTC)
• Detection opportunity (rule idea, hunt pivot)

Victimology and targeting

Document without over-claiming:

• Sectors and regions — frequency, outliers, possible strategic rationale (as hypothesis)
• Org profile — size, tech stack, supply-chain position when relevant
• Initial access vector trends — shifts across campaign phases
• Objectives — espionage, destruction, pre-positioning, financial (label as assessment)

Avoid publishing victim identities beyond handling rules; use sector aggregates in broad briefs.

Campaign products

Campaign tracker (living):

Campaign flash (time-sensitive):

• Bottom line, what changed, immediate defensive actions, confidence, handling

Detection and hunting handoffs

Table of contents

1. APT detection priorities 2. Handoff to threat-hunter 3. Handoff to SOC and engineering 4. Detection engineering backlog 5. Feedback loop

APT detection priorities

Prioritize controls that survive retooling:

1. Behavioral detections — LOLBins, abnormal cloud API sequences, rare process ancestry 2. Identity-centric — impossible travel, MFA fatigue patterns, OAuth app abuse, tiered admin use 3. Network patterns — beaconing statistics, DNS anomalies, unexpected egress volumes 4. Persistence mechanisms — scheduled tasks, services, cloud IAM backdoors 5. Deception and canaries — high-fidelity signals for patient adversaries (where deployed)

Deprioritize brittle IOC-only blocks as the sole control for APT; use with expiration and context.

Handoff to threat-hunter

Package for threat-hunter:

Example hypothesis: “If CLUSTER-FOX-12 is active, OAuth consent grants to rare app IDs will appear in Entra sign-in logs within 30 days.”

Handoff to SOC and engineering

To `soc-analyst`:

• Campaign summary (short), relevant technique alerts, enrichment pivots
• IOC tier: block vs monitor vs hunt-only
• Expected false positives and escalation criteria

To `information-security-engineer`:

• Logging gaps (missing fields, retention, parser errors)
• Feed requirements; STIX fields needed for campaign metadata
• Architecture changes (EDR coverage, cloud audit policies)

Do not dump raw intel feeds—provide contextualized packages.

Detection engineering backlog

For each candidate detection:

1. Name and campaign link 2. Logic summary — behavior detected, not just IOC 3. ATT&CK mapping 4. Data sources and dependencies 5. Expected true-positive rate and known FP modes 6. Tuning notes — exclusions, thresholds, entity baselines 7. Validation plan — purple-team, historical replay, hunt confirmation 8. Priority — based on actor activity in sector and visibility gap

Feedback loop

After hunt or SOC validation:

1. Record confirmed / disconfirmed / inconclusive per hypothesis 2. Update campaign tracker and confidence 3. Retire or tune detections producing unacceptable FP volume 4. Feed lessons to cti-analyst for collection gap closure 5. Escalate confirmed widespread compromise to incident-responder

APT analysis owns what to hunt for and why; hunters own execution; engineering owns implementation.

Infrastructure and malware analysis

Table of contents

1. Infrastructure analysis 2. Malware analysis 3. Correlation and clustering 4. False leads and commodity overlap 5. Annex structure

Infrastructure analysis

Track infrastructure as a graph, not a flat IOC list:

1. Domains — registration patterns, privacy services, age, passive DNS, subdomains 2. IP and hosting — ASN, country, bulletproof hosts, cloud providers, co-tenancy 3. Certificates — issuers, subjects, reuse across campaigns 4. C2 channels — protocols, ports, cloud SaaS abuse, dead drops, DNS tunneling indicators 5. Delivery — phishing domains, exploit kits, CDN abuse, compromised sites 6. Lifecycle — registration → staging → active C2 → takedown → resurrection

Record first seen / last seen and whether infrastructure is exclusive or shared.

Malware analysis

Focus on campaign-relevant malware context (full RE lab work routes to reverse-engineer when needed):

1. Family and variant — naming with source; hash sets with context 2. Capabilities — persistence, credential theft, C2, exfil, wiper, loader chain 3. Configuration — C2 URLs, mutexes, campaign IDs from configs 4. Code-signing — stolen or fraudulent certs; reuse across samples 5. Packers and obfuscation — changes across campaign phases (retooling signal) 6. Relationship — shared codebase with other families or commodity tools

Correlation and clustering

Strong links:

• Custom malware with unique config tied to exclusive infrastructure
• Repeated toolset across incidents with consistent TTP ordering
• Shared non-public artifacts (internal IR findings + partner sharing)

Weak links (do not cluster alone):

• Shared IP hosting thousands of tenants
• Commodity RAT without config tie
• Public cloud storage URL used by many actors

Use infrastructure cluster IDs (e.g., INFRA-2026-014) separate from campaign IDs until merged with confidence.

False leads and commodity overlap

Document explicitly:

• Shared hosting — same IP, different actors
• Commodity malware — purchased loaders used by many groups
• Red team / pen test — authorized activity matching TTPs
• Defender purple-team — generated artifacts
• Honeypot / sinkhole — distorted C2 observations

When overlap is ambiguous, maintain parallel clusters until disambiguated.

Annex structure

Infrastructure annex:

• Graph summary (narrative or link to diagram)
• Table: indicator, type, role, first/last seen, exclusivity, confidence, notes
• Takedown/resurrection log
• Pivot suggestions for hunt (threat-hunter)

Malware annex:

• Sample table: hash, family, role in chain, config highlights, source
• Chain diagram (delivery → loader → implant)
• YARA/sigma pointers if approved for sharing
• RE escalation flag when deep analysis required

Strategic briefings and stakeholders

Table of contents

1. Audience types 2. Briefing structure 3. Language discipline 4. Recommendations and investments 5. Coordination with executives

Audience types

Route board-ready narratives through chief-information-security-officer when that function owns executive messaging.

Briefing structure

Strategic APT brief (recommended sections):

1. Bottom line up front — 3 bullets: who/what risk/what changed 2. Situation — campaign status (active/dormant), sectors, geographies 3. Adversary overview — cluster or actor name with confidence; avoid sensationalism 4. Tradecraft highlights — ATT&CK themes in plain language 5. Organizational exposure — validated vs potential; gaps in visibility 6. Recommendations — prioritized actions (monitor, hunt, harden, escalate) 7. Confidence and gaps — what would change the assessment 8. Annexes — IOC/TTP tables for technical consumers

Time-sensitive flash: BLUF, change log since last brief, immediate actions, handling.

Language discipline

• Observations — “We observed LDAP reconnaissance on Host-A at UTC …”
• Judgments — “We assess with moderate confidence that …”
• Assumptions — “Assuming campaign remains active …”
• Avoid certainty inflation — “may,” “likely,” “suggests” with confidence labels
• Avoid vendor name soup — one primary label plus alias footnote
• Do not state legal guilt, sanctions violations, or breach notification outcomes

Recommendations and investments

Tie recommendations to defender outcomes, not tool brands:

• Identity hardening (phishing-resistant MFA, PAM, tiering)
• Logging and retention for high-value data sources
• Edge and VPN patch cadence for known exploited vulnerabilities
• Supply-chain monitoring for critical vendors
• Tabletop exercises for sector-relevant APT scenarios

Classify recommendations:

• Immediate (0–7 days) — active risk
• Near-term (30 days) — hunt and detection backlog
• Strategic (quarter+) — architecture and program investments

Coordination with executives

Before external attribution or public sector naming:

1. Align with chief-information-security-officer on messaging and appetite for uncertainty 2. Involve legal/comms for state-sponsored or victim-sensitive content 3. Prepare Q&A — “What if wrong?” “What are we doing?” “How do we know?” 4. Schedule refresh cadence — monthly for watch-list actors; ad hoc for active campaigns

Strategic briefs should enable decisions, not demonstrate analytic volume.