The Auth Stack Paradox: 10 Years of Persistence via Identity Hijacking
Just saw the report about Chinese threat actors maintaining persistence on a strictly isolated network for a decade by hijacking the authentication stack. This is terrifying but, honestly, unsurprising given how we prioritize network perimeter over identity integrity.
If you compromise the Identity Provider (IdP)—whether it's AD FS, Okta, or Ping—you don't need malware on the endpoint anymore. You are the trusted entity. The article mentions they had full visibility into administrative activity, which suggests they either cloned the token-signing certificate (Golden SAML) or established a backdoor directly in the auth pipeline.
Detection here is notoriously difficult because from the application's perspective, the user is legitimate, and the SAML assertion is validly signed. The only real indicators are anomalies in the issuance logs or the certificate metadata itself.
If you are still running on-prem AD FS, you need to be hunting for weird service ticket requests or changes to your trust relationships. I threw together a quick KQL query to check for anomalies in ADFS audit logs, specifically looking for rare Relying Party identifiers that might indicate a backdoor channel:
ADFSAudit
| where EventID == 501 // Security token request successful
| summarize Count = count() by RelyingParty, ClientIPAddress, bin(TimeGenerated, 1h)
| where Count < 5 // Filter for low-frequency, potentially stealthy access
| join kind=inner (ADFSAudit | where EventID == 501) on RelyingParty
| project TimeGenerated, RelyingParty, ClientIPAddress, UserId, AuthenticationMethod
If you own the IdP, you own the kingdom. Is anyone here still relying solely on standard AV for protecting domain controllers, or are we finally treating the auth stack as the most critical attack surface?
This is exactly why I keep pushing for Hardware Security Modules (HSMs) to protect the token-signing private keys. If they can exfil the cert, the game is over. However, the article mentioned they maintained visibility for 10 years. That implies they didn't just use the keys to log in; they likely had a persistent hook in the authentication middleware itself. If you're on AD FS, you should be monitoring for Event ID 391 (The configuration for the relying party trust was changed) religiously.
From a SOC perspective, Golden SAML is a nightmare because standard 'Impossible Travel' rules often fail if the attacker is correctly spoofing the internal IP ranges or bypassing the MFA prompt entirely via token forging. We've started correlating ADFS logs with physical access logs. If a SAML token is issued from a building that's currently closed (card access logs), we trigger an immediate critical alert. It’s a bit unconventional, but it catches the 'ghost' logins.
The 'isolated network' detail is the scariest part. It proves that air-gapping is useless if you still have valid credentials or a compromised trust mechanism. They didn't need to break through the firewall; they just waited for the admin to bridge the gap via authentication. We moved strictly to Entra ID (cloud-only) to get rid of these on-prem ADFS maintenance burdens, but that just moves the target to the cloud configuration. Have you checked your 'Trust Policies' lately?
Beyond protecting the key, monitoring the usage of token issuance is crucial. If the IdP is compromised, you need to detect anomalies in the delegation flows or sudden spikes in specific scope requests.
For SIEM correlation, use this KQL to spot high-frequency token issuance which often indicates automated forgery:
kusto
AuditLogs
| where OperationName contains "Issued"
| summarize count() by AppDisplayName, bin(TimeGenerated, 1h)
| where count_ > 50
This helps catch automated session creation even if the source looks legitimate.
Remediation is the real nightmare here. If the token-signing key is compromised, simply rotating it might not be enough if you don't know the extent of the breach. I recommend proactively polling your Federation Metadata to detect unauthorized certificate changes immediately.
Here’s a quick check to validate your signing cert thumbprint against a known good baseline:
$metadata = Invoke-WebRequest -Uri "https://your-idp/federationmetadata/2007-06/federationmetadata.xml"
if ($metadata.Content -notmatch "YOUR_KNOWN_THUMBPRINT") { Write-Warning "Thumbprint mismatch detected!" }
This catches 'shadow trust' setups before they fully weaponize the identity.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access