Investigate an Identity-Based Attack Path

📋 Overview

About This Lab

Microsoft Defender for Identity (MDI) builds behavioral profiles and lateral movement graphs that reveal how an attacker could pivot from a compromised account to high-value targets such as Domain Admins. This advanced lab walks you through a complete identity-based attack path investigation. from initial reconnaissance through credential harvesting, lateral movement, and domain dominance. You will use the MDI portal, Defender XDR Advanced Hunting (KQL), entity timelines, and MITRE ATT&CK mappings to reconstruct the full kill chain and determine the blast radius. The lab concludes with containment, remediation of insecure attack paths, and documentation of findings in a structured incident report.

🏢 Enterprise Use Case

Woodgrove Bank, a mid-size financial services firm, has detected anomalous identity activity across its Active Directory environment during routine monitoring. The SOC has received MDI alerts indicating network reconnaissance, suspicious Kerberos activity, and credential access. all originating from a single workstation in the trading floor. A threat intelligence advisory indicates that APT groups are actively targeting financial institutions using identity-based attack chains that exploit over-privileged service accounts and stale admin credentials.

Regulatory requirements (PCI-DSS, SOX) mandate full investigation and incident documentation within 72 hours, with evidence of root-cause analysis and remediation steps. Your mission: trace the full attack path, determine scope and impact, contain the threat, remediate the weaknesses, and produce a comprehensive incident report.

🎯 What You Will Learn

Understand how MDI computes lateral movement paths and identifies attack vectors to sensitive accounts
Identify and classify high-value target accounts in your directory
Navigate and interpret the MDI lateral movement graph to map attack surfaces
Simulate a reconnaissance attack and understand what signals MDI captures
Investigate reconnaissance alerts, review evidence, and determine attacker intent
Simulate credential harvesting from a compromised host and trace captured credentials
Trace lateral movement through the kill chain from initial access to domain dominance
Analyze entity timelines and activity logs to reconstruct attacker actions
Write Advanced Hunting KQL queries to correlate identity events across tables
Detect Kerberos ticket anomalies including overpass-the-hash and ticket forging
Map each attack phase to the MITRE ATT&CK framework for structured reporting
Assess the blast radius of compromised accounts and quantify exposure
Implement containment actions: disable accounts, force password resets, isolate hosts
Remediate the attack path by removing unnecessary privileges and hardening configurations
Document findings and generate a structured incident report suitable for compliance review

🔑 Why This Matters

Over 80% of breaches involve compromised credentials; understanding attack paths is essential for proactive defense. Financial services firms face average breach costs exceeding $5.9 million. rapid investigation and containment directly reduce exposure. Regulatory frameworks (PCI-DSS, SOX, GDPR) require documented incident response with evidence of root-cause analysis. Remediating lateral movement paths before exploitation reduces your attack surface by eliminating avenues an adversary would use to reach crown-jewel assets.

⚙️ Prerequisites

MDI sensors deployed on all domain controllers with healthy status (complete Lab 01)
Lab 02 completed. identity threat detection policies configured and validated (Lab 02)
Defender XDR Advanced Hunting access with at least Security Reader role
Test environment with at least two domain-joined workstations, one domain controller, and test user accounts (non-production recommended)
PowerShell 5.1+ with RSAT Active Directory module installed
Permissions: Security Administrator role in Microsoft 365 Defender; Domain Admin in the test AD environment

⚠️ Important: Perform all attack simulations exclusively in an isolated test environment. Never run offensive tools against production Active Directory. Obtain written authorization before conducting any simulated attacks.

Step 1 · Understand Lateral Movement Paths in MDI

MDI continuously analyzes authentication traffic, group memberships, and session data to compute lateral movement paths (LMPs). the shortest routes an attacker could take from any account to a sensitive target.

Key Concepts

Navigate to Microsoft Defender XDR > Identities > Lateral movement paths
Understand the three components of an LMP: source account (entry point), intermediary nodes (machines where credentials are cached), and target account (sensitive/high-value identity)
LMPs are computed every 24 hours using session data, local admin group memberships, and cached credential analysis
A path exists when a non-sensitive account has a session on a machine where a sensitive account’s credentials are cached. allowing credential harvesting and pivoting
Review the LMP summary dashboard: total paths, unique sensitive targets reachable, and most-exposed accounts

# Enumerate local admin group members across workstations to understand LMP inputs
$computers = Get-ADComputer -Filter {OperatingSystem -like "*Windows 10*"} -Properties OperatingSystem |
    Select-Object -ExpandProperty Name

foreach ($computer in $computers) {
    try {
        $admins = Invoke-Command -ComputerName $computer -ScriptBlock {
            Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass
        } -ErrorAction Stop
        Write-Host "`n[$computer] Local Administrators:" -ForegroundColor Cyan
        $admins | Format-Table -AutoSize
    } catch {
        Write-Host "[$computer] Unreachable" -ForegroundColor Yellow
    }
}

💡 Pro Tip: The more machines where a sensitive account has active sessions or cached credentials, the wider the attack surface. Focus remediation on reducing local admin sprawl and clearing stale sessions.

Step 2 · Identify High-Value Target Accounts

Before investigating attack paths, identify which accounts are classified as sensitive in MDI and which additional accounts should be tagged.

Navigate to Microsoft Defender XDR > Settings > Identities > Entity tags > Sensitive
Review auto-tagged accounts: Domain Admins, Enterprise Admins, Schema Admins, and built-in Administrator
Manually add high-value accounts: CISO, CFO, CTO, break-glass accounts, and service accounts with elevated privileges
Run the following PowerShell to identify accounts with AdminCount=1 (accounts that have had elevated privileges):

# Find all accounts with AdminCount=1 (elevated privilege history)
$adminAccounts = Get-ADUser -Filter {AdminCount -eq 1} -Properties AdminCount, MemberOf,
    LastLogonDate, PasswordLastSet, Enabled |
    Select-Object Name, SamAccountName, Enabled, LastLogonDate, PasswordLastSet,
        @{N='Groups';E={($_.MemberOf | ForEach-Object { ($_ -split ',')[0] -replace 'CN=' }) -join '; '}}

$adminAccounts | Sort-Object Name | Format-Table -AutoSize -Wrap
Write-Host "`nTotal accounts with AdminCount=1: $($adminAccounts.Count)" -ForegroundColor Cyan

# Identify stale admin accounts (no logon in 90+ days)
$stale = $adminAccounts | Where-Object {
    $_.LastLogonDate -lt (Get-Date).AddDays(-90) -and $_.Enabled -eq $true
}
Write-Host "Stale admin accounts (90+ days inactive): $($stale.Count)" -ForegroundColor Yellow
$stale | Format-Table Name, SamAccountName, LastLogonDate -AutoSize

💡 Pro Tip: Stale accounts with AdminCount=1 are prime targets for attackers. If an account hasn’t logged on in 90+ days but still has elevated privileges, disable it immediately and document the business justification.

Step 3 · Map the Attack Surface Using Lateral Movement Graph

Use the MDI lateral movement graph to visualize which accounts can reach sensitive targets and through which machines.

In Defender XDR, navigate to a sensitive user’s entity page (e.g., a Domain Admin account)
Click the Lateral movement paths tab to display the interactive graph
Examine each node: blue circles represent user accounts, gray boxes represent computers
Identify the shortest path. this is the most likely route an attacker would exploit
Note all intermediary machines; these are critical choke points for defensive action
Document the number of unique paths leading to each sensitive target
Export the graph data for offline analysis and reporting

# Query sessions on intermediary machines to validate LMP data
$intermediaryHosts = @("WS-TRADE-01", "WS-TRADE-02", "SRV-APP-03")

foreach ($host_ in $intermediaryHosts) {
    Write-Host "`n=== Sessions on $host_ ===" -ForegroundColor Cyan
    try {
        $sessions = Invoke-Command -ComputerName $host_ -ScriptBlock {
            query user 2>$null | ForEach-Object { $_.Trim() }
        } -ErrorAction Stop
        $sessions | ForEach-Object { Write-Host $_ }
    } catch {
        Write-Host "Cannot query sessions on $host_" -ForegroundColor Yellow
    }
}

# Check cached credentials on a target machine (requires local admin)
Invoke-Command -ComputerName "WS-TRADE-01" -ScriptBlock {
    # List credential profiles cached on this machine
    cmdkey /list 2>$null
}

⚠️ Important: Each intermediary machine in a lateral movement path is a potential pivot point. Prioritize machines that appear in multiple paths. securing them eliminates several attack vectors simultaneously.

Step 4 · Simulate a Reconnaissance Attack

Simulate the first phase of an identity-based attack: reconnaissance. The attacker enumerates accounts, groups, and trusts to identify targets before moving laterally.

Sign in to your test workstation (WS-TRADE-01) as a standard domain user (e.g., testuser01)
Run the reconnaissance simulation script that exercises LDAP queries, SPN enumeration, and group discovery:

# Reference: scripts/mdi/Invoke-MDIReconSimulation.ps1
# Run from the test workstation as a standard domain user

# --- Phase 1: Account and Group Enumeration ---
Write-Host "[RECON] Enumerating privileged groups..." -ForegroundColor Cyan
$groups = @("Domain Admins", "Enterprise Admins", "Schema Admins",
            "Account Operators", "Backup Operators")
foreach ($group in $groups) {
    $members = Get-ADGroupMember -Identity $group -ErrorAction SilentlyContinue
    Write-Host "  $group : $($members.Count) members" -ForegroundColor Gray
}

# --- Phase 2: SPN Enumeration (Kerberoasting recon) ---
Write-Host "`n[RECON] Enumerating Service Principal Names..." -ForegroundColor Cyan
$spnAccounts = Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
    -Properties ServicePrincipalName, MemberOf |
    Select-Object SamAccountName, @{N='SPN';E={$_.ServicePrincipalName -join '; '}}
$spnAccounts | Format-Table -AutoSize

# --- Phase 3: Trust Enumeration ---
Write-Host "`n[RECON] Enumerating domain trusts..." -ForegroundColor Cyan
Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType | Format-Table -AutoSize

# --- Phase 4: Account policy recon ---
Write-Host "[RECON] Reading default domain password policy..." -ForegroundColor Cyan
Get-ADDefaultDomainPasswordPolicy | Format-List ComplexityEnabled, LockoutThreshold,
    MaxPasswordAge, MinPasswordAge, MinPasswordLength

Wait 5–10 minutes for MDI to process the LDAP telemetry
Navigate to Microsoft Defender XDR > Incidents & alerts > Alerts and filter by source Microsoft Defender for Identity
You should see alerts for Account enumeration reconnaissance and/or Network-mapping reconnaissance (DNS)

💡 Pro Tip: Real-world attackers perform reconnaissance as their first step. MDI detects these LDAP-based enumeration queries even when performed with native tools like net group, nltest, or PowerShell AD cmdlets.

Step 5 · Investigate the Reconnaissance Alert

Open the reconnaissance alert and perform a structured investigation to determine scope and intent.

Click the Account enumeration reconnaissance alert to open the alert details page
Review the Alert story: source user, source computer, timestamp, and enumerated entities
Click the source user entity to open their profile page. review recent activity timeline
Check whether this user has legitimate reasons for querying privileged group memberships
Click the source computer to review logged-on users, installed software, and network activity
Set the alert status to In progress and assign it to yourself
Document initial findings: who, what, when, where, and preliminary assessment of intent

// KQL: Query identity reconnaissance events for the source user
IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType in ("Account Enumeration", "Group Enumeration",
    "LDAP query", "SAM-R query")
| where AccountName == "testuser01"
| project Timestamp, ActionType, AccountName, DeviceName,
    TargetAccountDisplayName, AdditionalFields
| sort by Timestamp desc

💡 Pro Tip: When investigating reconnaissance alerts, always check whether the source user is an IT administrator performing routine tasks. Context is key. a help-desk technician querying group memberships may be normal; a trading-floor user doing so is suspicious.

Step 6 · Simulate Credential Harvesting from a Compromised Host

Simulate the next phase: the attacker harvests credentials from the compromised workstation. In a real scenario, tools like Mimikatz would extract cached credentials from LSASS memory.

On the test workstation, create a simulated credential exposure scenario by logging in with multiple accounts:

# Simulate interactive logons that cache credentials on WS-TRADE-01
# Run these from a Domain Admin PowerShell session on the test DC

# Create test sessions (simulates an admin logging in to a workstation)
$cred = Get-Credential -Message "Enter svc-backup (service account) credentials"
Invoke-Command -ComputerName "WS-TRADE-01" -Credential $cred -ScriptBlock {
    Write-Host "Session established as $env:USERNAME on $env:COMPUTERNAME"
    # This caches the credential in LSASS memory
}

# Simulate NTLM authentication that MDI will detect
$adminCred = Get-Credential -Message "Enter test-admin credentials"
New-PSDrive -Name "SimShare" -PSProvider FileSystem -Root "\\WS-TRADE-01\C$" `
    -Credential $adminCred -ErrorAction SilentlyContinue
Remove-PSDrive -Name "SimShare" -ErrorAction SilentlyContinue

Write-Host "[SIM] Credential caching simulation complete" -ForegroundColor Green
Write-Host "[SIM] Check MDI for 'Suspected identity theft (pass-the-hash)' alerts" -ForegroundColor Yellow

Wait 5–15 minutes for MDI to detect the anomalous authentication patterns
Check for alerts: Suspected identity theft (pass-the-hash) or Unusual authentication activity
Note which accounts’ credentials were exposed on the machine. this forms the credential harvesting evidence

⚠️ Important: In production investigations, never use actual credential-dumping tools. MDI detects the behavioral patterns of credential theft (anomalous NTLM hashes, unusual Kerberos requests) without requiring you to replicate the actual extraction.

Step 7 · Trace Lateral Movement Through the Kill Chain

Reconstruct the attacker’s lateral movement by correlating alerts, entity activity, and authentication logs across the kill chain.

Open the Incident that MDI has auto-correlated from the reconnaissance and credential alerts
Review the Attack story graph. this visualizes the chain: source user → compromised machine → harvested credentials → target machine → sensitive account
Click each node to view detailed evidence and timestamps
Map the sequence chronologically:

// KQL: Reconstruct a lateral movement attack chain chronologically across three kill chain phases
// WHAT: Combines reconnaissance, credential access, and lateral movement events into a unified timeline
// WHY:  Incident investigation requires mapping the exact sequence: How did the attacker get in,
//       what credentials did they steal, and where did they move? This query joins three event
//       categories to show the complete kill chain from initial recon through domain compromise.
// TABLES: IdentityDirectoryEvents (recon), IdentityLogonEvents (credential access + lateral movement)
// FIELDS:
//   - ActionType: e.g., "Enumeration", "LDAP", "SAM-R" for recon; logon events for credential/lateral
//   - LogonType: "Interactive" = console logon, "RemoteInteractive" = RDP, "Network" = SMB/WMI
//   - Phase column labels each event for structured analysis
// OUTPUT: Chronological timeline with Phase, Timestamp, Action, Device, and Account columns
//         Phase 1 (Recon) should appear first, followed by Phase 2 (CredAccess), then Phase 3 (Lateral)
let attackerAccount = "testuser01";
let timeWindow = 24h;
// Step 1: Initial reconnaissance - LDAP queries, group enumeration, SAM-R calls
let recon = IdentityDirectoryEvents
| where Timestamp > ago(timeWindow)
| where AccountName == attackerAccount
| where ActionType has_any ("Enumeration", "LDAP", "SAM-R")
| project Phase="1-Recon", Timestamp, ActionType, DeviceName, AccountName;
// Step 2: Credential access - logons on the compromised host where credentials are cached in LSASS
let credAccess = IdentityLogonEvents
| where Timestamp > ago(timeWindow)
| where DeviceName == "WS-TRADE-01"   // The initially compromised workstation
| where LogonType in ("Interactive", "RemoteInteractive", "Network")
| project Phase="2-CredAccess", Timestamp, ActionType, DeviceName,
    AccountName, LogonType;
// Step 3: Lateral movement - harvested credentials used to access other machines
let lateral = IdentityLogonEvents
| where Timestamp > ago(timeWindow)
| where AccountName in ("svc-backup", "test-admin")   // Accounts whose creds were stolen
| where DeviceName != "WS-TRADE-01"   // Exclude the source machine
| project Phase="3-Lateral", Timestamp, ActionType, DeviceName,
    AccountName, LogonType;
// Combine all phases into a single chronological view
union recon, credAccess, lateral
| sort by Timestamp asc

Verify the timeline: reconnaissance happened first, followed by credential access, then lateral movement
Document each hop with source/destination, timestamp, and authentication protocol used (Kerberos vs. NTLM)

💡 Pro Tip: NTLM authentication during lateral movement is a strong indicator of pass-the-hash. Legitimate systems overwhelmingly use Kerberos. Any NTLM authentication from a workstation to a server should be investigated.

Step 8 · Analyze Entity Timelines and Activity Logs

Deep-dive into the entity timeline for each compromised account and machine to identify all attacker actions.

In Defender XDR, navigate to the entity page for testuser01
Click the Timeline tab and set the time range to cover the attack window
Filter by activity type: Logon activities, Directory activities, Alerts
Note all machines the user authenticated to. each represents a potential compromise
Repeat for each compromised account: svc-backup, test-admin
For each machine in the path, check the device timeline for process execution, file access, and network connections

// KQL: Build a comprehensive entity activity timeline across all three MDI identity tables
// WHAT: Combines logon events, directory changes, and LDAP/DNS queries for a single user identity
// WHY:  During investigation, you need a 360-degree view of everything a suspected compromised
//       account did. Each table captures different activity types:
//       - IdentityLogonEvents: Authentication events (who logged in where, using which protocol)
//       - IdentityDirectoryEvents: AD changes (password resets, group modifications, object creation)
//       - IdentityQueryEvents: LDAP/DNS queries (what the account searched for in the directory)
// OUTPUT: Unified chronological timeline with Category, Action, Device, and contextual Details
//         Look for: Recon queries followed by logons to unusual machines = lateral movement pattern
let targetUser = "testuser01";
let lookback = 48h;
// Logon events - shows where and how the user authenticated
let logons = IdentityLogonEvents
| where Timestamp > ago(lookback)
| where AccountName == targetUser
| project Timestamp, Category="Logon", Action=ActionType, Device=DeviceName,
    Details=strcat("LogonType: ", LogonType, " | Protocol: ", Protocol);
// Directory events - shows what AD objects the user modified
let dirEvents = IdentityDirectoryEvents
| where Timestamp > ago(lookback)
| where AccountName == targetUser
| project Timestamp, Category="Directory", Action=ActionType, Device=DeviceName,
    Details=tostring(AdditionalFields);
// Query events - shows what LDAP/DNS lookups the user performed (recon indicator)
let queryEvents = IdentityQueryEvents
| where Timestamp > ago(lookback)
| where AccountName == targetUser
| project Timestamp, Category="Query", Action=ActionType, Device=DeviceName,
    Details=strcat("QueryType: ", QueryType, " | Target: ", QueryTarget);
union logons, dirEvents, queryEvents
| sort by Timestamp asc

💡 Pro Tip: Entity timelines in MDI aggregate data from multiple sources. domain controller logs, RADIUS, VPN, and cloud sign-ins. This gives you a 360-degree view of the identity’s behavior across hybrid environments.

Step 9 · Use Advanced Hunting to Correlate Identity Events

Write Advanced Hunting queries to correlate identity events across multiple tables and surface hidden attacker activity.

Navigate to Microsoft Defender XDR > Hunting > Advanced hunting
Run the following queries to correlate reconnaissance with subsequent logon anomalies:

// KQL: Correlate recon with credential access. find users who
// performed enumeration followed by logon to sensitive machines
let reconUsers = IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType has_any ("Enumeration", "SAM-R")
| distinct AccountName;
IdentityLogonEvents
| where Timestamp > ago(24h)
| where AccountName in (reconUsers)
| where DeviceName has_any ("DC", "SRV", "SQL")
| summarize LogonCount=count(), Devices=make_set(DeviceName),
    Protocols=make_set(Protocol) by AccountName
| where LogonCount > 3
| sort by LogonCount desc

// KQL: Detect anomalous logon patterns. accounts authenticating
// to machines they have never accessed before (first-time access)
let baseline = IdentityLogonEvents
| where Timestamp between (ago(30d) .. ago(1d))
| where Application == "Active Directory"
| summarize KnownDevices=make_set(DeviceName) by AccountName;
IdentityLogonEvents
| where Timestamp > ago(24h)
| where Application == "Active Directory"
| join kind=inner baseline on AccountName
| where DeviceName !in (KnownDevices)
| project Timestamp, AccountName, DeviceName, LogonType, Protocol,
    DestinationIPAddress
| sort by Timestamp desc

Review results for accounts that performed reconnaissance and then accessed servers they had never touched before
Save promising queries as Custom detection rules for ongoing monitoring

💡 Pro Tip: The IdentityLogonEvents, IdentityDirectoryEvents, and IdentityQueryEvents tables are the three pillars of identity hunting in Defender XDR. Cross-joining them reveals patterns invisible in any single table.

Step 10 · Investigate Kerberos Ticket Anomalies

Kerberos ticket manipulation is a hallmark of advanced identity attacks. MDI detects overpass-the-hash, Golden Ticket, and forged PAC anomalies. Use KQL to hunt for suspicious ticket activity.

Navigate to Advanced hunting and run the following Kerberos anomaly queries:

// KQL: Detect potential overpass-the-hash attacks by correlating NTLM and Kerberos events
// WHAT: Finds accounts that authenticate via NTLM then immediately switch to Kerberos within 5min
// WHY:  Overpass-the-hash (MITRE ATT&CK T1550.002) is a technique where an attacker uses a stolen
//       NTLM hash to request a Kerberos TGT, which then provides full Kerberos authentication.
//       The telltale signature is: NTLM auth from IP X, followed by Kerberos auth from the same IP
//       within seconds to minutes. Legitimate users don't exhibit this pattern because their
//       workstations use Kerberos natively (NTLM is only a fallback).
// OUTPUT: Account, device, NTLM timestamp, Kerberos timestamp, and time delta in seconds
//         TimeDelta < 60 seconds is highly suspicious; < 300 seconds warrants investigation
IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "NTLM"
| where Application == "Active Directory"
| project NtlmTime=Timestamp, AccountName, SourceIP=IPAddress, DeviceName
| join kind=inner (
    IdentityLogonEvents
    | where Timestamp > ago(24h)
    | where Protocol == "Kerberos"
    | where Application == "Active Directory"
    | project KerbTime=Timestamp, AccountName, SourceIP=IPAddress, DeviceName
) on AccountName, SourceIP
// The Kerberos request must follow the NTLM auth within a 5-minute window
| where KerbTime between (NtlmTime .. (NtlmTime + 5m))
| project AccountName, DeviceName, NtlmTime, KerbTime,
    TimeDelta=datetime_diff('second', KerbTime, NtlmTime)
| sort by NtlmTime desc

// KQL: Detect Kerberos tickets using weak RC4 encryption (Kerberoasting/Golden Ticket indicator)
// WHAT: Finds Kerberos authentication using RC4 encryption (type 0x17/0x18) instead of AES
// WHY:  Modern AD environments should use AES (0x12) for Kerberos. RC4 (0x17 = RC4-HMAC) is
//       used by attack tools like Rubeus and Mimikatz because RC4 tickets are faster to crack.
//       Golden Ticket attacks also commonly use RC4 encryption. Any RC4 Kerberos traffic in
//       an AES-enforced environment is a strong indicator of credential-based attacks.
// FIELD: AdditionalFields.TicketEncryptionType - 0x17 = RC4-HMAC, 0x12 = AES-256
// OUTPUT: Accounts using RC4 encryption with timestamps and failure codes
//         FailureCode "0x0" = success (ticket was issued), non-zero = request failed
IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where Application == "Active Directory"
| extend TicketDetails = parse_json(AdditionalFields)
| where TicketDetails.TicketEncryptionType in ("0x17", "0x18")  // RC4-HMAC encryption types
| project Timestamp, AccountName, DeviceName, DestinationDeviceName,
    EncryptionType=tostring(TicketDetails.TicketEncryptionType),
    FailureCode=tostring(TicketDetails.FailureCode)
| sort by Timestamp desc

RC4 (0x17) encryption in Kerberos tickets is a strong indicator of credential-based attacks. modern environments should use AES (0x12)
Check for tickets with abnormally long lifetimes, which may indicate Golden Ticket usage
Cross-reference results with MDI alerts for Suspected Golden Ticket usage or Suspected overpass-the-hash attack

💡 Pro Tip: If your environment still has services requiring RC4 Kerberos encryption, document them as exceptions and create a remediation plan. AES-only Kerberos policies eliminate an entire class of ticket manipulation attacks.

Step 11 · Map Attack Path to MITRE ATT&CK Framework

Map each phase of the observed attack to the MITRE ATT&CK framework for structured analysis and reporting.

Review the incident alerts and map each to MITRE ATT&CK technique IDs (MDI provides these automatically)
Create a structured mapping table for the investigation report:

# Generate MITRE ATT&CK mapping for the attack path
$attackMapping = @(
    [PSCustomObject]@{
        Phase    = "Reconnaissance"
        Tactic   = "TA0043. Reconnaissance"
        Technique = "T1087.002. Account Discovery: Domain Account"
        Evidence = "LDAP enumeration of Domain Admins, Enterprise Admins"
        MDIAlert = "Account enumeration reconnaissance"
    },
    [PSCustomObject]@{
        Phase    = "Reconnaissance"
        Tactic   = "TA0007. Discovery"
        Technique = "T1069.002. Permission Groups Discovery: Domain Groups"
        Evidence = "Enumeration of privileged security groups"
        MDIAlert = "Account enumeration reconnaissance"
    },
    [PSCustomObject]@{
        Phase    = "Credential Access"
        Tactic   = "TA0006. Credential Access"
        Technique = "T1003.001. OS Credential Dumping: LSASS Memory"
        Evidence = "Credential harvesting from WS-TRADE-01"
        MDIAlert = "Suspected identity theft (pass-the-hash)"
    },
    [PSCustomObject]@{
        Phase    = "Lateral Movement"
        Tactic   = "TA0008. Lateral Movement"
        Technique = "T1550.002. Use Alternate Auth Material: Pass the Hash"
        Evidence = "NTLM authentication with harvested hashes"
        MDIAlert = "Suspected identity theft (pass-the-hash)"
    },
    [PSCustomObject]@{
        Phase    = "Lateral Movement"
        Tactic   = "TA0008. Lateral Movement"
        Technique = "T1021.002. Remote Services: SMB/Windows Admin Shares"
        Evidence = "SMB access to admin shares on SRV-APP-03"
        MDIAlert = "Lateral movement path detected"
    },
    [PSCustomObject]@{
        Phase    = "Privilege Escalation"
        Tactic   = "TA0004. Privilege Escalation"
        Technique = "T1558.003. Steal or Forge Kerberos Tickets: Kerberoasting"
        Evidence = "SPN enumeration followed by TGS requests with RC4"
        MDIAlert = "Suspected Kerberoasting activity"
    }
)

$attackMapping | Format-Table -AutoSize -Wrap
$attackMapping | Export-Csv -Path "MITRE_ATT&CK_Mapping.csv" -NoTypeInformation
Write-Host "`nMITRE mapping exported to MITRE_ATT&CK_Mapping.csv" -ForegroundColor Green

In the Defender XDR incident page, click MITRE ATT&CK techniques to see the auto-generated mapping
Compare the portal mapping with your manual analysis to identify any gaps
Document coverage: which techniques were detected, which were missed, and where detection gaps exist

💡 Pro Tip: MITRE ATT&CK mappings are invaluable for executive reporting. They translate technical findings into a standardized framework that security leadership and auditors understand.

Step 12 · Assess Blast Radius of Compromised Accounts

Determine the full scope of the compromise by assessing what each compromised account could access and which systems may have been affected.

For each compromised account, enumerate their group memberships, access rights, and recent activity:

# Assess blast radius for compromised accounts
$compromisedAccounts = @("testuser01", "svc-backup", "test-admin")

foreach ($account in $compromisedAccounts) {
    Write-Host "`n========================================" -ForegroundColor Cyan
    Write-Host "BLAST RADIUS: $account" -ForegroundColor Cyan
    Write-Host "========================================" -ForegroundColor Cyan

    $user = Get-ADUser -Identity $account -Properties MemberOf, LastLogonDate,
        PasswordLastSet, AdminCount, ServicePrincipalName

    # Group memberships
    Write-Host "`n[Groups]" -ForegroundColor Yellow
    $user.MemberOf | ForEach-Object {
        $groupName = ($_ -split ',')[0] -replace 'CN='
        $group = Get-ADGroup $groupName -Properties GroupScope
        Write-Host " . $groupName ($($group.GroupScope))"
    }

    # Machines where credentials may be cached (recent logons)
    Write-Host "`n[Recent Logon Machines]" -ForegroundColor Yellow
    $logons = Get-WinEvent -ComputerName "DC01" -FilterHashtable @{
        LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)
    } -ErrorAction SilentlyContinue |
        Where-Object { $_.Properties[5].Value -eq $account } |
        Select-Object @{N='Machine';E={$_.Properties[11].Value}} -Unique
    $logons | ForEach-Object { Write-Host " . $($_.Machine)" }

    # SPNs (if service account)
    if ($user.ServicePrincipalName) {
        Write-Host "`n[SPNs. Kerberoasting risk]" -ForegroundColor Red
        $user.ServicePrincipalName | ForEach-Object { Write-Host " . $_" }
    }

    Write-Host "`n[Risk Assessment]" -ForegroundColor Yellow
    $risk = if ($user.AdminCount -eq 1) { "CRITICAL. Has admin privileges" }
            elseif ($user.ServicePrincipalName) { "HIGH. Service account with SPN" }
            else { "MEDIUM. Standard user" }
    Write-Host "  Risk Level: $risk" -ForegroundColor $(if($risk -match "CRITICAL"){"Red"}elseif($risk -match "HIGH"){"Yellow"}else{"White"})
}

Quantify the exposure: number of machines accessed, sensitive data repositories reachable, and downstream accounts that could be compromised
Check whether any compromised account has access to Tier 0 assets (domain controllers, PKI, AD CS)
Document the blast radius for each account in the incident report

⚠️ Important: If any compromised account has access to Tier 0 assets, escalate the incident severity to Critical. Domain controller compromise may require full forest recovery procedures.

Step 13 · Implement Containment Actions

Execute immediate containment actions to stop the attacker’s progress and prevent further lateral movement.

From the Defender XDR incident page, use the Response actions to disable compromised accounts directly
Alternatively, use PowerShell for bulk containment:

# Containment Actions. execute with Domain Admin privileges
$incidentId = "MDI-2026-0342"
$compromised = @("testuser01", "svc-backup")
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

foreach ($account in $compromised) {
    Write-Host "`n[CONTAIN] Processing: $account" -ForegroundColor Red

    # 1. Disable the account immediately
    Disable-ADAccount -Identity $account
    Write-Host "  [OK] Account disabled" -ForegroundColor Green

    # 2. Reset the password to a random complex value
    $newPassword = [System.Web.Security.Membership]::GeneratePassword(32, 8)
    Set-ADAccountPassword -Identity $account -Reset `
        -NewPassword (ConvertTo-SecureString $newPassword -AsPlainText -Force)
    Write-Host "  [OK] Password reset" -ForegroundColor Green

    # 3. Invalidate existing Kerberos tickets (force krbtgt if needed)
    $user = Get-ADUser $account -Properties DistinguishedName
    Set-ADUser $account -Replace @{
        'msDS-AllowedToDelegateTo' = @()
    } -ErrorAction SilentlyContinue
    Write-Host "  [OK] Delegation permissions cleared" -ForegroundColor Green

    # 4. Log the containment action
    $logEntry = [PSCustomObject]@{
        Timestamp  = $timestamp
        IncidentId = $incidentId
        Account    = $account
        Action     = "Disabled, password reset, delegation cleared"
        Responder  = $env:USERNAME
    }
    $logEntry | Export-Csv "Containment_Log_$incidentId.csv" -Append -NoTypeInformation
    Write-Host "  [OK] Action logged" -ForegroundColor Green
}

# 5. Isolate compromised workstations via Defender for Endpoint
Write-Host "`n[CONTAIN] Initiate device isolation for WS-TRADE-01 via Defender XDR portal" -ForegroundColor Yellow
Write-Host "  Navigate to: Defender XDR > Assets > Devices > WS-TRADE-01 > Isolate device" -ForegroundColor Gray

Verify containment: attempt to authenticate with the disabled accounts to confirm they are blocked
Notify affected business units that service disruption may occur for the disabled service account
If the KRBTGT account is suspected compromised, initiate a double KRBTGT password reset (with 12-hour interval)

⚠️ Important: Disabling a service account may cause application outages. Coordinate with application owners and have a rollback plan ready before disabling production service accounts.

Step 14 · Remediate the Attack Path

Remove the structural weaknesses in your Active Directory that enabled the attack path. Focus on eliminating unnecessary privileges and reducing credential exposure.

Review the lateral movement path that was exploited and identify each remediation opportunity:

# Remediation Actions: harden the attack surface

# 1. Remove unnecessary local admin rights
$workstations = @("WS-TRADE-01", "WS-TRADE-02")
foreach ($ws in $workstations) {
    Write-Host "`n[REMEDIATE] Cleaning local admins on $ws" -ForegroundColor Cyan
    Invoke-Command -ComputerName $ws -ScriptBlock {
        $localAdmins = Get-LocalGroupMember -Group "Administrators"
        foreach ($admin in $localAdmins) {
            # Keep only Domain Admins and the built-in Administrator
            if ($admin.Name -notmatch "Domain Admins|Administrator$") {
                Remove-LocalGroupMember -Group "Administrators" -Member $admin.Name `
                    -ErrorAction SilentlyContinue
                Write-Host "  Removed: $($admin.Name)" -ForegroundColor Yellow
            }
        }
    }
}

# 2. Convert SPN service accounts to gMSA (eliminates Kerberoasting risk)
Write-Host "`n[REMEDIATE] Creating gMSA to replace svc-backup..." -ForegroundColor Cyan
New-ADServiceAccount -Name "gmsa-backup$" `
    -DNSHostName "gmsa-backup.woodgrove.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "SRV-APP-03$" `
    -ServicePrincipalNames "MSSQLSvc/SRV-APP-03.woodgrove.local:1433" `
    -Enabled $true
Write-Host "  [OK] gMSA created. update application to use gmsa-backup$" -ForegroundColor Green

# 3. Enable LAPS on intermediary machines
Write-Host "`n[REMEDIATE] Enabling LAPS on workstations..." -ForegroundColor Cyan
$workstations | ForEach-Object {
    Set-ADComputer $_ -Replace @{
        'ms-Mcs-AdmPwdExpirationTime' = 0
    } -ErrorAction SilentlyContinue
}
Write-Host "  [OK] LAPS expiration reset. passwords will rotate on next GP refresh" -ForegroundColor Green

# 4. Restrict privileged account logon to Tier 0 assets only
Write-Host "`n[REMEDIATE] Configuring logon restrictions for Domain Admins..." -ForegroundColor Cyan
Write-Host "  Apply GPO: Deny log on locally / Deny log on through Remote Desktop" -ForegroundColor Gray
Write-Host "  Scope: All workstations and member servers (not DCs)" -ForegroundColor Gray

Verify remediation by re-running the LMP analysis after 24 hours. the attack path should be eliminated
Implement Protected Users group membership for sensitive accounts to prevent credential caching
Deploy Credential Guard on all workstations to protect LSASS memory from credential harvesting
Review MDI Identity security assessments and address all High/Critical findings

💡 Pro Tip: The most impactful single remediation is removing unnecessary local admin rights. This breaks the credential-caching chain that enables lateral movement. Implement a Privileged Access Management (PAM) solution for just-in-time admin access.

Step 15 · Document Findings and Create Incident Report

Create a comprehensive incident report that documents the full investigation, suitable for compliance review and executive briefing.

Use the following PowerShell to generate a structured incident report:

# Generate Incident Report
$report = @"
============================================================
      INCIDENT REPORT. IDENTITY-BASED ATTACK PATH
============================================================
Incident ID    : MDI-2026-0342
Classification : Identity Compromise. Lateral Movement
Severity       : High
Status         : Contained / Remediation In Progress
Date Detected  : $(Get-Date -Format "yyyy-MM-dd")
Analyst        : $env:USERNAME

------------------------------------------------------------
1. EXECUTIVE SUMMARY
------------------------------------------------------------
An identity-based attack path was detected originating from
workstation WS-TRADE-01 on the trading floor. The attacker
performed Active Directory reconnaissance, harvested cached
credentials, and attempted lateral movement to server assets.
The attack was contained within $([math]::Round((New-TimeSpan -Start (Get-Date).AddHours(-4) -End (Get-Date)).TotalMinutes)) minutes of detection.

------------------------------------------------------------
2. ATTACK TIMELINE
------------------------------------------------------------
Phase 1. Reconnaissance : Account/group enumeration via LDAP
Phase 2. Credential Access : Credential harvesting from LSASS
Phase 3. Lateral Movement : Pass-the-hash to SRV-APP-03
Phase 4. Containment     : Accounts disabled, host isolated

------------------------------------------------------------
3. COMPROMISED ASSETS
------------------------------------------------------------
Accounts : testuser01, svc-backup
Machines : WS-TRADE-01, SRV-APP-03 (attempted)
Data     : No evidence of data exfiltration

------------------------------------------------------------
4. MITRE ATT&CK MAPPING
------------------------------------------------------------
T1087.002. Account Discovery: Domain Account
T1069.002. Permission Groups Discovery
T1003.001. OS Credential Dumping: LSASS Memory
T1550.002. Pass the Hash
T1558.003. Kerberoasting (attempted)

------------------------------------------------------------
5. CONTAINMENT ACTIONS
------------------------------------------------------------
- Compromised accounts disabled and passwords reset
- WS-TRADE-01 isolated via Defender for Endpoint
- Kerberos tickets invalidated
- Delegation permissions revoked

------------------------------------------------------------
6. REMEDIATION ACTIONS
------------------------------------------------------------
- Removed unnecessary local admin rights on workstations
- Converted svc-backup to gMSA (eliminates Kerberoasting)
- Enabled LAPS for local admin password rotation
- Restricted Domain Admin logon to Tier 0 assets only
- Added sensitive accounts to Protected Users group

------------------------------------------------------------
7. RECOMMENDATIONS
------------------------------------------------------------
- Deploy Credential Guard on all workstations (30 days)
- Implement PAM solution for just-in-time admin access
- Schedule monthly attack path reviews
- Conduct tabletop exercise for identity breach response
============================================================
"@

$report | Out-File -FilePath "Incident_Report_MDI-2026-0342.txt" -Encoding UTF8
Write-Host $report
Write-Host "`nReport saved to Incident_Report_MDI-2026-0342.txt" -ForegroundColor Green

Attach supporting evidence: KQL query results, MITRE mapping CSV, containment log, and LMP screenshots
Submit the report through your incident management system (ServiceNow, Jira, etc.)
Schedule a post-incident review meeting within 5 business days
Close the incident in Defender XDR with classification True Positive · Lateral Movement

💡 Pro Tip: For regulatory compliance (PCI-DSS, SOX), retain incident reports for at least 1 year. Include evidence of root-cause analysis and remediation timelines to satisfy audit requirements.

Summary

What You Accomplished

Understood how MDI computes lateral movement paths and identifies attack vectors to sensitive accounts
Identified and classified high-value target accounts including stale admin accounts and over-privileged service accounts
Mapped the attack surface using the lateral movement graph and identified critical choke points
Simulated reconnaissance and credential harvesting attacks to trigger MDI detections
Investigated alerts, analyzed entity timelines, and reconstructed the full attack kill chain
Wrote Advanced Hunting KQL queries to correlate identity events across multiple tables
Detected Kerberos ticket anomalies including overpass-the-hash and RC4 encryption usage
Mapped the entire attack path to the MITRE ATT&CK framework for structured reporting
Assessed the blast radius of each compromised account and quantified organizational exposure
Executed containment actions: disabled accounts, reset passwords, isolated compromised hosts
Remediated the structural weaknesses: removed local admin rights, deployed gMSA, enabled LAPS
Generated a comprehensive incident report suitable for compliance and executive review

Next Steps

Next Lab: Integrate MDI with Microsoft Sentinel and Automate Response
Deploy Credential Guard across all workstations within 30 days
Implement a Privileged Access Management (PAM) solution for just-in-time admin access
Schedule monthly attack path reviews and quarterly red team exercises
Establish identity security KPIs: mean time to detect, mean time to contain, and lateral movement path count

Resource	Description
Understand lateral movement paths	How MDI identifies and maps lateral movement attack vectors
Entity tags in MDI	Configure sensitive and honeytoken entity tags
IdentityLogonEvents table	Schema reference for identity logon hunting queries
IdentityDirectoryEvents table	Schema reference for directory change hunting queries
IdentityQueryEvents table	Schema reference for identity query hunting
Lateral movement alerts	Investigating lateral movement detections in MDI
Reconnaissance alerts	Understanding and investigating reconnaissance detections
MITRE ATT&CK: Lateral Movement	Lateral movement tactic reference and technique catalog
Identity security assessments	Posture recommendations and remediation guidance
Windows LAPS overview	Local Administrator Password Solution deployment guide