Capstone Project 3: Red Team Campaign Design — Adversary Emulation

Project Overview

This capstone challenges you to design a comprehensive red team campaign against FinanceForward Corp, a fictional mid-size financial services company. Unlike the previous two capstones, which emphasized hands-on exploitation, this project foregrounds the strategic planning, threat intelligence integration, and operational design that distinguish red teaming from penetration testing.

A penetration test asks: "What vulnerabilities exist?" A red team campaign asks: "Can a specific adversary achieve a specific objective against this organization's people, processes, and technology — and would the defenders detect it?"

You will select a real Advanced Persistent Threat (APT) group, study its documented tactics, techniques, and procedures (TTPs), map those TTPs to the MITRE ATT&CK framework, and design a multi-phase campaign that emulates that adversary's behavior against FinanceForward's environment. You will also design the purple team component: a plan for evaluating whether FinanceForward's security operations center (SOC) and incident response team can detect and respond to each phase of your campaign.

This project is primarily a planning and design exercise. You will produce detailed campaign documentation rather than executing the campaign. The deliverables you create are the same documents that real red team operators produce before an engagement — documents that must be thorough enough for a team of operators to execute the campaign over several weeks.

Estimated Duration: 35–50 hours across 2–3 weeks.

Learning Objectives

Upon completing this capstone, you will be able to:

1. Conduct threat intelligence research on a real APT group, extracting actionable TTPs from published threat reports, MITRE ATT&CK entries, and incident response case studies.
2. Design a realistic attack plan mapped to the MITRE ATT&CK framework, with decision trees that account for defensive responses and operational setbacks.
3. Architect command-and-control infrastructure that balances operational security with reliability, including redirectors, domain fronting alternatives, and communication channels.
4. Plan multi-phase initial access campaigns incorporating phishing, supply chain vectors, and external exploitation, with fallback approaches for each.
5. Develop a purple team evaluation methodology that measures defensive capabilities against each campaign phase.
6. Navigate the ethical, legal, and organizational complexities of red team operations, including deconfliction, safety mechanisms, and responsible disclosure of findings.

Scenario: FinanceForward Corp

Company Profile

FinanceForward Corp is a financial technology company headquartered in Chicago, Illinois, providing digital banking services, payment processing, and wealth management tools to approximately 1.2 million consumer customers and 15,000 business clients. The company was founded in 2015 and went public in 2022. Annual revenue is approximately $400 million.

FinanceForward operates under the regulatory oversight of the Office of the Comptroller of the Currency (OCC), the Federal Reserve, and state banking regulators. They are subject to SOX compliance, PCI DSS requirements, and GLBA privacy regulations. Their board of directors has mandated annual red team assessments as part of the company's cybersecurity risk management program.

Organizational Structure (Security-Relevant)

• CISO: Rebecca Tran, reports to the CEO. 12 years of financial services security experience.
• Security Operations Center (SOC): 15-person team, 24/7 coverage. Uses Splunk SIEM with CrowdStrike Falcon EDR. Tier 1 analysts handle initial triage; Tier 2 analysts investigate escalated alerts; Tier 3 analysts conduct threat hunting.
• Incident Response Team: 4-person dedicated IR team under the SOC manager. Conducts tabletop exercises quarterly.
• Application Security Team: 6 engineers responsible for SAST/DAST, code review, and developer security training.
• IT Operations: Manages infrastructure, identity, and access management. Uses ServiceNow for ticketing.
• Total Employees: Approximately 2,500 across three offices (Chicago HQ, Austin development center, New York client services).

Technical Environment

Identity and Access Management: - Azure Active Directory (Entra ID) as primary identity provider. - Hybrid configuration with on-premises Active Directory (financeforward.local) synchronized via Azure AD Connect. - Conditional Access policies enforce MFA for all cloud application access from external networks. - Privileged Access Management: CyberArk for privileged account vaulting and session recording. - Employee SSO through Azure AD for ~40 SaaS applications (Salesforce, Workday, Jira, Confluence, GitHub Enterprise, Slack).

Endpoint Security: - Windows 11 enterprise workstations managed via Microsoft Intune. - CrowdStrike Falcon endpoint detection and response (EDR) deployed on all endpoints and servers. - Application control: Microsoft Defender Application Control (WDAC) policies on standard user workstations; developer workstations have more permissive policies. - USB storage blocked via Group Policy on standard workstations.

Network Infrastructure: - Palo Alto Networks next-generation firewalls with SSL inspection at the perimeter. - Zscaler Internet Access (ZIA) for cloud-based web proxy and DNS security. - Internal network segmented into zones: Corporate, Development, Production, DMZ, and Management. - Cisco ISE for network access control with 802.1X authentication.

Cloud Infrastructure: - Primary Cloud: AWS (us-east-1, us-west-2 for DR). - Services: EKS (Kubernetes) for production applications, RDS (PostgreSQL and MySQL), S3, Lambda, API Gateway, CloudFront, SQS, SNS. - Security Tooling: AWS GuardDuty, AWS CloudTrail (all regions), AWS Config, AWS Security Hub. - Infrastructure as Code: Terraform, managed through GitHub Enterprise with CI/CD via GitHub Actions. - Container Security: Aqua Security for container image scanning and runtime protection.

Application Architecture: - Consumer-facing banking application: React frontend, Go microservices backend, deployed on EKS. - Internal tools: Mix of .NET applications (legacy) and Python/FastAPI services (newer). - API Gateway: Kong, with OAuth 2.0 and API key authentication. - Mobile apps: Native iOS (Swift) and Android (Kotlin), communicating via REST APIs.

Email Security: - Microsoft 365 with Exchange Online. - Proofpoint Email Protection for inbound email filtering. - DMARC policy set to p=quarantine (not reject).

Security Monitoring: - Splunk Enterprise Security as SIEM, ingesting logs from: CrowdStrike, Palo Alto firewalls, Zscaler, Azure AD, AWS CloudTrail, Proofpoint, CyberArk, and application logs. - CrowdStrike Falcon for endpoint detection and response. - Recorded Future for threat intelligence feeds integrated into Splunk. - Vulnerability scanning: Qualys with weekly scans of all external and internal assets.

Threat Intelligence Briefing

Your Assignment: Emulate APT29 (Cozy Bear)

For this capstone, you will design a campaign emulating APT29, also known as Cozy Bear, The Dukes, Nobelium, and Midnight Blizzard. APT29 is attributed to Russia's Foreign Intelligence Service (SVR) and is one of the most sophisticated and persistent threat actors targeting Western financial services, government, and technology sectors.

APT29 is an appropriate choice for FinanceForward's threat model for several reasons: - Financial services companies are documented APT29 targets, particularly for intelligence gathering related to sanctions, monetary policy, and economic data. - APT29's TTPs stress-test the specific defensive controls FinanceForward has deployed (EDR, cloud security monitoring, identity-based detection). - APT29's operational security is extremely disciplined, making detection genuinely challenging and providing a realistic benchmark for SOC effectiveness.

APT29 TTP Summary

You must research APT29 extensively using publicly available threat intelligence. The following summary provides a starting point; your campaign design must go deeper.

Known Characteristics: - Patience: APT29 campaigns operate over months or years. Initial access may occur weeks before any post-exploitation activity. - Operational Security: Extensive use of compromised infrastructure for C2, encrypted communications, timestomping, and log clearing. Avoidance of commodity malware in favor of custom tooling. - Supply Chain Exploitation: The SolarWinds compromise (SUNBURST/Solorigate) demonstrated APT29's willingness and capability to compromise software supply chains for initial access. - Cloud Expertise: APT29 has demonstrated sophisticated abuse of cloud environments, particularly Microsoft 365 and Azure AD. Techniques include OAuth application abuse, certificate manipulation for SAML token forging (Golden SAML), and mailbox delegation abuse. - Credential Access: Heavy emphasis on credential theft through memory scraping, token theft, Kerberos attacks, and password spraying (often at very low rates to avoid detection). - Living Off the Land: Extensive use of legitimate tools and built-in operating system capabilities to blend in with normal activity.

Key MITRE ATT&CK Techniques (non-exhaustive — you must expand this list):

Required Research Sources: You must cite at least the following in your campaign design: - MITRE ATT&CK APT29 page and associated technique pages. - Microsoft Threat Intelligence reports on Nobelium/Midnight Blizzard. - Mandiant's APT29 reporting. - The CISA/FBI joint advisory on SolarWinds (Alert AA20-352A). - At least two additional threat intelligence reports from vendors such as Recorded Future, CrowdStrike, Volexity, or Palo Alto Unit 42.

Your campaign does not need to replicate APT29's TTPs exactly — you are emulating their approach and adapting it to FinanceForward's specific environment. Where APT29 used a technique against a government agency's infrastructure, you must consider how the equivalent technique would work (or fail) against FinanceForward's defenses.

MITRE ATT&CK Mapping Requirements

A central deliverable of this capstone is a complete MITRE ATT&CK mapping of your campaign. This mapping must satisfy the following requirements:

1. Coverage: Your campaign must include techniques spanning at least 10 of the 14 ATT&CK tactics (Reconnaissance through Impact). Not every campaign phase needs to employ every tactic, but the overall campaign must demonstrate breadth.

2. Depth: For each technique you plan to use, document: - The specific sub-technique (e.g., T1059.001, not just T1059). - How APT29 has historically used this technique (with citation). - How you would adapt this technique for FinanceForward's environment. - What FinanceForward defensive control would potentially detect this technique. - Your plan to evade or minimize detection risk.

3. ATT&CK Navigator Layer: Produce an ATT&CK Navigator JSON layer file highlighting all techniques included in your campaign. Use color coding to indicate campaign phases (e.g., blue for initial access, green for persistence, red for objective actions).

4. Technique Justification: For each technique, explain why it was selected over alternatives. If APT29 historically uses Kerberoasting (T1558.003) for credential access, but FinanceForward uses CyberArk to vault privileged credentials and monitors Kerberos ticket requests, explain why you would still attempt this technique (or why you would substitute an alternative such as cloud token theft).

Campaign Phases

Phase 1: Threat Modeling and Intelligence Gathering (Estimated: 8–10 hours)

Objective: Develop a comprehensive threat model for FinanceForward and gather the intelligence necessary to design a realistic attack plan.

Activities:

1. APT29 Research: - Study a minimum of six published threat intelligence reports on APT29 activity. - Create a TTP profile documenting APT29's preferred techniques across all ATT&CK tactics. - Identify patterns: What does APT29 do first upon gaining access? How do they move laterally? What are their primary objectives in financial services targets? - Note APT29's known tools: custom implants (Cobalt Strike variants, custom backdoors), living-off-the-land binaries, and legitimate cloud administration tools used maliciously.

2. FinanceForward Threat Model: - Identify FinanceForward's crown jewels: What would APT29 want from a financial services company? Consider: customer financial data, transaction records, payment processing infrastructure, executive communications, regulatory filings, M&A activity, and API keys for banking integrations. - Map the attack surface: external web applications, VPN endpoints, email, cloud console access, mobile applications, third-party integrations, and the software supply chain (GitHub Enterprise, Terraform modules, container images). - Assess defensive capabilities: CrowdStrike Falcon EDR, Proofpoint email filtering, Palo Alto firewalls with SSL inspection, Zscaler web proxy, Splunk SIEM with threat intelligence integration. For each defensive control, research its known detection capabilities and documented bypass techniques. - Identify likely detection gaps: Where are FinanceForward's defenses weakest? Cloud-native attacks against Azure AD? Supply chain compromises through GitHub Actions? Social engineering that bypasses email filtering?

3. Target Research (Simulated OSINT): - Create a target profile based on the organizational information provided. In a real engagement, you would conduct passive reconnaissance; for this capstone, work from the scenario description and hypothesize what additional intelligence OSINT would yield. - Identify high-value targets for social engineering: who has privileged access, who recently joined (and may not have completed security training), who holds dual roles with excessive access? - Map the technology stack to known vulnerabilities: are there recent CVEs for any of FinanceForward's technologies (Kong API Gateway, EKS, Azure AD Connect, CyberArk)?

Deliverable: Threat Model Document (8–12 pages) containing APT29 TTP profile, FinanceForward crown jewel analysis, attack surface assessment, defensive capability evaluation, and identified attack opportunities.

Phase 2: Attack Plan Development (Estimated: 8–10 hours)

Objective: Develop a detailed, phased attack plan mapped to MITRE ATT&CK, with decision trees for each phase.

Activities:

1. Campaign Objective Definition: - Define the primary campaign objective in terms that mirror APT29's documented goals. For example: "Gain persistent, undetected access to FinanceForward's executive email and financial transaction processing systems to demonstrate capability for long-term intelligence collection." - Define secondary objectives that provide value even if the primary objective is not fully achieved: "Demonstrate ability to compromise developer workstations and inject code into the CI/CD pipeline." - Define minimum success criteria: "Achieve initial access and maintain persistence for 72 hours without SOC detection."

2. Phased Attack Plan: Structure your plan across these phases, with specific techniques, tools, and procedures for each:

a. Reconnaissance (ATT&CK Tactic: Reconnaissance) - Passive intelligence gathering: OSINT on employees, technology stack, third-party vendors. - Active reconnaissance: subdomain enumeration, service fingerprinting, credential leak monitoring. - Map to specific ATT&CK techniques (T1589, T1590, T1591, T1592, T1593, T1594, T1596, T1597).

b. Resource Development (ATT&CK Tactic: Resource Development) - Infrastructure procurement (covered in Phase 3 below). - Tooling selection: What implants, loaders, and utilities will you use? Justify each choice. - Credential acquisition: Purchase or identify leaked credentials from paste sites and dark web markets (simulated).

c. Initial Access (ATT&CK Tactic: Initial Access) - Primary vector: Design a spearphishing campaign targeting specific FinanceForward employees. Detail the pretext, payload delivery mechanism, and expected user interaction. - Secondary vector: Identify an external service exploitation path (VPN vulnerability, web application flaw, or exposed API). - Tertiary vector: Design a supply chain attack path (compromised GitHub Action, malicious Terraform module, or dependency confusion attack). - For each vector, map to specific ATT&CK techniques and explain the expected success probability.

d. Execution through Exfiltration (ATT&CK Tactics: Execution through Exfiltration) - For each post-access phase, document: - Specific techniques to be used (with ATT&CK IDs). - Tools and commands. - Expected defensive detection risk (High/Medium/Low) for each technique. - Evasion measures to reduce detection risk. - Alternative techniques if the primary approach fails.

3. Decision Trees: - For each major campaign decision point, create a decision tree:

   • "If phishing succeeds and we get a standard user session -> [Path A: credential harvesting and privilege escalation]"
   • "If phishing succeeds but EDR detects the payload -> [Path B: switch to fileless techniques]"
   • "If phishing fails entirely -> [Path C: activate external exploitation vector]"
   • "If SOC detects lateral movement -> [Path D: go silent for 72 hours, then re-engage from secondary access]"
   • Decision trees should cover at least: initial access success/failure, EDR detection/evasion, privileged access achievement, and SOC investigation response.

4. Timeline: - Develop a week-by-week campaign timeline spanning 4–6 weeks. - Include key milestones: infrastructure ready, initial access attempt, persistence established, lateral movement, objective achieved. - Build in "quiet periods" that emulate APT29's patient operational tempo.

Deliverable: Attack Plan Document (12–18 pages) with phased plan, ATT&CK mapping for each technique, decision trees, and campaign timeline.

Phase 3: Infrastructure Design (Estimated: 6–8 hours)

Objective: Design the command-and-control infrastructure necessary to support the campaign while maintaining operational security.

Activities:

1. C2 Architecture: - Select a primary C2 framework. Justify your choice (Cobalt Strike, Sliver, Mythic, Brute Ratel, or custom). Consider: FinanceForward runs CrowdStrike Falcon — your C2 must evade its behavioral detections. - Design a tiered C2 architecture:

   • Tier 1 (Short-haul): Disposable infrastructure for initial access and early-stage communications. Expected lifespan: 24–72 hours.
   • Tier 2 (Long-haul): Resilient infrastructure for persistent access. Expected lifespan: weeks to months.
   • Tier 3 (Interactive): On-demand infrastructure for hands-on-keyboard operations. Activated only when operator interaction is needed.
   • Document the C2 communication protocol for each tier: HTTP/S, DNS, DoH, or cloud-based channels.

2. Redirector Design: - Design traffic redirectors that sit between implants and the C2 team server. These redirectors serve to:

   • Obscure the team server's true IP address.
   • Filter out security researcher scanning traffic.
   • Provide geographic plausibility (if targeting a US company, redirectors should have US IP addresses).
   • Specify redirector technology: Apache mod_rewrite, Nginx, cloud functions (AWS Lambda, Azure Functions), or CDN-based redirecting.
   • Document redirector filtering rules: what traffic is forwarded to the team server, and what is redirected to a legitimate decoy site.

3. Domain and Certificate Strategy: - Select domain naming conventions that plausibly relate to FinanceForward's technology stack or business operations. Provide examples: finforward-auth.com, ff-cdn-assets.com, secure-updates-service.com. - Plan certificate acquisition: Let's Encrypt for general domains; purchased certificates for domains requiring higher trust assurance. - Consider domain categorization: how will you ensure the C2 domains are categorized by web proxies as benign categories (business, technology, CDN) rather than "newly registered" or "uncategorized"? - Address domain aging: plan to register domains at least 30 days before campaign start to avoid "newly registered domain" detection.

4. Communication Channels: - Design primary and backup communication channels between the operator team and the red team manager. - Document the out-of-band communication plan for emergencies (campaign deconfliction, inadvertent disruption, or discovery of a real compromise). - Specify encrypted communication tools for team coordination.

5. Infrastructure Diagram: - Produce a complete infrastructure architecture diagram showing:

   • All C2 servers (with hostnames, IP ranges, and cloud providers).
   • Redirector placement and traffic flow.
   • Domain assignments for each infrastructure tier.
   • Network paths from implant to team server.
   • Monitoring and logging within the red team infrastructure.

Deliverable: Infrastructure Design Document (6–10 pages) with architecture diagram, C2 configuration specifications, redirector rules, domain strategy, and operational security measures.

Phase 4: Initial Access Planning (Estimated: 4–6 hours)

Objective: Design detailed initial access operations for each planned attack vector.

Activities:

1. Spearphishing Campaign Design: - Target Selection: Identify 5–10 FinanceForward employees to target based on role, access level, and susceptibility indicators. Justify each selection. - Pretext Development: Design a plausible phishing pretext that aligns with FinanceForward's business context. APT29 has used pretexts including: embassy communications, COVID-19 updates, security alerts, and conference invitations. Adapt this to the financial services context. - Payload Design: Specify the payload delivery mechanism:

   • Option A: HTML smuggling delivering an ISO file containing a malicious LNK and DLL (mimicking APT29's 2022 campaigns).
   • Option B: OAuth consent phishing targeting Azure AD, requesting Mail.Read and Files.ReadWrite permissions (mimicking Midnight Blizzard's 2023 campaign against Microsoft).
   • Option C: QR code phishing directing to a credential harvesting page that also requests MFA approval (adapting to MFA-enforced environments).
   • Evasion Considerations: How will your phishing email bypass Proofpoint? Consider: sending infrastructure reputation, URL obfuscation, payload format, timing, and volume.
   • Success Metrics: Define what constitutes successful phishing (click-through, credential capture, payload execution, or OAuth consent).

2. External Exploitation Planning: - Identify the most promising external attack surface based on FinanceForward's technology stack. - Research recent CVEs for: Kong API Gateway, Azure AD Connect, EKS control plane, and any internet-facing .NET applications. - Design an exploitation scenario for one viable external vulnerability, including: vulnerability identification, exploit development or acquisition, staging, execution, and initial foothold establishment. - Address the challenge of exploiting services behind a Palo Alto firewall with SSL inspection.

3. Supply Chain Attack Design: - Design a supply chain attack vector targeting FinanceForward's CI/CD pipeline:

   • Option A: Compromise a GitHub Actions workflow by injecting a malicious step through a pull request to a public dependency.
   • Option B: Dependency confusion attack against FinanceForward's internal Python or npm packages.
   • Option C: Compromise a Terraform module used by FinanceForward's infrastructure team.
   • For the selected option, detail the complete attack chain from initial supply chain access to code execution in FinanceForward's environment.
   • Assess the operational security implications: supply chain attacks are high-impact but also high-risk for detection and attribution.

Deliverable: Initial Access Plan (6–8 pages) with detailed designs for each attack vector, target justifications, payload specifications, and evasion strategies.

Phase 5: Execution Timeline and Decision Trees (Estimated: 4–6 hours)

Objective: Develop a detailed execution timeline for the full campaign with decision points, contingencies, and abort criteria.

Activities:

1. Week-by-Week Timeline:

Design a 4–6 week campaign timeline with daily granularity for critical phases:

Pre-Campaign (Weeks -4 to -1): - Infrastructure provisioning, domain registration, and aging. - Tooling development, testing, and validation against CrowdStrike in a lab environment. - Target reconnaissance and phishing pretext refinement. - Operational readiness review with red team manager.

Week 1: Initial Access - Day 1–2: Launch phishing campaign (staggered sends to avoid bulk detection). - Day 3–5: Monitor for successful access. If phishing succeeds, establish initial persistence. - Day 5–7: If phishing fails, activate secondary vector (external exploitation). - Decision Point: Proceed to post-exploitation or extend initial access efforts.

Week 2: Establishing Persistence and Internal Reconnaissance - Establish persistent access on initial foothold. - Conduct internal reconnaissance: AD enumeration, network mapping, cloud resource discovery. - Identify lateral movement targets and privilege escalation opportunities. - Quiet period: minimize activity to observe normal network patterns and assess detection risk.

Week 3: Lateral Movement and Privilege Escalation - Move laterally toward high-value targets (domain controllers, cloud admin accounts, financial systems). - Escalate privileges through identified paths. - Establish additional persistence mechanisms on high-value systems. - Decision Point: If detected, activate contingency plan (go silent or switch to backup C2).

Week 4: Objective Actions - Access crown jewel systems: executive email, transaction processing, customer database. - Demonstrate data collection capability (email harvesting, database queries) without exfiltrating real data. - Document all access achieved and evidence collected.

Week 5: Cleanup and Reporting - Remove all persistence mechanisms, implants, and artifacts. - Verify cleanup completeness. - Compile evidence for debrief.

2. Decision Trees (Detailed):

For each major decision point, create a detailed decision tree with at least three branches:

Decision Point 1: Initial Access Outcome Phishing Campaign Launched ├── Success: Payload executed, C2 callback received │ ├── EDR alert generated → Pause 48 hours, assess SOC response, switch to fileless approach │ ├── No EDR alert → Proceed to persistence (Day 2 plan) │ └── Partial success: credentials captured but no code execution → Use credentials for cloud access ├── Partial Success: Clicks but no execution (sandbox detected) │ ├── Retarget with modified payload (different obfuscation) │ ├── Switch to OAuth consent phishing vector │ └── Activate external exploitation vector └── Failure: No clicks after 72 hours ├── Refine pretext and retarget different employee group ├── Activate external exploitation vector └── Activate supply chain vector

Decision Point 2: SOC Detection Response SOC Detects Activity ├── Alert triaged as false positive → Continue operations cautiously ├── Alert investigated but source not identified → Pause 72 hours on affected host, continue from alternate access ├── Alert investigated and implant discovered → │ ├── Only initial foothold compromised → Activate backup access (if established) │ ├── Multiple persistence mechanisms discovered → Campaign may be burned; consult red team manager │ └── SOC initiates full incident response → Invoke deconfliction protocol └── Alert not triaged within 24 hours → Note detection gap; continue operations

Create similar decision trees for: privilege escalation success/failure, lateral movement detection, and objective access achievement.

3. Abort Criteria: Define the conditions under which the campaign must be immediately suspended: - Discovery of a real active threat actor in FinanceForward's environment. - Unintended disruption to production systems or customer data. - Legal or regulatory complication (e.g., red team activity triggering a mandatory breach notification). - SOC detection leading to a full incident response that could involve law enforcement before deconfliction occurs. - Loss of control over red team infrastructure (C2 compromise by a third party).

Deliverable: Execution Timeline Document (6–10 pages) with week-by-week timeline, detailed decision trees, contingency plans, and abort criteria.

Phase 6: Detection and Response Testing Plan — Purple Team Component (Estimated: 5–7 hours)

Objective: Design a purple team evaluation plan that measures FinanceForward's defensive capabilities against each phase of your campaign.

Activities:

1. Detection Hypothesis Matrix: For each ATT&CK technique in your campaign, document: - Technique: ATT&CK ID and description. - Data Source: What log source should capture evidence of this technique (e.g., Windows Event Log, CrowdStrike telemetry, CloudTrail, Splunk). - Expected Detection: What specific alert, correlation rule, or hunting query should detect this technique? - Detection Confidence: Your assessment of whether FinanceForward's current tooling and SOC processes would actually detect this technique (High/Medium/Low/None), with justification. - Validation Method: How you would confirm whether detection occurred (check Splunk for specific event IDs, review CrowdStrike detection dashboard, etc.).

Example: | Technique | Data Source | Expected Detection | Confidence | Validation | |---|---|---|---|---| | T1003.001 (LSASS Memory Dump) | CrowdStrike Falcon | Falcon behavioral detection for LSASS access | High | Check Falcon console for detection alert within 5 minutes | | T1098.003 (Cloud Account Manipulation - Add Cloud Credential) | Azure AD Audit Logs -> Splunk | Splunk correlation rule for service principal credential addition | Medium | Query Splunk for Azure AD "Add service principal credentials" events | | T1567.002 (Exfiltration to Cloud Storage) | Zscaler logs -> Splunk | DLP rule or unusual upload volume alert | Low | Check Zscaler logs for uploads to external cloud storage |

2. Purple Team Exercise Design: Design a structured purple team exercise that can be conducted alongside or after the red team campaign: - Tabletop Component: Walk the SOC team through select attack phases and ask: "If you saw this indicator in your logs, what would you do?" Evaluate their response process, escalation procedures, and containment actions. - Technical Validation: For each detection hypothesis, execute the technique in a controlled manner and verify whether the expected detection fires. If it does not fire, document the gap. - Response Timing: Measure mean time to detect (MTTD) and mean time to respond (MTTR) for each detected technique.

3. Detection Gap Analysis: Based on your assessment of FinanceForward's defensive stack, proactively identify expected detection gaps: - Which ATT&CK techniques in your campaign have no corresponding detection rule or data source? - Where does FinanceForward have logging blind spots (e.g., container-level activity in EKS, Lambda function invocations, GitHub Actions execution)? - Which detections rely on signature matching that could be evaded by minor payload modification? - Where does the SOC's 24/7 staffing model create delays (e.g., Tier 1 analysts during overnight shifts may not recognize sophisticated attack patterns)?

4. Recommendations Framework: Prepare a framework for translating purple team findings into actionable recommendations: - For each detection gap: recommended detection rule, data source requirement, and estimated implementation effort. - For each slow response: process improvement recommendation. - For each evaded control: tuning or configuration change recommendation. - Priority ranking based on campaign phase (early detection of initial access is more valuable than detection of late-stage exfiltration).

Deliverable: Purple Team Plan (8–12 pages) with detection hypothesis matrix, exercise design, gap analysis methodology, and recommendations framework.

Required Deliverables Summary

Grading Rubric

Excellent (90–100%)

• Threat Intelligence: Demonstrates deep research into APT29's TTPs, drawing from multiple sources and synthesizing findings into a coherent adversary profile. TTP selection is justified in the context of FinanceForward's specific environment and defenses.
• Attack Plan: Campaign is sophisticated, realistic, and demonstrates understanding of how APT29 operates. Decision trees address realistic contingencies. Techniques are appropriately mapped to ATT&CK with sub-technique specificity. Plan accounts for FinanceForward's defensive capabilities and includes credible evasion strategies.
• Infrastructure Design: C2 architecture is operationally sound with appropriate tiering, redundancy, and operational security measures. Infrastructure diagram is detailed and professionally produced. Domain strategy accounts for categorization, aging, and SSL considerations.
• Initial Access: Multiple attack vectors are designed with sufficient detail for operator execution. Phishing pretexts are plausible and tailored to FinanceForward's context. Payload design accounts for the specific defensive controls in place (Proofpoint, CrowdStrike, WDAC).
• Purple Team: Detection hypothesis matrix covers all campaign techniques with realistic confidence assessments. Gap analysis identifies non-obvious detection blind spots. Recommendations are specific and prioritized.
• Professionalism: Documents are well-organized, clearly written, and formatted for professional consumption. ATT&CK references are accurate. Citations are provided for all threat intelligence claims.

Good (75–89%)

• Campaign design is competent and demonstrates solid understanding of red team methodology. ATT&CK mapping is accurate but may lack depth in evasion analysis or defensive consideration. Infrastructure design is functional but may not address all operational security concerns. Purple team plan covers key techniques but may miss detection gaps for less obvious attack phases.

Adequate (60–74%)

• Campaign design demonstrates basic understanding of adversary emulation but may rely too heavily on generic techniques rather than APT29-specific TTPs. ATT&CK mapping is present but may lack sub-technique specificity or defensive context. Decision trees address obvious contingencies but miss edge cases. Purple team plan is superficial, listing detection tools without analyzing their actual capabilities against the planned techniques.

Below Expectations (Below 60%)

• Campaign design is generic and could apply to any adversary against any target. Insufficient threat intelligence research — APT29's specific characteristics are not reflected in the plan. ATT&CK mapping is incomplete or inaccurate. Infrastructure design lacks operational security considerations. No meaningful purple team component. Documents are disorganized or incomplete.

Ethical and Legal Considerations

Red team operations involve simulating the activities of real-world adversaries. This creates ethical and legal obligations that are even more stringent than those in standard penetration testing.

Authorization and Scope

Red team campaigns require authorization at the highest organizational level — typically the CISO or CTO, with board awareness. The authorization must explicitly cover: - Social engineering of employees (with HR and Legal involvement). - Use of simulated malware and C2 infrastructure. - Access to sensitive systems including email, financial data, and customer records. - The duration and bounds of the engagement. - Deconfliction procedures (so that the SOC can verify whether an alert is the red team or a real attacker without compromising the test).

In this capstone, you are designing the campaign, not executing it. However, your deliverables must include the authorization framework you would require before any execution could begin.

Deconfliction

Deconfliction is the process by which red team activity is distinguished from real adversary activity without revealing the red team's presence to the SOC. This typically involves: - A trusted agent within the organization (often the CISO) who can confirm that observed activity is the red team. - A deconfliction protocol: the SOC escalates suspicious activity to the trusted agent, who confirms or denies red team involvement without revealing specifics. - Emergency deconfliction: if the SOC prepares to take drastic containment action (shutting down production systems, notifying law enforcement), the red team must be able to immediately identify themselves.

Your campaign design must include a deconfliction plan.

Real-World Harm Prevention

Even in a simulated exercise, red team campaigns can cause real harm: - Phishing simulations can cause employee stress and erode trust if poorly communicated afterward. - Testing against production systems risks data corruption, service disruption, or data exposure. - Discovering a real active compromise during the exercise creates immediate legal and operational obligations.

Your campaign design must include safety mechanisms that prevent unintended harm and procedures for handling unexpected discoveries.

Legal Compliance

Financial services companies operate under strict regulatory requirements. Red team activities must be designed to avoid triggering mandatory breach notification thresholds, violating data handling requirements, or creating compliance violations. Your campaign design should explicitly address: - How you will avoid accessing real customer financial data (use synthetic or clearly marked test data). - How you will handle the discovery of actual compliance violations during the engagement. - How your phishing campaign complies with applicable regulations (financial services employees have specific security awareness training requirements that may be affected).

Responsible Knowledge

The skills and knowledge required to design a red team campaign are the same skills used by real adversaries. Throughout this capstone, you will research how to evade security controls, design phishing campaigns, and plan infrastructure compromises. This knowledge carries a responsibility: it must be used only within the bounds of authorized engagements, legal frameworks, and ethical principles. The purpose of red teaming is to make organizations more secure, not to demonstrate how to attack them. Keep this purpose central to everything you design.

Final Guidance

Red team campaign design is where technical skill meets strategic thinking. The most effective red team operators are not those who know the most exploit techniques — they are those who can think like an adversary, anticipate defensive responses, and design campaigns that realistically test an organization's security posture.

APT29 is one of the most sophisticated adversaries operating today. Emulating their approach requires you to think beyond individual techniques and consider operational tempo, patience, contingency planning, and the interplay between offense and defense. A campaign that maps twenty ATT&CK techniques without considering how FinanceForward's SOC would respond to each one has missed the fundamental purpose of adversary emulation.

The purple team component of this capstone is equally important. A red team that finds vulnerabilities but cannot articulate how to detect and prevent the attacks it demonstrated has done only half the job. The most valuable red team engagements are those that result in measurable improvements to the organization's defensive capabilities.

Approach this project as a professional engagement. Your deliverables will be evaluated not just for technical accuracy but for clarity, organization, and strategic coherence. A well-designed campaign that tells a cohesive story — from threat intelligence through attack planning through defensive validation — demonstrates the kind of thinking that defines senior red team professionals.

This capstone project is designed for educational purposes. All company names, organizational structures, and technical environments are fictional. The threat intelligence regarding APT29 references publicly available information from government advisories and commercial threat intelligence reports. Adversary emulation and red team operations must only be conducted with explicit written authorization from the target organization. Unauthorized computer access is a federal crime under the Computer Fraud and Abuse Act (18 U.S.C. Section 1030) and analogous state laws.