Hardening AD FS: Blue Team Golden SAML Defense Guide

Md. Redwan Ahmed Md. Redwan Ahmed
·
Hardening AD FS: Blue Team Golden SAML Defense Guide

Overview & Defensive Context#

In our morning threat analysis (Golden SAML: Deconstructing ADFS Token Forgery Architecture), we deconstructed the catastrophic mechanics of the Golden SAML post-exploitation technique. By compromising an on-premises Active Directory Federation Services (AD FS) server or obtaining Tier-0 administrative access to an Active Directory forest, an adversary can extract the Distributed Key Management (DKM) master symmetric key from Active Directory and decrypt the private key of the AD FS Token-Signing Certificate.

With this private key in hand, the adversary's operational dependency on the victim's network vanishes. The attacker transitions entirely offline, synthesizing cryptographically authentic SAML 2.0 assertions that impersonate any synchronized or cloud-native identity—including Global Administrators—while embedding synthetic claims asserting that hardware Multi-Factor Authentication (MFA) was successfully fulfilled.

graph TD
    subgraph "THE GOLDEN SAML DEFENSIVE DILEMMA"
        direction TB
        item_1["<b>Attack Vector</b><br/>Offline Cryptographic SAML Token Forgery"]
        item_2["<b>On-Premise Visibility</b><br/>ZERO (No DC Kerberos traffic, No AD FS logs)"]
        item_3["<b>Cloud Visibility</b><br/>VALID Sign-In (Signature matches trusted cert)"]
        item_4["<b>Defensive Trap</b><br/>Standard password resets DO NOT stop the attack"]
        item_1 --> item_2
        item_2 --> item_3
        item_3 --> item_4
    end

Why Standard Enterprise Perimeter & Endpoint Defenses Fail#

Enterprise incident response playbooks designed around traditional perimeter breaches and credential stuffing fail catastrophically against Golden SAML:

  1. The Password Reset Fallacy: When an organization detects compromised credentials, standard containment procedures dictate resetting user passwords in Active Directory and forcing session logoffs. In a Golden SAML intrusion, resetting user passwords provides zero containment. Because the adversary generates SAML assertions offline and signs them with the valid private key, cloud Service Providers (Microsoft Entra ID, AWS IAM, Salesforce) validate the digital signature—not the user's on-premises password. The attacker continues minting new sessions indefinitely.

  2. The Cloud Conditional Access & MFA Blind Spot: Federated architecture delegates MFA evaluation to the Identity Provider. Cloud Conditional Access policies evaluate claims passed in the SAML token (http://schemas.microsoft.com/claims/authnmethodsreferences). Because the adversary controls the assertion construction, they inject claims stating that strong authentication was satisfied. Cloud security policies accept the token as compliant, bypassing MFA enforcement.

  3. The On-Premises Telemetry Black Hole: Security Operations Centers (SOCs) monitoring Windows Security Event Logs on Domain Controllers look for Event ID 4624 (Successful Logon), Event ID 4625 (Failed Logon), and Kerberos ticket requests (Event IDs 4768 and 4769). Because the adversary mints assertions offline, none of these events are generated. The on-premises SIEM receives zero indicators that a user account is being actively impersonated in the cloud.

  4. The Partial Eviction Catastrophe: If an incident response team discovers threat actor activity on an on-premises workstation, rebuilds the machine, and resets administrative passwords, but fails to recognize that the AD FS Token-Signing private key was exfiltrated, the eviction is incomplete. The adversary maintains persistent, unmonitored access to all federated cloud workloads via the forged SAML backdoor.

[!WARNING] Remediating Golden SAML requires an immediate, coordinated cryptographic eviction: generating a new Token-Signing Certificate, updating federation metadata across all cloud Service Providers, revoking all active cloud refresh tokens, and hardening the Active Directory DKM container against unauthorized read access.

Architecture Hardening#

Securing hybrid identity infrastructure against Golden SAML demands an integrated, defense-in-depth model spanning on-premises Active Directory hardening, cryptographic key isolation, cross-layer telemetry correlation, and ultimately, architectural migration to cloud-native authentication.

Defense-in-Depth Architecture Flowchart#

flowchart TD
    classDef tier0 fill:#0f172a,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef crypto fill:#1e1b4b,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef detect fill:#082f49,stroke:#0284c7,stroke-width:2px,color:#bae6fd
    classDef cloud fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#a7f3d0
    classDef gate fill:#2d1b06,stroke:#f59e0b,stroke-width:2px,color:#fde68a

    subgraph Tier0Hardening ["Tier-0 Active Directory & AD FS Hardening"]
        ADFS_Server["AD FS Farm Servers"]:::tier0
        DKM_Container["AD DKM Container: CN=ADFS,CN=Microsoft..."]:::tier0
        ADFS_SACL["Audit SACL on DKM Object (Event ID 4662)"]:::gate
        gMSA_Enforcement["Enforce gMSA Dedicated Service Account"]:::tier0
    end

    subgraph KeyProtection ["Cryptographic Key Isolation"]
        CryptoEngine{"Token-Signing Key Storage"}:::crypto
        SoftwareKSP["Software KSP (Vulnerable to Memory/DPAPI Dump)"]:::tier0
        HardwareHSM["Hardware Security Module (HSM) / Azure Key Vault HSM"]:::crypto
    end

    subgraph DetectionPipeline ["Cross-Layer Telemetry & SIEM Correlation"]
        OnPremLogs["On-Premises AD FS Security Logs: Event ID 1200"]:::detect
        EntraLogs["Microsoft Entra ID Sign-in Logs: Federated Auth"]:::detect
        SentinelEngine{"SIEM / Microsoft Sentinel Correlation Engine"}:::detect
        DiscrepancyAlert["Alert: Federated Sign-in Without Matching On-Prem Event 1200"]:::tier0
    end

    subgraph ArchitecturalFix ["Permanent Modernization: Cloud-Native Auth"]
        DecomADFS["Phase Out On-Premises AD FS"]:::cloud
        EntraPHS["Microsoft Entra Password Hash Sync (PHS) + Seamless SSO"]:::cloud
        PhishResistMFA["Enforce Phishing-Resistant MFA (FIDO2 / Certificate-Based Auth)"]:::cloud
    end

    ADFS_Server --> gMSA_Enforcement
    DKM_Container --> ADFS_SACL
    ADFS_SACL --> OnPremLogs

    CryptoEngine --> SoftwareKSP
    CryptoEngine --> HardwareHSM

    OnPremLogs --> SentinelEngine
    EntraLogs --> SentinelEngine
    SentinelEngine --> DiscrepancyAlert

    DiscrepancyAlert --> DecomADFS
    DecomADFS --> EntraPHS
    EntraPHS --> PhishResistMFA

Layer 1: Restricting & Auditing the Active Directory DKM Container#

Distributed Key Management (DKM) stores the symmetric master key required to decrypt the AD FS configuration database inside an Active Directory container: CN=<ADFS-Farm-GUID>,CN=ADFS,CN=Microsoft,CN=Program Data,DC=contoso,DC=com

In poorly maintained domains, excessive permissions (such as read access granted to Domain Users or delegated help desk groups) permit unprivileged users or lateral movement agents to query the thumbnailPhoto attribute where the DKM key resides.

1. Enforcing Least Privilege Access Control Lists (ACLs)

The DKM container must be locked down strictly to the AD FS service account (preferably a Group Managed Service Account - gMSA) and Domain Admins:

POWERSHELL 
# Execute in elevated PowerShell on a Domain Controller
# 1. Resolve the AD FS DKM Container Distinguished Name
$DkmPath = "CN=ADFS,CN=Microsoft,CN=Program Data," + (Get-ADRootDSE).defaultNamingContext
$DkmContainer = Get-ADObject -SearchBase $DkmPath -Filter 'ObjectClass -eq "container"' | 
    Where-Object { $_.Name -match '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}' }

Write-Host "[+] Target DKM Container: $($DkmContainer.DistinguishedName)"

# 2. Inspect existing Access Control Entries (ACEs)
$Acl = Get-Acl -Path "AD:\$($DkmContainer.DistinguishedName)"
$Acl.Access | Select-Object IdentityReference, AccessControlType, ActiveDirectoryRights

Ensure that non-administrative accounts and broad security groups (Authenticated Users, Domain Users, Account Operators) are explicitly stripped of read access to this container.

2. Deploying a Mandatory System Access Control List (SACL) for Event ID 4662

To detect when an unauthorized principal attempts to read the DKM symmetric key, apply a directory auditing SACL targeting read operations on the container:

POWERSHELL 
# Apply SACL to audit Read operations on the DKM container
$TargetDN = $DkmContainer.DistinguishedName
$DirectoryEntry = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$TargetDN")

# Define SACL rule: Audit Success and Failure for Everyone on Read Property (0x10)
$AuditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0", # Everyone
    [System.DirectoryServices.ActiveDirectoryRights]::ReadProperty,
    [System.Security.AccessControl.AuditFlags]::Success -bor [System.Security.AccessControl.AuditFlags]::Failure
)

$DirectoryEntry.ObjectSecurity.AddAuditRule($AuditRule)
$DirectoryEntry.CommitChanges()
Write-Host "[+] SACL successfully applied to DKM container for Event ID 4662 auditing."

Layer 2: Isolating the Token-Signing Key via Hardware Security Modules (HSM)#

By default, AD FS stores its Token-Signing private key using the Microsoft Software Key Storage Provider (KSP) on local disk (%ALLUSERSPROFILE%\Microsoft\Crypto\Keys), protected by Windows DPAPI. Any local administrator on the AD FS server can dump memory or invoke DPAPI unprotect routines to export the raw private key.

To permanently prevent key exfiltration:

  1. Deploy Network-Attached or Cloud HSMs: Configure AD FS to store the Token-Signing private key inside a FIPS 140-2 Level 3 validated Hardware Security Module (e.g., Azure Dedicated HSM, Thales Luna, or AWS CloudHSM).
  2. Non-Exportable Key Flags: When keys are generated inside an HSM, cryptographic operations (such as computing the RSA-SHA256 signature for <ds:SignatureValue>) occur strictly within the cryptographic boundary of the hardware chip. The private key material never leaves the HSM hardware, rendering memory dumping and offline token forging technically impossible.

Layer 3: Cross-Layer Telemetry Pipeline (Cloud-to-Ground Reconciliation)#

The most effective detection mechanism against Golden SAML is identifying the telemetry asymmetry between the cloud Service Provider and the on-premises Identity Provider:

  • Legitimate Authentication: A cloud sign-in is preceded by an on-premises token issuance event in the AD FS Security Log (Event ID 1200 or 1202).
  • Golden SAML Attack: A cloud federated sign-in succeeds, but no matching token issuance event exists on-premises.

Organizations must stream both on-premises AD FS Security event logs and Microsoft Entra ID SigninLogs into a unified SIEM (e.g., Microsoft Sentinel or Splunk ES) and execute continuous automated reconciliation.

Production Detection Queries#

Blue teams and detection engineers must deploy multi-layered detection rules across Active Directory directory service telemetry, on-premises AD FS operational logs, and cloud sign-in logs.

1. Production Sigma Rule: Unauthorized AD FS DKM Container Access (Event ID 4662)#

The following Sigma rule detects unauthorized principals querying or reading attributes from the AD FS DKM container in Active Directory:

YAML 
title: Unauthorized Access to AD FS DKM Key Container
id: e4b2d189-9c12-4f3a-8b71-2a9f4e5c8012
status: production
description: |
  Detects read property operations on the Active Directory Federation Services (AD FS) 
  Distributed Key Management (DKM) container by user accounts other than the designated 
  AD FS Group Managed Service Account (gMSA) or trusted domain administrative processes.
  This activity is a primary indicator of Golden SAML private key exfiltration.
references:
  - https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-golden-saml
  - https://www.cisa.gov/news-events/cybersecurity-alerts/2021/01/07/detecting-post-compromise-threat-activity-microsoft

tags:
  - attack.credential_access
  - attack.t1552.004
  - attack.defense_evasion
  - attack.t1556
logsource:
  product: windows
  service: security
  definition: 'Requires Directory Service Access auditing enabled with a SACL configured on CN=ADFS,CN=Microsoft,CN=Program Data'
detection:
  selection_event:
    EventID: 4662
  selection_dkm_object:
    ObjectName|contains:
      - 'CN=ADFS,CN=Microsoft,CN=Program Data'
      - 'CN=Microsoft,CN=Program Data'
  selection_access_mask:
    AccessMask|contains:
      - '0x10'   # Read Property
      - '0x100'  # Control Access
  filter_authorized_accounts:
    SubjectUserName|endswith: '$'  # Authorized Machine or gMSA accounts
    # Add your specific AD FS service account here:
    # SubjectUserName: 'svc_adfs_gmsa$'
  condition: selection_event and selection_dkm_object and selection_access_mask and not filter_authorized_accounts
fields:
  - SubjectUserName
  - SubjectDomainName
  - ObjectName
  - ObjectServer
  - AccessMask
falsepositives:
  - Legitimate AD FS server operations during initial setup or certificate rollover.
  - Authorized directory synchronization tools (Azure AD Connect / Entra Connect).
level: critical

2. Microsoft Sentinel KQL Rule: Cloud Federated Sign-In Without On-Premises AD FS Issuance#

This Kusto Query Language (KQL) detection reconciles Microsoft Entra ID sign-in events with on-premises AD FS Event ID 1200 token issuances. A cloud federated sign-in that lacks a corresponding on-premises token issuance indicates an offline-forged Golden SAML assertion:

KQL 
// Microsoft Sentinel KQL: Detect Golden SAML Offline Token Forgery
let lookback = 2h;
let tolerance = 5m;
// 1. Gather all successful federated sign-ins from Entra ID SigninLogs
let CloudFederatedSignins = SigninLogs
    | where TimeGenerated >= ago(lookback)
    | where ResultType == 0 // Successful logon
    | where AuthenticationRequirement == "multiFactorAuthentication" or AuthenticationDetails has "Federated"
    | extend FederatedIdp = tostring(parse_json(AuthenticationDetails)[0].authenticationStepRequirement)
    | extend UserPrincipal = tolower(UserPrincipalName)
    | project CloudLogonTime = TimeGenerated, 
              UserPrincipal, 
              IPAddress, 
              ClientAppUsed, 
              CorrelationId, 
              ConditionalAccessStatus,
              ResourceDisplayName;
// 2. Gather on-premises AD FS Token Issuance events (Event ID 1200)
let OnPremAdfsIssuances = WindowsEvent
    | where TimeGenerated >= ago(lookback + tolerance)
    | where EventID == 1200 // AD FS Token Issuance Audit Event
    | extend EventDataXML = parse_xml(EventData)
    | extend IssuedUPN = tolower(tostring(EventDataXML.DataItem.Claims.Claim[0].Value))
    | project OnPremTime = TimeGenerated, IssuedUPN, Computer;
// 3. Left Anti-Join: Identify cloud sign-ins with NO matching on-premise AD FS event
CloudFederatedSignins
| join kind=leftanti (
    OnPremAdfsIssuances
) on $left.UserPrincipal == $right.IssuedUPN
| project CloudLogonTime, 
          UserPrincipal, 
          IPAddress, 
          ClientAppUsed, 
          CorrelationId, 
          ResourceDisplayName,
          AlertReason = "CRITICAL: Federated Cloud Sign-in Occurred Without Matching On-Premises AD FS Token Issuance (Golden SAML Anomaly)"

3. PowerShell Auditing Script: Verify AD FS Token-Signing Certificate State#

Execute the following PowerShell verification script to audit current token-signing certificates, verify auto-rollover settings, and inspect thumbprints against cloud federation metadata:

POWERSHELL 
# Run in elevated PowerShell on primary AD FS Server
Import-Module ADFS

Write-Host "=== [1] AD FS Token-Signing Certificate Status ===" -ForegroundColor Cyan
$AdfsCerts = Get-AdfsCertificate -CertificateType Token-Signing
foreach ($Cert in $AdfsCerts) {
    [PSCustomObject]@{
        Subject        = $Cert.Certificate.Subject
        Thumbprint     = $Cert.Certificate.Thumbprint
        IsPrimary      = $Cert.IsPrimary
        ValidFrom      = $Cert.Certificate.NotBefore
        ValidTo        = $Cert.Certificate.NotAfter
        HasPrivateKey  = $Cert.Certificate.HasPrivateKey
    } | Format-List
}

Write-Host "=== [2] AD FS AutoCertificateRollover Configuration ===" -ForegroundColor Cyan
Get-AdfsProperties | Select-Object -Property AutoCertificateRollover, CertificateRolloverInterval, CertificateDuration, CertificateThreshold | Format-List

Enterprise Mitigation Matrix#

When planning defensive engineering and remediation against Golden SAML, security leadership must weigh immediate threat containment against enterprise operational dependencies across hybrid infrastructure:

Remediation Strategy Implementation Effort Blast Radius & Operational Risk Detection & Prevention Efficacy Performance Overhead Architectural Longevity
Workaround: DKM Container SACLs & Tier-0 Network Isolation 1 - 2 Hours (Apply AD SACLs for Event ID 4662; isolate AD FS behind management firewalls) Zero Normal AD FS service operation and client authentications are unaffected. Moderate (60%) Detects reconnaissance and unauthorized LDAP reads; does not stop memory dumps. Negligible Native Active Directory audit logging. Interim Compensating Control Essential tactical barrier while preparing certificate eviction.
Hotfix: Emergency Certificate Rollover & Session Revocation 2 - 4 Hours (Force AD FS certificate roll, update Entra ID federation, revoke refresh tokens) Moderate All active cloud users are prompted to re-authenticate with credentials and MFA. High (95%) Immediately invalidates all previously stolen token-signing private keys. Zero Native AD FS and Entra ID cryptographic operations. Mandatory Incident Response Standard Neutralizes active token-signing key compromise.
Architecture Fix: Migration to Cloud-Native Entra ID (PHS) 2 - 6 Weeks (Decommission AD FS; migrate to Password Hash Sync + FIDO2 / Entra CBA) Moderate - High Requires pilot group migrations, cutover planning, and relying party migration. Absolute (100%) Completely eliminates the on-premises SAML token-signing attack surface. Positive Reduces on-premises server footprint and latency. Permanent Modernization Aligns enterprise with Zero Trust Architecture and CISA guidance.

[!IMPORTANT] The single most critical step in remediating an active Golden SAML incident is executing an emergency certificate rollover combined with cloud session revocation. Simply evicting the threat actor from on-premises endpoints leaves the cloud federation backdoor fully operational.

Incident Response & Verification Playbook#

If telemetry indicates that an AD FS server was compromised or anomalous federated cloud logons are identified, execute this four-phase incident response playbook immediately:

flowchart TD
    classDef phase fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef action fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef verify fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef warn fill:#2d1b06,stroke:#f59e0b,stroke-width:2px,color:#fde68a

    P1["Phase 1: Compromise Scoping & Key Audit"]:::phase --> P1_Action["Identify Active Token-Signing Thumbprint & DKM Access Logs"]:::warn
    P1_Action --> P2["Phase 2: Emergency Certificate Eviction Protocol"]:::phase
    
    P2 --> P2_Step1["1. Force New AD FS Token-Signing Cert via PowerShell"]:::action
    P2_Step1 --> P2_Step2["2. Update Entra ID Federation via Microsoft Graph"]:::action
    P2_Step2 --> P2_Step3["3. Purge Compromised Secondary Certificates"]:::action
    
    P2_Step3 --> P3["Phase 3: Complete Cloud Session Invalidation"]:::phase
    P3 --> P3_Step1["1. Revoke Refresh Tokens for Privileged & Synced Users"]:::action
    P3_Step1 --> P3_Step2["2. Rotate AD DKM Secret & Execute krbtgt Dual Rollover"]:::action
    
    P3_Step2 --> P4["Phase 4: Post-Eviction Verification & Health Checklist"]:::phase
    P4 --> P4_Verify["Confirm Old Certificates Rejected & SIEM Telemetry Active"]:::verify

Phase 1: Forensic Triaging & Compromise Scoping#

  1. Identify the Active Token-Signing Certificate: Record the thumbprint, expiration date, and serial number of the primary token-signing certificate on the AD FS server.
  2. Review Active Directory DKM Access Telemetry: Search Windows Security Event Logs on all Domain Controllers for Event ID 4662 matching the DKM container path (CN=ADFS,CN=Microsoft,CN=Program Data). Identify which security principals accessed thumbnailPhoto during the intrusion window.
  3. Audit Microsoft Entra ID Federation Configuration: Retrieve the trusted signing certificate thumbprints currently recognized by your cloud tenant using Microsoft Graph PowerShell:
POWERSHELL 
# Connect to Microsoft Graph with Application / Directory Admin permissions
Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"

# Inspect federation configuration for the compromised domain
Get-MgDomainFederationConfiguration -DomainName "contoso.com" | Format-List

Phase 2: Emergency Certificate Eviction Protocol#

Execute an immediate, forced certificate rollover to generate a new private key and detach the compromised certificate from the federation trust.

1. Generate a New Token-Signing Certificate on AD FS

Execute the following commands on the primary AD FS server:

POWERSHELL 
# 1. Temporarily disable automatic certificate rollover to prevent race conditions
Set-AdfsProperties -AutoCertificateRollover $false

# 2. Force immediate generation of a new primary Token-Signing Certificate
Update-AdfsCertificate -CertificateType Token-Signing -Urgent

# 3. Verify the new certificate is marked as Primary
$NewPrimaryCert = Get-AdfsCertificate -CertificateType Token-Signing | Where-Object { $_.IsPrimary -eq $true }
Write-Host "[+] New Primary Token-Signing Thumbprint: $($NewPrimaryCert.Certificate.Thumbprint)" -ForegroundColor Green

2. Push the New Certificate to Microsoft Entra ID

Update Microsoft Entra ID with the new public certificate material:

POWERSHELL 
# Export the public certificate bytes (Base64)
$CertBytes = $NewPrimaryCert.Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
$CertBase64 = [System.Convert]::ToBase64String($CertBytes)

# Update Entra ID Federation Settings
$Domain = "contoso.com"
$FederationId = (Get-MgDomainFederationConfiguration -DomainName $Domain).Id

Update-MgDomainFederationConfiguration -DomainId $FederationId -DomainName $Domain `
    -SigningCertificate $CertBase64 `
    -NextSigningCertificate $null

Write-Host "[+] Microsoft Entra ID federation successfully updated with new signing certificate." -ForegroundColor Green

3. Purge the Compromised Secondary Certificate

Remove the compromised certificate from AD FS so that tokens signed by the old key are immediately rejected:

POWERSHELL 
# Identify and delete the old compromised certificate
$OldCerts = Get-AdfsCertificate -CertificateType Token-Signing | Where-Object { $_.IsPrimary -eq $false }
foreach ($OldCert in $OldCerts) {
    Remove-AdfsCertificate -CertificateType Token-Signing -Thumbprint $OldCert.Certificate.Thumbprint -Confirm:$false
    Write-Host "[+] Removed compromised certificate thumbprint: $($OldCert.Certificate.Thumbprint)" -ForegroundColor Yellow
}

# Re-enable AutoCertificateRollover
Set-AdfsProperties -AutoCertificateRollover $true

Phase 3: Cloud Session & Identity Revocation#

Invalidating the signing certificate blocks the creation of future forged tokens. However, any active sessions or OAuth2 refresh tokens previously minted by the adversary remain valid.

1. Invalidate All Active Cloud Refresh Tokens

Force immediate revocation of all active sessions across all directory users:

POWERSHELL 
# Revoke refresh tokens across all synchronized and privileged users in Entra ID
$Users = Get-MgUser -All -Property Id, UserPrincipalName
foreach ($User in $Users) {
    Revoke-MgUserSignOut -UserId $User.Id
}
Write-Host "[+] Successfully revoked active cloud refresh tokens for all directory users." -ForegroundColor Green

2. Rotate On-Premises Active Directory Keys

  • Execute the dual krbtgt password reset protocol using the Microsoft New-KrbtgtKeys.ps1 script to invalidate all on-premises Kerberos tickets.
  • Rotate the AD FS service account password (if not operating as a gMSA) and reset local administrative passwords across all AD FS farm nodes.

Phase 4: Post-Remediation Verification & Hardening Checklist#

Before closing incident response operations, verify the following controls:

  • Verify Certificate Thumbprint Exclusivity: Confirm via Get-MgDomainFederationConfiguration that only the new Token-Signing Certificate thumbprint is registered in Microsoft Entra ID.
  • Test Forged Assertion Rejection: Replay an assertion signed with the old private key against the cloud ACS endpoint (https://login.microsoftonline.com/login.srf) and confirm that Entra ID returns AADSTS50008: Unable to verify token signature.
  • Validate Active Directory SACL: Confirm that test read operations on CN=ADFS,CN=Microsoft,CN=Program Data generate Event ID 4662 in Domain Controller Security logs.
  • Activate Sentinel KQL Reconciliation: Verify that the cross-layer correlation rule is actively alerting on any federated sign-in lacking an on-premises Event ID 1200.
  • Establish Cloud Migration Roadmap: Schedule the decommissioning of legacy on-premises AD FS infrastructure in favor of cloud-native Entra ID Password Hash Sync (PHS) with Phishing-Resistant FIDO2 authentication.

Authoritative References#

  1. Cybersecurity and Infrastructure Security Agency (CISA): Alert AA21-008A: Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments — CISA Alerts
  2. Microsoft Entra Architecture Documentation: Emergency Rotation of the AD FS Certificates and Federation Metadata — Microsoft Learn
  3. Mandiant Threat Intelligence: Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452 — Google Cloud Mandiant Blog
  4. CyberArk Labs (Original Disclosure): Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Applications — CyberArk Research
  5. OASIS Standard: Security Assertion Markup Language (SAML) V2.0 Core Specification — OASIS Open

Comments

Post a Comment

Drag or use arrow keys to pan • Click outside or press Esc to close