[EXP] AD FS Federation Signing-Key Exposure and Forged-Token Trust Compromise Risk

Report Type: Exploit Exposure Assessment (EXP)
Threat Category: Identity Infrastructure and Federation Trust Compromise
Assessment Date: July 15, 2026
Primary Impact Domain: Enterprise Identity and Access Trust
Secondary Impact Domains: Privileged Access, Cloud and SaaS Security, Sensitive Data Exposure, Partner Trust, Operational Continuity
Affected Asset Class: AD FS Farms, Active Directory DKM Objects, Token-Signing Certificates, Relying Parties, Cloud Tenants, SaaS Applications, VPNs, and Administrative Systems
Threat Objective Classification: Federation Signing-Key Acquisition, Forged-Token Creation, Trusted Identity Impersonation, Persistent Access, and Downstream Trust Expansion

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 15, 2026
Publication Type: Cybersecurity Research Report / White Paper

S2 BLUF

AD FS federation signing-key exposure and forged-token trust compromise create material enterprise risk because unauthorized access to Distributed Key Manager material may enable recovery of the token-signing private key and creation of federation tokens that relying parties accept as cryptographically trusted. The technical risk arises when an adversary accesses a validated AD FS DKM container, certificate backup, recovery package, identity-management platform, privileged administrative path, or another source of signing-key material and uses that trust to impersonate users, administrators, service accounts, executives, emergency accounts, or fabricated identities without completing the expected authentication and token-issuance process. Successful abuse may provide access to cloud services, SaaS platforms, VPNs, administrative portals, sensitive applications, privileged roles, regulated data, credentials, security controls, and downstream infrastructure while appearing to originate from a trusted identity provider. Immediate executive action is required to validate DKM and signing-key exposure, preserve directory and federation evidence, reconcile accepted federation sessions with expected authentication and issuance lineage, investigate privileged or sensitive downstream activity, replace signing material when exposure cannot be ruled out, invalidate affected sessions, and restore trust across every relying party that accepted the affected federation relationship.

Executive Risk Translation

AD FS signing-key exposure shifts the business risk from a single identity-server vulnerability or directory-permission weakness to uncertainty over whether the organization can still trust federation tokens, represented identities, privileged sessions, cloud access, SaaS activity, VPN connections, and application authorization decisions made through the affected trust relationship. When available evidence cannot reliably distinguish permissive access from actual key-material acquisition or legitimate token issuance from forged-token use, leadership may need to assume that identities and sessions accepted through the affected federation trust were capable of being impersonated until proven otherwise. That response may require emergency certificate replacement, federation metadata distribution, relying-party coordination, session invalidation, privileged-role review, credential remediation, cloud and SaaS investigation, legal and compliance assessment, cyber-insurance coordination, customer or partner impact analysis, executive reporting, and formal confirmation that the federation environment and its dependent applications can safely return to trusted operation.

S3 — Why This Matters Now

·        AD FS signing-key exposure can convert directory or administrative access into the ability to create federation tokens that appear cryptographically valid to applications and cloud services.

·        Access to a validated AD FS DKM container may enable recovery of protected token-signing material without malware execution or an obvious exploit process on an AD FS server.

·        Signing material may be obtained through domain controllers, backup platforms, recovery packages, identity-management systems, privileged workstations, compromised administrators, directory exports, or other trusted operational paths.

·        Forged federation tokens may allow an adversary to represent a legitimate user, privileged administrator, service account, executive, emergency account, dormant account, disabled account, terminated identity, or fabricated identity.

·        A valid token signature confirms use of trusted cryptographic material but does not prove that the AD FS farm legitimately issued the token or that the represented identity completed authentication.

·        Forged-token activity may not produce failed logons, MFA prompts, password-validation events, conventional AD FS issuance records, malware artifacts, or suspicious process execution on the federation server.

·        Password resets, MFA resets, account disablement, endpoint remediation, and ordinary session revocation may not contain the threat while compromised signing material remains trusted.

·        Downstream exposure may extend to Microsoft 365, Azure, AWS, Google Cloud, third-party SaaS, VPNs, administrative portals, internal applications, regulated data systems, developer platforms, backup environments, security platforms, and other relying parties.

·        Attackers may delay token creation or use for days or weeks after obtaining DKM or signing-key material, allowing the original access evidence to age out of common investigation windows.

·        Legitimate certificate rollover, backup, recovery, migration, disaster-recovery testing, service-account maintenance, federation testing, and incident response can resemble portions of the compromise sequence when viewed without operational context.

·        Missing AD FS issuance events cannot be treated as proof of forged-token use until logging coverage, farm-node ingestion, failover behavior, timestamp alignment, retention, and relying-party architecture have been validated.

·        Detection based only on CVE identifiers, vulnerable versions, exploit names, certificate thumbprints, unusual sign-ins, impossible travel, missing MFA, or isolated claims anomalies cannot provide durable assurance.

S4 — Key Judgments

·        AD FS signing-key exposure should be treated as a federation-trust, identity-integrity, privileged-access, cloud-access, and enterprise application risk, not only as a vulnerability-management or certificate-management issue.

·        The primary enterprise risk is reduced ability to determine whether a trusted federation token was legitimately issued or constructed by an adversary using exposed signing material.

·        Successful access to a validated AD FS DKM object by an unexpected account, host, process, service, remote session, or administrative path is a high-risk identity-infrastructure event even when downstream token abuse has not been observed.

·        Suspicious DKM access followed by certificate interaction, backup or recovery activity, archive creation, staging, transfer, private-key operations, or monitoring degradation provides stronger evidence of probable key-material handling.

·        A permissive DKM access-control condition does not prove that protected signing material was accessed or recovered.

·        A validly signed federation session that lacks expected issuance or authentication lineage becomes materially more concerning when accompanied by identity-inconsistent claims, abnormal user state, privileged access, sensitive activity, source or device anomalies, or prior key-compromise evidence.

·        Missing issuance or authentication lineage alone does not prove token forgery because logging gaps, failover, ingestion delay, clock drift, retention limits, and relying-party implementation differences can create apparent gaps.

·        Business exposure increases sharply when the affected trust provides access to cloud control planes, Microsoft 365, SaaS applications, VPNs, privileged administrative systems, identity platforms, security tools, backup platforms, financial systems, legal systems, HR systems, developer platforms, or regulated data.

·        Replacing the signing certificate may be necessary but may not be sufficient unless relying-party metadata is updated, old certificates are removed from trust, active sessions are invalidated, and persistence or credentials created through suspected forged access are addressed.

·        Account-level remediation may create false closure when the trust failure exists at the federation-signing layer rather than within the represented user’s password, MFA method, or endpoint.

·        Incomplete DKM auditing, inconsistent session identifiers, weak claims retention, limited relying-party logs, short cloud retention, and poor identity normalization increase cost because the organization may need to investigate a broader population of identities, applications, sessions, and administrative actions.

·        The most damaging outcome occurs when forged-token access enables privileged role assignment, credential creation, security-control degradation, persistence, sensitive data access, cloud or SaaS administration, lateral expansion, or broad impersonation across multiple relying parties.

S5 — Executive Risk Summary

Business Risk

AD FS federation signing-key exposure can weaken the organization’s ability to trust identity and authorization decisions across every application, cloud service, SaaS platform, VPN, administrative portal, and business system that accepts tokens from the affected federation relationship. Risk increases when AD FS provides access to privileged administration, Microsoft 365, Azure, AWS, Google Cloud, customer data, regulated information, financial systems, legal systems, HR platforms, developer environments, repositories, backup systems, security tools, identity platforms, or operational technology management. The business impact is not limited to the AD FS farm or the account represented in a suspicious token; it can expand into uncertainty over whether adversaries impersonated trusted identities, created privileged sessions, accessed sensitive data, established persistent credentials, modified security controls, changed roles, abused cloud resources, or moved through connected environments while appearing legitimate.

Technical Cause

The risk is driven by unauthorized access to AD FS signing-key material or to the mechanisms used to protect and recover that material. The enabling path may involve a validated Distributed Key Manager container, excessive directory permissions, delegated administrative rights, backup or recovery access, certificate export capability, compromised service or administrative accounts, identity-management platforms, domain-controller access, recovery packages, configuration archives, certificate stores, private-key permissions, or another trusted operational path. Technical exposure becomes material when suspicious DKM access aligns with certificate or recovery activity, private-key handling, archive staging, outbound transfer, missing authentication or issuance lineage, identity-inconsistent claims, anomalous federation acceptance, privileged downstream activity, credential creation, security-control modification, persistence, sensitive data access, or lateral expansion. Exposure increases when object-level DKM auditing, signing-certificate inventories, farm-node logging, relying-party metadata, immutable session identifiers, claims records, identity-state data, cloud audit logs, and change-management evidence are incomplete.

Threat Posture

The threat posture is elevated because exposed AD FS signing material can allow an adversary to bypass ordinary authentication controls by constructing federation tokens that relying parties continue to trust. Token use may originate from trusted infrastructure, familiar locations, corporate VPN addresses, compromised endpoints, partner networks, residential proxies, cloud systems, or normal business geographies. The posture becomes critical when the federation trust provides access to privileged accounts, emergency identities, cloud control planes, administrative portals, security platforms, backup systems, sensitive SaaS applications, customer data, regulated systems, source-code environments, deployment platforms, or multiple relying parties. The threat may remain active after password resets, MFA changes, account disablement, endpoint remediation, or patch deployment because those actions do not invalidate signing material already obtained by the adversary.

Executive Decision Requirement

Executives must require measurable assurance that every AD FS farm, DKM container, signing certificate, privileged access path, backup workflow, recovery package, trust relationship, relying party, cloud integration, and dependent application is inventoried and assessed. Leadership should require validation of DKM access history, signing-key and certificate activity, approved administrative workflows, issuance and authentication lineage, claims consistency, user state, privileged sessions, downstream administrative actions, credential creation, sensitive data access, security-control changes, and persistence. When key exposure cannot be ruled out, executives must be prepared to authorize emergency signing-certificate replacement, metadata distribution, relying-party coordination, session invalidation, credential rotation, privileged-role review, cloud and SaaS investigation, forensic preservation, legal and compliance escalation, customer or partner impact analysis, and broader identity-trust recovery. Leadership should also require evidence that identity, Active Directory, cloud, application, security, infrastructure, legal, privacy, communications, cyber-insurance, and business owners can support a coordinated response.

S6 — Executive Cost Summary

AD FS federation signing-key exposure creates financial exposure because the organization must determine whether an unauthorized principal accessed protected signing material, whether the material was successfully recovered, whether forged tokens were created, which identities may have been impersonated, and which relying parties accepted suspicious sessions. The cost profile is different from a routine AD FS patch, certificate renewal, or permission correction because a compromised signing key may undermine the trust relationship used by multiple applications and cloud services. A single exposure condition can therefore require investigation across Active Directory, AD FS, domain controllers, administrative workstations, backup systems, recovery platforms, certificate-management systems, cloud tenants, SaaS services, VPN infrastructure, security platforms, business applications, and third-party relying parties.

Response cost is driven by the work required to validate DKM object identity and auditing, reconstruct directory access, investigate privileged sessions, review certificate and recovery activity, determine whether private-key handling occurred, preserve AD FS and endpoint evidence, compare accepted federation sessions with expected issuance and authentication lineage, analyze token claims and user state, inspect downstream administrative and sensitive activity, invalidate sessions, replace signing certificates, distribute updated federation metadata, coordinate with relying-party owners, rotate credentials, review cloud and SaaS persistence, and prove that federation trust has been restored.

Cost increases materially when DKM auditing was not enabled, source-host attribution is incomplete, shared administrative accounts were used, AD FS farm nodes were not consistently ingested, issuance events have expired, relying parties do not retain assertion or session identifiers, claims metadata was discarded, applications created long-lived local sessions, cloud identities cannot be reconciled with on-premises users, certificate history is incomplete, backup or recovery records are unavailable, or third-party application owners cannot rapidly update trust metadata. The highest-cost cases occur when the affected trust provides access to cloud control planes, Microsoft 365, security platforms, backup environments, privileged administration, sensitive SaaS services, customer or regulated data, financial systems, identity systems, developer platforms, repositories, deployment environments, or a large population of dependent applications.

Low Impact Scenario

Rapid investigation confirms a vulnerable or permissive AD FS and DKM condition, suspicious enumeration, failed access, or limited administrative activity without evidence of successful unauthorized DKM access, protected signing-material handling, certificate export, recovery-package access, anomalous federation acceptance, missing validated issuance lineage, identity impersonation, privileged downstream activity, credential creation, security-control change, persistence, or sensitive data access. Directory, AD FS, endpoint, certificate, backup, change-management, relying-party, identity, cloud, SaaS, VPN, and application records support a failed, contained, approved, or non-impacting event. Response is limited to targeted patch and configuration validation, DKM permission hardening, object-auditing enablement, certificate review, focused hunting, limited host isolation, evidence preservation, administrative review, short-term enhanced monitoring, and executive assurance that federation trust was not materially affected. Estimated impact $500K - $3M.

Moderate Impact Scenario

Confirmed or strongly suspected unauthorized DKM access or probable signing-key-material handling affects one or more AD FS environments, identity-management systems, domain controllers, backup platforms, recovery systems, or privileged administrative paths. Evidence may include unexpected protected-object access, permission or ownership changes, certificate or recovery activity, archive staging, transfer behavior, signing-certificate inconsistency, or accepted federation sessions that cannot be fully reconciled with expected issuance and authentication lineage. The organization cannot immediately determine whether the signing key was recovered, whether forged tokens were used, which identities were represented, or which relying parties accepted affected sessions. Response requires enterprise-focused directory and federation investigation, endpoint and certificate analysis, signing-certificate replacement planning, relying-party coordination, federation metadata updates, session invalidation, privileged-role review, cloud and SaaS investigation, credential and token rotation, application-owner validation, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for continued activity. Estimated impact $5M - $35M.

High Impact Scenario

AD FS signing-key compromise becomes an enterprise-impact event when confirmed or suspected forged-token use results in privileged identity impersonation, cloud control-plane access, Microsoft 365 compromise, sensitive SaaS administration, VPN access, security-control degradation, credential creation, persistent role assignment, service-principal or access-key creation, regulated data exposure, customer data access, backup compromise, developer-platform access, lateral expansion, destructive activity, ransomware deployment, or broad multi-application compromise. The organization may need to assume that identities, sessions, roles, credentials, applications, cloud resources, and sensitive data accessible through the affected federation relationship were exposed until evidence proves otherwise. Response may require emergency signing-key replacement, removal of old trust certificates, accelerated metadata distribution, broad session invalidation, credential and token rotation, cloud-role restriction, application shutdown, privileged-access suspension, forensic investigation, persistence removal, data-access review, customer or partner notification analysis, privacy and regulatory escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that federation trust and dependent systems can safely return to operation. Estimated impact $40M - $200M+.

S6A — Key Cost Drivers

·        Number and sensitivity of affected AD FS farms, federation servers, Web Application Proxy systems, domain controllers, administrative workstations, identity-management platforms, backup systems, recovery platforms, certificate-management systems, cloud tenants, and relying parties.

·        Scope of unauthorized or potentially unauthorized access to validated DKM containers, protected attributes, access-control entries, recovery material, certificate stores, federation configuration, identity backups, or signing-key-related archives.

·        Number of token-signing certificates, secondary certificates, rollover certificates, recovery packages, federation trusts, claims-provider trusts, relying-party trusts, and application integrations requiring validation or replacement.

·        Availability and retention of Active Directory object-access, directory-change, AD FS authentication, AD FS issuance, claim-processing, certificate, endpoint, PowerShell, backup, recovery, network, MFA, VPN, cloud, SaaS, application, and change-management telemetry.

·        Ability to identify the exact DKM object, actor, actor SID, source host, source IP, process, logon session, administrative path, access right, certificate, artifact, and event time associated with suspicious activity.

·        Ability to distinguish routine AD FS installation, certificate rollover, backup, recovery, migration, disaster-recovery testing, service-account maintenance, federation testing, vulnerability validation, and incident response from attacker-driven activity.

·        Reliability of AD FS farm-node ingestion, event forwarding, timestamp synchronization, event retention, failover records, tracing configuration, and certificate history.

·        Availability of immutable assertion identifiers, federation-session identifiers, application-session identifiers, cloud-session identifiers, issuer, audience, subject, claims, certificate thumbprint, source, device, and relying-party context.

·        Number of applications that validate federation tokens locally, retain limited assertion metadata, create long-lived application sessions, or cannot rapidly invalidate sessions after a trust change.

·        Complexity of distributing new federation metadata, replacing signing certificates, removing prior certificates from trust, and coordinating updates across internally managed, externally hosted, partner-operated, or vendor-managed relying parties.

·        Number and privilege level of identities potentially impersonated, including administrators, executives, emergency accounts, service accounts, application owners, cloud operators, security personnel, dormant users, disabled users, and terminated identities.

·        Scope of downstream platforms potentially accessed, including Microsoft 365, Azure, AWS, Google Cloud, SaaS applications, VPNs, administrative portals, identity platforms, backup systems, security platforms, finance systems, legal systems, HR platforms, developer tools, repositories, databases, and regulated workloads.

·        Scope of credentials or persistence potentially created after suspicious federation access, including service principals, OAuth grants, application credentials, API tokens, access keys, refresh tokens, administrative accounts, privileged roles, local application sessions, and workload identities.

·        Need to review role assignments, group changes, access-policy changes, security-control changes, logging changes, identity-provider configuration, trust configuration, credential creation, data access, and application administration across multiple environments.

·        Need to invalidate federation sessions, application sessions, cloud sessions, VPN sessions, refresh tokens, API tokens, and credentials that may remain active after signing-key replacement.

·        Business disruption caused by emergency federation changes, application outages, trust-metadata propagation delays, privileged-access restrictions, cloud-role suspension, SaaS access interruption, VPN disruption, administrative freezes, and relying-party validation.

·        Dependence on third-party vendors, SaaS providers, partners, managed-service providers, and application owners to update federation metadata, remove old signing certificates, preserve logs, invalidate sessions, or investigate suspicious activity.

·        Legal, privacy, regulatory, contractual, cyber-insurance, communications, customer, partner, executive, or board-level obligations triggered by identity impersonation, privileged access, regulated data exposure, incomplete containment, or inability to prove non-exposure.

S6B — Compliance and Risk Context

Figure 1

AD FS federation signing-key exposure and forged-token trust compromise executive risk model showing how unauthorized DKM access can progress into probable signing-key recovery, forged federation-token creation, trusted identity impersonation, privileged relying-party access, cloud or SaaS compromise, security-control degradation, persistence, sensitive data exposure, operational disruption, and enterprise-level financial and regulatory impact.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

AD FS Federation Signing-Key Exposure and Forged-Token Trust Compromise Risk

Risk Description

Adversaries may obtain or recover AD FS token-signing material through unauthorized access to Distributed Key Manager objects, directory permissions, backup systems, recovery packages, certificate-management processes, privileged administrative paths, identity-management platforms, domain controllers, or related trusted infrastructure. Recovered signing material may allow construction of cryptographically valid federation tokens representing legitimate or fabricated identities without the expected authentication and AD FS issuance process. Successful abuse may enable privileged access to cloud services, SaaS applications, VPNs, administrative portals, internal systems, regulated data, security platforms, backup environments, developer platforms, and other relying parties. This may increase business interruption, identity-trust loss, credential exposure, cloud compromise, application compromise, data exposure, legal and compliance review, customer or partner notification analysis, cyber-insurance scrutiny, and board-level concern. Compliance exposure should be driven by local evidence of unauthorized DKM access, probable key-material handling, unexplained certificate activity, missing validated authentication or issuance lineage, identity-inconsistent claims, suspicious federation acceptance, privileged downstream action, credential creation, persistence, security-control change, sensitive data access, or operational impact, not by vulnerable-version status, CVE association, public exploitation reporting, permissive access, valid token signatures, unusual claims, or missing events alone.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated annualized exposure of $6M - $45M+ for materially exposed enterprise environments where AD FS supports privileged, cloud, SaaS, VPN, administrative, security, backup, identity, customer, or regulated workloads and where permissive DKM access, incomplete object auditing, broad administrative access, backup or recovery dependencies, inconsistent farm-node logging, limited token metadata, weak session correlation, short retention, large relying-party populations, third-party trust dependencies, or concentrated identity privileges increase both incident likelihood and response burden. A realized severe event may exceed $40M - $200M+ when signing-key compromise results in broad identity impersonation, cloud control-plane access, Microsoft 365 compromise, privileged SaaS administration, security-control degradation, persistent credential creation, regulated data exposure, customer or partner impact, operational disruption, ransomware or destructive activity, multi-application compromise, incomplete session invalidation, legal escalation, regulatory reporting, cyber-insurance review, communications response, or board-level intervention.

S7 — Risk Drivers

·        AD FS may function as a central trust provider for cloud services, SaaS applications, VPNs, administrative portals, internal applications, security platforms, backup systems, and regulated workloads.

·        The AD FS token-signing key is trusted across relying parties and can therefore provide access beyond the federation server or Active Directory environment where the material originated.

·        Unauthorized access to a validated DKM container may allow an adversary to recover signing material through directory, certificate, recovery, backup, or offline processing paths.

·        Signing-key exposure can allow an adversary to construct tokens without knowing the represented user’s password, possessing the user’s MFA device, or generating the normal authentication sequence.

·        A cryptographically valid token may be accepted even when the AD FS farm did not legitimately issue it.

·        Forged-token use may not generate a conventional AD FS issuance event, failed authentication, MFA prompt, password-validation event, malware alert, or suspicious process on the federation server.

·        Password reset, account disablement, MFA reset, endpoint isolation, and ordinary session revocation may not contain the threat while the signing key remains trusted.

·        Attackers may impersonate privileged administrators, executives, service accounts, emergency accounts, dormant accounts, disabled accounts, terminated users, common users, or fabricated identities.

·        Attackers may manipulate claims, roles, groups, authentication methods, subjects, audiences, issuers, token lifetimes, session identifiers, or application entitlements to match the intended target.

·        Trusted devices, corporate VPNs, familiar locations, internal relays, compromised administrative systems, partner networks, cloud hosts, and normal business hours may reduce the effectiveness of simple anomaly detection.

·        DKM access, key recovery, token construction, and token use may occur on different systems and at different times, creating a delayed and distributed investigation problem.

·        Legitimate certificate rollover, recovery, backup, migration, disaster-recovery testing, identity synchronization, claim-rule changes, federation testing, vendor support, and incident response can resemble portions of the attack chain.

·        Incomplete DKM auditing, missing source attribution, shared administrative accounts, inconsistent farm-node logging, weak certificate history, missing assertion identifiers, limited claims retention, and short cloud or SaaS retention increase uncertainty.

·        Applications may validate tokens locally, retain little federation metadata, or create long-lived local sessions that survive federation changes or ordinary identity remediation.

·        Business exposure increases when the affected federation trust provides access to privileged administration, customer information, regulated data, identity platforms, security systems, backup environments, financial applications, developer infrastructure, repositories, deployment platforms, or cloud control planes.

·        Identity impersonation, credential creation, privileged role changes, persistent cloud access, security-control degradation, data exposure, operational disruption, and incomplete containment can transform an identity-infrastructure incident into legal, regulatory, communications, cyber-insurance, customer, partner, executive, and board-level exposure.

S8 — Bottom Line for Executives

AD FS federation signing-key exposure and forged-token trust compromise should be treated as a high-priority identity-integrity, federation-trust, privileged-access, cloud-security, application-security, and business-resilience risk because unauthorized access to protected signing material can allow an adversary to create tokens that dependent systems continue to accept as trusted. The executive question is not only whether AD FS was patched, whether DKM permissions were corrected, whether the token-signing certificate was replaced, whether a public exploit exists, or whether an unusual sign-in occurred; it is whether the organization can prove that protected signing material was not acquired, that accepted federation sessions were supported by legitimate authentication and issuance lineage, and that suspicious access did not lead to identity impersonation, privileged administration, credential creation, persistence, security-control degradation, cloud or SaaS compromise, sensitive data access, or downstream expansion. Response must focus on validating DKM access, preserving directory and federation evidence, reviewing certificate and recovery activity, reconciling federation sessions, investigating downstream behavior, replacing signing keys when exposure cannot be ruled out, updating every relying party, invalidating affected sessions, rotating exposed credentials, removing persistence, and confirming that federation trust has been restored before leadership relies on the affected identity environment.

S9 — Board-Level Takeaway

AD FS signing-key compromise becomes a board-level issue when access to a protected directory object, backup, recovery package, certificate workflow, or privileged administrative path can be converted into trusted identity impersonation across cloud services, SaaS applications, VPNs, administrative systems, regulated workloads, and other business-critical relying parties. The risk is not simply that an AD FS vulnerability existed, DKM permissions were excessive, a signing certificate required replacement, a valid token appeared unusual, or an issuance event was missing; it is the possibility that adversaries used trusted signing material to bypass ordinary authentication, represent privileged identities, access sensitive systems, create persistent credentials, weaken security controls, expose regulated data, disrupt operations, or expand across multiple environments while appearing legitimate. Leadership should require evidence that DKM auditing, AD FS logging, signing-certificate governance, backup and recovery controls, relying-party inventory, immutable session correlation, claims retention, cloud and SaaS visibility, privileged-role review, session invalidation, credential rotation, emergency certificate replacement, legal readiness, communications planning, and business-continuity procedures can support rapid and defensible decisions when federation trust cannot be confirmed.

S10 — Threat Overview

AD FS federation signing-key exposure and forged-token trust compromise describe adversary behavior in which unauthorized access to Active Directory Federation Services signing material may be converted into the ability to create cryptographically valid federation tokens that relying parties accept as trusted. The activity may begin with access to a validated AD FS Distributed Key Manager container, domain controller, privileged administrative session, backup system, recovery package, identity-management platform, certificate-management process, federation configuration archive, or another trusted path capable of exposing protected signing material. Multiple vulnerabilities, permission conditions, administrative compromises, backup exposures, and recovery mechanisms may produce this behavior, but the durable enterprise risk is broader than any single CVE identifier, exploit name, proof-of-concept implementation, certificate thumbprint, access path, or affected version.

·        This is not only a vulnerable-version, CVE, KEV, proof-of-concept, certificate-thumbprint, directory-permission, unusual-sign-in, missing-MFA, impossible-travel, or missing-event model.

·        The core threat behavior is unauthorized access to protected federation signing material followed by probable private-key recovery, forged-token creation, trusted identity impersonation, or downstream access that cannot be reconciled with legitimate authentication and issuance behavior.

·        AD FS farms, domain controllers, backup and recovery systems, identity-management platforms, certificate-management systems, privileged administrative workstations, and directory-management paths represent the primary signing-material exposure surface.

·        Microsoft 365, Azure, AWS, Google Cloud, SaaS applications, VPNs, administrative portals, security platforms, backup systems, developer environments, and sensitive internal applications represent the primary downstream trust surface.

·        A valid token signature establishes cryptographic validity but does not prove that the AD FS farm legitimately generated the token or that the represented identity completed the expected authentication process.

·        Forged-token creation may occur offline and may not produce malware, process creation on an AD FS server, failed authentication, MFA activity, password validation, or a conventional token-issuance event.

·        The primary enterprise risk is reduced ability to determine whether suspicious DKM access remained limited to exposure, approved administration, backup, recovery, migration, or testing, or progressed into signing-key acquisition and trusted identity impersonation.

·        Suspected signing-key compromise creates uncertainty around federation trust, user identity, privileged sessions, application authorization, cloud access, SaaS activity, VPN access, security controls, credentials, regulated information, and downstream infrastructure.

·        Password resets, MFA resets, account disablement, endpoint remediation, ordinary session revocation, patching, and DKM permission hardening may not contain or disprove compromise when signing material was previously obtained.

·        Public reporting on individual AD FS vulnerabilities, active exploitation, proof-of-concept availability, or KEV inclusion should increase urgency without narrowing the assessment into a single-CVE, exploit-artifact, actor, or indicator-only model.

S11 — Threat Classification and Type

Threat Type

Federation signing-key exposure and forged-token identity-trust compromise risk.

Threat Sub-Type

Unauthorized AD FS DKM access, directory-permission abuse, protected signing-material exposure, certificate or private-key recovery, backup or recovery-package abuse, federation configuration access, cryptographic key handling, offline signing-key recovery, forged SAML token creation, claims manipulation, trusted identity impersonation, authentication-lineage bypass, relying-party trust abuse, privileged cloud or SaaS access, credential creation, persistence, security-control degradation, sensitive data access, and downstream infrastructure expansion.

Operational Classification

Federation signing-key compromise, identity-provider trust loss, cryptographically trusted token forgery, relying-party authorization compromise, privileged identity impersonation, cloud and application trust-path abuse, and downstream enterprise access pathway.

Primary Function

Obtain or recover AD FS token-signing material and use the resulting cryptographic trust to create federation tokens that represent legitimate or fabricated identities without the expected authentication and issuance process, enabling access to relying parties, privileged applications, cloud services, SaaS platforms, VPNs, administrative systems, sensitive information, credentials, security controls, or downstream infrastructure while creating uncertainty around identity validity, session legitimacy, containment completeness, and enterprise trust.

S12 — Campaign or Activity Overview

Figure 2

AD FS federation signing-key exposure and forged-token trust compromise activity model showing unauthorized access to DKM or related signing material, probable private-key recovery, offline or remote forged-token construction, trusted federation-token acceptance, identity impersonation, and possible privileged, persistent, sensitive, or expansive downstream activity.

This report assesses AD FS federation signing-key exposure and forged-token trust compromise as a durable behavior class rather than a single vulnerability, exploit release, directory-permission finding, certificate event, proof-of-concept repository, actor cluster, or patch event. The core activity pattern begins with unauthorized or suspicious access to a validated AD FS DKM container or another trusted source of signing material, may progress through certificate, backup, recovery, archive, transfer, or private-key handling, and may result in creation of cryptographically valid federation tokens outside the expected AD FS authentication and issuance process. Successful token use may then enable identity impersonation and one or more conditional downstream behaviors, including privileged access, sensitive data use, credential creation, persistence, security-control degradation, cloud administration, SaaS administration, or lateral expansion.

·        The activity is best understood as an identity-provider trust, privileged-access, cloud-security, application-security, credential-protection, and business-resilience threat rather than a routine patch-management or certificate-renewal issue.

·        The initial access method that provides the adversary with directory, administrative, backup, recovery, or management access may vary and is not required to be established for the signing-key-compromise behavior model to remain valid.

·        Adversaries may access signing material through domain controllers, DKM permissions, privileged accounts, backup operators, replication rights, recovery platforms, certificate-management systems, identity-management tools, administrative workstations, configuration exports, or compromised management infrastructure.

·        Discovery and collection activity may involve LDAP queries, PowerShell, directory tools, certificate-store enumeration, private-key permission checks, backup access, recovery-package access, configuration export, archive creation, staging, transfer, or cryptographic operations.

·        Activity may remain limited to broad DKM permissions, suspicious enumeration, failed access, unauthorized object access, certificate interaction, operational faults, or unconfirmed key-material handling.

·        Probable signing-key acquisition is indicated when suspicious DKM access is followed by certificate export, private-key access, recovery-package use, backup handling, encrypted archive creation, staging, transfer, or cryptographic operations where visible.

·        Forged-token construction may occur on an unmonitored system and may be separated from the original DKM access by days or weeks.

·        Suspected token forgery is indicated when a validly signed federation session lacks expected AD FS issuance or upstream authentication lineage and is supported by independent identity, claims, source, device, relying-party, privilege, or prior key-compromise evidence.

·        Identity impersonation may involve administrators, executives, emergency accounts, service accounts, dormant accounts, disabled accounts, terminated users, common users, or fabricated identities.

·        Post-acceptance activity may include privileged administration, role or group changes, service-principal creation, access-key creation, application-credential creation, API-token creation, sensitive data access, security-control modification, persistence, or expansion into connected environments.

·        Actor names, exploit names, CVE references, KEV status, public proof-of-concept releases, source infrastructure, token values, certificate thumbprints, or isolated claims anomalies should enrich the assessment rather than replace local behavior-led evidence.

S13 — Targets and Exposure Surface

The exposure surface includes AD FS environments and connected identity, directory, certificate, backup, recovery, cloud, SaaS, VPN, and application systems where unauthorized access to signing material could undermine federation trust. It also includes every relying party, privileged identity, administrative workflow, certificate process, recovery mechanism, and downstream system that depends on the affected AD FS relationship.

CVE-2026-56155 is the current vulnerability anchor for this behavior family because exploitation may expose AD FS Distributed Key Manager-protected signing material and create a path toward federation signing-key recovery. The report remains behavior-driven because the same signing-material-access, key-recovery, forged-token, identity-impersonation, and downstream trust-compromise sequence may arise through other vulnerabilities, permission weaknesses, backup exposures, recovery mechanisms, or privileged administrative compromise.

·        AD FS federation servers, federation farms, farm databases, Web Application Proxy systems, federation-service accounts, service communication certificates, token-signing certificates, token-decryption certificates, and federation configuration.

·        Active Directory domain controllers, validated AD FS DKM containers, associated key objects, directory permissions, ownership, inheritance, auditing settings, delegated rights, replication paths, backup rights, and privileged directory-administration workflows.

·        Privileged administrative workstations, jump hosts, remote-management systems, privileged-access platforms, identity-management systems, directory-management tools, monitoring systems, deployment platforms, and management agents capable of interacting with AD FS or DKM material.

·        Backup servers, recovery systems, disaster-recovery environments, configuration archives, AD FS recovery packages, directory backups, identity-infrastructure backups, certificate backups, database backups, and restoration workflows.

·        Certificate-management systems, certificate stores, private-key storage, Personal Information Exchange files, key-storage providers, recovery secrets, export processes, certificate rollover workflows, primary and secondary signing certificates, and federation metadata.

·        Relying-party trusts, claims-provider trusts, partner federation relationships, business-to-business federation, issuance rules, authorization rules, claims rules, access-control policies, federation endpoints, token lifetimes, and application trust configuration.

·        Microsoft 365, Entra ID, Azure subscriptions, Azure administrative portals, Azure resources, AWS accounts, AWS roles, Google Cloud organizations and projects, and other cloud platforms accepting identities connected to the AD FS trust.

·        SaaS applications, VPN services, remote-access systems, administrative portals, security platforms, backup consoles, virtualization platforms, developer platforms, repositories, deployment systems, financial applications, legal systems, HR platforms, and sensitive internal applications.

·        Privileged and high-value identities, including domain administrators, cloud administrators, application administrators, executives, emergency accounts, service accounts, automation accounts, security personnel, backup operators, certificate administrators, and application owners.

·        Dormant, disabled, terminated, noninteractive, service, emergency, or rarely used identities that may be impersonated because their federation use is unexpected or difficult to validate quickly.

·        Token and session attributes, including issuer, audience, subject, role, group, authentication method, token lifetime, assertion identifier, federation-session identifier, application-session identifier, cloud-session identifier, source IP, device, relying party, and claims set.

·        Downstream trust relationships, including roles, service principals, OAuth grants, application credentials, access keys, API tokens, refresh tokens, local application sessions, workload identities, databases, storage systems, secret stores, backup environments, and infrastructure-management systems.

·        Environments with incomplete DKM auditing, broad directory permissions, inconsistent farm-node logging, limited certificate history, weak private-key visibility, short token retention, missing assertion identifiers, poor identity normalization, incomplete relying-party inventory, or weak downstream session correlation.

S14 — Sectors / Countries Affected

Sectors Affected

·        Technology, SaaS, software, telecommunications, hosting, cloud-service, managed-service, and digital-platform organizations using AD FS to provide employee, customer, partner, administrator, or application access.

·        Financial services, insurance, banking, payment-adjacent, legal, consulting, and professional-services organizations using federation for privileged administration, customer information, regulated applications, remote access, cloud services, or partner relationships.

·        Healthcare, life sciences, public-sector, defense, education, research, nonprofit, and regulated-service organizations using AD FS for workforce identity, remote access, cloud integration, sensitive-data access, administrative systems, or interorganizational federation.

·        Retail, e-commerce, hospitality, travel, transportation, logistics, media, marketing, and customer-facing service organizations using federated access for business applications, cloud platforms, support systems, partner portals, or distributed workforces.

·        Manufacturing, industrial, energy, utilities, supply-chain, aerospace, engineering, and supplier-dependent organizations using AD FS for enterprise applications, remote administration, cloud services, vendor access, partner federation, production support, or privileged infrastructure management.

·        Organizations using AD FS to federate access to Microsoft 365, Azure, AWS, Google Cloud, third-party SaaS, VPNs, administrative portals, security platforms, backup systems, developer infrastructure, repositories, regulated workloads, or customer-facing applications.

·        Large enterprises, distributed organizations, hybrid-cloud operators, government contractors, multi-forest environments, partner-connected businesses, and organizations with large or complex relying-party populations.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because AD FS, Active Directory, Microsoft cloud services, third-party SaaS applications, VPN platforms, and federated enterprise applications are deployed globally.

·        Countries with large populations of hybrid identity infrastructure, Microsoft enterprise services, government contractors, regulated industries, cloud-connected organizations, multinational enterprises, and managed-service providers may face elevated operational exposure.

·        Cross-border federation, international subsidiaries, partner relationships, business-to-business trusts, regional cloud tenants, and globally distributed relying parties can expand the investigation and containment scope.

·        Country-specific impact should be assessed by AD FS deployment, DKM exposure, relying-party criticality, privileged identity concentration, cloud and SaaS dependency, regulated-data access, partner trust, telemetry maturity, notification obligations, and incident-response capability rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require sufficient capability to obtain access to Active Directory, privileged administration, backup or recovery systems, identity-management platforms, certificate workflows, or another source of AD FS signing material; identify the relevant DKM objects or recovery mechanisms; recover or reconstruct protected signing-key material; understand federation-token structure and claims; and create tokens accepted by targeted relying parties. Lower-complexity activity may use published proof-of-concept code, known DKM-access techniques, common directory tools, PowerShell, certificate utilities, backup access, recovery packages, or publicly documented token-forging methods. Higher-capability activity may involve custom directory access, offline key recovery, cryptographic processing, claims engineering, token-lifetime manipulation, audience and issuer targeting, identity selection, session blending, telemetry suppression, delayed token use, multi-application impersonation, and coordinated cloud or SaaS persistence.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may rely on one compromised administrative system, public tooling, commodity remote access, direct directory queries, common certificate utilities, local archive creation, and cloud-hosted or residential source infrastructure. Higher-maturity activity may use compromised domain controllers, trusted administrative workstations, backup systems, identity-management platforms, separate collection and token-construction systems, encrypted staging, approved cloud services, partner networks, corporate VPN paths, compromised endpoints, distributed source infrastructure, and activity designed to resemble certificate rollover, backup, recovery, migration, identity administration, or emergency access.

Operational Scale

Single signing-material exposure to multi-application and multi-cloud federation trust compromise

Operational scale ranges from suspicious access to one AD FS DKM container or signing certificate to enterprise-wide identity-trust compromise when the affected signing material is accepted by multiple relying parties, cloud services, SaaS applications, VPNs, administrative portals, and sensitive business systems. Within one organization, scale can expand from DKM access into signing-key recovery, forged-token creation, privileged identity impersonation, cloud administration, sensitive data access, persistent credential creation, security-control degradation, lateral expansion, destructive activity, or broad multi-application compromise. Partner, subsidiary, multi-domain, multi-forest, or business-to-business federation relationships may increase the scale beyond the originating AD FS environment.

Escalation Likelihood

High

Escalation likelihood is high when suspicious DKM access is followed by certificate interaction, private-key access, recovery-package use, configuration export, backup access, archive creation, staging, transfer, unusual cryptographic activity, monitoring degradation, or anomalous federation access. Escalation likelihood increases further when a validly signed token lacks expected issuance or authentication lineage and is associated with identity-inconsistent claims, a dormant or privileged identity, an unusual source or device, unexpected relying-party access, privileged administration, credential creation, persistence, sensitive data access, security-control change, or activity across multiple applications or cloud services. Escalation likelihood is highest when signing material is reused after account-level remediation or when the organization cannot rapidly replace trust across all relying parties.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        AD FS may provide centralized authentication and authorization for cloud services, SaaS applications, VPNs, administrative portals, internal applications, partner environments, and sensitive business systems.

·        A single trusted signing key may be accepted across multiple relying parties, allowing one signing-material compromise to create access opportunities beyond the AD FS farm.

·        Active Directory, DKM objects, domain controllers, privileged administrative accounts, backup systems, recovery platforms, and identity-management tools provide multiple potential paths to protected signing material.

·        Public research, proof-of-concept code, documented federation internals, directory tools, certificate utilities, and token-construction methods may lower the barrier for technically capable adversaries.

·        Signing-key possession may allow an adversary to bypass ordinary password, MFA, device, and authentication controls by presenting tokens that appear cryptographically trusted.

·        Forged-token use may be difficult to distinguish from legitimate federation when relying parties retain limited claims, issuer, certificate, assertion, source, device, or session metadata.

·        Attackers benefit from environments where DKM auditing, privileged-access governance, certificate history, backup monitoring, AD FS farm-node logging, token issuance retention, identity normalization, session correlation, and relying-party inventories are incomplete.

·        Long-lived trust relationships, slow certificate-rollover coordination, third-party relying parties, locally validated tokens, persistent application sessions, and delayed metadata propagation can increase the value of exposed signing material.

·        Privileged identities, emergency accounts, service accounts, executives, cloud administrators, application owners, security personnel, and dormant accounts provide high-value impersonation opportunities.

·        Targeting probability should be assessed through DKM exposure, privileged-access paths, backup and recovery dependencies, federation scope, relying-party criticality, identity privilege, cloud and SaaS connectivity, telemetry maturity, and local evidence of signing-material-access-to-token-abuse behavior rather than CVE count or exploit names alone.

Most Likely Targets

·        AD FS farms supporting Microsoft 365, Azure, AWS, Google Cloud, SaaS applications, VPNs, administrative portals, security platforms, backup systems, regulated workloads, or high-value internal applications.

·        Validated AD FS DKM containers, associated key objects, domain controllers, directory-service interfaces, delegated administrative paths, and access-control configurations.

·        AD FS service accounts, domain administrators, backup operators, certificate administrators, identity administrators, privileged-access accounts, emergency accounts, and compromised administrative identities.

·        Domain controllers, administrative workstations, jump hosts, identity-management systems, backup servers, recovery platforms, certificate-management systems, monitoring systems, deployment platforms, and remote-management infrastructure.

·        Certificate stores, token-signing certificates, private-key permissions, Personal Information Exchange files, recovery packages, configuration exports, federation databases, identity backups, and encrypted archives.

·        Organizations with large relying-party populations, partner federation, multi-forest environments, hybrid-cloud identity, outsourced applications, managed SaaS dependencies, or slow certificate and metadata replacement processes.

·        Privileged, dormant, disabled, terminated, service, executive, emergency, application-owner, security, backup, cloud-administrator, and other high-value identities.

·        Environments with broad DKM permissions, incomplete object auditing, weak privileged-access controls, inconsistent AD FS logging, limited token metadata, missing assertion identifiers, short retention, weak claims validation, or poor identity and session correlation.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Domain Trust Discovery

The adversary may enumerate domain trust relationships to identify connected Active Directory environments and trust paths that could expand access beyond the originating AD FS deployment.

·        T1482 — Domain Trust Discovery

Stage 2 — Federation Signing-Key Acquisition

The adversary obtains AD FS token-signing private-key material from a DKM-protected source, certificate store, backup, recovery package, configuration archive, or another identity-infrastructure source.

·        T1552.004 — Unsecured Credentials: Private Keys

Stage 3 — Forged Federation-Token Creation and Use

The adversary uses the recovered signing material to create and present forged SAML tokens containing attacker-selected identity, authorization, and lifetime claims to federated relying parties.

·        T1606.002 — Forge Web Credentials: SAML Tokens

Stage 4 — Persistent Cloud Access

After obtaining federated cloud access, the adversary may add adversary-controlled credentials to a cloud account or assign additional roles or permissions to an adversary-controlled cloud account to preserve or elevate access.

·        T1098.001 — Account Manipulation: Additional Cloud Credentials

·        T1098.003 — Account Manipulation: Additional Cloud Roles

Stage 5 — Information Repository Collection

The adversary may use forged federation access or subsequently established credentials to collect sensitive information from accessible collaboration platforms, code repositories, messaging platforms, databases, SharePoint environments, or other information repositories.

·        T1213 — Data from Information Repositories

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

AD FS federation signing-key exposure and forged-token trust compromise begin when an adversary gains access to Active Directory, privileged administration, backup or recovery infrastructure, certificate-management systems, identity-management platforms, or another trusted path capable of exposing protected federation signing material. The core attack path is movement from unauthorized DKM or signing-material access into probable private-key recovery, forged federation-token creation, trusted identity impersonation, and downstream use of the represented identity. Credential creation, persistence, security-control degradation, sensitive data access, cloud administration, SaaS administration, lateral expansion, destructive activity, ransomware deployment, and broad multi-application compromise remain conditional outcomes unless supporting telemetry confirms them.

Stage 1: AD FS and Federation Trust Discovery

The adversary identifies the AD FS environment, federation-service configuration, service accounts, DKM objects, domain relationships, signing certificates, recovery mechanisms, relying-party trusts, claims rules, authorization paths, and downstream applications that depend on the federation relationship. Observable evidence may include LDAP or Global Catalog queries, PowerShell activity, directory-management tools, certificate-store enumeration, AD FS configuration commands, trust discovery, service-account discovery, permission review, backup inventory access, or unusual administrative interaction with identity infrastructure. This stage does not establish signing-key compromise because legitimate administration, migration, backup, recovery, security testing, and troubleshooting may generate similar behavior. It becomes material when discovery activity originates from an unexpected account, host, process, remote session, administrative path, or recently elevated identity and is followed by DKM access or protected signing-material handling.

Stage 2: Federation Signing-Material Access

The adversary accesses a validated AD FS DKM container, associated key object, certificate store, recovery package, federation configuration backup, identity-infrastructure archive, or another source capable of exposing protected token-signing material. Observable evidence may include successful object access, control access, protected-attribute reads, permission changes, ownership changes, inheritance changes, auditing changes, backup access, recovery-package use, certificate interaction, or activity from an unexpected account or administrative system. This stage becomes the central exposure point when successful access to validated signing-material sources occurs outside an approved installation, certificate-management, backup, recovery, migration, disaster-recovery, or incident-response workflow.

Stage 3: Probable Private-Key Recovery and Material Handling

Following access to protected signing material, the adversary may recover, export, archive, stage, transfer, decrypt, reconstruct, or otherwise process the token-signing private key. Observable evidence may include certificate export, Personal Information Exchange file creation, private-key permission access, recovery-package handling, backup extraction, encrypted archive creation, configuration export, cryptographic operations, unusual file staging, removable-media activity, cloud-storage transfer, email transfer, or process-linked outbound communication. Private-key recovery may occur offline or on an unmonitored system, so direct cryptographic evidence may be unavailable. This stage should be classified as probable key-material acquisition when suspicious DKM access aligns with one or more protected-key-handling behaviors, not as confirmed recovery without stronger evidence.

Stage 4: Forged Federation-Token Creation

The adversary uses recovered signing material to construct a SAML token outside the expected AD FS authentication and issuance process. The token may represent a legitimate, privileged, dormant, disabled, terminated, service, executive, emergency, or fabricated identity and may contain attacker-selected issuer, audience, subject, role, group, authentication method, token lifetime, session identifier, or entitlement claims. Token construction may occur on infrastructure unrelated to the AD FS farm and may generate no observable process, authentication, MFA, or issuance telemetry within the monitored environment. This stage becomes operationally visible when a relying party accepts a validly signed federation token that cannot be reconciled with expected AD FS issuance or upstream authentication lineage and independent behavioral anomalies are present.

Stage 5: Trusted Identity Impersonation

The adversary presents the forged token to a relying party, which accepts the token because it is signed with trusted AD FS signing material. Observable evidence may include successful federation access without expected issuance or authentication lineage, identity-inconsistent claims, access by dormant or disabled accounts, privileged application use, unusual source or device context, unexpected application access, long-lived sessions, or continued access after password reset, MFA reset, account disablement, or ordinary session revocation. This stage becomes high priority when the represented identity, role, claims, relying party, source, device, or session behavior is inconsistent with current directory state, entitlement, employment status, or historical use.

Stage 6: Downstream Trust Expansion

The adversary uses the impersonated identity or credentials created after federation access to administer cloud services, SaaS platforms, VPNs, applications, security tools, backup systems, developer platforms, repositories, databases, storage, or other connected systems. Observable evidence may include privileged administration, role or group changes, service-principal creation, OAuth grants, access-key creation, API-token creation, application-credential addition, security-control changes, sensitive data access, persistent application sessions, lateral movement, or access across multiple relying parties. This stage becomes critical when downstream behavior aligns with suspected forged-token use by identity, session, issuer, audience, relying party, source, device, administrative action, or bounded time window.

S19 — Attack Chain Risk Amplification Summary

AD FS federation signing-key exposure amplifies risk because it can convert access to one protected identity-infrastructure path into the ability to create cryptographically valid tokens accepted across multiple relying parties. The chain becomes materially more dangerous when suspicious DKM access is followed by protected-key handling, a validly signed session lacks expected issuance or authentication lineage, a high-value identity is represented, or downstream privileged and sensitive activity occurs.

·        Broad or excessive DKM permissions increase exposure because more accounts, systems, backup paths, and administrative workflows may be capable of reaching protected signing material.

·        Unexpected DKM access increases concern when the actor, source host, process, remote session, access right, administrative path, or timing does not align with an approved workflow.

·        Permission, ownership, inheritance, or auditing changes amplify risk because they may create, preserve, conceal, or expand unauthorized access to signing material.

·        Certificate export, recovery-package access, backup extraction, archive creation, staging, transfer, or cryptographic activity increases confidence that protected material may have been collected or processed.

·        Offline key recovery increases uncertainty because successful private-key reconstruction may leave no definitive event on the AD FS server.

·        Forged-token creation bypasses normal authentication assurance because the adversary may not need the represented user’s password, MFA device, managed endpoint, or expected logon sequence.

·        Valid signatures amplify the deception because relying parties may accept the token as trusted even when the AD FS farm did not legitimately issue it.

·        Claims manipulation increases impact when the adversary assigns privileged roles, groups, authentication methods, audiences, subjects, token lifetimes, or application entitlements inconsistent with the represented identity.

·        Privileged, executive, emergency, service, dormant, disabled, terminated, or rarely used identities increase risk because their access may provide high-value privileges or delay rapid validation.

·        Multiple relying parties increase the blast radius because one signing-key compromise may enable access to cloud services, SaaS applications, VPNs, administrative portals, security platforms, backup environments, developer systems, and sensitive business applications.

·        Long-lived local application sessions increase containment difficulty because relying-party access may persist after signing-key replacement or ordinary account remediation.

·        Credential and persistence creation increase residual risk when forged access is converted into service principals, OAuth grants, access keys, API tokens, refresh tokens, application credentials, privileged roles, or local accounts.

·        Security-control degradation increases uncertainty when logging, monitoring, audit, endpoint protection, identity controls, cloud security, or alerting is weakened after suspected federation access.

·        Cloud and SaaS administration increase enterprise exposure because the impersonated identity may access control-plane functions, data repositories, identities, workloads, storage, backups, and business-critical services.

·        Partner, subsidiary, multi-domain, multi-forest, and business-to-business federation relationships may extend the investigation beyond the originating AD FS environment.

·        Delayed token use increases investigation difficulty because the original DKM access or key-handling evidence may fall outside common retention and correlation windows.

·        Incomplete DKM auditing, inconsistent farm-node ingestion, weak assertion retention, missing session identifiers, limited claims visibility, and fragmented downstream logs may force a broader identity, application, and cloud investigation.

·        Response burden increases because teams may need to replace signing certificates, distribute metadata, remove old trust, invalidate sessions, rotate credentials, review privileged roles, investigate downstream systems, and prove that federation trust has been restored.

S20 — Tactics, Techniques, and Procedures

Figure 3

AD FS and Federation Trust Discovery

Adversaries may enumerate AD FS farms, service accounts, domain trusts, DKM containers, certificate stores, recovery mechanisms, relying-party trusts, claims rules, authorization rules, endpoints, token lifetimes, and downstream applications. Observable behavior may include LDAP or Global Catalog queries, PowerShell activity, AD FS administration commands, certificate-store enumeration, trust discovery, service-account discovery, permission review, or backup and recovery inventory access. This behavior becomes risk-relevant when it originates from an unexpected account, host, process, remote session, or administrative path and is followed by access to validated signing-material sources.

Distributed Key Manager Access

Adversaries may access, read, modify, take ownership of, change permissions on, alter inheritance for, or reduce auditing on validated AD FS DKM containers and associated objects. Activity may occur through domain controllers, administrative workstations, directory-management tools, backup systems, identity platforms, remote sessions, or compromised privileged accounts. This behavior becomes high priority when the accessed object and right are validated and the actor, source, workflow, or timing is inconsistent with approved AD FS administration, backup, recovery, migration, or incident response.

Certificate, Recovery, and Private-Key Material Handling

Adversaries may enumerate certificate stores, inspect private-key permissions, access recovery packages, extract backups, export certificates, create Personal Information Exchange files, archive identity material, stage protected files, transfer data, or perform cryptographic operations. This behavior becomes materially significant when it follows suspicious DKM access, involves an unusual process or source, creates anomalous sensitive artifacts, uses unexpected staging paths, or is followed by rare outbound communication.

Forged Federation-Token Construction

Adversaries may use recovered AD FS signing material to generate SAML tokens outside the expected authentication and token-issuance process. Tokens may include manipulated subjects, roles, groups, authentication methods, audiences, issuers, validity periods, session identifiers, or application entitlements. Token construction may occur offline and may generate no observable activity on the AD FS farm. Detection therefore depends on identifying accepted sessions that lack expected issuance or authentication lineage and contain independent behavioral inconsistencies.

Trusted Identity Impersonation

Adversaries may present forged federation tokens as privileged administrators, executives, service accounts, emergency identities, dormant users, disabled users, terminated users, common users, or fabricated identities. This behavior becomes high risk when the represented account state, claims, privilege, source, device, application, relying party, or historical use is inconsistent with legitimate activity.

Relying-Party and Cloud Access

Adversaries may use forged tokens to access Microsoft 365, Azure, AWS, Google Cloud, SaaS platforms, VPNs, administrative portals, security systems, backup platforms, developer environments, repositories, financial systems, regulated applications, and other relying parties. This behavior becomes materially significant when accepted federation access lacks expected lineage and is followed by privileged administration, sensitive data access, credential creation, security-control change, or access to applications outside the represented identity’s normal portfolio.

Persistent Identity and Credential Creation

Adversaries may convert temporary federated access into durable control by creating service principals, OAuth grants, application credentials, access keys, API tokens, refresh tokens, administrative accounts, privileged roles, local application sessions, or workload identities. This behavior becomes high priority when the creation follows anomalous federation access and is not supported by an approved administrative or application workflow.

Security-Control and Visibility Degradation

Adversaries may disable or reduce AD FS tracing, directory auditing, event forwarding, endpoint monitoring, cloud logging, application audit, identity protection, or security controls after gaining trusted access. Observable behavior may include audit-policy changes, log clearing, forwarding interruption, monitoring exclusions, agent failure, role modification, or security-policy weakening. This behavior becomes materially significant when it follows suspicious DKM, signing-key, token-lineage, or privileged identity activity.

Operational Blending With Identity Administration

Adversaries may blend malicious behavior into legitimate certificate rollover, backup, recovery, migration, disaster-recovery testing, service-account maintenance, federation testing, directory administration, cloud administration, security operations, vendor support, or incident response. This blending is effective because identity environments routinely generate privileged directory access, certificate interaction, configuration export, administrative sessions, claims changes, trust changes, and downstream access. Detection and response require correlation across the DKM object, actor, source, process, remote session, certificate, issuer, audience, subject, claims, session, relying party, device, administrative action, change record, and bounded time window rather than reliance on one event.

Post-Remediation Trust Validation Failure

Adversaries may retain access through previously obtained signing material, long-lived application sessions, refresh tokens, access keys, API tokens, service principals, application credentials, or privileged roles after patching, DKM hardening, password reset, MFA reset, account disablement, endpoint remediation, or certificate replacement. This behavior becomes high priority when suspicious federation access, privileged activity, credential use, security-control change, or sensitive access continues after remediation and cannot be tied to approved recovery or validation activity.

S20A — Adversary Tradecraft Summary

AD FS federation signing-key exposure and forged-token trust compromise target the trust relationship among Active Directory, DKM-protected signing material, AD FS token issuance, cryptographic signature validation, represented identities, claims, relying parties, privileged applications, cloud services, and downstream authorization. The adversary objective is to convert access to protected federation material into trusted identity impersonation while avoiding or bypassing the normal password, MFA, device, authentication, and issuance controls relied upon by the organization.

·        The core tradecraft pattern is federation-environment discovery followed by unauthorized DKM or signing-material access, probable private-key recovery, forged-token creation, trusted identity impersonation, and possible downstream privilege or data access.

·        The behavior is not dependent on a single CVE, exploit name, vulnerable version, proof-of-concept repository, certificate thumbprint, directory path, token value, source IP, actor name, or static indicator.

·        Adversaries may use LDAP, PowerShell, directory-management tools, certificate utilities, backup systems, recovery packages, identity-management platforms, administrative sessions, archive tools, transfer mechanisms, or custom cryptographic processing.

·        Private-key recovery and token construction may occur offline or on an unmonitored system, separating the original signing-material access from later federation abuse.

·        A valid token signature confirms use of trusted signing material but does not confirm legitimate AD FS issuance or legitimate authentication by the represented identity.

·        Adversaries may manipulate subjects, roles, groups, authentication methods, audiences, issuers, token lifetimes, session identifiers, or entitlements to match the targeted relying party.

·        High-value impersonation targets may include administrators, executives, emergency accounts, service accounts, cloud operators, application owners, security personnel, dormant users, disabled users, terminated users, or fabricated identities.

·        Trusted infrastructure, familiar source locations, corporate VPN paths, compromised endpoints, partner networks, residential proxies, cloud systems, and normal business hours may help forged-token use blend into expected activity.

·        Credential creation, privileged-role assignment, persistent sessions, OAuth grants, service principals, access keys, API tokens, and application credentials may preserve access after the forged session ends.

·        Detection requires visibility into DKM access, certificate and recovery activity, key-material handling, issuance and authentication lineage, token claims, identity state, relying-party acceptance, session identifiers, source and device context, privileged actions, and downstream data access.

·        Response requires treating suspected signing-key exposure as an identity-provider trust and enterprise authorization incident, not only as a vulnerable-version, directory-permission, certificate-management, or account-remediation issue.

·        The behavior remains durable because the adversary objective is to abuse trusted federation signing material and relying-party acceptance regardless of the initial access method, vulnerability, recovery mechanism, token-construction tool, represented identity, or downstream platform used.

S21 — Detection Strategy Overview

Detection Philosophy

Detect AD FS federation signing-key exposure and forged-token trust compromise through correlated behavior across Active Directory, Distributed Key Manager access, AD FS administration, certificate and key handling, federation-token issuance, authentication lineage, relying-party acceptance, trusted identity use, and downstream application or cloud activity. The durable detection model is unauthorized access to validated AD FS DKM key material followed by probable token-signing private-key acquisition, anomalous federation-token use, trusted identity impersonation, or downstream access that cannot be reconciled with legitimate authentication and issuance behavior. CVE identifiers, vulnerable-state findings, valid token signatures, unusual sign-ins, or missing AD FS events are prioritization inputs and must not be treated as standalone proof of compromise.

Primary Detection Anchors

·        Successful read or control-access activity involving the validated AD FS DKM container or associated key objects from an unexpected account, host, process, service, or administrative path.

·        Permission, ownership, inheritance, or auditing changes affecting the validated AD FS DKM container outside an approved administrative workflow.

·        DKM access by privileged users, delegated administrators, service accounts, backup operators, directory-management platforms, or remote sessions that do not normally interact with AD FS key material.

·        Suspicious directory-query, PowerShell, certificate-management, backup, export, archive, or transfer activity near DKM access.

·        Access to AD FS token-signing private-key material, certificate stores, recovery packages, federation configuration backups, or identity-infrastructure archives outside approved activity.

·        Unexpected token-signing certificate export, addition, replacement, promotion, rollover, or private-key permission change.

·        Validly signed federation access with no corresponding expected AD FS issuance or upstream authentication lineage after telemetry completeness has been validated.

·        Tokens containing claims, roles, groups, authentication methods, audiences, issuers, subjects, or lifetimes inconsistent with the represented identity or relying-party policy.

·        Federated use of dormant, disabled, terminated, service, emergency, executive, administrative, or otherwise high-value identities without expected operational context.

·        Privileged application, SaaS, cloud, VPN, or administrative access following anomalous federation-token acceptance.

·        Sensitive data access, role modification, security-control change, credential creation, persistence, or lateral expansion following suspected forged-token use.

·        Similar anomalous token or identity behavior across multiple relying parties, applications, cloud services, or identities within a bounded time window.

Detection Prioritization Model

·        Prioritize unauthorized DKM access followed by certificate activity, key-material handling, token anomalies, identity impersonation, or downstream access.

·        Prioritize validly signed federation access that lacks expected issuance and authentication lineage after logging gaps, farm-node differences, ingestion delays, retention limits, and relying-party architecture have been excluded.

·        Prioritize token-signing certificate access or export by unusual accounts, hosts, processes, remote sessions, backup contexts, or management platforms.

·        Prioritize accepted tokens with privileged, impossible, identity-inconsistent, or policy-inconsistent claims.

·        Prioritize anomalous federation access involving privileged, dormant, disabled, terminated, service, emergency, or high-value identities.

·        Prioritize anomalous federation sessions followed by administrative action, cloud control-plane change, sensitive data access, credential creation, persistence, or security-control degradation.

·        Treat isolated DKM exposure, directory access, certificate activity, missing MFA, impossible travel, or unusual claims as supporting evidence unless corroborated.

Correlation Strategy (Strict Enforcement)

Do not promote a vulnerable AD FS deployment, permissive DKM access-control list, valid token signature, missing AD FS event, unusual claims set, rare source IP, or downstream application anomaly to confirmed compromise without correlation by DKM object, account, source host, process, remote session, certificate, issuer, audience, subject, claims, assertion identifier, session identifier, relying party, device, source IP, application, administrative action, or bounded time window.

Use the following confidence progression:

·        DKM exposure: access controls permit broader access than intended, but unauthorized access has not been observed.

·        Suspicious DKM access: validated DKM objects are accessed by an unexpected account, host, process, or administrative path.

·        Probable key-material acquisition: suspicious DKM access is followed by certificate access, export, backup, archive, staging, transfer, or private-key operations where visible.

·        Suspected token forgery: a validly signed token lacks expected issuance and authentication lineage or contains identity-inconsistent claims after telemetry limitations have been excluded.

·        Trusted identity impersonation: a suspected forged token is accepted as a specific user or privileged identity by a relying party.

·        Downstream compromise: the impersonated identity is used for privileged action, sensitive access, persistence, credential creation, security-control change, or lateral expansion.

Absence of AD FS issuance telemetry must not be treated as forged-token proof until logging coverage, farm-node ingestion, retention, failover, timestamp alignment, and relying-party behavior have been validated. Signature validity confirms cryptographic trust only. It does not prove that the AD FS farm legitimately generated the token or that the represented identity completed authentication.

Telemetry Prioritization

·        Active Directory object-access and directory-change auditing for the validated AD FS DKM container.

·        AD FS administrative, authentication, token-issuance, certificate, trust, claim-rule, and configuration telemetry.

·        Endpoint telemetry from AD FS servers, domain controllers, administrative workstations, backup platforms, identity-management hosts, and suspected source systems.

·        Certificate-store, file, Registry, PowerShell, remote-management, backup, archive, and transfer telemetry.

·        Cryptographic-provider and private-key-operation telemetry where available.

·        MFA, Kerberos, password-validation, device, VPN, privileged-access, and session-initiation telemetry.

·        Relying-party, SaaS, Entra ID, Microsoft 365, Azure, AWS, GCP, VPN, administrative portal, and sensitive-application logs.

·        Issuer, audience, subject, claims, authentication method, token lifetime, assertion identifier, session identifier, source IP, device, application, user state, and role context.

·        Change-management, certificate-management, recovery, backup, migration, and maintenance records.

Detection Design Constraints

·        Do not base detection on CVE identifiers, exploit names, proof-of-concept names, static commands, fixed file paths, hashes, certificate thumbprints, source IPs, or token values.

·        Do not assume token forgery produces malware, process creation on an AD FS server, MFA activity, failed authentication, or a conventional AD FS issuance event.

·        Account for DKM access and key recovery occurring through domain controllers, backup systems, management platforms, administrative workstations, recovery packages, or offline processing.

·        Treat direct cryptographic API, memory, or private-key-operation telemetry as conditional enrichment.

·        Do not require direct observation of private-key decryption.

·        Distinguish malicious activity from approved certificate rollover, farm recovery, disaster-recovery testing, federation migration, service-account maintenance, backup activity, claim-rule changes, and incident response.

·        Preserve scope around signing-key exposure and forged federation-token trust compromise.

·        Support delayed token use, offline token construction, trusted infrastructure, compromised endpoints, corporate VPN paths, and familiar geographies.

Baseline and Deployment Requirements

·        Inventory AD FS farms, federation servers, Web Application Proxy systems, domain controllers, service accounts, DKM containers, token-signing certificates, token-decryption certificates, relying parties, trusts, cloud integrations, and dependent applications.

·        Validate the distinguished name, object GUID, ownership, inheritance, access-control entries, and auditing configuration for each AD FS DKM container.

·        Baseline accounts, hosts, tools, backup systems, recovery systems, and administrative paths authorized to access DKM material.

·        Baseline token-signing certificate thumbprints, primary and secondary roles, rollover schedules, private-key locations, export policy, and approved certificate workflows.

·        Baseline normal token issuance by identity, relying party, application, authentication method, device state, source network, claims set, token lifetime, issuer, audience, and time window.

·        Baseline privileged federation use involving administrators, service accounts, emergency accounts, executives, application owners, and cloud-control-plane users.

·        Maintain mappings among Active Directory identities, AD FS identities, cloud identities, SaaS accounts, privileged roles, devices, relying parties, and federation sessions.

·        Validate timestamp synchronization and SIEM field normalization across directory, AD FS, endpoint, MFA, VPN, cloud, SaaS, and application telemetry.

·        Maintain approved change records for certificate rollover, recovery, backup, migration, service-account changes, trust changes, claim-rule changes, and disaster-recovery testing.

Variant Resilience Requirements

·        Rules must remain effective when attackers use different methods to obtain DKM material, recover signing keys, construct tokens, manipulate claims, select identities, or access relying parties.

·        Detection should emphasize unauthorized key-material access, probable key handling, missing authentication lineage, identity-inconsistent claims, unusual federation sessions, and downstream use.

·        Support token construction on unmonitored systems.

·        Support token use occurring days or weeks after the original DKM access.

·        Support impersonation of common users, dormant accounts, service accounts, executives, administrators, emergency accounts, or fabricated identities.

·        Support access originating from trusted infrastructure, compromised endpoints, partner networks, residential proxies, cloud hosts, VPN services, or familiar geographies.

·        Support both broad multi-application abuse and narrowly targeted access to one sensitive relying party.

·        Support manipulated token lifetimes, roles, groups, authentication methods, audiences, issuers, subjects, and session identifiers.

·        Remain applicable across on-premises applications, Microsoft cloud services, third-party SaaS, VPNs, administrative portals, and other AD FS relying parties.

Operational Detection Model

·        Begin with DKM object identification, permission validation, object-auditing validation, AD FS farm mapping, signing-certificate inventory, and relying-party mapping.

·        Run DKM access, certificate activity, token-lineage, claims-consistency, and downstream-session analytics in hunt mode before production alerting.

·        Treat suspicious DKM access as a high-risk identity-infrastructure event even when downstream token abuse has not been observed.

·        Escalate when DKM access is followed by certificate interaction, export, archive creation, staging, transfer, anomalous token use, or downstream federation access.

·        Escalate validly signed tokens that lack expected issuance and authentication lineage after telemetry completeness has been validated.

·        Escalate anomalous federation use involving privileged, dormant, disabled, terminated, service, emergency, or high-value identities.

·        Escalate anomalous federation access followed by privileged operations, sensitive data access, security-control change, credential creation, persistence, or lateral expansion.

·        Preserve investigation windows sufficient to connect earlier DKM access with delayed key recovery and later token use.

·        Route high-confidence findings to Active Directory, AD FS, identity, cloud, application, incident-response, legal, and business owners.

·        Preserve the distinction between exposure, suspicious access, probable acquisition, suspected forgery, impersonation, and downstream compromise.

Explicit Non-Deployment Guardrails

·        Do not deploy CVE-name, vulnerable-version, patch-state, DKM-path, certificate-thumbprint, or scanner matches as compromise detections.

·        Do not classify ordinary directory reads as suspicious DKM access without validating the object, access right, actor, source, process, and workflow.

·        Do not classify certificate activity as malicious without validating rollover, renewal, recovery, migration, backup, and maintenance context.

·        Do not classify successful federation access, missing MFA, impossible travel, unusual claims, rare source infrastructure, or privileged access as forged-token proof.

·        Do not assume a valid signature proves legitimate AD FS issuance.

·        Do not assume a missing issuance event proves forgery without validating telemetry coverage and architecture.

·        Do not attribute downstream cloud, SaaS, VPN, or application activity to signing-key compromise without identity, issuer, audience, session, source, device, relying-party, and time-window linkage.

·        Do not suppress suspicious DKM or signing-key activity solely because the initiating identity is privileged.

·        Do not promote rules to production until DKM object identity, authorized access paths, certificate workflows, AD FS logging, relying-party mappings, timestamp alignment, identity lineage, and false-positive controls have been validated.

S22 — Primary Detection Signals

Figure 4

Primary Detection Signals

·        Successful read or control-access activity involving the validated AD FS DKM container by an unexpected account, host, process, service, or administrative path.

·        Permission, ownership, inheritance, or auditing changes affecting the validated DKM container outside an approved workflow.

·        DKM access from a workstation, member server, backup system, management platform, remote session, or identity-administration host that does not normally interact with AD FS key material.

·        DKM access by recently privileged, dormant, service, delegated, backup, emergency, or otherwise unexpected accounts.

·        Token-signing private-key access, export, backup, archive, replacement, addition, promotion, rollover, or permission change outside approved certificate activity.

·        Directory-query, PowerShell, certificate-management, backup, archive, or transfer activity near suspicious DKM access.

·        Validly signed federation access without corresponding expected AD FS issuance or upstream authentication evidence after telemetry completeness has been validated.

·        Accepted tokens containing roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or attributes inconsistent with the represented identity or relying-party policy.

·        Federated use of disabled, dormant, terminated, noninteractive, service, emergency, executive, administrative, or otherwise high-value identities without expected context.

·        Privileged application, SaaS, cloud, VPN, or administrative access following anomalous federation-token acceptance.

·        Sensitive data access, role modification, security-control change, credential creation, persistence, or lateral expansion following suspected forged-token use.

·        Similar anomalous token or identity behavior across multiple relying parties, applications, cloud services, or identities within a bounded time window.

Supporting Detection Signals

·        LDAP or directory-service queries targeting validated DKM objects, federation configuration, service-account objects, certificate-related attributes, or identity-infrastructure settings from unusual sources.

·        Directory access by accounts that recently received elevated privileges, delegated rights, backup rights, replication rights, or administrative group membership.

·        Remote PowerShell, WinRM, WMI, RDP, SMB, scheduled-task, service-control, or privileged-session activity involving AD FS servers, domain controllers, backup systems, or identity-management hosts near suspicious access.

·        Certificate-store enumeration, private-key permission checks, export attempts, recovery-package access, or certificate backup activity.

·        Access to AD FS configuration exports, recovery packages, database backups, service-account secrets, certificate backups, or identity-infrastructure archives.

·        Archive creation, encryption, compression, staging, removable-media use, cloud-storage upload, file transfer, or email transfer involving identity or certificate material.

·        Unexpected changes to relying-party trusts, claims-provider trusts, issuance rules, authorization rules, access-control policies, endpoints, token lifetimes, service accounts, auditing, or certificate settings.

·        Sign-ins with valid signatures but inconsistent MFA, authentication method, device, source network, user state, role entitlement, or application entitlement.

·        Claims assigning roles, groups, authentication methods, identifiers, usernames, or permissions not supported by current directory or application state.

·        Assertion or session identifiers reused across incompatible user, source, device, application, or geographic contexts.

·        Application access inconsistent with the represented user’s role, employment status, business unit, normal application portfolio, or historical behavior.

·        DKM, certificate, trust, claims, or federation activity without an approved change, recovery, backup, or maintenance record.

Exploit Attempt and Instability Signals

·        Repeated enumeration or access attempts against validated AD FS DKM objects from accounts or hosts that do not normally administer federation infrastructure.

·        Failed DKM or directory-object access followed by successful access, permission modification, ownership modification, or privileged-session activity.

·        Privilege escalation, delegated-right assignment, backup-operator use, replication-right use, or administrative-token acquisition shortly before DKM access.

·        Suspicious remote administration of a domain controller, AD FS server, backup system, or identity-management host preceding DKM enumeration.

·        PowerShell or directory-query activity enumerating AD FS configuration, DKM objects, service accounts, signing certificates, certificate stores, or federation settings.

·        Certificate-state errors, private-key permission errors, AD FS configuration faults, service restarts, cryptographic exceptions, or token-signing errors near suspicious administrative activity.

·        Unexpected certificate additions, duplicate certificates, unusual rollover timing, unexplained primary-certificate promotion, or certificate-state inconsistencies.

·        AD FS tracing reduction, audit-policy change, event-log clearing, event-forwarding interruption, collection-agent failure, or monitoring degradation following suspicious activity.

·        Short-lived certificate, archive, export, backup, script, command-output, or staging artifacts created and removed within a narrow time window.

·        Similar DKM, certificate, AD FS, or token-lineage anomalies across multiple federation servers, domains, forests, or relying parties.

Outbound Communication Signals

·        Outbound communication from an AD FS server, domain controller, backup platform, identity-management host, administrative workstation, or suspected source host to a rare, newly seen, unapproved, cloud-storage, paste, file-transfer, tunneling, or command-and-control-like destination near DKM access.

·        DNS, HTTP, HTTPS, SMB, SSH, FTP, email, cloud-storage, raw-IP, or tunnel-like activity associated with a process that accessed, exported, archived, or staged identity or certificate material.

·        Transfer of certificate exports, recovery packages, AD FS configuration backups, encrypted archives, directory-query output, or identity-infrastructure data.

·        External communication by a host that recently performed unusual LDAP queries, certificate-store access, PowerShell execution, remote administration, or DKM access.

·        Repeated callbacks from an administrative or identity-infrastructure host after suspected key-material collection.

·        Unexpected communication from AD FS or domain-controller systems to internal storage, backup, deployment, mail, cloud-synchronization, or management services outside approved workflows.

·        Federation access from source infrastructure appearing shortly after probable key-material acquisition or transfer.

·        Validly signed federation sessions originating from devices or source networks with no expected relationship to the represented identity.

Persistence and Post-Exploitation Signals (Conditional)

·        Unauthorized addition, replacement, promotion, or permission modification of token-signing or token-decryption certificates.

·        Changes to certificate rollover, token lifetime, federation metadata, signing configuration, endpoints, auditing, service accounts, or federation-service properties.

·        Creation or modification of relying-party trusts, claims-provider trusts, issuance rules, authorization rules, or access-control policies.

·        DKM access-control changes that preserve or expand unauthorized access.

·        Creation or modification of privileged accounts, delegated administrators, service accounts, backup operators, remote-management permissions, or emergency-access identities.

·        Scheduled tasks, services, scripts, startup mechanisms, remote-management configurations, or administrative tooling added to AD FS servers, domain controllers, or management hosts.

·        Audit reduction, AD FS trace disablement, log clearing, forwarding interruption, endpoint-control tampering, or monitoring exclusions.

·        Long-lived or unusually durable federation sessions.

·        Continued federation access after password reset, MFA reset, account disablement, or ordinary session revocation.

·        Cloud, SaaS, or application persistence established through new roles, service principals, OAuth grants, access keys, API tokens, application credentials, or administrative accounts after anomalous federation access.

Lateral Movement and Expansion Signals (Conditional)

·        Anomalous federation identity used across multiple relying parties, SaaS platforms, cloud tenants, VPNs, administrative portals, or internal applications.

·        Privileged federation access to Active Directory, Entra ID, Microsoft 365, AWS, GCP, virtualization, backup, security, code repository, deployment, finance, legal, HR, or data platforms.

·        Administrative activity from an identity that lacks expected upstream authentication, device context, privileged-access approval, or role entitlement.

·        Movement from a federated application into internal APIs, databases, file shares, management systems, secret stores, key vaults, backup systems, developer platforms, or cloud workloads.

·        Role assignment, group membership change, service-principal creation, access-key creation, credential addition, access-policy modification, or security-control weakening after anomalous federation authentication.

·        Access to applications or cloud services not normally used by the represented identity.

·        Similar suspected forged-token behavior across partner, subsidiary, multi-domain, multi-forest, or business-to-business federation relationships.

·        Conversion of federated access into persistent application sessions, cloud credentials, API tokens, refresh tokens, local accounts, or workload identities.

Signal Usage Constraints

Do not treat any single signal as compromise confirmation. Promote confidence only when evidence aligns by validated DKM object, account, source host, process, remote session, certificate, issuer, audience, subject, claims, assertion identifier, session identifier, relying party, application, device, source IP, administrative action, or bounded time window.

·        A permissive DKM access-control condition does not prove key-material access.

·        Suspicious DKM access does not prove successful private-key recovery.

·        A valid signature does not prove legitimate AD FS issuance.

·        Missing AD FS issuance telemetry does not prove forgery until logging and architecture have been validated.

·        Certificate reads, rollovers, backups, exports, or replacements require administrative and change context.

·        Missing MFA, impossible travel, unusual claims, rare sources, or privileged access are supporting signals.

·        Password reset, account disablement, MFA reset, or ordinary session revocation may not contain compromise if signing-key material remains trusted.

·        CVE status, public exploitation, proof-of-concept availability, and scanner findings are urgency inputs, not detection proof.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        EDR telemetry from AD FS servers, domain controllers, administrative workstations, backup systems, identity-management hosts, privileged-access systems, and suspected source hosts.

·        Process creation, parent-child lineage, command line, executable path, user, integrity level, logon session, remote-session context, current directory, timestamp, and destination connection.

·        PowerShell script-block, module, transcription, and command-line logging where operationally permitted.

·        Execution telemetry for directory-query tools, certificate utilities, backup software, archive tools, transfer tools, scripting engines, remote-management tools, and administrative frameworks.

·        Detection of processes accessing federation configuration, certificate stores, recovery packages, backups, identity exports, or files associated with signing material.

·        Remote administration telemetry for PowerShell remoting, WinRM, WMI, RDP, SMB, scheduled tasks, service control, management agents, and privileged-access platforms.

·        Host-role classification for AD FS servers, Web Application Proxy systems, domain controllers, backup servers, identity-management systems, administrative workstations, recovery platforms, and security systems.

·        Approved administrator, service-account, backup, deployment, recovery, migration, maintenance, monitoring, and incident-response lookups.

Memory and Execution Telemetry

·        Process-memory, handle-access, and cryptographic-provider telemetry involving AD FS services, certificate providers, PowerShell, directory-management tools, or processes handling private-key material where available.

·        Cryptographic API activity indicating private-key enumeration, access, export, decryption, or signing where supported.

·        Abnormal module loading, code injection, privileged-process access, or execution within AD FS, certificate, directory, or security-service contexts.

·        Execution lineage connecting remote access, directory queries, DKM access, certificate operations, archive creation, file staging, and outbound transfer.

·        Access to certificate passwords, recovery secrets, backup credentials, service-account credentials, or managed-service-account context where visible.

·        Memory and direct private-key-operation telemetry should be treated as conditional enrichment.

·        Offline key recovery may produce no memory or execution telemetry on an AD FS server.

·        Absence of memory telemetry must not be used to rule out DKM theft, private-key recovery, or forged-token activity.

Crash and Fault Telemetry

·        AD FS Admin, operational, tracing, debug, and security-relevant logs.

·        Windows Security, System, Application, Directory Service, and Active Directory Web Services logs from relevant identity systems.

·        AD FS service startup, shutdown, restart, certificate-access, private-key permission, token-processing, relying-party, claim-rule, trust, configuration, and audit failures.

·        Certificate Services, Cryptographic Services, certificate-store, key-storage-provider, and private-key access errors where available.

·        LDAP, authentication, replication, directory-access, and Active Directory faults near suspicious DKM activity.

·        Unexpected AD FS service restarts, token-signing errors, federation-metadata errors, configuration-loading failures, or cryptographic exceptions.

·        Logging interruption, event-log clearing, trace disablement, collection-agent failure, audit-policy change, and forwarding gaps.

·        Fault telemetry must be correlated with suspicious DKM, certificate, administrative, token, or downstream activity before being treated as compromise evidence.

·        Isolated AD FS, certificate, or directory faults should remain operational signals.

File and Persistence Telemetry

·        File creation, read, write, modification, rename, copy, export, archive, encryption, deletion, permission, ownership, and timestamp telemetry from relevant identity-infrastructure systems.

·        Coverage for certificate stores, private-key storage, Personal Information Exchange files, AD FS configuration exports, recovery packages, database backups, service-account configuration, temporary directories, administrative shares, and staging locations.

·        Detection of certificate exports, recovery files, encrypted archives, command output, directory-query results, scripts, configuration snapshots, and identity-related data staged for transfer.

·        Registry telemetry for AD FS, certificate, cryptographic-provider, PowerShell, service, remote-management, audit, logging, and persistence-related settings where relevant.

·        Scheduled-task, service, script, startup, management-agent, and remote-access configuration changes on AD FS servers, domain controllers, and administrative hosts.

·        Known-good inventories for signing certificates, token-decryption certificates, certificate thumbprints, primary-certificate status, private-key permissions, DKM access controls, service accounts, trusts, claim rules, endpoints, and audit settings.

·        Backup comparison data for DKM permissions, certificate state, AD FS configuration, relying-party trusts, claim rules, authorization rules, and federation-service properties.

·        Change-management, certificate-management, privileged-access, backup, migration, recovery, and incident-response records.

·        File telemetry must not be required to identify forged-token use because token construction may occur outside monitored identity systems.

Network and Outbound Communication Telemetry

·        Firewall, proxy, DNS, NDR, EDR network, VPN, remote-access, flow, and cloud-network telemetry covering AD FS servers, domain controllers, backup systems, identity-management hosts, administrative workstations, and suspected source systems.

·        Source host, source IP, destination, destination port, protocol, process where available, user where available, direction, timestamp, byte volume, session duration, and action.

·        LDAP, LDAPS, Global Catalog, SMB, RPC, WinRM, RDP, HTTPS, database, backup, and management traffic involving federation and directory infrastructure.

·        External communication following DKM access, certificate operations, configuration export, archive creation, or identity-data staging.

·        Destination reputation, first-seen status, domain age, country, ASN, hosting type, and approved-destination enrichment where available.

·        Approved Microsoft, certificate-authority, backup, monitoring, update, DNS, NTP, syslog, management, security, and vendor-support destination lookups.

·        Internal destination mapping for storage, backup, deployment, mail, certificate management, cloud synchronization, privileged access, identity management, and security platforms.

·        Federation access telemetry preserving source IP, proxy chain, VPN context, device context, application destination, and relying-party path.

·        Network telemetry alone cannot prove private-key recovery or forged-token creation.

Web and Application Telemetry (Conditional Availability)

·        AD FS sign-in, token-issuance, relying-party, claim-processing, authentication, endpoint, and federation-service logs.

·        Web Application Proxy, reverse-proxy, load-balancer, firewall, VPN, privileged-access, and application-access logs associated with federated authentication.

·        Relying-party logs preserving issuer, audience, subject, claims, authentication method, assertion identifier, session identifier, token lifetime, certificate thumbprint, source IP, device, application, and result where available.

·        Entra ID sign-in and audit logs, Microsoft 365 Unified Audit Log, Azure Activity logs, Microsoft Defender telemetry, and application-specific logs where AD FS federation is used.

·        AWS CloudTrail, IAM, STS, IAM Identity Center, console, role-assumption, administrative, data-access, and workload logs where AD FS identities can access AWS.

·        GCP Cloud Audit Logs, IAM, Workforce Identity Federation, console, service-account, administrative, data-access, and workload logs where AD FS identities can access GCP.

·        SaaS and on-premises application authentication, session, authorization, administrative, API, and data-access logs.

·        MFA, identity-provider, Kerberos, NTLM, password-validation, device-compliance, endpoint, VPN, and privileged-access logs required to establish authentication lineage.

·        User state, employment state, group membership, role entitlement, application entitlement, device inventory, privileged-role inventory, and business-unit context.

·        Where raw tokens cannot be retained, normalized metadata should preserve issuer, audience, subject, claims summary, authentication method, validity period, assertion identifier, certificate thumbprint, application, and correlation identifiers.

Telemetry Availability Requirements

·        Minimum viable coverage requires object-access auditing for the validated DKM container, DKM permission-change auditing, AD FS administrative and authentication logs, signing-certificate inventory, and downstream relying-party or cloud sign-in telemetry.

·        Strong coverage requires DKM auditing joined to endpoint process telemetry, remote-administration telemetry, certificate activity, change-management records, and outbound network telemetry.

·        Strong forged-token coverage requires comparison of relying-party acceptance against AD FS issuance, primary authentication, MFA, Kerberos, password validation, device, session, identity, and claims context.

·        Highest confidence requires correlation across suspicious DKM access, probable key handling, inconsistent token lineage, anomalous claims, trusted identity impersonation, and downstream activity.

·        Domain controllers must audit successful and failed access to the validated DKM container and relevant access-control attributes.

·        AD FS farms must capture sufficient authentication, issuance, certificate, trust, claim-rule, service, and administrative telemetry.

·        Cloud, SaaS, VPN, and application platforms must retain session, authorization, administrative, and data-access logs for a period sufficient to investigate delayed token use.

·        Environments unable to inspect token claims require compensating user, device, source-network, session, application, entitlement, and authorization context.

·        Managed identity environments require access to directory, AD FS, certificate, cloud, application, and incident-response telemetry.

·        Clock synchronization and consistent identity normalization are mandatory for reliable cross-platform correlation.

Telemetry Limitations and Gaps

·        Object-access auditing may not be enabled for the DKM container before an incident.

·        Directory auditing may identify access without proving which key material was retrieved.

·        DKM access may occur through legitimate administrative, backup, recovery, or directory-management tools that appear operationally normal.

·        Private-key recovery and token construction may occur offline on unmonitored systems.

·        Direct cryptographic API, memory, process, and private-key-operation telemetry may be unavailable.

·        AD FS logs may not retain every issuance, claims, authentication, or certificate event needed for definitive token lineage.

·        Relying parties may validate tokens locally and preserve little or no assertion metadata.

·        Raw federation tokens may not be retained because of security, privacy, storage, or platform limitations.

·        Missing AD FS issuance events may result from logging gaps, ingestion delay, farm failover, retention limits, or architecture.

·        MFA, Kerberos, AD FS, cloud, SaaS, and application systems may use inconsistent identifiers that complicate joins.

·        Proxy, VPN, NAT, browser, mobile, and partner-access behavior may obscure original source, device, or session context.

·        Legitimate certificate rollover, migration, disaster recovery, backup restoration, federation testing, and incident response may resemble malicious behavior.

·        Password reset, account disablement, MFA reset, and ordinary session revocation do not invalidate an exposed signing key.

·        Cloud or SaaS telemetry may establish anomalous identity use without proving token forgery.

·        A clean AD FS host examination cannot rule out DKM theft through Active Directory, backups, or offline processing.

·        Vulnerable-state or permissive-access findings cannot determine whether signing-key material was previously accessed.

·        Telemetry gaps must reduce confidence and expand investigative requirements rather than support unsupported conclusions.

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Object-level DKM auditing can identify unauthorized access, permission changes, ownership changes, inheritance changes, and delegated-access expansion before token abuse is observed.

·        DKM access correlated by object, account, source host, process, remote session, privilege context, and change window can distinguish routine administration from probable key-material collection.

·        Endpoint telemetry can identify suspicious directory queries, PowerShell use, certificate access, backup access, archive creation, staging, remote administration, and transfer activity near DKM access.

·        Certificate telemetry can identify unexpected token-signing private-key access, export, backup, addition, promotion, replacement, or rollover.

·        AD FS administrative logs can identify unexpected trust, claim-rule, endpoint, audit, service-account, token-lifetime, or certificate changes.

·        Token-lineage correlation can identify relying-party access that lacks expected AD FS issuance or upstream authentication evidence.

·        Claims analysis can identify roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or entitlements inconsistent with the represented identity or relying-party policy.

·        User-state and entitlement context can identify federation access involving disabled, dormant, terminated, service, emergency, or otherwise unexpected identities.

·        Cloud, SaaS, VPN, and application telemetry can identify suspected identity impersonation followed by privileged activity, sensitive data access, credential creation, persistence, or lateral expansion.

·        Long-duration correlation can connect earlier DKM access with delayed private-key recovery and later token use.

·        Multi-application correlation can identify the same represented identity, claims pattern, assertion identifier, session pattern, source infrastructure, or behavioral sequence across unrelated relying parties.

·        Known-good baselines for DKM permissions, signing certificates, AD FS configuration, trusts, claim rules, and federation behavior can reveal unauthorized state changes.

·        Change-management, certificate-management, backup, recovery, migration, and privileged-access records can distinguish approved identity operations from suspicious behavior.

Detection Gaps

·        DKM object auditing may not have been enabled before exposure occurred.

·        Directory access logs may not prove which cryptographic material was retrieved or whether private-key recovery succeeded.

·        An attacker may obtain DKM material through a backup, recovery package, directory export, compromised administrator, or management platform without generating a distinctive AD FS server event.

·        Token-signing private-key recovery and forged-token construction may occur entirely offline.

·        Forged tokens may remain cryptographically valid and indistinguishable from legitimate tokens when only signature validation is available.

·        AD FS issuance, claims, authentication, and certificate logs may be incomplete, disabled, rotated, delayed, or absent.

·        Relying parties may not retain assertion identifiers, claims, issuer details, certificate thumbprints, device context, or original source information.

·        Applications may create long-lived local sessions after accepting a token.

·        Attackers may use common users, trusted devices, corporate VPN infrastructure, familiar locations, compromised endpoints, expected applications, or normal business hours.

·        Attackers may delay token use until DKM access and key-recovery evidence has aged out of common investigation windows.

·        Legitimate certificate rollover, migration, backup restoration, disaster recovery, federation testing, and service-account maintenance may resemble suspicious activity.

·        MFA reset, password reset, account disablement, device revocation, and ordinary session invalidation may not contain compromise while the signing key remains trusted.

·        Relying parties may normalize, discard, or log token metadata differently.

·        Cloud and SaaS platforms may show anomalous identity use without proving whether access resulted from token forgery, stolen credentials, stolen sessions, or another identity attack.

·        Inconsistent identifiers across Active Directory, AD FS, Entra ID, SaaS, AWS, GCP, and on-premises applications may prevent reliable joins.

·        Outsourced or managed applications may not provide sufficient token, authentication, or session telemetry.

·        A clean AD FS host review cannot rule out DKM theft, backup compromise, offline key recovery, or forged-token use.

·        Patching and DKM permission hardening cannot establish whether key material was accessed before remediation.

Compensating Controls

·        Use domain-controller object-access logs to reconstruct DKM access where AD FS host telemetry is incomplete.

·        Use endpoint, PowerShell, certificate, backup, archive, and network telemetry to reconstruct probable key-material handling.

·        Use relying-party, MFA, Kerberos, VPN, device, cloud, SaaS, and application logs to reconstruct authentication lineage.

·        Use normalized token metadata when raw federation assertions cannot be retained.

·        Use known-good DKM permission, certificate, trust, claim-rule, and federation-configuration baselines to identify unauthorized state change.

·        Use configuration exports, backup comparisons, and certificate history when native audit telemetry is incomplete.

·        Use change-management, certificate-management, recovery, migration, backup, and privileged-access records to validate approved activity.

·        Use user-state, role, entitlement, device, business-unit, and application-portfolio context to assess anomalous identity use.

·        Use long-duration correlation to connect earlier DKM access with delayed token use.

·        Use downstream administrative and data-access telemetry to determine whether suspected identity impersonation produced operational impact.

·        Preserve relevant identity, directory, AD FS, cloud, SaaS, VPN, application, endpoint, and network logs before rotation during exposure review.

·        Treat vulnerable-state and DKM access-control findings as investigation-prioritization inputs rather than compromise proof.

Non-Coverage Conditions

·        Vulnerable or unpatched AD FS status without suspicious DKM, certificate, token-lineage, identity, or downstream evidence.

·        A permissive DKM access-control list without evidence that an unauthorized principal accessed the validated object.

·        Routine Active Directory object access unrelated to the validated AD FS DKM container.

·        Approved AD FS installation, farm expansion, service-account configuration, certificate rollover, disaster recovery, backup, restoration, migration, or federation testing.

·        Legitimate token-signing certificate access or replacement supported by approved administrator, source host, process, change, and maintenance context.

·        Successful federation authentication with expected AD FS issuance, upstream authentication, device, source, claims, and relying-party lineage.

·        Authentication anomalies explained by logging delay, retention gaps, farm failover, VPN use, travel, device change, partner access, or application implementation differences.

·        Cloud-only, SaaS-only, application-only, identity-only, endpoint-only, certificate-only, or network-only anomalies without AD FS, DKM, signing-key, token, issuer, audience, identity, relying-party, source, device, or time-window linkage.

·        Stolen passwords, stolen sessions, OAuth abuse, application-token theft, Kerberos ticket forgery, web-cookie forgery, or certificate abuse that does not involve AD FS signing-key exposure or forged federation tokens.

·        Unrelated Active Directory, AD CS, Entra ID, SAML, OIDC, OAuth, VPN, Web Application Proxy, or cloud vulnerabilities that do not produce the report’s signing-key-exposure and forged-token behavior family.

·        Claims anomalies caused by approved entitlement, application, identity-synchronization, claim-rule, or partner-federation changes.

·        Downstream privileged or sensitive activity that cannot be linked to anomalous federation authentication.

·        Public proof-of-concept availability, exploitation reporting, KEV status, scanner findings, exploit names, or CVE references without locally observed behavioral evidence.

·        Absence of malware, webshells, command execution, or AD FS host artifacts does not establish non-compromise because DKM theft and token construction may occur without those signals.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR / Network Behavioral Analytics includes one primary rule. The platform provides production-deployable supporting detection after local mapping when network telemetry identifies unusual administrative access to domain controllers, AD FS servers, backup platforms, or identity-management systems and correlates that access with rare or unapproved outbound communication. NDR cannot identify the specific Active Directory DKM object accessed, confirm private-key recovery, inspect forged-token claims in encrypted sessions, or prove that a valid federation token was illegitimately created. The rule therefore detects a high-risk access-and-egress sequence and must be joined with directory-object, endpoint, certificate, AD FS, identity, or relying-party evidence before analysts attribute the activity to signing-key exposure or forged-token trust compromise.

Rule

Unusual Identity-Infrastructure Administrative Access Followed by Rare Egress

Rule Format

NDR behavioral pseudoquery

Detection Purpose

Detect a suspicious network sequence in which an unapproved source or an approved administrative source behaving outside its established baseline accesses AD FS, domain-controller, backup, or identity-management infrastructure over administrative or directory protocols and the same source system or accessed identity-infrastructure asset subsequently communicates with a rare or unapproved destination.

Detection Logic

Generate a medium-severity alert when a source system initiates LDAP, LDAPS, Global Catalog, SMB, RPC, WinRM, RDP, or validated HTTPS management communication with a protected identity-infrastructure asset and the same source system or accessed identity asset initiates rare or unapproved outbound communication within a bounded time window.

For sources outside the approved identity-administration, backup, recovery, monitoring, deployment, vulnerability-validation, certificate-management, or management inventory, require a newly observed or rare source-to-asset relationship, unusual administrative path, or other locally validated access anomaly.

For approved administrative or support sources, require behavior inconsistent with their established baseline, such as a new protected destination, rare administrative path, unusual protocol, unexpected asset role, abnormal timing, unusual transfer volume, repeated callbacks, or rare outbound destination. Do not suppress an event solely because the source belongs to an approved administrative or support inventory.

Treat TCP 443 as administrative activity only when at least one of the following conditions is met:

·        The destination address or interface is mapped to an approved AD FS, directory, backup, recovery, identity-management, or administrative management plane.

·        Network application identification classifies the session as HTTPS management, remote administration, administrative API, or equivalent control-plane traffic.

·        The destination URI, host, virtual service, certificate, device role, or access path identifies a known management interface.

·        The session originates through an administrative network, privileged-access path, jump host, or management VPN and is anomalous for that source.

Escalate the alert to high severity only when the locally validated escalation score meets or exceeds the production threshold. Escalation factors may include:

·        The source accesses multiple protected identity-infrastructure systems within the correlation window.

·        The access-and-egress sequence involves materially elevated or unusual byte volume.

·        The external destination, domain, source-to-destination relationship, or administrative access path is newly observed.

·        The activity occurs outside approved maintenance, backup, recovery, migration, certificate-management, or incident-response windows.

·        The outbound destination is categorized as suspicious, malicious, tunneling, anonymization, paste, unapproved cloud storage, newly registered infrastructure, or another high-risk service.

·        The same source or accessed identity asset produces repeated callbacks or multiple rare outbound sessions.

·        An approved administrative source performs activity outside its established asset, protocol, access-path, timing, or destination baseline.

·        Directory-object, endpoint, certificate, AD FS, authentication, identity, or relying-party telemetry corroborates suspicious DKM access, certificate handling, anomalous token use, or downstream identity abuse.

Do not infer DKM access, signing-key theft, token forgery, trusted identity impersonation, or downstream compromise from the network sequence alone.

Required Telemetry

·        NDR, firewall, proxy, DNS, NetFlow, cloud-flow, or equivalent network-connection telemetry.

·        Asset groups for domain controllers, AD FS servers, Web Application Proxy systems, backup servers, identity-management platforms, recovery systems, and privileged administrative workstations.

·        Management-interface, management-address, management-virtual-service, administrative-path, and device-role mappings.

·        Approved identity-administration, privileged-access, backup, recovery, monitoring, deployment, vulnerability-validation, certificate-management, and management-system inventories.

·        Historical source-to-asset, source-to-protocol, source-to-access-path, source-to-destination, and source-to-time-window baselines.

·        Approved internal service and external destination lookups.

·        Protocol or application identification for LDAP, LDAPS, Global Catalog, SMB, RPC, WinRM, RDP, HTTPS management, administrative APIs, DNS, HTTP, HTTPS, SSH, FTP, email, and cloud-storage communication.

·        NAT, VPN, proxy, load-balancer, cloud private-address, device-owner, and source-host enrichment.

·        Destination reputation, first-seen, domain-age, hosting-provider, country, and ASN enrichment where available.

·        Byte count, session duration, connection count, callback frequency, and relationship history.

·        Maintenance-window and change-record enrichment.

·        Directory-object, endpoint, certificate, AD FS, authentication, identity, or relying-party telemetry for downstream corroboration and severity escalation.

Engineering Implementation Instructions

Create protected asset groups for all identity-infrastructure systems and separately map their management interfaces, management addresses, administrative virtual services, privileged-access paths, and externally or partner-reachable control planes. Validate that source and destination fields survive NAT, VPN, proxy, load-balancer, and cloud-network translation.

Baseline approved administrative, backup, recovery, monitoring, patching, vulnerability-validation, certificate-management, deployment, migration, and vendor-support communication for at least 30 days where practical. Build separate baselines for source-to-asset relationships, administrative protocols, access paths, time windows, destination classes, transfer volume, and callback frequency.

Do not exclude approved administrative or support systems from evaluation. Suppress only behavior that matches a validated approved baseline. Allow approved systems to generate alerts when they access new protected assets, use unusual management paths, operate at abnormal times, communicate through unexpected protocols, transfer unusual volumes, or initiate rare outbound communication.

Do not treat destination port 443 alone as management activity. Require management-interface mapping, administrative-path context, application identification, device-role context, or another validated control-plane indicator.

Identify newly observed source-to-identity-infrastructure relationships, unusual administrative paths, rare outbound destinations, repeated callbacks, and abnormal transfer volume separately from simple port matching. Correlate access and egress by source asset, accessed identity asset, user or device where available, protocol, administrative path, destination, session, and bounded time window.

Assign medium severity to the uncorroborated access-and-egress sequence. Escalate to high severity only when the locally validated escalation score reaches the production threshold through stronger network convergence or corroborating directory-object, endpoint, certificate, AD FS, identity, authentication, or relying-party evidence.

Use maintenance and change windows as scoring and triage context rather than as a universal base exclusion. Approved activity inside a maintenance window may still alert when the source, access path, destination, transfer pattern, or egress behavior is anomalous.

Run in hunt mode until asset mapping, management-interface mapping, approved-source baselines, relationship baselines, NAT handling, volume thresholds, maintenance context, escalation scoring, query performance, severity transitions, and SOC triage procedures have been validated. Do not enable alert mode until this gate is complete.

DRI Assessment

Moderate to high. The rule is behavior-driven and resilient to changes in exploit method, tooling, command line, CVE, and external infrastructure. Robustness depends on accurate identity-infrastructure asset mapping, management-interface identification, approved-source behavioral baselines, destination history, and the ability to connect administrative access with subsequent egress.

DRI

7.8 / 10

TCR Assessment

Operational confidence is moderate because unusual administrative access followed by rare egress is suspicious around identity infrastructure but does not reveal the directory object accessed or prove key acquisition. High-severity confidence requires the locally validated escalation threshold to be met through stronger network convergence, anomalous behavior by an approved source, or corroboration from DKM object auditing, certificate activity, endpoint execution, AD FS anomalies, authentication lineage, or downstream federation evidence.

Operational TCR

7.1 / 10

Full-Telemetry TCR

8.8 / 10

Limitations

Encrypted LDAP, HTTPS, SMB, and administrative sessions may prevent NDR from determining the object, command, file, certificate, or token involved. Legitimate backup, recovery, certificate-management, vendor-support, vulnerability-validation, migration, disaster-recovery, deployment, and incident-response activity may produce similar sequences.

Approved administrative systems may legitimately access new assets, operate outside normal hours, or communicate with rare destinations during emergency maintenance, migration, recovery, or incident response. Incomplete baselines may therefore increase false positives.

Management-interface mappings may be incomplete, particularly when HTTPS administrative traffic shares an address, listener, reverse proxy, virtual service, or load balancer with ordinary application traffic. Application identification may also misclassify encrypted sessions.

Attackers may use approved administrative workstations, trusted internal relays, compromised backup systems, familiar cloud services, permitted egress destinations, low-volume transfers, delayed exfiltration, or previously established source-to-destination relationships. Offline private-key recovery and forged-token construction may create no observable network activity on AD FS systems.

The rule cannot prove DKM access, private-key recovery, forged-token creation, trusted identity impersonation, or downstream compromise without supporting telemetry.

Detection Query Pattern

The following platform-neutral implementation pattern must be translated into the environment’s NDR or SIEM query language and mapped to local network, asset, identity, management-interface, change, behavioral-baseline, and enrichment schemas before production use.

FROM ENV_NETWORK_CONNECTIONS

WHERE destination.asset IN ASSET_GROUP(

  "ENV_ADFS_SERVERS",

  "ENV_DOMAIN_CONTROLLERS",

  "ENV_IDENTITY_MANAGEMENT_SYSTEMS",

  "ENV_IDENTITY_BACKUP_AND_RECOVERY_SYSTEMS"

)

AND (

  network.application IN (

    "ldap",

    "ldaps",

    "global_catalog",

    "smb",

    "rpc",

    "winrm",

    "rdp",

    "https_management",

    "administrative_api"

  )

  OR destination.port IN (

    389,

    636,

    3268,

    3269,

    445,

    135,

    5985,

    5986,

    3389

  )

  OR (

    destination.port = 443

    AND (

      destination.ip IN LOOKUP("ENV_IDENTITY_MANAGEMENT_INTERFACE_IPS")

      OR destination.virtual_service IN LOOKUP(

        "ENV_IDENTITY_MANAGEMENT_VIRTUAL_SERVICES"

      )

      OR destination.interface_role = "management"

      OR destination.device_role IN (

        "adfs_management",

        "directory_management",

        "identity_management",

        "backup_management",

        "recovery_management"

      )

      OR network.application IN (

        "https_management",

        "administrative_api",

        "remote_administration"

      )

      OR network.access_path IN (

        "privileged_access",

        "administrative_network",

        "jump_host",

        "management_vpn"

      )

    )

  )

)

LET source_is_approved =

  source.asset IN ASSET_GROUP(

    "ENV_APPROVED_IDENTITY_ADMIN_HOSTS",

    "ENV_APPROVED_PRIVILEGED_ACCESS_WORKSTATIONS",

    "ENV_APPROVED_BACKUP_SYSTEMS",

    "ENV_APPROVED_RECOVERY_SYSTEMS",

    "ENV_APPROVED_IDENTITY_MANAGEMENT_SYSTEMS",

    "ENV_APPROVED_MONITORING_SYSTEMS",

    "ENV_APPROVED_VULNERABILITY_VALIDATION_SYSTEMS",

    "ENV_APPROVED_DEPLOYMENT_SYSTEMS",

    "ENV_APPROVED_CERTIFICATE_MANAGEMENT_SYSTEMS"

  )

  OR source.ip IN LOOKUP("ENV_APPROVED_IDENTITY_ADMIN_SOURCE_IPS")

LET relationship_is_new =

  RELATIONSHIP_FIRST_SEEN(

    source.asset,

    destination.asset,

    "30d"

  )

LET relationship_is_rare =

  RELATIONSHIP_RARITY(

    source.asset,

    destination.asset,

    network.application,

    "30d"

  ) <= ENV_RARE_RELATIONSHIP_THRESHOLD

LET admin_path_is_rare =

  ADMIN_PATH_RARITY(

    source.asset,

    destination.asset,

    network.access_path,

    "30d"

  ) <= ENV_RARE_ADMIN_PATH_THRESHOLD

LET protocol_is_unusual =

  PROTOCOL_RARITY(

    source.asset,

    destination.asset,

    network.application,

    "30d"

  ) <= ENV_RARE_PROTOCOL_THRESHOLD

LET timing_is_unusual =

  TIME_WINDOW_RARITY(

    source.asset,

    destination.asset,

    timestamp,

    "30d"

  ) <= ENV_RARE_TIME_WINDOW_THRESHOLD

WHERE (

  source_is_approved = false

  AND (

    relationship_is_new = true

    OR relationship_is_rare = true

    OR admin_path_is_rare = true

    OR protocol_is_unusual = true

  )

)

OR (

  source_is_approved = true

  AND (

    relationship_is_new = true

    OR relationship_is_rare = true

    OR admin_path_is_rare = true

    OR protocol_is_unusual = true

    OR timing_is_unusual = true

  )

)

LET outbound_event = EVENT_NEAR(

  FROM ENV_NETWORK_CONNECTIONS

  WHERE (

    source.asset = PRIOR.source.asset

    OR source.asset = PRIOR.destination.asset

  )

  AND network.direction = "outbound"

  AND destination.ip NOT IN LOOKUP(

    "ENV_APPROVED_IDENTITY_INFRASTRUCTURE_EGRESS"

  )

  AND destination.domain NOT IN LOOKUP(

    "ENV_APPROVED_IDENTITY_INFRASTRUCTURE_DOMAINS"

  )

  AND destination.asset NOT IN ASSET_GROUP(

    "ENV_APPROVED_INTERNAL_SERVICE_DESTINATIONS"

  )

  AND (

    DESTINATION_FIRST_SEEN(

      destination.ip,

      destination.domain,

      "30d"

    )

    OR DESTINATION_RARITY(

      source.asset,

      destination.ip,

      destination.domain,

      "30d"

    ) <= ENV_RARE_DESTINATION_THRESHOLD

    OR destination.reputation IN (

      "suspicious",

      "malicious",

      "unknown_high_risk"

    )

    OR destination.category IN (

      "newly_registered_domain",

      "dynamic_dns",

      "paste_site",

      "file_sharing",

      "cloud_storage_unapproved",

      "anonymizer",

      "tunneling"

    )

  ),

  60m

)

WHERE outbound_event.exists = true

LET escalation_score =

    CASE WHEN DISTINCT_PROTECTED_ASSET_COUNT(

      source.asset,

      "60m"

    ) >= ENV_MULTI_ASSET_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.bytes_out >=

      ENV_ELEVATED_TRANSFER_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.callback_count >=

      ENV_CALLBACK_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.destination_first_seen = true

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.destination_high_risk = true

      THEN 1 ELSE 0 END

  + CASE WHEN ACTIVITY_OUTSIDE_APPROVED_WINDOW(

      timestamp,

      destination.asset,

      "ENV_IDENTITY_INFRASTRUCTURE_CHANGE_WINDOWS"

    ) = true

      THEN 1 ELSE 0 END

  + CASE WHEN source_is_approved = true

      AND (

        relationship_is_new = true

        OR admin_path_is_rare = true

        OR protocol_is_unusual = true

        OR timing_is_unusual = true

      )

      THEN 1 ELSE 0 END

  + CASE WHEN CORROBORATING_EVENT_NEAR(

      source.asset,

      destination.asset,

      "ENV_DIRECTORY_ENDPOINT_CERTIFICATE_ADFS_IDENTITY_EVENTS",

      "120m"

    ) = true

      THEN 2 ELSE 0 END

EMIT alert

SET severity =

  CASE

    WHEN escalation_score >= ENV_HIGH_SEVERITY_THRESHOLD

      THEN "high"

    ELSE "medium"

  END

SET cyberdax_rule =

  "Unusual Identity-Infrastructure Administrative Access Followed by Rare Egress"

SET confidence =

  CASE

    WHEN escalation_score >= ENV_HIGH_SEVERITY_THRESHOLD

      THEN "strong_network_convergence_or_corroborated_behavior"

    ELSE "supporting_network_behavior_requires_corroboration"

  END

SET production_validation =

  "Validate identity asset groups, management-interface mappings, approved-source behavioral baselines, HTTPS administrative-path logic, NAT and VPN handling, destination enrichment, transfer thresholds, maintenance context, escalation scoring, query performance, and SOC triage. Do not enable alert mode until this gate is complete."

SentinelOne

Detection Viability Assessment

SentinelOne includes two primary rules. The platform provides production-deployable endpoint detection after local schema validation and asset mapping for suspicious directory, certificate, backup, archive, staging, and transfer activity on domain controllers, AD FS servers, identity-management systems, backup platforms, recovery systems, privileged administrative workstations, and other hosts with access to federation key material.

SentinelOne can identify suspicious process lineage, command execution, certificate-store interaction where exposed through process or file telemetry, creation of certificate and recovery artifacts, archive staging, remote administration, and process-linked outbound communication. SentinelOne may not directly identify the specific Active Directory DKM object accessed, capture every cryptographic operation, prove that token-signing private-key recovery succeeded, inspect a forged federation assertion, or confirm that a relying party accepted an illegitimately created token.

The rules therefore detect probable key-material collection and transfer behavior. High-confidence classification requires correlation with Active Directory object-access auditing, AD FS certificate or configuration telemetry, token-issuance and authentication lineage, relying-party logs, or downstream identity activity.

Rule

Suspicious Federation Key and Identity-Material Discovery or Export Activity

Rule Format

SentinelOne Deep Visibility query pattern

Detection Purpose

Detect unusual directory, AD FS, certificate, backup, recovery, or key-material discovery and export behavior on systems with access to federation signing material.

Detection Logic

Alert when a process on a protected identity-infrastructure host performs one or more of the following outside a validated behavioral baseline:

·        Enumerates AD FS configuration, service accounts, DKM-related directory objects, certificate stores, private-key permissions, trusts, claims rules, or federation settings.

·        Invokes certificate, cryptographic, directory, backup, recovery, or export tooling with arguments consistent with private-key, certificate, federation, or identity-material access.

·        Creates or modifies Personal Information Exchange files, certificate exports, recovery packages, federation configuration exports, directory-query output, or other identity-sensitive artifacts.

·        Uses PowerShell, command processors, scripting engines, directory utilities, certificate utilities, backup software, or archive tools from an unusual parent process, user context, remote session, source host, or endpoint role.

·        Performs certificate or identity-material access shortly after remote administration, privilege elevation, unusual logon activity, or execution from a previously unseen administrative source.

·        Initiates unusual process-linked outbound communication after discovery, export, archive, or sensitive artifact creation.

Determine whether the activity aligns with an approved administrative, certificate-management, backup, recovery, migration, deployment, security-testing, or incident-response workflow. Do not suppress solely because the tool, account, endpoint, or workflow is approved. Suppress only when the workflow and its process lineage, command behavior, artifact type, path, user, source host, timing, and subsequent network activity all remain consistent with the validated approved baseline.

Sensitive artifact creation may contribute to severity but must not automatically override an otherwise validated approved workflow. For approved workflows, require the artifact type, path, process, source host, user, timing, volume, or destination behavior to be anomalous before retaining the event.

Assign medium severity to isolated suspicious discovery or export behavior. Escalate to high severity only when the locally validated escalation threshold is met through multiple sensitive actions, unusual user or source context, remote-administration lineage, anomalous sensitive artifact creation, archive staging, process-linked egress, or corroborating directory, AD FS, certificate, authentication, or identity telemetry.

Do not classify the activity as confirmed DKM theft, signing-key recovery, or forged-token compromise from endpoint behavior alone.

Required Telemetry

·        SentinelOne Deep Visibility process, file, Registry, user, logon, and network telemetry.

·        Endpoint groups for AD FS servers, domain controllers, Web Application Proxy systems, identity-management platforms, backup systems, recovery systems, certificate-management systems, privileged-access workstations, and administrative jump hosts.

·        Process name, process path, parent process, command line, user, integrity level, logon session, remote-session context, endpoint name, endpoint role, timestamp, file path, file extension, file operation, process storyline, and network destination.

·        PowerShell, command processor, scripting engine, directory utility, certificate utility, backup utility, archive utility, and transfer-tool mappings.

·        Approved administrator, service-account, backup, recovery, certificate-management, migration, deployment, maintenance, security-testing, and incident-response workflow definitions.

·        Sensitive path and artifact mappings for certificate stores, certificate exports, Personal Information Exchange files, federation configuration exports, recovery packages, identity backups, directory-query output, and staging directories.

·        Approved artifact-type, path, process, source-host, timing, destination, and transfer-volume baselines for identity workflows.

·        Approved and expected network-destination mappings for identity-infrastructure systems and administrative tools.

·        Asset, user, process, command-line, path, source-host, destination, timing, and maintenance-window baselines.

·        Destination reputation, first-seen, relationship rarity, transfer volume, and callback enrichment where available.

·        Active Directory object-access, AD FS, certificate, authentication, or identity telemetry for required corroboration.

Engineering Implementation Instructions

Create and validate endpoint groups for all systems that can access or administer AD FS, Active Directory, token-signing certificates, identity backups, recovery packages, or federation configuration. Include domain controllers, AD FS servers, privileged administrative workstations, backup servers, identity-management systems, certificate-management systems, recovery systems, and jump hosts.

Build locally validated process groups for:

·        PowerShell and scripting engines.

·        Command processors.

·        Directory-query and Active Directory administration tools.

·        Certificate-management and cryptographic utilities.

·        Backup and recovery software.

·        Archive, compression, encryption, transfer, and staging utilities.

·        Remote-administration and privileged-access tools.

Build sensitive artifact mappings for:

·        Personal Information Exchange files.

·        Certificate and private-key exports.

·        AD FS recovery packages.

·        Federation configuration exports.

·        Directory-query output.

·        Identity or certificate backups.

·        Temporary, user-profile, administrative-share, backup-staging, and recovery-staging locations.

Do not treat a process name or command fragment alone as malicious. Correlate process behavior with endpoint role, user context, source host, parent process, remote session, command line, file activity, sensitive artifact creation, maintenance context, and subsequent process-linked network activity.

Determine approved-workflow status without applying an unconditional exclusion. Evaluate whether the workflow remains consistent with its validated process, command, artifact type, artifact path, user, source-host, timing, destination, and transfer baseline. Retain the event when any of those elements are anomalous.

Derive sensitive-artifact creation directly from the matched file-event branch and validated artifact classification. Separately determine whether the artifact behavior is anomalous for the matched workflow. Do not allow ordinary artifact creation inside an approved certificate, backup, or recovery workflow to defeat suppression by itself.

Assign medium severity to suspicious discovery or export behavior without corroboration. Escalate to high severity only when the local escalation threshold is met through multiple sensitive operations, anomalous sensitive-artifact creation, remote-administration lineage, unusual account or source context, process-linked egress, or external corroboration.

Run in hunt mode until endpoint-role mappings, process groups, command-line mappings, artifact paths, artifact-behavior baselines, user and source baselines, process-to-network correlation, approved-workflow modeling, severity thresholds, query performance, and SOC triage procedures have been validated. Do not enable alert mode until this gate is complete.

DRI Assessment

High. The rule is behaviorally anchored to directory, certificate, backup, recovery, export, artifact-creation, and process-linked egress activity on protected identity systems rather than to CVE identifiers, exploit names, hashes, static paths, or specific attacker tooling. It remains effective when adversaries change utilities, command syntax, source infrastructure, or collection sequence.

Robustness is constrained by incomplete command-line capture, insufficient endpoint coverage, legitimate certificate and recovery operations, offline processing, and the possibility that DKM access occurs without an observable endpoint process on a monitored system.

DRI

8.6 / 10

TCR Assessment

Operational confidence is moderate to high when suspicious identity-material discovery or export activity occurs on a protected endpoint outside its validated behavioral baseline. Confidence increases when activity includes anomalous sensitive-artifact creation, unusual process lineage, remote administration, anomalous source-host use, archive staging, process-linked outbound communication, or corroborating directory-object and AD FS telemetry.

The rule cannot independently prove that the validated DKM object was accessed, that token-signing private-key recovery succeeded, or that a forged federation token was created.

Operational TCR

7.9 / 10

Full-Telemetry TCR

9.2 / 10

Limitations

Legitimate AD FS deployment, certificate rollover, backup, recovery, migration, disaster-recovery testing, federation troubleshooting, security validation, and incident response may produce similar behavior.

SentinelOne may not capture the target Active Directory object, every certificate-store operation, direct cryptographic API activity, hardware-backed key operations, or private-key decryption. Directory and certificate tooling may execute through signed administrative utilities or management products that appear normal.

Process-to-network attribution may be incomplete when communication occurs through a separate service, browser, synchronization client, management agent, or delayed process lineage.

Incomplete approved-workflow and artifact-behavior baselines may increase false positives or suppress activity that resembles legitimate identity administration.

An attacker may access DKM material through directory APIs, backups, compromised management platforms, or approved administrative tools without creating an obvious export artifact. Private-key recovery may occur offline on an unmonitored host.

The rule identifies probable collection or export behavior. It cannot prove DKM theft, signing-key recovery, token forgery, identity impersonation, or downstream compromise without supporting telemetry.

Detection Query Pattern

The following SentinelOne Deep Visibility pattern requires tenant-specific syntax validation, field validation, endpoint-role mapping, command-line testing, artifact-path validation, process-to-network correlation testing, approved-workflow behavioral modeling, artifact-behavior baselining, and environment-specific tuning before production deployment.

EndpointOS = "windows"

AND AgentComputerName IN ASSET_GROUP(

  "ENV_ADFS_SERVERS",

  "ENV_DOMAIN_CONTROLLERS",

  "ENV_IDENTITY_MANAGEMENT_SYSTEMS",

  "ENV_IDENTITY_BACKUP_SYSTEMS",

  "ENV_IDENTITY_RECOVERY_SYSTEMS",

  "ENV_CERTIFICATE_MANAGEMENT_SYSTEMS",

  "ENV_PRIVILEGED_ADMIN_WORKSTATIONS",

  "ENV_IDENTITY_JUMP_HOSTS"

)

AND EventType IN ANY(

  "Process Creation",

  "File Creation",

  "File Modification",

  "File Rename"

)

LET process_branch =

  EventType = "Process Creation"

  AND TgtProcName IN ANY(

    "powershell.exe",

    "pwsh.exe",

    "cmd.exe",

    "cscript.exe",

    "wscript.exe",

    "certutil.exe",

    "certreq.exe",

    "certmgr.exe",

    "mmc.exe",

    "dsquery.exe",

    "ldp.exe",

    "ldifde.exe",

    "csvde.exe",

    "ntdsutil.exe",

    "wbadmin.exe",

    "esentutl.exe",

    "7z.exe",

    "7za.exe",

    "rar.exe",

    "winrar.exe",

    "tar.exe"

  )

  AND (

    TgtProcCmdLine CONTAINS ANY(

      "adfs",

      "federation",

      "distributed key manager",

      "dkm",

      "token-signing",

      "token signing",

      "certificate",

      "private key",

      "privatekey",

      "cert:\\",

      "localmachine\\my",

      "export-pfxcertificate",

      "get-adfs",

      "get-adobject",

      "get-acl",

      "ldifde",

      "csvde",

      "dsquery",

      "backup",

      "recovery"

    )

    OR PROCESS_BEHAVIOR_RARITY(

      AgentComputerName,

      TgtProcName,

      TgtProcCmdLine,

      "30d"

    ) <= ENV_RARE_IDENTITY_TOOL_THRESHOLD

  )

LET artifact_class =

  SENSITIVE_ARTIFACT_CLASSIFICATION(

    TgtFilePath,

    SrcProcName,

    SrcProcCmdLine,

    FileSize,

    FileHash

  )

LET file_branch =

  EventType IN ANY(

    "File Creation",

    "File Modification",

    "File Rename"

  )

  AND (

    TgtFilePath ENDSWITH ANY(

      ".pfx",

      ".p12",

      ".cer",

      ".crt",

      ".key",

      ".pem",

      ".p7b",

      ".bkf",

      ".zip",

      ".7z",

      ".rar"

    )

    OR TgtFilePath CONTAINS ANY(

      "\\adfs\\",

      "\\federation\\",

      "\\certificate",

      "\\recovery\\",

      "\\backup\\",

      "\\staging\\",

      "\\temp\\",

      "\\users\\public\\",

      "\\programdata\\"

    )

  )

  AND (

    SrcProcName IN ANY(

      "powershell.exe",

      "pwsh.exe",

      "cmd.exe",

      "certutil.exe",

      "certreq.exe",

      "certmgr.exe",

      "mmc.exe",

      "wbadmin.exe",

      "esentutl.exe",

      "ntdsutil.exe",

      "7z.exe",

      "7za.exe",

      "rar.exe",

      "winrar.exe",

      "tar.exe"

    )

    OR FILE_PATH_RARITY(

      AgentComputerName,

      TgtFilePath,

      "30d"

    ) <= ENV_RARE_IDENTITY_ARTIFACT_THRESHOLD

  )

WHERE process_branch = true

   OR file_branch = true

LET sensitive_artifact_created =

  file_branch = true

  AND artifact_class IN(

    "certificate_export",

    "private_key_material",

    "adfs_recovery_package",

    "federation_configuration_export",

    "identity_backup",

    "directory_query_output",

    "encrypted_identity_archive",

    "sensitive_identity_staging"

  )

LET workflow_is_approved =

  APPROVED_WORKFLOW_MATCH(

    AgentComputerName,

    User,

    SrcProcName,

    TgtProcName,

    TgtProcCmdLine,

    TgtFilePath,

    "ENV_APPROVED_IDENTITY_CERTIFICATE_BACKUP_RECOVERY_WORKFLOWS"

  )

LET artifact_behavior_is_anomalous =

  sensitive_artifact_created = true

  AND (

    ARTIFACT_TYPE_RARITY(

      AgentComputerName,

      User,

      artifact_class,

      "30d"

    ) <= ENV_RARE_IDENTITY_ARTIFACT_TYPE_THRESHOLD

    OR FILE_PATH_RARITY(

      AgentComputerName,

      TgtFilePath,

      "30d"

    ) <= ENV_RARE_IDENTITY_ARTIFACT_THRESHOLD

    OR PROCESS_ARTIFACT_RARITY(

      AgentComputerName,

      SrcProcName,

      artifact_class,

      "30d"

    ) <= ENV_RARE_PROCESS_ARTIFACT_THRESHOLD

    OR ARTIFACT_SIZE_ANOMALY(

      AgentComputerName,

      artifact_class,

      FileSize,

      "30d"

    ) = true

  )

LET source_context_is_anomalous =

  REMOTE_SESSION_CONTEXT = true

  OR SOURCE_HOST_RARITY(

    User,

    AgentComputerName,

    "30d"

  ) <= ENV_RARE_ADMIN_SOURCE_THRESHOLD

  OR PARENT_PROCESS_RARITY(

    AgentComputerName,

    SrcProcName,

    TgtProcName,

    "30d"

  ) <= ENV_RARE_PARENT_PROCESS_THRESHOLD

LET timing_is_anomalous =

  TIME_WINDOW_RARITY(

    AgentComputerName,

    User,

    EventTime,

    "30d"

  ) <= ENV_RARE_IDENTITY_ACTIVITY_TIME_THRESHOLD

LET outbound_event = EVENT_NEAR(

  EventType = "Network Connection"

  AND AgentComputerName = PRIOR.AgentComputerName

  AND (

    SrcProcStorylineId = PRIOR.SrcProcStorylineId

    OR PROCESS_LINEAGE_RELATED(

      SrcProcStorylineId,

      PRIOR.SrcProcStorylineId

    ) = true

    OR SrcProcName = PRIOR.SrcProcName

  )

  AND NetworkDirection = "outbound",

  60m

)

LET outbound_behavior_is_anomalous =

  outbound_event.exists = true

  AND (

    DESTINATION_FIRST_SEEN(

      AgentComputerName,

      outbound_event.DstIP,

      outbound_event.DstDomain,

      "30d"

    ) = true

    OR DESTINATION_RARITY(

      AgentComputerName,

      outbound_event.DstIP,

      outbound_event.DstDomain,

      "30d"

    ) <= ENV_RARE_DESTINATION_THRESHOLD

    OR DESTINATION_RELATIONSHIP_ANOMALY(

      AgentComputerName,

      SrcProcName,

      outbound_event.DstIP,

      outbound_event.DstDomain,

      "30d"

    ) = true

    OR outbound_event.bytes_out >=

      ENV_IDENTITY_MATERIAL_TRANSFER_THRESHOLD

    OR outbound_event.DestinationReputation IN(

      "suspicious",

      "malicious",

      "unknown_high_risk"

    )

    OR outbound_event.DestinationCategory IN(

      "newly_registered_domain",

      "dynamic_dns",

      "paste_site",

      "file_sharing",

      "cloud_storage_unapproved",

      "anonymizer",

      "tunneling"

    )

  )

LET process_behavior_is_anomalous =

  PROCESS_BEHAVIOR_RARITY(

    AgentComputerName,

    TgtProcName,

    TgtProcCmdLine,

    "30d"

  ) <= ENV_RARE_IDENTITY_TOOL_THRESHOLD

LET workflow_behavior_is_anomalous =

  source_context_is_anomalous = true

  OR timing_is_anomalous = true

  OR artifact_behavior_is_anomalous = true

  OR outbound_behavior_is_anomalous = true

  OR process_behavior_is_anomalous = true

WHERE workflow_is_approved = false

   OR workflow_behavior_is_anomalous = true

LET escalation_score =

    CASE WHEN USER_RISK_CLASS(

      User

    ) IN(

      "unexpected",

      "recently_privileged",

      "dormant",

      "service_account_unusual",

      "emergency_account",

      "compromised_suspected"

    ) THEN 1 ELSE 0 END

  + CASE WHEN source_context_is_anomalous = true

      THEN 1 ELSE 0 END

  + CASE WHEN artifact_behavior_is_anomalous = true

      THEN 2 ELSE 0 END

  + CASE WHEN DISTINCT_SENSITIVE_ACTION_COUNT(

      AgentComputerName,

      User,

      "30m"

    ) >= ENV_MULTI_ACTION_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_behavior_is_anomalous = true

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.exists = true

      AND outbound_event.bytes_out >=

      ENV_IDENTITY_MATERIAL_TRANSFER_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN CORROBORATING_EVENT_NEAR(

      AgentComputerName,

      User,

      "ENV_DIRECTORY_ADFS_CERTIFICATE_IDENTITY_EVENTS",

      "120m"

    ) = true

      THEN 2 ELSE 0 END

EMIT alert

SET severity =

  CASE

    WHEN escalation_score >= ENV_SENTINELONE_HIGH_THRESHOLD

      THEN "high"

    ELSE "medium"

  END

SET cyberdax_rule =

  "Suspicious Federation Key and Identity-Material Discovery or Export Activity"

SET confidence =

  CASE

    WHEN escalation_score >= ENV_SENTINELONE_HIGH_THRESHOLD

      THEN "probable_identity_material_collection_or_export"

    ELSE "suspicious_identity_material_activity_requires_corroboration"

  END

Rule

Sensitive Federation Material Staging Followed by Unusual Outbound Communication

Rule Format

SentinelOne Deep Visibility query pattern

Detection Purpose

Detect sensitive certificate, recovery, federation, directory, or identity artifacts staged on a protected endpoint and followed by unusual process-linked outbound communication.

Detection Logic

Alert when a protected identity-infrastructure host creates, modifies, renames, compresses, encrypts, or stages a certificate export, Personal Information Exchange file, recovery package, federation configuration export, identity backup, directory-query output, or archive and the responsible process or associated process lineage initiates anomalous outbound communication within a bounded time window.

Require the file or staging activity to be unusual for the endpoint, user, source host, process, path, workflow, or maintenance context. Do not alert solely because a .pfx, backup, archive, or certificate file exists.

Determine whether the staging activity aligns with an approved backup, recovery, certificate-management, migration, deployment, support, security-testing, or incident-response workflow. Do not suppress solely because the initial file activity resembles an approved workflow. Evaluate the complete process-to-file-to-network sequence and suppress only when the artifact, process, source, user, destination, transfer method, timing, and byte volume all remain consistent with the approved baseline.

Evaluate both approved and unapproved destinations. Approved destinations must remain eligible when the process, artifact, transfer method, relationship, timing, destination use, or byte volume is anomalous for the endpoint or user.

Require anomalous outbound behavior for every matched sequence, including activity originating from an unapproved workflow. The existence of an outbound connection alone is insufficient.

Encrypted archives may contribute to severity but must not automatically override a validated approved workflow. Treat archive encryption as anomalous only when it is unexpected for the matched workflow, process, artifact type, path, source host, user, or timing baseline.

Assign medium severity to the uncorroborated anomalous staging-and-egress sequence. Escalate to high severity only when the locally validated escalation threshold is met through a sensitive artifact type, anomalous archive encryption, unusual administrative source, elevated transfer volume, rare or high-risk destination, anomalous use of an approved destination, repeated callbacks, deletion after transfer, similar activity across multiple protected systems, or corroborating directory, AD FS, certificate, identity, or relying-party evidence.

Do not infer signing-key theft, token forgery, or downstream identity compromise from file and network activity alone.

Required Telemetry

·        SentinelOne process, file, network, user, and logon telemetry.

·        Protected endpoint groups covering AD FS servers, domain controllers, identity-management systems, backup systems, recovery platforms, certificate-management systems, privileged administrative workstations, and administrative jump hosts.

·        File creation, modification, rename, deletion, path, extension, size, hash where available, source process, process lineage, user, source host, endpoint, and timestamp.

·        Process-linked destination IP, domain, port, protocol, byte count, connection count, and session timing.

·        Sensitive artifact mappings for certificate exports, Personal Information Exchange files, recovery packages, federation configuration exports, identity backups, directory-query output, encrypted archives, and staging directories.

·        Approved backup, recovery, migration, certificate-management, deployment, vendor-support, security-testing, and incident-response workflow definitions.

·        Approved archive-encryption behavior by process, artifact type, path, source host, user, and workflow.

·        Approved cloud-storage, backup, email, management, synchronization, collaboration, and transfer-destination inventories.

·        Destination reputation, first-seen, domain-age, hosting-provider, country, ASN, relationship rarity, and approved-destination-use baselines.

·        File-path, file-type, process, user, source-host, destination, timing, transfer-method, and byte-volume baselines.

·        Cross-host aggregation for protected identity-infrastructure systems.

·        Directory-object, certificate, AD FS, identity, authentication, and relying-party telemetry for corroboration.

Engineering Implementation Instructions

Map sensitive certificate, federation, recovery, backup, and identity artifact types using file extension, path, process lineage, creation context, and local naming conventions. Do not rely on extension matching alone.

Create baselines for approved certificate export, backup, recovery, migration, archive, staging, encryption, and transfer behavior. Include approved source process, endpoint, user, source host, destination, transfer method, path, timing, file size, artifact type, and maintenance context.

Correlate file and network activity by endpoint, user, source host, source process, process lineage, file path, artifact classification, destination, and bounded time window. Where direct process-to-file-to-network linkage is unavailable, require a shorter correlation window and stronger endpoint, user, source, artifact, and destination context.

Determine approved-workflow status without excluding the event. Evaluate whether the complete workflow remains consistent with its approved process, artifact, path, source, user, timing, destination, transfer method, encryption behavior, and byte-volume baseline.

Require anomalous outbound behavior as a mandatory condition for every alert. Do not allow an unapproved staging workflow followed only by ordinary outbound communication to satisfy the rule.

Do not exclude approved backup, certificate, recovery, cloud-storage, email, synchronization, collaboration, or management destinations. Alert when an approved destination is used by an unexpected process, user, endpoint, source host, artifact type, transfer method, time window, relationship, or byte volume.

Treat archive encryption as an escalation factor only when the encryption behavior is anomalous for the workflow. Do not classify an approved encrypted backup or recovery package as suspicious solely because encryption occurred.

Aggregate similar activity across protected systems by artifact class, destination, process, user, transfer method, and bounded time window. Use multi-host convergence as an escalation factor rather than a standalone compromise determination.

Assign medium severity to the base anomalous staging-and-egress sequence. Escalate to high severity only when the local score reaches the production threshold.

Run in hunt mode until sensitive-artifact classification, file-path mappings, process lineage, approved-workflow modeling, archive-encryption baselines, source-host baselines, approved-destination baselines, destination enrichment, transfer thresholds, cross-host aggregation, correlation windows, deletion-after-transfer logic, query performance, and SOC triage procedures have been validated. Do not enable alert mode until this gate is complete.

DRI Assessment

High. The rule is anchored to durable staging and transfer behavior involving sensitive federation, certificate, backup, recovery, and identity material. It remains useful when adversaries change utilities, filenames, archive types, destinations, or transfer methods.

Robustness is constrained when artifacts are processed entirely in memory, transferred through approved applications, created on unmonitored systems, stored in opaque backup formats, or recovered offline without endpoint-visible file activity.

DRI

8.7 / 10

TCR Assessment

Operational confidence is moderate to high because sensitive identity-material staging followed by anomalous outbound communication is strongly suspicious on protected identity systems. Confidence increases when the artifact type, anomalous archive encryption, process lineage, administrative-source context, destination behavior, transfer volume, deletion behavior, multi-host convergence, or external telemetry supports probable collection and transfer.

The rule cannot independently establish that the artifact contained the AD FS signing key, that private-key recovery succeeded, or that forged-token activity followed.

Operational TCR

8.2 / 10

Full-Telemetry TCR

9.3 / 10

Limitations

Legitimate certificate export, backup, disaster recovery, migration, vendor support, incident response, and security validation may create and transfer sensitive artifacts.

Approved workflows and destinations may legitimately receive sensitive material. Incomplete workflow, source-host, archive-encryption, destination-use, or transfer-volume baselines may increase false positives.

File extensions and paths may be changed. Sensitive material may be embedded in databases, backup containers, memory, encrypted archives, management-platform exports, or custom formats that are not directly identifiable.

An attacker may use low-volume transfers, browser uploads, cloud synchronization, email clients, management software, administrative shares, removable media, delayed transfer, or a destination already common for the endpoint. Process-to-file-to-network attribution may be incomplete.

Multi-host activity may reflect coordinated maintenance, migration, backup, recovery, or certificate rollover rather than malicious convergence.

Offline private-key recovery or token construction may generate no activity on the original identity-infrastructure host. The rule cannot prove DKM access, signing-key recovery, forged-token creation, trusted identity impersonation, or downstream compromise without supporting telemetry.

Detection Query Pattern

The following SentinelOne Deep Visibility pattern requires tenant-specific syntax validation, field validation, process-to-file-to-network correlation testing, sensitive-artifact classification, approved-workflow behavioral modeling, archive-encryption baselining, approved-destination baselining, source-host anomaly testing, cross-host aggregation, destination enrichment, and environment-specific tuning before production deployment.

EndpointOS = "windows"

AND AgentComputerName IN ASSET_GROUP(

  "ENV_ADFS_SERVERS",

  "ENV_DOMAIN_CONTROLLERS",

  "ENV_IDENTITY_MANAGEMENT_SYSTEMS",

  "ENV_IDENTITY_BACKUP_SYSTEMS",

  "ENV_IDENTITY_RECOVERY_SYSTEMS",

  "ENV_CERTIFICATE_MANAGEMENT_SYSTEMS",

  "ENV_PRIVILEGED_ADMIN_WORKSTATIONS",

  "ENV_IDENTITY_JUMP_HOSTS"

)

AND EventType IN ANY(

  "File Creation",

  "File Modification",

  "File Rename"

)

LET artifact_class =

  SENSITIVE_ARTIFACT_CLASSIFICATION(

    TgtFilePath,

    SrcProcName,

    SrcProcCmdLine,

    FileSize,

    FileHash

  )

WHERE (

  TgtFilePath ENDSWITH ANY(

    ".pfx",

    ".p12",

    ".cer",

    ".crt",

    ".key",

    ".pem",

    ".bkf",

    ".zip",

    ".7z",

    ".rar",

    ".tar",

    ".gz"

  )

  OR TgtFilePath CONTAINS ANY(

    "\\adfs\\",

    "\\federation\\",

    "\\certificate",

    "\\recovery\\",

    "\\backup\\",

    "\\identity\\",

    "\\staging\\",

    "\\temp\\",

    "\\users\\public\\",

    "\\programdata\\"

  )

)

AND artifact_class IN(

  "certificate_export",

  "private_key_material",

  "adfs_recovery_package",

  "federation_configuration_export",

  "identity_backup",

  "directory_query_output",

  "encrypted_identity_archive",

  "sensitive_identity_staging"

)

LET workflow_is_approved =

  APPROVED_WORKFLOW_MATCH(

    AgentComputerName,

    User,

    SrcProcName,

    SrcProcCmdLine,

    TgtFilePath,

    "ENV_APPROVED_IDENTITY_ARTIFACT_WORKFLOWS"

  )

LET source_context_is_anomalous =

  REMOTE_SESSION_CONTEXT = true

  OR SOURCE_HOST_RARITY(

    User,

    AgentComputerName,

    "30d"

  ) <= ENV_RARE_ADMIN_SOURCE_THRESHOLD

  OR SOURCE_ROLE_MISMATCH(

    User,

    AgentComputerName,

    "ENV_APPROVED_IDENTITY_ADMIN_SOURCE_ROLES"

  ) = true

LET archive_encryption_is_anomalous =

  artifact_class = "encrypted_identity_archive"

  AND (

    ARCHIVE_ENCRYPTION_RARITY(

      AgentComputerName,

      SrcProcName,

      User,

      "30d"

    ) <= ENV_RARE_ARCHIVE_ENCRYPTION_THRESHOLD

    OR ARTIFACT_TYPE_RARITY(

      AgentComputerName,

      User,

      artifact_class,

      "30d"

    ) <= ENV_RARE_IDENTITY_ARTIFACT_TYPE_THRESHOLD

    OR FILE_PATH_RARITY(

      AgentComputerName,

      TgtFilePath,

      "30d"

    ) <= ENV_RARE_IDENTITY_ARTIFACT_THRESHOLD

  )

LET artifact_behavior_is_anomalous =

  ARTIFACT_TYPE_RARITY(

    AgentComputerName,

    User,

    artifact_class,

    "30d"

  ) <= ENV_RARE_IDENTITY_ARTIFACT_TYPE_THRESHOLD

  OR FILE_PATH_RARITY(

    AgentComputerName,

    TgtFilePath,

    "30d"

  ) <= ENV_RARE_IDENTITY_ARTIFACT_THRESHOLD

  OR PROCESS_ARTIFACT_RARITY(

    AgentComputerName,

    SrcProcName,

    artifact_class,

    "30d"

  ) <= ENV_RARE_PROCESS_ARTIFACT_THRESHOLD

  OR ARTIFACT_SIZE_ANOMALY(

    AgentComputerName,

    artifact_class,

    FileSize,

    "30d"

  ) = true

LET outbound_event = EVENT_NEAR(

  EventType = "Network Connection"

  AND AgentComputerName = PRIOR.AgentComputerName

  AND (

    SrcProcName = PRIOR.SrcProcName

    OR SrcProcStorylineId = PRIOR.SrcProcStorylineId

    OR PROCESS_LINEAGE_RELATED(

      SrcProcStorylineId,

      PRIOR.SrcProcStorylineId

    ) = true

  )

  AND NetworkDirection = "outbound",

  60m

)

WHERE outbound_event.exists = true

LET destination_is_approved =

  outbound_event.DstIP IN LOOKUP(

    "ENV_APPROVED_IDENTITY_ARTIFACT_DESTINATION_IPS"

  )

  OR outbound_event.DstDomain IN LOOKUP(

    "ENV_APPROVED_IDENTITY_ARTIFACT_DESTINATION_DOMAINS"

  )

  OR outbound_event.DestinationCategory IN(

    "approved_cloud_storage",

    "approved_backup",

    "approved_email",

    "approved_management",

    "approved_synchronization",

    "approved_collaboration"

  )

LET destination_relationship_is_new =

  DESTINATION_FIRST_SEEN(

    AgentComputerName,

    outbound_event.DstIP,

    outbound_event.DstDomain,

    "30d"

  )

LET destination_relationship_is_rare =

  DESTINATION_RARITY(

    AgentComputerName,

    outbound_event.DstIP,

    outbound_event.DstDomain,

    "30d"

  ) <= ENV_RARE_DESTINATION_THRESHOLD

LET transfer_timing_is_anomalous =

  TIME_WINDOW_RARITY(

    AgentComputerName,

    User,

    outbound_event.timestamp,

    "30d"

  ) <= ENV_RARE_TRANSFER_TIME_THRESHOLD

LET approved_destination_use_is_anomalous =

  destination_is_approved = true

  AND (

    PROCESS_DESTINATION_RARITY(

      AgentComputerName,

      SrcProcName,

      outbound_event.DstDomain,

      "30d"

    ) <= ENV_RARE_PROCESS_DESTINATION_THRESHOLD

    OR USER_DESTINATION_RARITY(

      User,

      outbound_event.DstDomain,

      "30d"

    ) <= ENV_RARE_USER_DESTINATION_THRESHOLD

    OR TRANSFER_METHOD_ANOMALY(

      AgentComputerName,

      SrcProcName,

      outbound_event.Protocol,

      "30d"

    ) = true

    OR outbound_event.bytes_out >=

      ENV_IDENTITY_MATERIAL_TRANSFER_THRESHOLD

    OR transfer_timing_is_anomalous = true

  )

LET unapproved_destination_use_is_anomalous =

  destination_is_approved = false

  AND (

    destination_relationship_is_new = true

    OR destination_relationship_is_rare = true

    OR outbound_event.DestinationReputation IN(

      "suspicious",

      "malicious",

      "unknown_high_risk"

    )

    OR outbound_event.DestinationCategory IN(

      "newly_registered_domain",

      "dynamic_dns",

      "paste_site",

      "file_sharing",

      "cloud_storage_unapproved",

      "anonymizer",

      "tunneling"

    )

  )

LET outbound_behavior_is_anomalous =

  approved_destination_use_is_anomalous = true

  OR unapproved_destination_use_is_anomalous = true

WHERE outbound_behavior_is_anomalous = true

LET workflow_behavior_is_anomalous =

  source_context_is_anomalous = true

  OR artifact_behavior_is_anomalous = true

  OR archive_encryption_is_anomalous = true

  OR outbound_behavior_is_anomalous = true

  OR PROCESS_BEHAVIOR_RARITY(

    AgentComputerName,

    SrcProcName,

    SrcProcCmdLine,

    "30d"

  ) <= ENV_RARE_IDENTITY_TOOL_THRESHOLD

WHERE workflow_is_approved = false

   OR workflow_behavior_is_anomalous = true

LET multi_host_count =

  DISTINCT_PROTECTED_HOST_COUNT(

    artifact_class,

    outbound_event.DstIP,

    outbound_event.DstDomain,

    "120m",

    "ENV_IDENTITY_INFRASTRUCTURE_ASSETS"

  )

LET escalation_score =

    CASE WHEN artifact_class IN(

      "private_key_material",

      "certificate_export",

      "adfs_recovery_package"

    ) THEN 2 ELSE 0 END

  + CASE WHEN archive_encryption_is_anomalous = true

      THEN 1 ELSE 0 END

  + CASE WHEN source_context_is_anomalous = true

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.bytes_out >=

      ENV_IDENTITY_MATERIAL_TRANSFER_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN destination_relationship_is_new = true

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.DestinationReputation IN(

      "suspicious",

      "malicious",

      "unknown_high_risk"

    ) THEN 1 ELSE 0 END

  + CASE WHEN approved_destination_use_is_anomalous = true

      THEN 1 ELSE 0 END

  + CASE WHEN outbound_event.callback_count >=

      ENV_CALLBACK_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN FILE_DELETED_NEAR(

      AgentComputerName,

      TgtFilePath,

      "60m"

    ) = true THEN 1 ELSE 0 END

  + CASE WHEN USER_RISK_CLASS(

      User

    ) IN(

      "unexpected",

      "recently_privileged",

      "dormant",

      "service_account_unusual",

      "emergency_account",

      "compromised_suspected"

    ) THEN 1 ELSE 0 END

  + CASE WHEN multi_host_count >=

      ENV_MULTI_PROTECTED_HOST_THRESHOLD

      THEN 1 ELSE 0 END

  + CASE WHEN CORROBORATING_EVENT_NEAR(

      AgentComputerName,

      User,

      "ENV_DIRECTORY_ADFS_CERTIFICATE_IDENTITY_EVENTS",

      "120m"

    ) = true THEN 2 ELSE 0 END

EMIT alert

SET severity =

  CASE

    WHEN escalation_score >= ENV_SENTINELONE_HIGH_THRESHOLD

      THEN "high"

    ELSE "medium"

  END

SET cyberdax_rule =

  "Sensitive Federation Material Staging Followed by Unusual Outbound Communication"

SET confidence =

  CASE

    WHEN escalation_score >= ENV_SENTINELONE_HIGH_THRESHOLD

      THEN "probable_sensitive_identity_material_staging_and_transfer"

    ELSE "suspicious_identity_material_staging_requires_corroboration"

  END

Splunk

Detection Viability Assessment

Splunk can provide strong behavior-driven coverage for AD FS signing-key exposure and forged-token trust compromise when normalized Active Directory object-access, endpoint, certificate, AD FS issuance, authentication, relying-party, cloud, identity-context, and downstream administrative telemetry are available.

Three rule opportunities survive validation:

·        Unexpected access or control change involving the validated AD FS DKM container

·        Suspicious DKM access followed by probable federation key-material handling

·        Federation access without expected issuance lineage followed by privileged, sensitive, or identity-inconsistent activity

Each rule is independently deployable. The implementation patterns use visible SPL, customer-maintained lookups, fixed example windows, and normalized fields. They do not require custom macros, CyberDax-named objects, or another CyberDax rule to fire first.

Rule

Unexpected Access or Control Change Involving the Validated AD FS DKM Container

Rule Format

Splunk SPL implementation pattern

Detection Purpose

Detect successful access or security-relevant control changes involving a validated AD FS DKM container when the actor, source, access right, administrative path, or approved-change context is anomalous.

Detection Logic

Alert when normalized Windows directory-service telemetry records protected-object access, permission change, ownership change, inheritance change, auditing change, or protected-attribute modification involving a validated AD FS DKM object.

·        Match only locally validated DKM object GUIDs or distinguished names.

·        Require a normalized access action that can expose or alter protected DKM material.

·        Treat approved accounts and systems as baseline context rather than unconditional exclusions.

·        Validate approved activity against actor, source, object, action, and change-window time.

·        Retain source-unattributed activity with reduced confidence.

·        Increase severity for control changes, unusual identities, repeated access, multiple DKM objects, or supporting certificate and endpoint evidence.

·        Do not classify the result as confirmed signing-key theft or forged-token activity.

Required Telemetry

·        Windows Security and Directory Service object-access and object-change events

·        Validated AD FS DKM object GUID and distinguished-name inventory

·        Normalized actor, actor SID, source host, source IP, logon ID, object identifier, access action, and event time

·        Approved AD FS administration, backup, recovery, certificate-management, migration, and maintenance records

·        Identity-risk and privilege-state enrichment

·        Certificate, endpoint, authentication, and AD FS telemetry for corroboration

Engineering Implementation Instructions

Maintain adfs_dkm_objects as a customer-managed lookup containing each monitored DKM object identifier, AD FS farm, environment, canonical object GUID, and canonical distinguished name.

Normalize raw access masks and property identifiers into the access_action field before deploying the rule.

Maintain adfs_approved_activity as a time-aware lookup containing the approved actor, source host, object, action, change start time, and change end time.

The example uses a 30-minute aggregation window and three events as the repeated-access threshold. Adjust these values only after local testing.

Validate the search in hunt mode before alert activation.

DRI Assessment

High. The rule is anchored to validated DKM object access and security-control behavior rather than to a CVE, exploit, command line, file path, or attacker tool.

DRI

8.9 / 10

TCR Assessment

Operational confidence is high for unexpected successful access or security-control change involving a validated DKM object. The rule does not independently prove that usable signing-key material was recovered.

Operational TCR

8.4 / 10

Full-Telemetry TCR

9.5 / 10

Limitations

Object-access auditing may be incomplete or misconfigured. Directory events may identify the object and requested action without proving which protected value was returned.

Legitimate installation, backup, recovery, migration, certificate rollover, testing, or incident-response activity may resemble suspicious access.

Previously collected DKM material may be used without generating a new directory event.

Detection Query Pattern

(index=windows_security OR index=active_directory)

(EventCode=4662 OR EventCode=4670 OR EventCode=5136 OR EventCode=5137 OR EventCode=5139 OR EventCode=5141)

| eval original_event_time=_time

| eval object_identifier=coalesce(

    ObjectGUID,

    object_guid,

    ObjectName,

    object_dn,

    DistinguishedName

  )

| lookup adfs_dkm_objects

    object_identifier

    OUTPUT farm_id,

           environment_scope,

           canonical_object_guid,

           canonical_object_dn

| where isnotnull(farm_id)

| eval actor=lower(coalesce(

    Account_Name,

    SubjectUserName,

    user,

    src_user

  ))

| eval actor_sid=coalesce(

    SubjectUserSid,

    user_sid

  )

| eval source_host=lower(coalesce(

    Workstation_Name,

    Caller_Computer_Name,

    src_host,

    ComputerName,

    host

  ))

| eval source_ip=coalesce(

    IpAddress,

    ClientAddress,

    src_ip

  )

| eval logon_id=coalesce(

    SubjectLogonId,

    Logon_ID,

    session_id

  )

| where access_action IN (

    "read_protected_value",

    "control_access",

    "write_protected_value",

    "change_permissions",

    "take_ownership",

    "change_inheritance",

    "change_auditing"

  )

| lookup adfs_approved_activity

    actor

    source_host

    canonical_object_guid

    access_action

    OUTPUT change_start_time,

           change_end_time,

           approved_activity

| eval change_start_time=tonumber(change_start_time)

| eval change_end_time=tonumber(change_end_time)

| eval approved_activity=if(

    approved_activity="true"

    AND isnotnull(change_start_time)

    AND isnotnull(change_end_time)

    AND original_event_time>=change_start_time

    AND original_event_time<=change_end_time,

    1,

    0

  )

| lookup identity_risk

    actor

    OUTPUT identity_risk,

           privilege_change_time

| eval event_id=md5(

    tostring(original_event_time)

    ."|".coalesce(canonical_object_guid,"")

    ."|".coalesce(actor_sid,actor,"")

    ."|".coalesce(source_host,source_ip,"")

    ."|".coalesce(logon_id,"")

    ."|".coalesce(access_action,"")

  )

| eval grouping_actor=coalesce(

    actor_sid,

    actor,

    event_id

  )

| eval grouping_source=coalesce(

    source_host,

    source_ip,

    event_id

  )

| eval grouping_session=coalesce(

    logon_id,

    event_id

  )

| eval attribution_complete=if(

    isnotnull(actor)

    AND (

      isnotnull(source_host)

      OR isnotnull(source_ip)

    ),

    1,

    0

  )

| bin _time span=30m

| stats count AS event_count dc(canonical_object_guid) AS dkm_object_count values(access_action) AS access_actions values(canonical_object_guid) AS dkm_objects values(canonical_object_dn) AS dkm_object_names values(actor) AS actor values(actor_sid) AS actor_sid values(source_host) AS source_host values(source_ip) AS source_ip values(logon_id) AS logon_id values(identity_risk) AS identity_risk min(approved_activity) AS approved_activity max(attribution_complete) AS attribution_complete earliest(original_event_time) AS first_event_time latest(original_event_time) AS last_event_time BY time farmid environment_scope grouping_actor grouping_source grouping_session

| eval control_change=if(

    mvfind(

      access_actions,

      "^(control_access|change_permissions|take_ownership|change_inheritance|change_auditing)$"

    )>=0,

    1,

    0

  )

| eval unusual_identity=if(

    mvfind(

      identity_risk,

      "^(unexpected|recently_privileged|dormant|service_account_unusual|emergency_account|terminated)$"

    )>=0,

    1,

    0

  )

| where approved_activity=0

    OR control_change=1

    OR unusual_identity=1

    OR event_count>=3

    OR dkm_object_count>=2

| eval severity=if(

    control_change=1

    OR unusual_identity=1

    OR event_count>=3

    OR dkm_object_count>=2,

    "high",

    "medium"

  )

| eval detection_name=

    "Unexpected Access or Control Change Involving the Validated AD FS DKM Container"

| eval confidence=case(

    severity="high"

      AND attribution_complete=1,

      "suspicious_dkm_access_or_control_change",

    attribution_complete=0,

      "unexpected_dkm_activity_with_incomplete_attribution",

    true(),

      "unexpected_dkm_activity_requires_investigation"

  )

| eval time=lastevent_time

| table

    _time

    first_event_time

    last_event_time

    farm_id

    environment_scope

    dkm_objects

    dkm_object_names

    actor

    actor_sid

    source_host

    source_ip

    logon_id

    access_actions

    event_count

    dkm_object_count

    identity_risk

    approved_activity

    attribution_complete

    severity

    detection_name

    confidence

Rule

Suspicious DKM Access Followed by Probable Federation Key-Material Handling

Rule Format

Splunk SPL implementation pattern

Detection Purpose

Detect access to a validated AD FS DKM object followed by certificate, private-key, recovery, backup, export, archive, staging, transfer, or cryptographic activity consistent with probable federation signing-key-material handling.

Detection Logic

Correlate a normalized DKM event with subsequent key-material handling performed by the same actor and source host.

·        Require the handling event to occur after the DKM event.

·        Limit the production correlation window to four hours.

·        Require both events to share the same normalized actor and source host.

·        Prefer matching logon IDs when both events contain one.

·        Exclude locally approved backup, recovery, certificate-management, migration, and incident-response workflows.

·        Increase severity for private-key access, certificate export, recovery-package access, archive staging, transfer, or monitoring degradation.

·        Classify the result as probable key-material handling rather than confirmed key recovery.

Required Telemetry

·        Normalized DKM access and control-change events

·        Endpoint process, command-line, file, certificate, private-key, archive, staging, transfer, and network telemetry

·        Actor, source host, logon ID, AD FS farm, object identifier, action classification, and event time

·        Approved backup, recovery, migration, certificate-management, and incident-response workflow context

Engineering Implementation Instructions

Normalize qualifying events into two visible classifications:

·        event_stage="dkm_access" for validated DKM access or control-change activity

·        event_stage="key_handling" for certificate, private-key, recovery, export, archive, staging, transfer, or monitoring-degradation activity

Populate handling_action with the normalized behavior observed on the handling event.

Maintain approved_key_workflows as a customer-managed lookup containing actor, source host, handling action, and approved start and end times.

The example uses a four-hour correlation window. Reduce the window where normal administrative workflows are tightly scheduled.

DRI Assessment

High. The rule detects the durable sequence of validated DKM access followed by probable protected-key handling across changing tools and command syntax.

DRI

8.8 / 10

TCR Assessment

Operational confidence is high when DKM access and key-handling activity share the same actor, source host, and compatible logon context. The rule does not prove successful private-key recovery.

Operational TCR

8.5 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Handling may occur offline, entirely in memory, through opaque backup formats, on an unmonitored system, or without reusable actor and source context.

Shared administrative accounts or management relays can reduce attribution quality.

Detection Query Pattern

(index=windows_security OR index=active_directory OR index=endpoint OR index=certificate OR index=network)

(event_stage="dkm_access" OR event_stage="key_handling")

| eval actor=lower(coalesce(

    actor,

    Account_Name,

    SubjectUserName,

    user,

    src_user

  ))

| eval source_host=lower(coalesce(

    source_host,

    Workstation_Name,

    Caller_Computer_Name,

    src_host,

    ComputerName,

    host

  ))

| eval logon_id=coalesce(

    logon_id,

    SubjectLogonId,

    Logon_ID,

    session_id

  )

| eval logon_id=if(

    isnull(logon_id)

    OR trim(tostring(logon_id))="",

    null(),

    tostring(logon_id)

  )

| where isnotnull(actor)

    AND isnotnull(source_host)

| eval dkm_event_id=if(

    event_stage="dkm_access",

    coalesce(

      dkm_event_id,

      event_id,

      md5(

        tostring(_time)

        ."|".actor

        ."|".source_host

        ."|".coalesce(logon_id,"")

        ."|".coalesce(canonical_object_guid,"")

        ."|".coalesce(farm_id,"")

      )

    ),

    null()

  )

| eval handling_event_id=if(

    event_stage="key_handling",

    coalesce(

      handling_event_id,

      event_id,

      md5(

        tostring(_time)

        ."|".actor

        ."|".source_host

        ."|".coalesce(logon_id,"")

        ."|".coalesce(handling_action,"")

        ."|".coalesce(process_name,"")

        ."|".coalesce(file_path,"")

        ."|".coalesce(dest_ip,"")

        ."|".coalesce(dest_domain,"")

      )

    ),

    null()

  )

| eval dkm_candidate=if(

    event_stage="dkm_access",

    dkm_event_id

      ."|||".tostring(_time)

      ."|||".coalesce(canonical_object_guid,"")

      ."|||".coalesce(farm_id,"")

      ."|||".coalesce(logon_id,""),

    null()

  )

| eventstats

    values(dkm_candidate) AS dkm_candidates

    BY actor source_host

| where event_stage="key_handling"

    AND mvcount(dkm_candidates)>0

| eval handling_time=_time

| mvexpand dkm_candidates

| rex field=dkm_candidates

    "^(?<dkm_event_id>.*?)\|\|\|(?<dkm_time>\d+(?:\.\d+)?)\|\|\|(?<dkm_object>.*?)\|\|\|(?<farm_id>.*?)\|\|\|(?<dkm_logon_id>.*)$"

| eval dkm_time=tonumber(dkm_time)

| eval dkm_logon_id=if(

    isnull(dkm_logon_id)

    OR trim(dkm_logon_id)="",

    null(),

    dkm_logon_id

  )

| where isnotnull(dkm_event_id)

    AND isnotnull(dkm_time)

    AND handling_time>=dkm_time

    AND handling_time-dkm_time<=14400

| eval logon_context_valid=if(

    isnull(dkm_logon_id)

    OR isnull(logon_id)

    OR dkm_logon_id=logon_id,

    1,

    0

  )

| where logon_context_valid=1

| eval approved_start_time=tonumber(approved_start_time)

| eval approved_end_time=tonumber(approved_end_time)

| eval approved_workflow=if(

    lower(coalesce(approved_workflow,"false"))="true"

    AND isnotnull(approved_start_time)

    AND isnotnull(approved_end_time)

    AND handling_time>=approved_start_time

    AND handling_time<=approved_end_time,

    1,

    0

  )

| where approved_workflow=0

| eval high_risk_handling=if(

    handling_action IN (

      "certificate_export",

      "private_key_access",

      "adfs_recovery_access",

      "cryptographic_private_key_operation",

      "identity_material_transfer"

    ),

    1,

    0

  )

| eval supporting_handling=if(

    handling_action IN (

      "encrypted_identity_archive",

      "sensitive_identity_staging",

      "monitoring_degradation"

    ),

    1,

    0

  )

| eval correlation_delay=handling_time-dkm_time

| eval grouping_logon=coalesce(

    logon_id,

    "missing_logon_context"

  )

| stats

    earliest(handling_time) AS first_handling_time

    latest(handling_time) AS last_handling_time

    values(logon_id) AS logon_id

    values(handling_action) AS handling_actions

    values(process_name) AS processes

    values(file_path) AS file_paths

    values(dest_ip) AS destination_ips

    values(dest_domain) AS destination_domains

    max(high_risk_handling) AS high_risk_handling

    max(supporting_handling) AS supporting_handling

    min(correlation_delay) AS shortest_delay

    dc(handling_event_id) AS handling_event_count

    BY dkm_event_id

       dkm_time

       dkm_object

       farm_id

       actor

       source_host

       grouping_logon

| eval severity=if(

    high_risk_handling=1

    OR handling_event_count>=2

    OR supporting_handling=1,

    "high",

    "medium"

  )

| eval detection_name=

    "Suspicious DKM Access Followed by Probable Federation Key-Material Handling"

| eval confidence=case(

    severity="high"

      AND high_risk_handling=1,

      "probable_federation_key_material_handling",

    severity="high",

      "suspicious_post_dkm_handling_with_multiple_signals",

    true(),

      "suspicious_post_dkm_handling_requires_investigation"

  )

| eval time=lasthandling_time

| table

    _time

    dkm_event_id

    dkm_time

    dkm_object

    farm_id

    first_handling_time

    last_handling_time

    shortest_delay

    actor

    source_host

    logon_id

    handling_actions

    handling_event_count

    processes

    file_paths

    destination_ips

    destination_domains

    severity

    detection_name

    confidence

Rule

Federation Access Without Expected Issuance Lineage Followed by Privileged, Sensitive, or Identity-Inconsistent Activity

Rule Format

Splunk SPL implementation pattern

Detection Purpose

Detect an accepted AD FS federation session that cannot be reconciled with expected AD FS issuance or upstream authentication and is followed by privileged, sensitive, persistent, or identity-inconsistent downstream activity.

Detection Logic

Group normalized federation issuance, upstream authentication, federation acceptance, and downstream activity by an immutable assertion or session identifier.

·        Require a successful federation acceptance event.

·        Use an assertion ID, federation-session ID, application-session ID, or cloud-session ID as the correlation key.

·        Treat issuance as matched only when it occurred within five minutes before acceptance.

·        Treat upstream authentication as matched only when it occurred within fifteen minutes before acceptance.

·        Treat downstream behavior as relevant only when it occurred within two hours after acceptance.

·        Require missing issuance or authentication plus at least one independent behavioral anomaly.

·        Increase severity when two or more independent anomalies are present or prior DKM or key-handling evidence exists.

·        Do not treat missing lineage alone as proof of token forgery.

Required Telemetry

·        AD FS issuance, authentication, claim-processing, trust, and administrative events

·        Relying-party, cloud, SaaS, VPN, proxy, and administrative-application acceptance logs

·        Assertion ID, federation-session ID, application-session ID, cloud-session ID, issuer, audience, subject, source, device, and event time

·        Primary authentication, MFA, identity-state, entitlement, and privileged-role context

·        Downstream administrative, credential, persistence, security-control, and sensitive-data activity

·        Prior DKM or probable key-handling evidence where available

Engineering Implementation Instructions

Normalize qualifying records into:

·        event_stage="issuance"

·        event_stage="authentication"

·        event_stage="acceptance"

·        event_stage="downstream"

Populate correlation_id from the strongest available immutable session identifier. Do not use username and time as the sole production correlation method.

Populate downstream_action with normalized privileged, persistence, security-control, lateral-expansion, or sensitive-data behavior.

Maintain identity_context as a customer-managed lookup containing account state, employment state, account type, privilege tier, and expected applications.

The five-minute issuance window, fifteen-minute authentication window, and two-hour downstream window are example production values and should be validated locally.

DRI Assessment

High. The rule detects accepted federation access with missing expected lineage and anomalous downstream identity behavior rather than relying on a specific forged-token implementation.

DRI

9.0 / 10

TCR Assessment

Operational confidence is moderate to high when missing lineage is accompanied by independent claims, identity, privileged, sensitive, source, device, or prior key-compromise evidence.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.6 / 10

Limitations

Incomplete AD FS, authentication, relying-party, identity, or downstream logging can create apparent lineage gaps.

Some relying parties do not preserve immutable assertion or federation-session identifiers.

Legitimate failover, clock drift, testing, claim-rule changes, entitlement changes, or emergency access may produce similar conditions.

Detection Query Pattern

(index=adfs OR index=authentication OR index=cloud OR index=saas OR index=vpn)

(event_stage="issuance" OR event_stage="authentication" OR event_stage="acceptance" OR event_stage="downstream")

| eval subject=lower(coalesce(

    subject,

    user,

    user_name,

    account

  ))

| where isnotnull(subject)

| eval event_result=lower(coalesce(

    result,

    action,

    status

  ))

| lookup adfs_monitored_trusts

    issuer

    audience

    relying_party

    OUTPUT trust_id,

           monitored_trust

| eval monitored_trust=lower(coalesce(

    monitored_trust,

    "false"

  ))

| eval successful_acceptance=if(

    event_stage="acceptance"

    AND event_result IN (

      "success",

      "successful",

      "allowed",

      "accepted"

    )

    AND monitored_trust="true"

    AND isnotnull(trust_id),

    1,

    0

  )

| eval event_id=coalesce(

    event_id,

    md5(

      tostring(_time)

      ."|".event_stage

      ."|".subject

      ."|".coalesce(assertion_id,"")

      ."|".coalesce(federation_session_id,"")

      ."|".coalesce(application_session_id,"")

      ."|".coalesce(cloud_session_id,"")

      ."|".coalesce(downstream_action,"")

      ."|".coalesce(_raw,"")

    )

  )

| eval acceptance_event_id=if(

    successful_acceptance=1,

    coalesce(

      acceptance_event_id,

      event_id

    ),

    null()

  )

| eval correlation_keys=mvappend(

    if(

      isnotnull(assertion_id)

      AND trim(tostring(assertion_id))!="",

      "assertion::".tostring(assertion_id),

      null()

    ),

    if(

      isnotnull(federation_session_id)

      AND trim(tostring(federation_session_id))!="",

      "federation_session::".tostring(federation_session_id),

      null()

    ),

    if(

      isnotnull(application_session_id)

      AND trim(tostring(application_session_id))!="",

      "application_session::".tostring(application_session_id),

      null()

    ),

    if(

      isnotnull(cloud_session_id)

      AND trim(tostring(cloud_session_id))!="",

      "cloud_session::".tostring(cloud_session_id),

      null()

    )

  )

| eval correlation_keys=mvfilter(

    isnotnull(correlation_keys)

    AND correlation_keys!=""

  )

| where mvcount(correlation_keys)>0

| mvexpand correlation_keys

| eval acceptance_anchor=if(

    successful_acceptance=1,

    acceptance_event_id

      ."|||".tostring(_time)

      ."|||".coalesce(trust_id,"")

      ."|||".coalesce(issuer,"")

      ."|||".coalesce(audience,"")

      ."|||".coalesce(relying_party,"")

      ."|||".coalesce(src_ip,"")

      ."|||".coalesce(device_id,""),

    null()

  )

| eventstats

    values(acceptance_anchor) AS acceptance_anchors

    BY subject correlation_keys

| where mvcount(acceptance_anchors)>0

| mvexpand acceptance_anchors

| rex field=acceptance_anchors

    "^(?<anchor_acceptance_event_id>.*?)\|\|\|(?<acceptance_time>\d+(?:\.\d+)?)\|\|\|(?<anchor_trust_id>.*?)\|\|\|(?<anchor_issuer>.*?)\|\|\|(?<anchor_audience>.*?)\|\|\|(?<anchor_relying_party>.*?)\|\|\|(?<anchor_src_ip>.*?)\|\|\|(?<anchor_device_id>.*)$"

| eval acceptance_time=tonumber(acceptance_time)

| where isnotnull(anchor_acceptance_event_id)

    AND isnotnull(acceptance_time)

| eval acceptance_anchor_row=if(

    successful_acceptance=1

    AND acceptance_event_id=anchor_acceptance_event_id,

    1,

    0

  )

| eval issuance_candidate=if(

    event_stage="issuance"

    AND time<=acceptancetime

    AND acceptance_time-_time<=300,

    1,

    0

  )

| eval authentication_candidate=if(

    event_stage="authentication"

    AND time<=acceptancetime

    AND acceptance_time-_time<=900,

    1,

    0

  )

| eval downstream_candidate=if(

    event_stage="downstream"

    AND time>=acceptancetime

    AND time-acceptancetime<=7200,

    1,

    0

  )

| where acceptance_anchor_row=1

    OR issuance_candidate=1

    OR authentication_candidate=1

    OR downstream_candidate=1

| eval issuance_time_candidate=if(

    issuance_candidate=1,

    _time,

    null()

  )

| eval authentication_time_candidate=if(

    authentication_candidate=1,

    _time,

    null()

  )

| eval downstream_time_candidate=if(

    downstream_candidate=1,

    _time,

    null()

  )

| eval downstream_action_candidate=if(

    downstream_candidate=1,

    downstream_action,

    null()

  )

| eval claims_signal=if(

    acceptance_anchor_row=1

    AND claims_inconsistent=1,

    1,

    0

  )

| eval source_device_signal=if(

    (

      acceptance_anchor_row=1

      OR downstream_candidate=1

    )

    AND source_or_device_anomalous=1,

    1,

    0

  )

| eval application_context_signal=if(

    (

      acceptance_anchor_row=1

      OR downstream_candidate=1

    )

    AND application_context_inconsistent=1,

    1,

    0

  )

| eval prior_key_signal=if(

    acceptance_anchor_row=1

    AND prior_key_compromise_evidence=1,

    1,

    0

  )

| stats

    max(acceptance_anchor_row) AS acceptance_anchor_present

    max(issuance_candidate) AS issuance_match

    max(authentication_candidate) AS authentication_match

    max(downstream_candidate) AS downstream_match

    max(issuance_time_candidate) AS issuance_time

    max(authentication_time_candidate) AS authentication_time

    min(downstream_time_candidate) AS first_downstream_time

    max(downstream_time_candidate) AS last_downstream_time

    values(downstream_action_candidate) AS downstream_actions

    max(claims_signal) AS claims_inconsistent

    max(source_device_signal) AS source_or_device_anomalous

    max(application_context_signal) AS application_context_inconsistent

    max(prior_key_signal) AS prior_key_compromise_evidence

    BY anchor_acceptance_event_id

       acceptance_time

       anchor_trust_id

       anchor_issuer

       anchor_audience

       anchor_relying_party

       anchor_src_ip

       anchor_device_id

       subject

       event_id

| stats

    max(acceptance_anchor_present) AS acceptance_anchor_present

    max(issuance_match) AS issuance_match

    max(authentication_match) AS authentication_match

    max(downstream_match) AS downstream_match

    max(issuance_time) AS issuance_time

    max(authentication_time) AS authentication_time

    min(first_downstream_time) AS first_downstream_time

    max(last_downstream_time) AS last_downstream_time

    values(downstream_actions) AS downstream_actions

    max(claims_inconsistent) AS claims_inconsistent

    max(source_or_device_anomalous) AS source_or_device_anomalous

    max(application_context_inconsistent) AS application_context_inconsistent

    max(prior_key_compromise_evidence) AS prior_key_compromise_evidence

    BY anchor_acceptance_event_id

       acceptance_time

       anchor_trust_id

       anchor_issuer

       anchor_audience

       anchor_relying_party

       anchor_src_ip

       anchor_device_id

       subject

| where acceptance_anchor_present=1

    AND downstream_match=1

| lookup identity_context

    subject

    OUTPUT account_state,

           employment_state,

           account_type,

           privilege_tier

| eval identity_inconsistent=if(

    account_state IN (

      "disabled",

      "dormant"

    )

    OR employment_state IN (

      "terminated",

      "leave_unexpected"

    )

    OR account_type IN (

      "service_noninteractive",

      "emergency"

    ),

    1,

    0

  )

| eval privileged_downstream_action=if(

    mvfind(

      downstream_actions,

      "^(privileged_administration|role_change|group_change|credential_creation|service_principal_creation|access_key_creation|api_token_creation|security_control_change|persistence)$"

    )>=0,

    1,

    0

  )

| eval sensitive_downstream_action=if(

    mvfind(

      downstream_actions,

      "^(sensitive_data_access|lateral_expansion)$"

    )>=0,

    1,

    0

  )

| eval claims_inconsistent=coalesce(

    claims_inconsistent,

    0

  )

| eval source_or_device_anomalous=coalesce(

    source_or_device_anomalous,

    0

  )

| eval application_context_inconsistent=coalesce(

    application_context_inconsistent,

    0

  )

| eval prior_key_compromise_evidence=coalesce(

    prior_key_compromise_evidence,

    0

  )

| eval corroboration_count=

    if(claims_inconsistent=1,1,0)

    + if(identity_inconsistent=1,1,0)

    + if(application_context_inconsistent=1,1,0)

    + if(privileged_downstream_action=1,1,0)

    + if(sensitive_downstream_action=1,1,0)

    + if(source_or_device_anomalous=1,1,0)

    + if(prior_key_compromise_evidence=1,1,0)

| where (

      issuance_match=0

      OR authentication_match=0

    )

    AND corroboration_count>=1

| eval severity=case(

    prior_key_compromise_evidence=1,

      "high",

    corroboration_count>=2,

      "high",

    true(),

      "medium"

  )

| eval detection_name=

    "Federation Access Without Expected Issuance Lineage Followed by Privileged, Sensitive, or Identity-Inconsistent Activity"

| eval confidence=case(

    severity="high"

      AND prior_key_compromise_evidence=1,

      "suspected_forged_token_with_prior_key_compromise_evidence",

    severity="high"

      AND issuance_match=0

      AND authentication_match=0,

      "accepted_federation_session_without_expected_lineage_and_multiple_anomalies",

    severity="high",

      "lineage_failure_with_multiple_behavioral_anomalies",

    true(),

      "lineage_failure_with_behavioral_anomaly_requires_investigation"

  )

| rename

    anchor_acceptance_event_id AS acceptance_event_id

    anchor_trust_id AS trust_id

    anchor_issuer AS issuer

    anchor_audience AS audience

    anchor_relying_party AS relying_party

    anchor_src_ip AS source_ip

    anchor_device_id AS device_id

| eval time=acceptancetime

| table

    _time

    acceptance_event_id

    trust_id

    subject

    issuer

    audience

    relying_party

    source_ip

    device_id

    issuance_time

    authentication_time

    acceptance_time

    first_downstream_time

    last_downstream_time

    issuance_match

    authentication_match

    downstream_actions

    account_state

    employment_state

    account_type

    privilege_tier

    claims_inconsistent

    identity_inconsistent

    application_context_inconsistent

    privileged_downstream_action

    sensitive_downstream_action

    source_or_device_anomalous

    prior_key_compromise_evidence

    corroboration_count

    severity

    detection_name

    confidence

Elastic

Detection Viability Assessment

Elastic can provide strong behavior-driven coverage for AD FS signing-key exposure and forged-token trust compromise when normalized Windows directory-service, endpoint, certificate, AD FS issuance, authentication, relying-party, cloud, identity-context, and downstream administrative telemetry are available.

Three rule opportunities survive validation:

·        Unexpected access or control change involving the validated AD FS DKM container

·        Suspicious DKM access followed by probable federation key-material handling

·        Federation access without expected issuance lineage followed by privileged, sensitive, or identity-inconsistent activity

Each rule is independently deployable. The implementation patterns use visible EQL logic, neutral enriched fields, explicit correlation windows, and customer-managed exception context. They do not require CyberDax-named objects, custom query macros, or another CyberDax rule to fire first.

Rule

Unexpected Access or Control Change Involving the Validated AD FS DKM Container

Rule Format

Elastic EQL implementation pattern

Detection Purpose

Detect successful access or security-relevant control changes involving a validated AD FS DKM container when the actor, source, access right, administrative path, or approved-change context is anomalous.

Detection Logic

Alert when normalized Windows directory-service telemetry records protected-object access, protected-attribute modification, ownership change, permission change, inheritance change, or auditing change involving a validated AD FS DKM object.

·        Match only DKM object GUIDs or distinguished names validated for the monitored AD FS environment.

·        Require a normalized access action capable of exposing or modifying protected DKM material.

·        Treat approved accounts and systems as contextual baselines rather than unconditional exclusions.

·        Apply approved-change exceptions only when actor, source, object, action, and event time align.

·        Retain source-unattributed activity with reduced confidence.

·        Increase severity through local rule logic when control changes, unusual identities, repeated access, multiple DKM objects, or supporting endpoint and certificate evidence are present.

·        Do not classify the event as confirmed signing-key theft or forged-token activity.

Required Telemetry

·        Windows Security and Directory Service object-access and object-change telemetry

·        Validated DKM object GUID and distinguished-name inventory

·        Normalized actor, actor SID, source host, source IP, logon ID, object identifier, access action, and event time

·        Approved AD FS administration, backup, recovery, certificate-management, migration, and maintenance context

·        Identity-risk and privilege-state enrichment

·        Endpoint, certificate, authentication, and AD FS telemetry for investigation and severity enrichment

Engineering Implementation Instructions

Use this pattern as an implementation guide for Elastic environments that support normalized Windows directory-service object-access and object-change telemetry; validated AD FS DKM object enrichment; access-right classification; identity-risk enrichment; time-aware approved administrative exceptions; and local severity logic.

Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

Populate adfs.dkm.object.validated only when the event object matches a locally validated DKM object GUID or distinguished name.

Populate adfs.dkm.access_action from locally validated access-mask, property-GUID, and directory-change mappings.

Populate exception.approved_adfs_dkm_activity only when actor, source, object, action, and event time match an approved administrative record.

Run the rule in investigation mode until DKM object identity, action classification, approved exceptions, source attribution, event volume, and SOC procedures have been validated.

DRI Assessment

High. The rule is anchored to validated DKM object access and security-control behavior rather than to a CVE, exploit, command line, file path, or attacker tool.

DRI

8.9 / 10

TCR Assessment

Operational confidence is high for unexpected successful access or security-control change involving a validated DKM object. The rule does not independently prove that usable signing-key material was recovered.

Operational TCR

8.4 / 10

Full-Telemetry TCR

9.5 / 10

Limitations

Object-access auditing may be incomplete or misconfigured. Directory events may identify the object and requested action without proving which protected value was returned.

Legitimate installation, backup, recovery, migration, certificate rollover, testing, or incident-response activity may resemble suspicious access.

Previously collected DKM material may be used without generating a new directory event.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support normalized Windows directory-service object-access and object-change telemetry; validated AD FS DKM object enrichment; access-action classification; identity-risk context; time-aware approved exceptions; and local severity logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

any where

host.os.type == "windows" and

event.outcome in (

  "success",

  "successful",

  "succeeded"

) and

?adfs.dkm.object.validated == true and

?adfs.dkm.access_action in (

  "read_protected_value",

  "control_access",

  "write_protected_value",

  "change_permissions",

  "take_ownership",

  "change_inheritance",

  "change_auditing"

) and

(

  ?exception.approved_adfs_dkm_activity == null or

  ?exception.approved_adfs_dkm_activity != true or

  ?adfs.dkm.control_change == true or

  ?identity.risk.classification in (

    "unexpected",

    "recently_privileged",

    "dormant",

    "service_account_unusual",

    "emergency_account",

    "terminated"

  )

) and

(

  ?adfs.dkm.object.guid != null or

  ?adfs.dkm.object.distinguished_name != null

)

Rule

Suspicious DKM Access Followed by Probable Federation Key-Material Handling

Rule Format

Elastic EQL sequence implementation pattern

Detection Purpose

Detect access to a validated AD FS DKM object followed by certificate, private-key, recovery, export, archive, staging, transfer, or cryptographic activity consistent with probable federation signing-key-material handling.

Detection Logic

Correlate validated DKM access with subsequent key-material handling performed through the same actor and source-host context.

·        Require the DKM event to occur before the handling event.

·        Limit the production sequence to four hours.

·        Require the actor and source host to remain consistent across both sequence stages.

·        Require compatible logon context when both events contain a logon identifier.

·        Exclude approved backup, recovery, migration, certificate-management, and incident-response workflows only when their time-aware exception criteria match.

·        Detect private-key access, certificate export, recovery-package access, archive staging, identity-material transfer, cryptographic private-key operations, or monitoring degradation.

·        Classify the result as probable key-material handling rather than confirmed private-key recovery.

Required Telemetry

·        Normalized DKM object-access and control-change telemetry

·        Endpoint process, command-line, file, certificate, private-key, archive, staging, transfer, and network telemetry

·        Actor, source host, logon ID, AD FS farm, DKM object identifier, handling classification, and event time

·        Approved backup, recovery, migration, certificate-management, and incident-response workflow context

Engineering Implementation Instructions

Use this pattern as an implementation guide for Elastic environments that support normalized DKM access telemetry; endpoint and certificate handling classification; actor and source-host normalization; compatible logon-context enrichment; time-aware approved workflow exceptions; and local severity logic.

Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

Populate adfs.dkm.access.confirmed only for access or control-change events involving locally validated DKM objects.

Populate adfs.key_material.action only for normalized certificate, private-key, recovery, archive, staging, transfer, cryptographic, or monitoring-degradation behavior.

Populate adfs.correlation.actor_key with the preferred stable actor identifier and a normalized actor name as the fallback.

Populate adfs.correlation.source_key with the preferred stable host identifier and a normalized host name as the fallback.

Populate adfs.correlation.logon_compatible as true when the logon identifiers match or when one side lacks a usable logon identifier and the actor-plus-source relationship remains valid.

Populate exception.approved_adfs_key_workflow only when the key-handling event falls within the applicable approved workflow window.

The sequence uses a four-hour production correlation window. Reduce the window where administrative operations are tightly scheduled.

DRI Assessment

High. The rule detects the durable sequence of validated DKM access followed by probable protected-key handling across changing tools, file names, command syntax, archive formats, and destinations.

DRI

8.8 / 10

TCR Assessment

Operational confidence is high when DKM access and key-handling behavior share the same actor, source host, and compatible logon context. The rule does not prove successful private-key recovery.

Operational TCR

8.5 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Handling may occur offline, entirely in memory, through opaque backup formats, on an unmonitored system, or without reusable actor and source context.

Shared administrative accounts, management relays, or incomplete logon telemetry can reduce attribution quality.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support normalized DKM access, endpoint, certificate, file, archive, transfer, network, approved-workflow, and actor-and-source correlation telemetry; key-material behavior classification; compatible logon-context enrichment; and local severity logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by adfs.correlation.actor_key, adfs.correlation.source_key with maxspan=4h

  [any where

    ?adfs.dkm.access.confirmed == true and

    ?adfs.dkm.object.validated == true and

    ?adfs.dkm.access_action in (

      "read_protected_value",

      "control_access",

      "write_protected_value",

      "change_permissions",

      "take_ownership",

      "change_inheritance",

      "change_auditing"

    ) and

    ?adfs.correlation.actor_key != null and

    ?adfs.correlation.source_key != null

  ]

  [any where

    ?adfs.key_material.action in (

      "certificate_export",

      "private_key_access",

      "adfs_recovery_access",

      "cryptographic_private_key_operation",

      "encrypted_identity_archive",

      "sensitive_identity_staging",

      "identity_material_transfer",

      "monitoring_degradation"

    ) and

    ?adfs.correlation.actor_key != null and

    ?adfs.correlation.source_key != null and

    ?adfs.correlation.logon_compatible == true and

    (

      ?exception.approved_adfs_key_workflow == null or

      ?exception.approved_adfs_key_workflow != true

    )

  ]

Rule

Federation Access Without Expected Issuance Lineage Followed by Privileged, Sensitive, or Identity-Inconsistent Activity

Rule Format

Elastic EQL sequence implementation pattern

Detection Purpose

Detect an accepted AD FS federation session that lacks expected issuance or upstream-authentication lineage and is followed by privileged, sensitive, persistent, or identity-inconsistent downstream activity.

Detection Logic

Correlate a successful acceptance event from a monitored AD FS trust with downstream activity associated with the same immutable federation or application-session context.

·        Require a successful federation acceptance event.

·        Require the issuer, audience, trust, and relying-party path to map to a monitored AD FS relationship.

·        Require a typed immutable assertion, federation-session, application-session, or cloud-session correlation key.

·        Require the normalized acceptance event to indicate missing expected issuance or authentication lineage.

·        Require downstream activity within two hours after acceptance.

·        Require at least one independent claims, identity, application-context, privileged-action, sensitive-action, source-or-device, or prior-key-compromise signal across the enriched session context.

·        Promote higher severity through local rule logic when multiple independent categories or prior key-compromise evidence are present.

·        Do not treat missing issuance or authentication lineage alone as proof of forged-token use.

Required Telemetry

·        AD FS issuance, authentication, claim-processing, trust, and administrative events

·        Relying-party, cloud, SaaS, VPN, proxy, and administrative-application acceptance logs

·        Typed immutable assertion, federation-session, application-session, or cloud-session identifiers

·        Issuer, audience, trust, subject, source, device, relying party, result, and event time

·        Primary authentication, MFA, identity-state, entitlement, and privileged-role context

·        Downstream administrative, credential, persistence, security-control, lateral-expansion, and sensitive-data activity

·        Prior DKM or probable key-handling evidence where available

Engineering Implementation Instructions

Use this pattern as an implementation guide for Elastic environments that support normalized successful federation acceptance, monitored AD FS trust validation, typed session identifiers, bounded issuance and authentication lineage evaluation, downstream administrative and sensitive-activity classification, historical identity context, and prior DKM or key-handling enrichment.

Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

Create a normalized typed correlation field such as adfs.session.correlation_key using one of the following forms:

·        assertion::<identifier>

·        federation_session::<identifier>

·        application_session::<identifier>

·        cloud_session::<identifier>

Where events contain different identifiers for the same session, reconcile them before the production rule through a transform or enrichment process.

Populate adfs.lineage.issuance_match only when a qualifying AD FS issuance event occurred within five minutes before acceptance.

Populate adfs.lineage.authentication_match only when a qualifying upstream authentication event occurred within fifteen minutes before acceptance.

Populate adfs.trust.monitored only when issuer, audience, trust identifier, and relying-party context match the locally validated AD FS relationship.

Populate adfs.event.type="federation_acceptance" only for successful relying-party or application acceptance events associated with the monitored AD FS trust.

Populate adfs.event.type="downstream_activity" only for downstream administrative, persistence, security-control, lateral-expansion, sensitive-data, identity-context, application-context, or source-and-device behavior occurring within the configured two-hour post-acceptance window.

Acceptance-specific claims inconsistency and prior key-compromise evidence should be incorporated into an enriched session-level field or local rule severity calculation. Downstream identity, application-context, privileged, sensitive, persistence, and source-or-device evidence should be classified on the downstream event.

EQL establishes the ordered acceptance-to-downstream sequence but does not calculate a combined cross-event corroboration count. Multiple-category promotion and prior-key-compromise severity escalation must therefore be implemented through precomputed session enrichment or local Elastic rule severity and risk-score logic.

Run the rule in investigation mode until trust validation, acceptance-result normalization, identifier reconciliation, lineage windows, downstream association, historical identity enrichment, and independent-signal scoring have been validated.

DRI Assessment

High. The rule detects successful federation access with missing expected lineage and anomalous downstream identity behavior rather than relying on a specific forged-token implementation.

DRI

9.0 / 10

TCR Assessment

Operational confidence is moderate to high when a successful monitored AD FS acceptance lacks expected issuance or authentication lineage and is followed by independent identity, claims, privileged, sensitive, source, device, or prior key-compromise evidence.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.6 / 10

Limitations

Incomplete AD FS, authentication, relying-party, identity, or downstream telemetry can create apparent lineage gaps.

Some relying parties do not preserve immutable assertion or federation-session identifiers.

Legitimate failover, clock drift, federation testing, claim-rule changes, entitlement changes, or emergency access may produce similar conditions.

The rule cannot provide cryptographic proof of offline forged-token construction.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support successful federation-acceptance normalization; monitored AD FS trust validation; typed and reconciled assertion, federation-session, application-session, or cloud-session identifiers; bounded issuance and authentication lineage evaluation; post-acceptance downstream behavior classification; historical identity context; prior DKM or key-handling enrichment; and local severity logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by adfs.session.correlation_key with maxspan=2h

  [any where

    event.outcome in (

      "success",

      "successful",

      "succeeded"

    ) and

    ?adfs.event.type == "federation_acceptance" and

    ?adfs.trust.monitored == true and

    ?adfs.session.correlation_key != null and

    (

      ?adfs.lineage.issuance_match == false or

      ?adfs.lineage.authentication_match == false

    )

  ]

  [any where

    ?adfs.event.type == "downstream_activity" and

    ?adfs.session.correlation_key != null and

    (

      ?downstream.action in (

        "privileged_administration",

        "role_change",

        "group_change",

        "credential_creation",

        "service_principal_creation",

        "access_key_creation",

        "api_token_creation",

        "security_control_change",

        "persistence",

        "sensitive_data_access",

        "lateral_expansion"

      ) or

      ?identity.state.inconsistent == true or

      ?identity.application_context.inconsistent == true or

      ?source_or_device.anomalous == true

    )

  ]

QRadar

Detection Viability Assessment

QRadar can provide strong behavior-driven coverage for AD FS signing-key exposure and forged-token trust compromise when Windows directory-service, endpoint, certificate, AD FS, authentication, relying-party, cloud, identity, and downstream administrative telemetry is normalized through supported DSMs, enabled custom event properties, reference data, building blocks, CRE rules, and locally validated stateful correlation processes.

Three rule opportunities survive validation:

·        Unexpected access or control change involving the validated AD FS DKM container

·        Suspicious DKM access followed by probable federation key-material handling

·        Federation access without expected issuance lineage followed by privileged, sensitive, or identity-inconsistent activity

Rule 1 uses a direct AQL aggregate search as an analyst and validation view, with production thresholds implemented separately through native CRE state and counting tests.

Rules 2 and 3 use CRE correlation, state preservation, and structured workflow-summary events. Event ordering, bounded negative-lineage evaluation, prior-stage value preservation, cross-stage enrichment, replay protection, and corroboration scoring must be completed before the summary event is emitted.

Structured summary events must be emitted through an approved custom action or external stateful correlation process, ingested through a dedicated QRadar log source, parsed through enabled custom properties, and excluded from all original-event building blocks and correlation rules.

The implementations do not require another CyberDax rule to generate an offense first.

Rule

Unexpected Access or Control Change Involving the Validated AD FS DKM Container

Rule Format

QRadar AQL aggregate search with separate native CRE threshold and offense conditions

Detection Purpose

Detect successful access or security-relevant control changes involving a validated AD FS DKM container when the actor, source, access action, administrative context, or approved-change state is anomalous.

Detection Logic

Alert when normalized Windows directory-service telemetry records successful protected-object access, protected-value access, ownership change, permission change, inheritance change, or auditing change involving a validated AD FS DKM object.

·        Match only DKM object identifiers contained in the validated AD FS DKM object inventory.

·        Require a normalized DKM object correlation key populated from the object GUID when available and the distinguished name as a controlled fallback.

·        Require a collision-resistant DKM activity correlation key that prevents unrelated events with missing attribution from being merged.

·        Require an access action capable of exposing, changing, or weakening control over protected DKM material.

·        Treat approved accounts, systems, and workflows as contextual baselines rather than unconditional exclusions.

·        Apply approved exceptions only when actor, source, object, action, workflow key, and approved time window align.

·        Retain events without reliable actor or source attribution when the DKM object and access action are otherwise validated.

·        Preserve unattributed events as independent detections through a unique-event fallback.

·        Aggregate by the normalized activity correlation key so repeated activity and access to multiple DKM objects remain measurable.

·        Increase offense magnitude through native CRE logic when control changes, unusual identities, repeated access, multiple DKM objects, or supporting endpoint and certificate evidence are present.

·        Do not classify the activity as confirmed signing-key theft or forged-token use.

Required Telemetry

·        Windows Security and Directory Service object-access and object-change events

·        Validated DKM object GUID and distinguished-name inventory

·        Normalized DKM object correlation key

·        Normalized DKM activity correlation key

·        Stable actor identifier

·        Stable source-system identifier

·        Actor name and SID

·        Source host and source IP

·        Logon identifier

·        Unique event identifier

·        DKM access action

·        Event outcome

·        Approved AD FS administrative-workflow context

·        Identity-risk and privilege-state enrichment

·        Asset-role, exposure-state, and asset-criticality enrichment

·        Endpoint, certificate, authentication, and AD FS telemetry for supporting investigation

Engineering Implementation Instructions

Create and enable the following custom event properties:

·        DKM Object Correlation Key

·        DKM Activity Correlation Key

·        DKM Object GUID

·        DKM Object Distinguished Name

·        DKM Access Action

·        DKM Control Change Confirmed

·        Approved AD FS DKM Workflow Key

·        Identity Risk Classification

·        Stable Actor Identifier

·        Stable Source Identifier

·        Unique Event Identifier

·        Source Host

·        AD FS Farm

·        Asset Role

·        Exposure State

·        Asset Criticality

Populate DKM Object Correlation Key with the normalized object GUID when available. Use the normalized distinguished name only when the GUID is unavailable.

Construct DKM Activity Correlation Key upstream, through a DSM or log-source extension, through a validated AQL-based custom property, or through another locally approved normalization process.

Use typed components, explicit delimiters, and canonical lowercase normalization.

Use the following priority:

·        actor_id::<stable actor identifier>|source_id::<stable source identifier>

·        actor_id::<stable actor identifier>|logon_id::<logon identifier>

·        source_id::<stable source identifier>|logon_id::<logon identifier>

·        actor_name::<normalized actor name>|source_name::<normalized source host>

·        event_id::<unique event identifier>

Do not use an empty, null, generic, or shared fallback value.

When the unique-event fallback is used, the event remains detectable but is not aggregated with unrelated unattributed activity.

Validate that every component used to construct the key is parsed as an alphanumeric property before production use.

Maintain normalized DKM object correlation keys in:

Validated_ADFS_DKM_Objects

Maintain approved administrative workflow keys in:

Approved_ADFS_DKM_Workflow_Keys

Each approved workflow key must bind:

·        Actor

·        Source

·        DKM object

·        Access action

·        Approved purpose

·        Approved start time

·        Approved end time

Normalize DKM access actions to:

·        read_protected_value

·        control_access

·        write_protected_value

·        change_permissions

·        take_ownership

·        change_inheritance

·        change_auditing

The AQL aliases dkm_event_count, distinct_dkm_objects, and distinct_dkm_actions exist only in the search result. They are not event properties and must not be referenced by CRE tests.

Implement production thresholds separately through native CRE state and counting tests, including:

·        DKM Control Change Confirmed is true

·        The actor identity state is unexpected or elevated risk

·        More than one validated DKM object is accessed by the same DKM Activity Correlation Key within the locally approved interval

·        The number of matching DKM events for the same DKM Activity Correlation Key exceeds the locally established threshold

·        Supporting key-handling or certificate activity is observed

Use the AQL query as an analyst view, validation search, or scheduled-search output.

Run the rule in test or non-offense mode until object validation, activity-key construction, property typing, access-action classification, exception matching, source attribution, event volume, and SOC procedures have been validated.

DRI Assessment

High. The rule is anchored to validated DKM object access and security-control behavior rather than to a CVE, exploit, command line, file path, or attacker tool.

DRI

8.9 / 10

TCR Assessment

Operational confidence is high for unexpected successful access or control change involving a validated DKM object. The rule does not independently prove that usable signing-key material was recovered.

Operational TCR

8.4 / 10

Full-Telemetry TCR

9.5 / 10

Limitations

Object-access auditing may be incomplete or misconfigured. Directory events may identify the object and requested access without proving which protected value was returned.

Legitimate installation, backup, recovery, migration, certificate rollover, testing, or incident-response activity may resemble suspicious access.

Previously collected DKM material may be used without generating new directory-service activity.

Unattributed events using the unique-event fallback remain independently detectable but cannot contribute to multi-event thresholds unless later enrichment establishes a reliable shared correlation key.

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL aggregate search and map all property names, reference sets, DSM fields, activity-correlation logic, asset profiles, search intervals, aggregation thresholds, approved-workflow properties, and separate CRE offense conditions to the target QRadar environment before deployment.

SELECT

"DKM Activity Correlation Key" AS activity_correlation_key,

FIRST("AD FS Farm") AS adfs_farm,

FIRST("Username") AS user_name,

FIRST("User SID") AS user_sid,

FIRST("Source Host") AS source_host,

FIRST("Source IP") AS source_ip,

FIRST("Logon ID") AS logon_id,

FIRST("Identity Risk Classification") AS identity_risk_classification,

FIRST("Approved AD FS DKM Workflow Key") AS approved_workflow_key,

FIRST("Asset Role") AS asset_role,

FIRST("Exposure State") AS exposure_state,

FIRST("Asset Criticality") AS asset_criticality,

MIN("starttime") AS first_seen,

MAX("starttime") AS last_seen,

COUNT(*) AS dkm_event_count,

UNIQUECOUNT("DKM Object Correlation Key") AS distinct_dkm_objects,

UNIQUECOUNT("DKM Access Action") AS distinct_dkm_actions

FROM events

WHERE

"Host OS" ILIKE '%windows%'

AND "DKM Activity Correlation Key" IS NOT NULL

AND "DKM Activity Correlation Key" <> ''

AND "DKM Object Correlation Key" IS NOT NULL

AND "DKM Object Correlation Key" <> ''

AND "DKM Access Action" IN (

  'read_protected_value',

  'control_access',

  'write_protected_value',

  'change_permissions',

  'take_ownership',

  'change_inheritance',

  'change_auditing'

)

AND "Event Outcome" IN (

  'success',

  'successful',

  'succeeded'

)

AND REFERENCESETCONTAINS(

  'Validated_ADFS_DKM_Objects',

  "DKM Object Correlation Key"

)

AND (

  "Approved AD FS DKM Workflow Key" IS NULL

  OR "Approved AD FS DKM Workflow Key" = ''

  OR NOT REFERENCESETCONTAINS(

    'Approved_ADFS_DKM_Workflow_Keys',

    "Approved AD FS DKM Workflow Key"

  )

  OR "DKM Control Change Confirmed" = 'true'

  OR "Identity Risk Classification" IN (

    'unexpected',

    'recently_privileged',

    'dormant',

    'service_account_unusual',

    'emergency_account',

    'terminated'

  )

)

GROUP BY

"DKM Activity Correlation Key"

LAST 15 MINUTES

Rule

Suspicious DKM Access Followed by Probable Federation Key-Material Handling

Rule Format

QRadar CRE sequence rule with state preservation and structured workflow-summary-event AQL search

Detection Purpose

Detect access to a validated AD FS DKM object followed by certificate, private-key, recovery, export, archive, staging, transfer, or cryptographic activity consistent with probable federation signing-key-material handling.

Detection Logic

Use CRE correlation and state preservation to identify validated DKM access followed by probable key-material handling through the same normalized actor and source-system context.

·        Require validated DKM access to occur first.

·        Require probable key-material handling to follow within four hours.

·        Require the normalized actor correlation key and source correlation key to match across stages.

·        Require compatible logon context when both stage events contain a usable logon identifier.

·        Exclude approved backup, recovery, migration, certificate-management, and incident-response activity only when the applicable workflow key and approval window match.

·        Detect certificate export, private-key access, AD FS recovery access, encrypted identity archive creation, sensitive identity staging, identity-material transfer, cryptographic private-key operations, or monitoring degradation.

·        Preserve first-stage values before the second-stage event arrives.

·        Create a deterministic workflow identifier for the completed sequence.

·        Suppress duplicate or replayed workflow identifiers.

·        Emit one structured workflow-summary payload only after the complete sequence is validated.

·        Ingest the payload through the dedicated AD FS workflow-summary log source.

·        Parse and enable every required property before using the event in AQL or additional CRE processing.

·        Exclude the dedicated summary-event source from all original DKM, endpoint, certificate, and key-handling building blocks.

·        Classify the result as probable key-material handling rather than confirmed private-key recovery.

Required Telemetry

·        Normalized DKM object-access and control-change events

·        Endpoint process, command-line, file, certificate, private-key, archive, staging, transfer, and network telemetry

·        Actor correlation key

·        Source correlation key

·        Logon identifier

·        AD FS farm

·        DKM object correlation key

·        DKM access action

·        Key-material handling action

·        Event identifier and event time

·        Approved backup, recovery, migration, certificate-management, and incident-response workflow context

·        Asset-role, exposure-state, and asset-criticality enrichment

·        Reference data or equivalent state used to preserve first-stage values

·        Structured workflow-summary events ingested through a dedicated QRadar log source

Engineering Implementation Instructions

Create normalized properties for:

·        AD FS Actor Correlation Key

·        AD FS Source Correlation Key

·        AD FS Key-Material Workflow Key

·        DKM Object Correlation Key

·        DKM Access Action

·        Key Material Handling Action

·        DKM Access Event ID

·        Key Material Handling Event ID

·        DKM Access Time

·        Key Material Handling Time

·        AD FS Workflow Sequence Valid

·        AD FS Logon Context Compatible

·        Approved AD FS Key Workflow Key

·        Approved AD FS Key Workflow State

·        Workflow Summary Type

Use stable actor and source identifiers where available. Use normalized names only as controlled fallback values.

Create building blocks for:

·        Validated AD FS DKM access

·        Probable federation key-material handling

·        Approved AD FS key-management workflow

·        Compatible logon context

·        Monitored AD FS source systems

Store first-stage DKM values in a reference map, reference table, intermediate normalized event, or external stateful correlation store keyed by the normalized actor and source correlation context.

Preserve:

·        DKM access event ID

·        DKM access time

·        DKM object correlation key

·        DKM access action

·        Actor correlation key

·        Source correlation key

·        Logon identifier

·        AD FS farm

·        Actor identity

·        Source system

·        Asset context

Expire retained first-stage state after the approved four-hour correlation window plus the locally approved delay tolerance.

Use a global CRE rule or another architecture that ensures events from relevant log sources and Event Processors can participate in the same correlation workflow.

Use CRE or the stateful correlation process to validate:

·        A validated DKM access event occurred first

·        A qualifying key-material handling event followed within four hours

·        Actor and source correlation keys matched

·        Logon context was compatible

·        The activity did not match an approved workflow

Create AD FS Key-Material Workflow Key deterministically from:

·        Actor correlation key

·        Source correlation key

·        DKM access event ID

·        Key-material handling event ID

·        DKM access time

Use typed components and explicit delimiters or a locally approved hash of those values.

Before emitting the summary payload, test the workflow key against a replay-suppression reference set or equivalent idempotency store.

Do not emit another summary event when the same workflow key already exists.

After validation, use an approved QRadar custom action or external stateful correlation process to emit one structured LEEF, CEF, or JSON payload to the dedicated AD FS workflow-summary log source.

The payload must use the following exact property names:

·        Workflow Summary Type

·        AD FS Key-Material Workflow Key

·        AD FS Farm

·        AD FS Actor Correlation Key

·        AD FS Source Correlation Key

·        Username

·        User SID

·        Source Host

·        Source IP

·        Logon ID

·        DKM Object Correlation Key

·        DKM Access Action

·        Key Material Handling Action

·        DKM Access Event ID

·        Key Material Handling Event ID

·        DKM Access Time

·        Key Material Handling Time

·        Approved AD FS Key Workflow Key

·        Approved AD FS Key Workflow State

·        AD FS Workflow Sequence Valid

·        AD FS Logon Context Compatible

·        Asset Role

·        Exposure State

·        Asset Criticality

Set:

·        Workflow Summary Type to adfs_key_material_sequence

·        AD FS Workflow Sequence Valid to lowercase true

·        AD FS Logon Context Compatible to lowercase true

·        Approved AD FS Key Workflow State to lowercase false for alert-eligible workflows

Define property data types as follows:

·        Workflow, correlation, event, workflow-key, action, identity, host, and classification fields: alphanumeric

·        Sequence, compatibility, and approved-workflow states: alphanumeric lowercase true or false

·        DKM access time and key-material handling time: numeric epoch milliseconds

·        Asset-criticality values: the locally standardized numeric or alphanumeric representation used by QRadar

Create and enable custom properties scoped to the dedicated summary-event log source.

Validate property parsing against the emitted payload before enabling the production search or offense response.

Original-event building blocks must explicitly exclude the dedicated summary-event log source or log-source type.

The AQL query must explicitly include only the dedicated summary-event log source.

Run the workflow in test or non-offense mode until state preservation, actor and source normalization, sequence ordering, logon compatibility, workflow-key generation, replay suppression, summary emission, property typing, parsing, log-source scoping, and event volume have been validated.

DRI Assessment

High. The rule detects the durable sequence of validated DKM access followed by probable protected-key handling across changing tools, file names, command syntax, archive formats, and destinations.

DRI

8.8 / 10

TCR Assessment

Operational confidence is high when DKM access and key-handling behavior share the same actor, source system, and compatible logon context. The rule does not prove successful private-key recovery.

Operational TCR

8.5 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Handling may occur offline, entirely in memory, through opaque backup formats, on an unmonitored system, or without reusable actor and source context.

Shared administrative accounts, management relays, delayed telemetry, or incomplete logon information can reduce correlation quality.

The AQL search depends on correctly preserved cross-stage state and correctly emitted, ingested, typed, and parsed workflow-summary events.

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL search for parsed structured workflow-summary events. Map all property names, payload formats, DSM mappings, custom-property expressions, reference data, dedicated log-source identifiers, asset profiles, search intervals, replay controls, and CRE offense conditions to the target QRadar environment before deployment.

SELECT

"AD FS Key-Material Workflow Key" AS workflow_key,

"AD FS Farm" AS adfs_farm,

"AD FS Actor Correlation Key" AS actor_correlation_key,

"AD FS Source Correlation Key" AS source_correlation_key,

"Username" AS user_name,

"User SID" AS user_sid,

"Source Host" AS source_host,

"Source IP" AS source_ip,

"Logon ID" AS logon_id,

"DKM Object Correlation Key" AS dkm_object_key,

"DKM Access Action" AS dkm_access_action,

"Key Material Handling Action" AS key_material_handling_action,

"DKM Access Event ID" AS dkm_access_event_id,

"Key Material Handling Event ID" AS key_material_handling_event_id,

"DKM Access Time" AS dkm_access_time,

"Key Material Handling Time" AS key_material_handling_time,

"Approved AD FS Key Workflow Key" AS approved_key_workflow_key,

"Approved AD FS Key Workflow State" AS approved_key_workflow_state,

"Asset Role" AS asset_role,

"Exposure State" AS exposure_state,

"Asset Criticality" AS asset_criticality,

"starttime" AS workflow_summary_time

FROM events

WHERE

LOGSOURCENAME(logsourceid) = 'AD FS Workflow Summary Events'

AND "Workflow Summary Type" = 'adfs_key_material_sequence'

AND "AD FS Key-Material Workflow Key" IS NOT NULL

AND "AD FS Key-Material Workflow Key" <> ''

AND "AD FS Actor Correlation Key" IS NOT NULL

AND "AD FS Actor Correlation Key" <> ''

AND "AD FS Source Correlation Key" IS NOT NULL

AND "AD FS Source Correlation Key" <> ''

AND "AD FS Workflow Sequence Valid" = 'true'

AND "AD FS Logon Context Compatible" = 'true'

AND "Approved AD FS Key Workflow State" = 'false'

AND "DKM Access Time" IS NOT NULL

AND "Key Material Handling Time" IS NOT NULL

AND "Key Material Handling Action" IN (

  'certificate_export',

  'private_key_access',

  'adfs_recovery_access',

  'cryptographic_private_key_operation',

  'encrypted_identity_archive',

  'sensitive_identity_staging',

  'identity_material_transfer',

  'monitoring_degradation'

)

LAST 4 HOURS

Rule

Federation Access Without Expected Issuance Lineage Followed by Privileged, Sensitive, or Identity-Inconsistent Activity

Rule Format

QRadar global CRE session-sequence rule with timestamp-aware lineage state, replay protection, and structured workflow-summary-event AQL search

Detection Purpose

Detect an accepted AD FS federation session that lacks expected issuance or upstream-authentication lineage and is followed by privileged, sensitive, persistent, or identity-inconsistent downstream activity.

Detection Logic

Use global CRE correlation, reference data, and stateful enrichment to identify successful acceptance from a monitored AD FS trust, evaluate expected lineage, and correlate the accepted session with qualifying downstream activity.

·        Require a successful federation acceptance event.

·        Require issuer, audience, trust identifier, and relying-party context to match a monitored AD FS trust relationship.

·        Require a typed assertion, federation-session, application-session, or cloud-session correlation key.

·        Preserve issuance and authentication timestamps before acceptance.

·        Require issuance lineage to be absent within five minutes before acceptance or authentication lineage to be absent within fifteen minutes before acceptance.

·        Apply locally validated delay and clock-skew tolerances before classifying lineage as absent.

·        Require qualifying downstream activity within two hours after acceptance.

·        Require the same reconciled session correlation key across acceptance and downstream activity.

·        Require at least one independent claims, identity, application-context, privileged-action, sensitive-action, source-or-device, or prior-key-compromise signal.

·        Preserve acceptance, lineage, and downstream values across stages.

·        Calculate corroboration category count before emitting the workflow-summary payload.

·        Create a deterministic workflow identifier and suppress duplicate or replayed workflows.

·        Emit one structured summary payload only after the complete workflow is validated.

·        Ingest the payload through the dedicated AD FS workflow-summary log source.

·        Parse and enable every required property before using the event in AQL or additional CRE processing.

·        Exclude the dedicated summary-event source from all original federation, authentication, AD FS, cloud, SaaS, VPN, and downstream building blocks.

·        Do not treat missing lineage alone as proof of forged-token use.

Required Telemetry

·        AD FS issuance events

·        Upstream authentication and MFA events

·        Federation acceptance and relying-party events

·        Claim-processing and trust events

·        Cloud, SaaS, VPN, proxy, and administrative-application events

·        Typed assertion, federation-session, application-session, or cloud-session identifiers

·        Issuer, audience, trust identifier, subject, source, device, relying party, outcome, and event time

·        Identity-state, entitlement, and privilege context

·        Downstream administrative, credential, persistence, security-control, lateral-expansion, and sensitive-data activity

·        Prior DKM or probable key-handling evidence where available

·        Timestamp-aware reference data or equivalent lineage state

·        Stateful cross-stage correlation storage

·        Structured federation-lineage summary events ingested through the dedicated QRadar summary log source

Engineering Implementation Instructions

Create a normalized AD FS Session Correlation Key using one of the following typed formats:

·        assertion::<identifier>

·        federation_session::<identifier>

·        application_session::<identifier>

·        cloud_session::<identifier>

Where acceptance and downstream systems expose different identifiers for the same session, reconcile them before production correlation through DSM mapping, custom properties, reference maps, reference map-of-sets, data gateway enrichment, intermediate events, or another locally validated stateful process.

Create and enable normalized properties for:

·        AD FS Session Correlation Key

·        AD FS Federation Lineage Workflow Key

·        AD FS Acceptance Event ID

·        AD FS Acceptance Time

·        Issuance Event ID

·        Issuance Event Time

·        Authentication Event ID

·        Authentication Event Time

·        First Downstream Event ID

·        First Downstream Time

·        Last Downstream Time

·        Issuance Lineage Match

·        Authentication Lineage Match

·        Qualifying Downstream Activity

·        AD FS Federation Workflow Sequence Valid

·        Monitored AD FS Trust

·        Federation Acceptance Successful

·        AD FS Corroboration Category Count

·        Workflow Summary Type

Create building blocks for:

·        Successful monitored AD FS federation acceptance

·        Expected issuance lineage present

·        Expected authentication lineage present

·        Missing expected federation lineage

·        Qualifying downstream activity

·        Privileged downstream activity

·        Sensitive downstream activity

·        Persistence or security-control change

·        Identity-state inconsistency

·        Claims inconsistency

·        Application-context inconsistency

·        Source-or-device anomaly

·        Prior DKM or probable key-compromise evidence

Store normalized issuance and authentication state as those events arrive.

Use a reference map or equivalent state store keyed by AD FS Session Correlation Key.

Store:

·        Event identifier

·        Event timestamp

·        Subject

·        Source

·        AD FS farm

·        Issuer or authentication authority

·        Applicable trust context

Use expiration periods that cover:

·        Five-minute issuance window

·        Fifteen-minute authentication window

·        Locally approved ingestion-delay tolerance

·        Locally approved clock-skew tolerance

At acceptance time:

·        Confirm successful acceptance

·        Confirm the issuer, audience, trust ID, and relying party map to a monitored AD FS trust

·        Retrieve issuance and authentication state for the same session key

·        Set Issuance Lineage Match to lowercase true only when a qualifying issuance event occurred no more than five minutes before acceptance

·        Set Authentication Lineage Match to lowercase true only when a qualifying authentication event occurred no more than fifteen minutes before acceptance

·        Apply the locally approved delay and clock-skew tolerance before classifying either lineage result as false

·        Preserve the acceptance event and lineage results in state for the two-hour downstream window

Use global CRE evaluation when contributing events can be processed by different Event Processors or log-source groups.

The workflow must not classify lineage as absent merely because a contributing event has not yet reached the relevant processor.

Store acceptance-stage values for retrieval when the downstream event arrives:

·        Acceptance event ID

·        Acceptance time

·        AD FS farm

·        Federation issuer

·        Federation audience

·        Federation trust ID

·        Relying party

·        Federated subject

·        Source IP

·        Device ID

·        Issuance-lineage result

·        Authentication-lineage result

·        Claims inconsistency

·        Prior key-compromise evidence

·        Asset context

When a qualifying downstream event arrives:

·        Require the same reconciled session correlation key

·        Require the event to occur after acceptance and within two hours

·        Set Qualifying Downstream Activity to lowercase true

·        Preserve the first and last qualifying downstream times

·        Preserve the downstream action and applicable identity, application, source, device, privilege, persistence, and sensitive-activity indicators

Calculate AD FS Corroboration Category Count before emitting the summary event.

Count each independent category once:

·        Claims inconsistency

·        Identity-state inconsistency

·        Application-context inconsistency

·        Privileged downstream action

·        Sensitive downstream action

·        Source-or-device anomaly

·        Prior key-compromise evidence

Create AD FS Federation Lineage Workflow Key deterministically from:

·        Session correlation key

·        Acceptance event ID

·        First downstream event ID

·        Acceptance time

Use typed components and explicit delimiters or a locally approved hash of those values.

Before emitting the summary payload, test the workflow key against a replay-suppression reference set or equivalent idempotency store.

Do not emit another summary event when the same workflow key already exists.

After validation, use an approved QRadar custom action or external stateful correlation process to emit one structured LEEF, CEF, or JSON payload to the dedicated AD FS workflow-summary log source.

The payload must use the following exact property names:

·        Workflow Summary Type

·        AD FS Federation Lineage Workflow Key

·        AD FS Session Correlation Key

·        AD FS Acceptance Event ID

·        AD FS Farm

·        Federation Issuer

·        Federation Audience

·        Federation Trust ID

·        Relying Party

·        Federated Subject

·        Source IP

·        Device ID

·        Issuance Lineage Match

·        Authentication Lineage Match

·        Qualifying Downstream Activity

·        Downstream Action

·        Identity State Inconsistent

·        Claims Inconsistent

·        Application Context Inconsistent

·        Source or Device Anomalous

·        Prior Key Compromise Evidence

·        AD FS Corroboration Category Count

·        Acceptance Time

·        First Downstream Time

·        Last Downstream Time

·        Asset Role

·        Exposure State

·        Asset Criticality

·        AD FS Federation Workflow Sequence Valid

·        Monitored AD FS Trust

·        Federation Acceptance Successful

Set:

·        Workflow Summary Type to adfs_federation_lineage_sequence

·        AD FS Federation Workflow Sequence Valid to lowercase true

·        Monitored AD FS Trust to lowercase true

·        Federation Acceptance Successful to lowercase true

·        Qualifying Downstream Activity to lowercase true

·        Issuance Lineage Match and Authentication Lineage Match to lowercase true or false

Define property data types as follows:

·        Workflow, session, event, trust, identity, source, device, action, and classification fields: alphanumeric

·        Sequence, trust, acceptance, lineage, downstream, and anomaly-state fields: alphanumeric lowercase true or false

·        Corroboration category count: numeric

·        Acceptance and downstream times: numeric epoch milliseconds

·        Asset-criticality values: the locally standardized numeric or alphanumeric representation used by QRadar

Create and enable custom properties scoped to the dedicated AD FS workflow-summary log source.

Validate every property against the emitted payload before enabling the production search or offense response.

Original-event building blocks must explicitly exclude the dedicated summary-event log source or log-source type.

The AQL query must explicitly include only the dedicated summary-event log source.

Use CRE offense magnitude or rule-response logic to promote higher severity when:

·        AD FS Corroboration Category Count is two or greater

·        Prior Key Compromise Evidence is true

·        Both issuance and authentication lineage are false

·        Privileged or persistence-related downstream activity is present

·        The affected identity or asset is highly privileged or business critical

Run the workflow in test or non-offense mode until trust validation, acceptance-result normalization, identifier reconciliation, timestamp-state maintenance, delay tolerance, global correlation, downstream association, historical identity enrichment, corroboration scoring, workflow-key generation, replay suppression, payload generation, property typing, parsing, and log-source scoping have been validated.

DRI Assessment

High. The rule detects successful federation access with missing expected lineage and anomalous downstream identity behavior rather than relying on a specific forged-token implementation.

DRI

9.0 / 10

TCR Assessment

Operational confidence is moderate to high when a successful monitored AD FS acceptance lacks expected issuance or authentication lineage and is followed by independent identity, claims, privileged, sensitive, source, device, or prior key-compromise evidence.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.6 / 10

Limitations

Incomplete AD FS, authentication, relying-party, identity, or downstream telemetry can create apparent lineage gaps.

Late-arriving events, clock skew, or processor-local visibility can create false lineage failures if the approved delay tolerance and global correlation design are not implemented.

Some relying parties do not preserve immutable assertion or federation-session identifiers.

Legitimate failover, federation testing, claim-rule changes, entitlement changes, or emergency access may produce similar conditions.

The AQL search depends on correctly maintained lineage state and correctly emitted, ingested, typed, and parsed workflow-summary events.

The rule cannot provide cryptographic proof of offline forged-token construction.

Detection Query Pattern

Use this pattern as an implementation-ready QRadar AQL search for parsed structured federation-lineage workflow-summary events. Map all property names, dedicated log-source identifiers, payload formats, DSM mappings, custom-property expressions, reference data, state-expiration settings, processor scope, delay tolerances, asset profiles, search intervals, replay controls, corroboration thresholds, and CRE offense conditions to the target QRadar environment before deployment.

SELECT

"AD FS Federation Lineage Workflow Key" AS workflow_key,

"AD FS Session Correlation Key" AS session_correlation_key,

"AD FS Acceptance Event ID" AS acceptance_event_id,

"AD FS Farm" AS adfs_farm,

"Federation Issuer" AS federation_issuer,

"Federation Audience" AS federation_audience,

"Federation Trust ID" AS federation_trust_id,

"Relying Party" AS relying_party,

"Federated Subject" AS federated_subject,

"Source IP" AS source_ip,

"Device ID" AS device_id,

"Issuance Lineage Match" AS issuance_lineage_match,

"Authentication Lineage Match" AS authentication_lineage_match,

"Qualifying Downstream Activity" AS qualifying_downstream_activity,

"Downstream Action" AS downstream_action,

"Identity State Inconsistent" AS identity_state_inconsistent,

"Claims Inconsistent" AS claims_inconsistent,

"Application Context Inconsistent" AS application_context_inconsistent,

"Source or Device Anomalous" AS source_or_device_anomalous,

"Prior Key Compromise Evidence" AS prior_key_compromise_evidence,

"AD FS Corroboration Category Count" AS corroboration_category_count,

"Acceptance Time" AS acceptance_time,

"First Downstream Time" AS first_downstream_time,

"Last Downstream Time" AS last_downstream_time,

"Asset Role" AS asset_role,

"Exposure State" AS exposure_state,

"Asset Criticality" AS asset_criticality,

"starttime" AS workflow_summary_time

FROM events

WHERE

LOGSOURCENAME(logsourceid) = 'AD FS Workflow Summary Events'

AND "Workflow Summary Type" = 'adfs_federation_lineage_sequence'

AND "AD FS Federation Lineage Workflow Key" IS NOT NULL

AND "AD FS Federation Lineage Workflow Key" <> ''

AND "AD FS Session Correlation Key" IS NOT NULL

AND "AD FS Session Correlation Key" <> ''

AND "AD FS Federation Workflow Sequence Valid" = 'true'

AND "Monitored AD FS Trust" = 'true'

AND "Federation Acceptance Successful" = 'true'

AND (

  "Issuance Lineage Match" = 'false'

  OR "Authentication Lineage Match" = 'false'

)

AND "Qualifying Downstream Activity" = 'true'

AND "AD FS Corroboration Category Count" >= 1

LAST 2 HOURS

SIGMA

Detection Viability Assessment

SIGMA can provide portable behavior-driven detection content for AD FS signing-key exposure and forged-token trust compromise when the target SIEM or EDR supports normalized Windows directory-service, endpoint, certificate, federation, authentication, relying-party, identity, and downstream activity fields.

Three rule opportunities survive validation:

·        Unexpected access or control change involving the validated AD FS DKM container

·        Suspicious DKM access followed by probable federation key-material handling

·        Federation access without expected issuance lineage followed by privileged, sensitive, or identity-inconsistent activity

Rule 1 is expressed as a standalone SIGMA rule.

Rules 2 and 3 are expressed as SIGMA correlation-design packages. They become implementation-ready only after successful conversion through a backend with verified temporal_ordered support, complete processing-pipeline and log-source mapping, cross-source field validation, clock and event-order testing, and functional testing against representative telemetry.

Lineage evaluation, monitored-trust validation, approved-workflow state, session-identifier reconciliation, identity context, and prior key-compromise evidence must be populated before SIGMA evaluation. SIGMA does not independently reconstruct cross-platform federation lineage or maintain historical reference state.

Rule

Unexpected Access or Control Change Involving the Validated AD FS DKM Container

Rule Format

Standalone SIGMA rule

Detection Purpose

Detect successful access or security-relevant control changes involving a validated AD FS DKM container when the access action, actor context, source context, or approved-workflow state is anomalous.

Detection Logic

Alert when normalized Windows directory-service telemetry records access or control change involving a locally validated AD FS DKM object.

·        Require a validated DKM object correlation key.

·        Require successful protected-value access, control access, protected-value modification, permission change, ownership change, inheritance change, or auditing change.

·        Suppress activity only when the complete actor, source, object, action, and approved time-window context matches an approved workflow.

·        Retain confirmed DKM control changes and elevated-risk identities even when an approved workflow field is present.

·        Do not classify the event as confirmed signing-key theft or forged-token use.

Required Telemetry

·        Windows Security and Directory Service object-access and object-change telemetry

·        Validated DKM object identifiers

·        DKM access-action classification

·        Actor and source context

·        Event outcome

·        Approved administrative-workflow context

·        Identity-risk classification

·        DKM control-change state

Engineering Implementation Instructions

Map all neutral field names to the target SIEM or EDR schema.

Populate DKMObjectValidated only when the object GUID or distinguished name matches the locally validated AD FS DKM inventory.

Populate DKMAccessAction from locally validated access-mask, property-GUID, and directory-change mappings.

Populate ApprovedADFSDKMWorkflow only when actor, source, object, action, purpose, and event time match a current approved workflow.

Populate DKMControlChangeConfirmed for ownership, permission, inheritance, auditing, or protected-value control changes that were successfully applied.

Run the rule in test status until DKM object validation, access classification, exception logic, and expected administrative activity have been baselined.

DRI Assessment

High. The rule is anchored to validated DKM object access and security-control behavior rather than to a CVE, exploit, command line, file name, or attacker tool.

DRI

8.9 / 10

TCR Assessment

Operational confidence is high for unexpected successful access or control change involving a validated DKM object. The rule does not prove that usable signing-key material was recovered.

Operational TCR

8.4 / 10

Full-Telemetry TCR

9.5 / 10

Limitations

Object-access auditing may be incomplete or disabled.

Directory events may show an access request without proving which protected value was returned.

Legitimate installation, backup, recovery, migration, certificate rollover, testing, or incident-response activity may resemble suspicious access.

Previously collected DKM material may be used without generating new directory-service activity.

Detection Query Pattern

Use this as an implementation-ready SIGMA rule. Map all fields, log-source definitions, value lists, identity-context fields, and approved-workflow fields to the target SIEM or EDR before deployment.

title: Unexpected Access or Control Change Involving a Validated AD FS DKM Container

id: 0ac9cf31-20ec-49d0-9333-6395ef592406

status: test

description: Detects successful protected-value access or security-relevant control changes involving a locally validated AD FS DKM object when the activity is not fully explained by an approved workflow.

references:

  - Internal CyberDax detection model for AD FS signing-key exposure and forged-token trust compromise

author: CyberDax

date: 2026-07-14

logsource:

  product: windows

  service: security

  definition: Requires normalized Windows directory-service object-access and object-change telemetry with validated AD FS DKM object enrichment.

detection:

  selection_dkm_object:

    DKMObjectValidated: true

    DKMObjectCorrelationKey|exists: true

  selection_access_action:

    DKMAccessAction:

      - 'read_protected_value'

      - 'control_access'

      - 'write_protected_value'

      - 'change_permissions'

      - 'take_ownership'

      - 'change_inheritance'

      - 'change_auditing'

  selection_success:

    EventOutcome:

      - 'success'

      - 'successful'

      - 'succeeded'

  filter_approved_workflow:

    ApprovedADFSDKMWorkflow: true

  selection_control_change:

    DKMControlChangeConfirmed: true

  selection_elevated_identity:

    IdentityRiskClassification:

      - 'unexpected'

      - 'recently_privileged'

      - 'dormant'

      - 'service_account_unusual'

      - 'emergency_account'

      - 'terminated'

  condition: selection_dkm_object and selection_access_action and selection_success and (not filter_approved_workflow or selection_control_change or selection_elevated_identity)

falsepositives:

  - Approved AD FS installation or certificate rollover

  - Approved backup or disaster-recovery activity

  - Approved migration or federation maintenance

  - Approved incident-response or security testing

level: high

tags:

  - attack.credential_access

  - attack.t1552.004

Rule

Suspicious DKM Access Followed by Probable Federation Key-Material Handling

Rule Format

SIGMA temporal-ordered correlation-design package

Detection Purpose

Detect validated AD FS DKM access followed by certificate, private-key, recovery, export, archive, staging, transfer, cryptographic, or monitoring-degradation activity associated with the same normalized actor and source context.

Detection Logic

Correlate a validated DKM access event with a later probable key-material handling event.

·        Require the DKM access event to occur first.

·        Require the key-material handling event to occur within four hours.

·        Require matching normalized actor and source correlation keys.

·        Require compatible logon context before the second-stage base rule is generated.

·        Exclude approved key-management workflows.

·        Detect probable key-material handling rather than claim confirmed private-key recovery.

Required Telemetry

·        Validated DKM access telemetry

·        Certificate and private-key access telemetry

·        Endpoint process and file telemetry

·        Archive, staging, transfer, and network telemetry

·        Actor correlation key

·        Source correlation key

·        Compatible logon-context result

·        Approved workflow state

·        Key-material handling classification

Engineering Implementation Instructions

Use this as a SIGMA correlation-design package.

The package becomes implementation-ready only when the selected backend:

·        Supports temporal_ordered correlation

·        Supports referenced base-rule names

·        Supports multiple group-by fields

·        Supports a four-hour correlation timespan

·        Successfully converts the full package

·        Preserves correlation across the normalized log sources used by the referenced rules

·        Has been tested for event ordering, timestamp behavior, and cross-source clock skew

·        Produces the expected results against representative telemetry

Populate ADFSActorCorrelationKey using a stable SID, object identifier, or other locally validated actor identifier. Use a normalized account name only as a controlled fallback.

Populate ADFSSourceCorrelationKey using a stable endpoint or asset identifier. Use a normalized host name only as a controlled fallback.

Populate ADFSLogonContextCompatible before SIGMA evaluation. Set it to true only when logon identifiers match or when one side lacks a usable logon identifier and the actor-plus-source relationship remains valid.

Populate ApprovedADFSKeyWorkflow only for time-aware approved backup, recovery, migration, certificate-management, or incident-response activity.

Normalize qualifying endpoint, certificate, private-key, archive, staging, transfer, network, and monitoring-degradation events into the locally defined adfs_key_material_handling category before SIGMA evaluation.

The normalized handling-event schema must provide the same ADFSActorCorrelationKey and ADFSSourceCorrelationKey fields used by the DKM-access base rule.

Where the selected backend cannot correlate the normalized cross-source handling category, use one separate two-stage correlation package for each supported handling source.

Each alternative package must contain:

·        The same validated DKM-access base rule as stage one

·        One specific handling base rule as stage two

·        The same actor and source grouping fields

·        The same four-hour timespan

Do not place endpoint, certificate, network-transfer, monitoring, and other alternative handling rules together inside one temporal_ordered rule list. Doing so would require every listed rule to occur in the stated order rather than treating them as interchangeable alternatives.

The base rules identify eligible stages. The correlation rule establishes sequence order and the four-hour window.

DRI Assessment

High. The package detects the durable sequence of validated DKM access followed by probable protected-key handling across changes in tools, file names, command syntax, archive formats, and destinations.

DRI

8.8 / 10

TCR Assessment

Operational confidence is high when DKM access and key-material handling share the same normalized actor, source, and compatible logon context. The rule does not prove successful private-key recovery.

Operational TCR

8.5 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

The selected SIGMA backend must provide verified temporal-ordered correlation support for the converted package.

Cross-source clock skew, delayed ingestion, or backend-specific ordering behavior may disrupt the expected sequence.

Handling may occur offline, entirely in memory, through opaque backup formats, on an unmonitored system, or without reusable actor and source context.

Shared accounts, management relays, delayed telemetry, or incomplete logon identifiers can reduce correlation quality.

Detection Query Pattern

Use this as a SIGMA temporal-ordered correlation-design package. Map all fields and enrichment fields to the target SIEM or EDR. Confirm successful backend conversion, temporal_ordered support, multiple grouping-field support, normalized cross-source mapping, clock behavior, event ordering, and the four-hour timespan through functional testing before deployment.

title: Validated AD FS DKM Access Event

name: adfs_validated_dkm_access_event

logsource:

  product: windows

  definition: Requires normalized Windows directory-service telemetry with validated AD FS DKM object, actor-correlation, and source-correlation fields.

detection:

  selection_dkm_access:

    DKMObjectValidated: true

    DKMObjectCorrelationKey|exists: true

    DKMAccessAction:

      - 'read_protected_value'

      - 'control_access'

      - 'write_protected_value'

      - 'change_permissions'

      - 'take_ownership'

      - 'change_inheritance'

      - 'change_auditing'

    EventOutcome:

      - 'success'

      - 'successful'

      - 'succeeded'

  selection_required_fields:

    ADFSActorCorrelationKey|exists: true

    ADFSSourceCorrelationKey|exists: true

  condition: selection_dkm_access and selection_required_fields

---

title: Probable Federation Key-Material Handling Event

name: adfs_probable_key_material_handling_event

logsource:

  category: adfs_key_material_handling

  definition: Requires a locally normalized cross-source event category covering endpoint, certificate, private-key, archive, staging, transfer, network, and monitoring-degradation telemetry.

detection:

  selection_handling_action:

    ADFSKeyMaterialAction:

      - 'certificate_export'

      - 'private_key_access'

      - 'adfs_recovery_access'

      - 'cryptographic_private_key_operation'

      - 'encrypted_identity_archive'

      - 'sensitive_identity_staging'

      - 'identity_material_transfer'

      - 'monitoring_degradation'

  selection_required_fields:

    ADFSActorCorrelationKey|exists: true

    ADFSSourceCorrelationKey|exists: true

    ADFSLogonContextCompatible: true

  filter_approved_workflow:

    ApprovedADFSKeyWorkflow: true

  condition: selection_handling_action and selection_required_fields and not filter_approved_workflow

---

title: Validated AD FS DKM Access Followed by Probable Federation Key-Material Handling

id: c35fb1a7-1928-4182-8f5e-f9f601d7e2a1

status: test

description: Detects validated AD FS DKM access followed within four hours by probable federation key-material handling through the same normalized actor and source context.

references:

  - Internal CyberDax detection model for AD FS signing-key exposure and forged-token trust compromise

author: CyberDax

date: 2026-07-14

correlation:

  type: temporal_ordered

  rules:

    - adfs_validated_dkm_access_event

    - adfs_probable_key_material_handling_event

  group-by:

    - ADFSActorCorrelationKey

    - ADFSSourceCorrelationKey

  timespan: 4h

falsepositives:

  - Approved AD FS certificate rollover

  - Approved federation backup or recovery

  - Approved migration or disaster-recovery testing

  - Approved certificate-management activity

  - Approved incident-response or security testing

level: high

tags:

  - attack.credential_access

  - attack.t1552.004

Rule

Federation Access Without Expected Issuance Lineage Followed by Privileged, Sensitive, or Identity-Inconsistent Activity

Rule Format

SIGMA temporal-ordered correlation-design package

Detection Purpose

Detect successful federation acceptance from a monitored AD FS trust when expected issuance or upstream-authentication lineage is missing and qualifying downstream activity follows through the same reconciled session context.

Detection Logic

Correlate a successful monitored federation-acceptance event with a later qualifying downstream behavior event.

·        Require a successful federation acceptance event.

·        Require a locally validated monitored AD FS trust.

·        Require a typed and reconciled federation-session correlation key.

·        Require issuance-lineage or authentication-lineage evaluation to be false before the acceptance base rule is generated.

·        Require a qualifying downstream behavior event.

·        Require the correlation rule to establish that acceptance occurs first and downstream activity follows within two hours.

·        Require at least one independent downstream or enriched session-level corroboration category.

·        Do not treat missing lineage alone as proof of forged-token use.

Required Telemetry

·        AD FS issuance and authentication telemetry

·        Federation-acceptance and relying-party telemetry

·        Cloud, SaaS, VPN, proxy, and administrative-application activity

·        Typed and reconciled assertion, federation-session, application-session, or cloud-session identifiers

·        Monitored-trust state

·        Successful-acceptance state

·        Issuance-lineage and authentication-lineage results

·        Qualifying downstream-behavior classification

·        Claims, identity, application, source, device, privilege, persistence, sensitive-action, and prior key-compromise enrichment

·        Session-level corroboration count propagated to the qualifying downstream event

Engineering Implementation Instructions

Use this as a SIGMA correlation-design package.

The package becomes implementation-ready only when the selected backend:

·        Supports temporal_ordered correlation

·        Supports referenced base-rule names

·        Supports grouping by the reconciled session key

·        Supports a two-hour timespan

·        Successfully converts the full package

·        Preserves the session grouping field across the participating log sources

·        Has been tested for event ordering, timestamp behavior, ingestion delay, and clock skew

·        Produces the expected results against representative acceptance and downstream telemetry

Populate ADFSSessionCorrelationKey before SIGMA evaluation using a typed identifier:

·        assertion::<identifier>

·        federation_session::<identifier>

·        application_session::<identifier>

·        cloud_session::<identifier>

Where acceptance and downstream platforms expose different identifiers, reconcile them through a transform, enrichment pipeline, reference mapping, or equivalent stateful process before the rule runs.

Populate IssuanceLineageMatch only after evaluating whether a qualifying issuance event occurred within five minutes before acceptance.

Populate AuthenticationLineageMatch only after evaluating whether a qualifying authentication event occurred within fifteen minutes before acceptance.

Apply locally approved ingestion-delay and clock-skew tolerances before setting either lineage field to false.

Populate MonitoredADFSTrust only when issuer, audience, trust identifier, and relying-party context match the locally validated AD FS relationship.

Populate QualifyingDownstreamActivity as a behavior-classification field only. Set it to true when an event represents qualifying administrative, persistence, security-control, sensitive-access, lateral-expansion, identity-inconsistent, application-inconsistent, or source-and-device-anomalous behavior.

Do not precompute acceptance-before-downstream order or the two-hour relationship inside QualifyingDownstreamActivity. The temporal_ordered correlation rule establishes those conditions.

Calculate ADFSCorroborationCategoryCount at the enriched session level. Count each independent category once:

·        Claims inconsistency

·        Identity-state inconsistency

·        Application-context inconsistency

·        Privileged downstream action

·        Sensitive downstream action

·        Source-or-device anomaly

·        Prior key-compromise evidence

Join or propagate ADFSCorroborationCategoryCount onto the qualifying downstream event through ADFSSessionCorrelationKey before SIGMA evaluation.

Acceptance-side or session-level fields such as claims inconsistency and prior key-compromise evidence must be included in that propagated count even when they are not native fields on the downstream telemetry source.

Normalize qualifying cloud, SaaS, VPN, proxy, identity, administrative, security-control, persistence, lateral-expansion, and sensitive-access events into the locally defined adfs_downstream_behavior category.

The normalized downstream schema must provide:

·        ADFSSessionCorrelationKey

·        QualifyingDownstreamActivity

·        ADFSCorroborationCategoryCount

The SIGMA correlation establishes acceptance-before-downstream ordering and the two-hour window. It does not independently calculate negative lineage, historical identity context, session reconciliation, or the corroboration count.

DRI Assessment

High. The package detects successful federation access with missing expected lineage and anomalous downstream behavior rather than relying on a specific forged-token implementation.

DRI

9.0 / 10

TCR Assessment

Operational confidence is moderate to high when successful monitored federation acceptance lacks expected issuance or authentication lineage and is followed by independent identity, claims, privileged, sensitive, source, device, or prior key-compromise evidence.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.6 / 10

Limitations

The selected SIGMA backend must provide verified temporal-ordered correlation support for the converted package.

SIGMA does not independently maintain issuance, authentication, acceptance, and downstream state.

Cross-source clock skew, delayed ingestion, backend-specific ordering behavior, failed session-identifier reconciliation, or failed corroboration propagation can produce false lineage failures or missed correlations.

Incomplete AD FS, authentication, relying-party, identity, or downstream telemetry can create apparent lineage gaps.

Some relying parties do not preserve immutable assertion or federation-session identifiers.

The rule cannot provide cryptographic proof of offline forged-token construction.

Detection Query Pattern

Use this as a SIGMA temporal-ordered correlation-design package. Map all fields and enrichment fields to the target SIEM or EDR. Confirm successful backend conversion, temporal_ordered support, reconciled session grouping, normalized cross-source mapping, clock behavior, event ordering, and the two-hour timespan through functional testing before deployment.

title: Successful Monitored AD FS Federation Acceptance with Missing Expected Lineage

name: adfs_acceptance_missing_expected_lineage_event

logsource:

  category: authentication

  definition: Requires normalized federation-acceptance telemetry with monitored-trust, successful-acceptance, reconciled-session, and precomputed lineage fields.

detection:

  selection_acceptance:

    ADFSEventType: 'federation_acceptance'

    FederationAcceptanceSuccessful: true

    MonitoredADFSTrust: true

  selection_required_session:

    ADFSSessionCorrelationKey|exists: true

  selection_missing_issuance:

    IssuanceLineageMatch: false

  selection_missing_authentication:

    AuthenticationLineageMatch: false

  condition: selection_acceptance and selection_required_session and (selection_missing_issuance or selection_missing_authentication)

---

title: Qualifying Federation Downstream Behavior Event

name: adfs_qualifying_downstream_activity_event

logsource:

  category: adfs_downstream_behavior

  definition: Requires a locally normalized cross-source event category covering cloud, SaaS, VPN, proxy, identity, administrative, persistence, security-control, sensitive-access, lateral-expansion, and source-or-device-anomalous activity with session-level corroboration propagated through the reconciled session key.

detection:

  selection_downstream_state:

    QualifyingDownstreamActivity: true

    ADFSSessionCorrelationKey|exists: true

  selection_corroboration:

    ADFSCorroborationCategoryCount|gte: 1

  condition: selection_downstream_state and selection_corroboration

---

title: Federation Access Without Expected Issuance Lineage Followed by Suspicious Downstream Activity

id: 9445e37b-3216-4ef3-bc20-52d5f30c9e8c

status: test

description: Detects successful monitored AD FS federation acceptance with missing expected issuance or authentication lineage followed within two hours by qualifying downstream activity associated with the same reconciled session.

references:

  - Internal CyberDax detection model for AD FS signing-key exposure and forged-token trust compromise

author: CyberDax

date: 2026-07-14

correlation:

  type: temporal_ordered

  rules:

    - adfs_acceptance_missing_expected_lineage_event

    - adfs_qualifying_downstream_activity_event

  group-by:

    - ADFSSessionCorrelationKey

  timespan: 2h

falsepositives:

  - Federation failover

  - Delayed or incomplete AD FS telemetry

  - Clock synchronization issues

  - Approved federation testing

  - Approved claim-rule or relying-party changes

  - Approved emergency-access activity

level: high

tags:

  - attack.credential_access

  - attack.t1606.002

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, directory-service driven, identity-context based, federation-lineage based, SIEM-correlation based, and downstream cloud-correlation based rather than static-file or malware-signature based.

YARA may provide limited supporting value only if a confirmed malicious artifact, key-extraction utility, certificate-export tool, encoded payload, script artifact, archive artifact, memory artifact, token-forging utility, or reusable malware family is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

Detection Viability Assessment

AWS can provide one supporting correlation rule for AD FS signing-key exposure and forged-token trust compromise when CloudTrail, IAM, STS, GuardDuty, Security Hub, identity, federation, and normalized AD FS session context are available.

AWS telemetry does not independently prove that a SAML assertion was forged. Do not promote without confirmed missing issuance or authentication lineage, prior DKM or signing-key compromise evidence, or another independently validated federation-compromise signal.

Rule

Suspicious AD FS-Federated AWS Access Followed by Privileged or Persistent Cloud Activity

Rule Format

AWS correlation pseudologic

Detection Purpose

Detect privileged, credential-related, persistent, security-control, logging, identity-provider, or sensitive administrative AWS behavior associated with a suspicious AD FS-federated session.

Detection Logic

Correlate a successful AD FS federation acceptance with AWS activity or a relevant AWS security finding associated with the same AWS account and canonical federated session.

·        Require successful federation acceptance through a monitored AD FS trust.

·        Require a canonical session-binding key containing a session-specific identifier.

·        Anchor AWS correlation to the federation-acceptance time.

·        Require successful high-risk AWS activity or a relevant high-risk AWS finding.

·        Require confirmed missing issuance or authentication lineage with independent corroboration, or prior DKM or signing-key compromise evidence with qualifying AWS behavior.

·        Do not use role ARN, federated subject, source identity, principal ID, account, source IP, region, or user agent alone as a session-binding key.

·        Do not count the same activity record or finding more than once.

·        Do not suppress mandatory-review resources, events, or findings.

·        Do not promote based only on a federated sign-in, routine administrative activity, unavailable telemetry, or an unbound security finding.

Required Telemetry

·        AWS CloudTrail management events

·        AWS CloudTrail data events where enabled

·        AWS STS and IAM activity

·        Amazon GuardDuty findings

·        AWS Security Hub findings

·        AWS SAML provider and IAM Identity Center configuration

·        AWS account, principal, role, role-session, source-identity, access-key, source, user-agent, region, and resource identifiers

·        Normalized AD FS federation-acceptance, issuance, authentication, trust, relying-party, claims, and session context

·        Prior DKM-access and probable signing-key-material handling evidence

·        Approved automation, infrastructure-as-code, managed-service, incident-response, break-glass, and administrative-workflow context

Engineering Implementation Instructions

Create and validate:

·        adfs_aws_federation_context

·        aws_activity_context

·        aws_finding_context

·        aws_session_risk_context

The normalized AD FS context must provide:

·        federation_acceptance_id

·        federation_acceptance_time

·        federation_acceptance_successful

·        monitored_adfs_trust

·        aws_account_id

·        canonical_session_binding_key

·        issuance_lineage_status

·        authentication_lineage_status

·        issuance_lineage_evaluation_complete

·        authentication_lineage_evaluation_complete

·        prior_key_compromise_evidence

·        claims_inconsistent

·        identity_state_inconsistent

·        source_or_device_anomalous

Retain one authoritative AD FS context row per AWS account, federation acceptance, and canonical session-binding key.

The canonical session-binding key must contain at least one session-specific value:

·        Immutable assertion identifier

·        Mapped federation-session identifier

·        Temporary AWS access-key ID

·        Validated STS session identifier

Source identity, principal ID, role ARN, role-session name, account, source IP, region, and user agent may support attribution but must not independently form the session key.

Use controlled lineage states:

·        matched

·        not_found

·        unavailable

·        unsupported

·        evaluation_failed

Treat lineage as confirmed missing only when the applicable evaluation completed successfully and returned not_found.

The normalized AWS activity view must provide:

·        event_time

·        event_source

·        event_id

·        source_qualified_event_id

·        event_name

·        event_outcome

·        account_id

·        canonical_session_binding_key

·        aws_region

·        resource_id

·        activity_category

·        high_risk_activity

·        approved_workflow_validated

·        approved_start_time

·        approved_end_time

Require source_qualified_event_id for every activity record.

When a native event identifier exists, construct:

activity::<event source>|account::<account ID>|region::<region>|id::<event ID>

When no durable native identifier exists, generate a deterministic source-qualified identifier from stable normalized event fields and a normalized raw-record hash.

Do not require native event_id when a valid deterministic source_qualified_event_id has been generated.

The normalized AWS finding view must provide:

·        finding_time

·        finding_source

·        product_arn

·        finding_id

·        source_qualified_finding_id

·        finding_type

·        finding_high_risk

·        finding_represents_qualifying_aws_behavior

·        account_id

·        canonical_session_binding_key

·        aws_region

·        resource_id

·        approved_workflow_validated

·        approved_start_time

·        approved_end_time

Define finding_time as the normalized source-observed activity time used for correlation.

Do not use finding creation or update time unless it is the only source-supported observation time and that limitation is documented.

Derive finding_high_risk through controlled source-specific logic using finding type, severity, resource criticality, identity or credential relevance, and privileged or security-control impact.

Construct:

finding::<finding source>|product::<product ARN>|account::<account ID>|region::<region>|id::<finding ID>

Assign one primary evidence category to each activity record or finding.

Approved-workflow suppression applies only when the account, session or credential, behavior, resource, source, and authorized time window align.

Mandatory-review resources, events, and findings bypass suppression and remain alertable.

Run the rule in test or non-production alerting mode until session binding, lineage evaluation, identifiers, finding classification, suppression handling, and expected federated administration have been validated.

DRI Assessment

High. The rule is anchored to controlled federation-session attribution and durable AWS privilege, credential, persistence, security-control, logging, identity-provider, and sensitive administrative behaviors rather than to one exploit, token format, command, or attacker tool.

DRI

8.8 / 10

TCR Assessment

Operational confidence is moderate to high when qualifying AWS behavior is associated with a suspicious AD FS federation acceptance and supported by confirmed missing lineage, prior key-compromise evidence, identity inconsistency, source or device anomalies, or a relevant session-bound AWS finding.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

AWS telemetry does not independently prove that a SAML assertion was forged.

Federation, assertion, access-key, and STS session identifiers may be transformed, omitted, truncated, or inconsistently retained.

Source identity, principal ID, role ARN, and role-session name provide attribution but are not inherently unique session identifiers.

GuardDuty and Security Hub findings may not preserve complete originating session context.

Unavailable or failed lineage evaluation cannot be treated as confirmed missing lineage.

Legitimate automation, emergency administration, identity-provider maintenance, role testing, migration, security testing, managed-service activity, or incident response may resemble suspicious behavior.

Incomplete AD FS, STS, CloudTrail, identity, finding, or enrichment telemetry can prevent reliable session reconstruction.

Detection Query Pattern

authoritative_adfs_context =

FROM adfs_aws_federation_context

WHERE federation_acceptance_id IS NOT NULL

AND federation_acceptance_time IS NOT NULL

AND federation_acceptance_successful = true

AND monitored_adfs_trust = true

AND aws_account_id IS NOT NULL

AND canonical_session_binding_key IS NOT NULL

AND CANONICAL_KEY_HAS_SESSION_SPECIFIC_COMPONENT(

  canonical_session_binding_key

) = true

DEDUPLICATE BY

aws_account_id,

federation_acceptance_id,

canonical_session_binding_key

normalized_aws_activity =

FROM aws_activity_context

WHERE event_time IS NOT NULL

AND source_qualified_event_id IS NOT NULL

AND event_outcome = "success"

AND account_id IS NOT NULL

AND canonical_session_binding_key IS NOT NULL

AND aws_region IS NOT NULL

DEDUPLICATE BY

source_qualified_event_id

normalized_aws_findings =

FROM aws_finding_context

WHERE finding_time IS NOT NULL

AND source_qualified_finding_id IS NOT NULL

AND account_id IS NOT NULL

AND canonical_session_binding_key IS NOT NULL

AND aws_region IS NOT NULL

DEDUPLICATE BY

source_qualified_finding_id

qualifying_aws_activity =

FROM normalized_aws_activity

JOIN authoritative_adfs_context

ON normalized_aws_activity.account_id

= authoritative_adfs_context.aws_account_id

AND normalized_aws_activity.canonical_session_binding_key

= authoritative_adfs_context.canonical_session_binding_key

WHERE normalized_aws_activity.event_time BETWEEN

authoritative_adfs_context.federation_acceptance_time

AND authoritative_adfs_context.federation_acceptance_time

+ ENV_ADFS_TO_AWS_ACTIVITY_WINDOW

AND normalized_aws_activity.event_name

IN ENV_QUALIFYING_AWS_ACTIVITY_EVENTS

AND (

  normalized_aws_activity.resource_id

  IN ENV_MANDATORY_REVIEW_RESOURCES

  OR normalized_aws_activity.event_name

  IN ENV_MANDATORY_REVIEW_EVENTS

  OR NOT (

    normalized_aws_activity.approved_workflow_validated = true

    AND normalized_aws_activity.event_time BETWEEN

    normalized_aws_activity.approved_start_time

    AND normalized_aws_activity.approved_end_time

  )

)

CALCULATE

primary_evidence_category =

MAP_ACTIVITY_TO_ONE_PRIMARY_CATEGORY(

  normalized_aws_activity.event_name,

  normalized_aws_activity.activity_category

)

EMIT

normalized_aws_activity.account_id AS account_id,

authoritative_adfs_context.federation_acceptance_id

AS federation_acceptance_id,

authoritative_adfs_context.canonical_session_binding_key

AS canonical_session_binding_key,

normalized_aws_activity.source_qualified_event_id

AS evidence_id,

"activity" AS evidence_source_type,

normalized_aws_activity.event_time AS evidence_time,

primary_evidence_category,

coalesce(

  normalized_aws_activity.high_risk_activity,

  false

) AS high_risk_behavior,

normalized_aws_activity.event_name AS risk_type,

false AS finding_represents_qualifying_aws_behavior

qualifying_aws_findings =

FROM normalized_aws_findings

JOIN authoritative_adfs_context

ON normalized_aws_findings.account_id

= authoritative_adfs_context.aws_account_id

AND normalized_aws_findings.canonical_session_binding_key

= authoritative_adfs_context.canonical_session_binding_key

WHERE normalized_aws_findings.finding_time BETWEEN

authoritative_adfs_context.federation_acceptance_time

AND authoritative_adfs_context.federation_acceptance_time

+ ENV_ADFS_TO_AWS_ACTIVITY_WINDOW

AND normalized_aws_findings.finding_type

IN ENV_RELEVANT_AWS_SECURITY_FINDINGS

AND (

  normalized_aws_findings.resource_id

  IN ENV_MANDATORY_REVIEW_RESOURCES

  OR normalized_aws_findings.finding_type

  IN ENV_MANDATORY_REVIEW_FINDINGS

  OR NOT (

    normalized_aws_findings.approved_workflow_validated = true

    AND normalized_aws_findings.finding_time BETWEEN

    normalized_aws_findings.approved_start_time

    AND normalized_aws_findings.approved_end_time

  )

)

EMIT

normalized_aws_findings.account_id AS account_id,

authoritative_adfs_context.federation_acceptance_id

AS federation_acceptance_id,

authoritative_adfs_context.canonical_session_binding_key

AS canonical_session_binding_key,

normalized_aws_findings.source_qualified_finding_id

AS evidence_id,

"finding" AS evidence_source_type,

normalized_aws_findings.finding_time AS evidence_time,

"active_aws_security_finding"

AS primary_evidence_category,

coalesce(

  normalized_aws_findings.finding_high_risk,

  false

) AS high_risk_behavior,

normalized_aws_findings.finding_type AS risk_type,

coalesce(

  normalized_aws_findings.finding_represents_qualifying_aws_behavior,

  false

) AS finding_represents_qualifying_aws_behavior

aws_session_risk_context =

UNION ALL ALIGNED

qualifying_aws_activity,

qualifying_aws_findings

DEDUPLICATE BY

evidence_source_type,

evidence_id,

federation_acceptance_id,

canonical_session_binding_key

aws_session_risk_aggregation =

FROM aws_session_risk_context

JOIN authoritative_adfs_context

ON aws_session_risk_context.account_id

= authoritative_adfs_context.aws_account_id

AND aws_session_risk_context.federation_acceptance_id

= authoritative_adfs_context.federation_acceptance_id

AND aws_session_risk_context.canonical_session_binding_key

= authoritative_adfs_context.canonical_session_binding_key

GROUP BY

aws_session_risk_context.account_id,

aws_session_risk_context.federation_acceptance_id,

aws_session_risk_context.canonical_session_binding_key

AGGREGATE

distinct_aws_evidence_count =

count_distinct(

  aws_session_risk_context.evidence_id

),

distinct_primary_evidence_categories =

count_distinct(

  aws_session_risk_context.primary_evidence_category

),

high_risk_behavior_present =

max(

  boolean_to_integer(

    coalesce(

      aws_session_risk_context.high_risk_behavior,

      false

    )

  )

),

qualifying_aws_activity_present =

max(

  boolean_to_integer(

    aws_session_risk_context.evidence_source_type

    = "activity"

  )

),

qualifying_behavior_finding_present =

max(

  boolean_to_integer(

    aws_session_risk_context.evidence_source_type

    = "finding"

    AND aws_session_risk_context

    .finding_represents_qualifying_aws_behavior

    = true

  )

),

confirmed_lineage_failure_present =

(

  (

    authoritative_adfs_context

    .issuance_lineage_evaluation_complete = true

    AND authoritative_adfs_context

    .issuance_lineage_status = "not_found"

  )

  OR (

    authoritative_adfs_context

    .authentication_lineage_evaluation_complete = true

    AND authoritative_adfs_context

    .authentication_lineage_status = "not_found"

  )

),

independent_corroboration_present =

(

  authoritative_adfs_context.claims_inconsistent = true

  OR authoritative_adfs_context

  .identity_state_inconsistent = true

  OR authoritative_adfs_context

  .source_or_device_anomalous = true

  OR distinct_primary_evidence_categories

  >= ENV_MIN_DISTINCT_AWS_CORROBORATION_CATEGORIES

),

prior_key_compromise_present =

coalesce(

  authoritative_adfs_context.prior_key_compromise_evidence,

  false

),

required_aws_behavior_validated =

(

  qualifying_aws_activity_present = 1

  OR qualifying_behavior_finding_present = 1

),

independent_corroboration_validated =

(

  (

    confirmed_lineage_failure_present = true

    AND independent_corroboration_present = true

  )

  OR (

    prior_key_compromise_present = true

    AND required_aws_behavior_validated = true

  )

)

FROM aws_session_risk_aggregation

WHERE independent_corroboration_validated = true

AND required_aws_behavior_validated = true

AND (

  distinct_aws_evidence_count

  >= ENV_MIN_DISTINCT_AWS_RISK_RECORDS

  OR high_risk_behavior_present = 1

  OR qualifying_behavior_finding_present = 1

)

CALCULATE

alert_deduplication_key =

HASH(

  ENV_AWS_ADFS_RULE_IDENTIFIER,

  account_id,

  federation_acceptance_id,

  canonical_session_binding_key

)

UPSERT supporting alert

BY alert_deduplication_key

UPDATE EXISTING ALERT WHEN

NEW_UNIQUE_EVIDENCE_IDS_ADDED = true

OR SEVERITY_INCREASED = true

DO NOT PROMOTE WITHOUT

independent_corroboration_validated = true

AND required_aws_behavior_validated = true

AND alert_deduplication_key IS NOT NULL

Azure

Detection Viability Assessment

Azure can provide one supporting correlation rule for AD FS signing-key exposure and forged-token trust compromise when Microsoft Entra ID sign-in logs, Azure Activity logs, Entra audit logs, Defender for Cloud, Microsoft Sentinel, resource telemetry, federation context, and normalized AD FS telemetry are available.

Azure telemetry does not independently prove that a SAML assertion was forged. Promotion requires confirmed missing AD FS issuance or authentication lineage supported by an independent federation anomaly, or prior DKM or signing-key compromise evidence combined with qualifying Azure behavior.

Rule

Suspicious AD FS-Federated Azure Access Followed by Privileged or Persistent Cloud Activity

Rule Format

Azure correlation pseudologic

Detection Purpose

Detect privileged, credential-related, persistent, security-control, logging, identity-provider, or sensitive administrative Azure behavior associated with a suspicious AD FS-federated identity.

Detection Logic

Correlate successful Azure access through a monitored AD FS trust with qualifying Azure administrative activity or a relevant Defender for Cloud or Sentinel finding associated with the same tenant and normalized federated identity.

·        Require a successful AD FS federation acceptance.

·        Require a validated normalized federated-identity identifier.

·        Correlate Azure activity within the configured post-federation window.

·        Associate each Azure record with the most recent qualifying federation acceptance preceding the record.

·        Require qualifying Azure behavior or a relevant security finding representing qualifying behavior.

·        Require either a high-risk condition or the configured multi-record threshold.

·        Require confirmed missing AD FS lineage with an independent federation anomaly, or prior DKM or signing-key compromise evidence.

·        Exclude validated administrative, automation, infrastructure-as-code, managed-service, break-glass, and incident-response activity unless the affected resource, operation, or finding requires mandatory review.

·        Do not promote based only on a federated sign-in, unavailable telemetry, routine administration, or an unbound security finding.

Required Telemetry

·        Microsoft Entra ID sign-in logs

·        Microsoft Entra ID audit logs

·        Azure Activity logs

·        Azure Resource Manager events

·        Microsoft Defender for Cloud alerts

·        Microsoft Sentinel incidents or analytics results

·        Azure role-assignment and privileged-access activity

·        Service-principal, managed-identity, application, and workload-identity activity

·        Key Vault, Storage, VM, App Service, container, network, logging, and diagnostic-setting activity where applicable

·        Azure tenant, subscription, identity, application, role, source, user-agent, resource, and operation identifiers

·        AD FS federation-acceptance, issuance, authentication, trust, claims, identity, source, and device context

·        Prior DKM-access and probable signing-key-material handling evidence

·        Approved administrative, automation, infrastructure-as-code, managed-service, break-glass, and incident-response context

Engineering Implementation Instructions

Use this pattern as implementation-ready Azure federation and administrative-activity correlation pseudologic.

adfs_azure_federation_context represents normalized AD FS federation-acceptance, issuance, authentication, trust, claims, identity, source, device, and prior key-compromise context.

azure_federated_activity represents normalized Entra sign-in, Entra audit, Azure Activity, Defender for Cloud, Sentinel, resource, identity, workflow, and source-enrichment context.

Local teams must create, map, or enrich both views before deployment. The normalized federated-identity identifier must be derived from a validated Entra object, immutable federated subject, or equivalent stable identity mapping. Tenant, subscription, application, source, device, and user-agent values may support correlation but must not independently identify the federated actor.

Defender for Cloud alerts and Sentinel findings must be enriched with the associated normalized federated identity before entering the finding branch.

When more than one federation acceptance for the same tenant and normalized federated identity falls within the correlation window, retain only the most recent qualifying acceptance preceding each Azure record after all activity, finding, lineage, corroboration, and workflow conditions have been applied.

Approved workflow exclusions must match the tenant, subscription, identity, operation or finding, resource, source, and approved time window. Mandatory-review resources, operations, and findings must remain alertable.

DRI Assessment

High. The rule is anchored to federated-identity attribution and durable Azure privilege, credential, persistence, security-control, logging, identity-provider, and sensitive administrative behaviors rather than to one exploit, token format, command, or attacker tool.

DRI

8.8 / 10

TCR Assessment

Operational confidence is moderate to high when qualifying Azure behavior is associated with a suspicious AD FS federation acceptance and supported by confirmed missing lineage and an independent federation anomaly, or prior DKM or signing-key compromise evidence.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Azure telemetry does not independently prove that a SAML assertion was forged.

Federated identity, session, correlation, and token identifiers may be transformed, omitted, truncated, or inconsistently retained.

Entra object IDs, application IDs, service principals, tenant IDs, subscriptions, source values, and user agents provide attribution but are not inherently unique session identifiers.

Defender for Cloud alerts and Sentinel findings may require enrichment to associate them with the originating federated identity.

Unavailable or failed AD FS lineage evaluation cannot be treated as confirmed missing lineage.

Legitimate automation, emergency administration, identity-provider maintenance, role testing, migration, security testing, managed-service activity, or incident response may resemble suspicious behavior.

Incomplete AD FS, Entra, Azure Activity, resource, finding, or enrichment telemetry can prevent reliable identity reconstruction.

Detection Query Pattern

Use this pattern as implementation-ready Azure federation and administrative-activity correlation pseudologic and map all AD FS, Entra sign-in, Entra audit, Azure Activity, Defender for Cloud, Sentinel, identity, workflow, resource, source, and time-window fields to the target Sentinel, SIEM, data lake, or analytics environment before deployment.

adfs_azure_federation_context represents a normalized federation view derived from AD FS authentication, token issuance, relying-party trust, claims, assertion, identity, source, device, DKM-access, signing-key-material handling, and federation-acceptance telemetry.

azure_federated_activity represents a normalized Azure view derived from Entra sign-in logs, Entra audit logs, Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Sentinel incidents, tenant, subscription, identity, application, role, resource, source, user-agent, workflow, and enrichment context.

Local teams must create, map, or enrich both views before deploying the Azure federation correlation pattern.

filtered_azure_federated_activity =

FROM azure_federated_activity,

adfs_azure_federation_context

WHERE adfs_azure_federation_context.federation_acceptance_id

IS NOT NULL

AND adfs_azure_federation_context.federation_acceptance_time

IS NOT NULL

AND adfs_azure_federation_context.federation_acceptance_successful

= true

AND adfs_azure_federation_context.monitored_adfs_trust

= true

AND adfs_azure_federation_context.tenant_id

= azure_federated_activity.tenant_id

AND adfs_azure_federation_context.normalized_federated_identity_id

= azure_federated_activity.normalized_federated_identity_id

AND adfs_azure_federation_context.normalized_federated_identity_id

IS NOT NULL

AND azure_federated_activity.normalized_federated_identity_id

IS NOT NULL

AND azure_federated_activity.event_time BETWEEN

adfs_azure_federation_context.federation_acceptance_time

AND adfs_azure_federation_context.federation_acceptance_time

+ ENV_ADFS_TO_AZURE_ACTIVITY_WINDOW

AND azure_federated_activity.source_qualified_record_id

IS NOT NULL

AND (

  (

    azure_federated_activity.record_type = "activity"

    AND azure_federated_activity.event_outcome = "success"

    AND azure_federated_activity.operation_name

    IN ENV_QUALIFYING_AZURE_ACTIVITY_OPERATIONS

  )

  OR (

    azure_federated_activity.record_type = "finding"

    AND azure_federated_activity.finding_provider_id

    IS NOT NULL

    AND (

      azure_federated_activity.defender_for_cloud_alert_type

      IN ENV_RELEVANT_AZURE_DEFENDER_FINDINGS

      OR azure_federated_activity.sentinel_finding_type

      IN ENV_RELEVANT_AZURE_SENTINEL_FINDINGS

    )

    AND azure_federated_activity

    .finding_represents_qualifying_azure_behavior

    = true

  )

)

AND (

  (

    (

      adfs_azure_federation_context

      .issuance_lineage_evaluation_complete

      = true

      AND adfs_azure_federation_context

      .issuance_lineage_status

      = "not_found"

    )

    OR (

      adfs_azure_federation_context

      .authentication_lineage_evaluation_complete

      = true

      AND adfs_azure_federation_context

      .authentication_lineage_status

      = "not_found"

    )

  )

  AND (

    adfs_azure_federation_context.claims_inconsistent

    = true

    OR adfs_azure_federation_context

    .identity_state_inconsistent

    = true

    OR adfs_azure_federation_context

    .source_or_device_anomalous

    = true

  )

  OR adfs_azure_federation_context

  .prior_key_compromise_evidence

  = true

)

AND (

  azure_federated_activity.resource_id

  IN ENV_MANDATORY_REVIEW_AZURE_RESOURCES

  OR azure_federated_activity.operation_name

  IN ENV_MANDATORY_REVIEW_AZURE_OPERATIONS

  OR azure_federated_activity.defender_for_cloud_alert_type

  IN ENV_MANDATORY_REVIEW_AZURE_DEFENDER_FINDINGS

  OR azure_federated_activity.sentinel_finding_type

  IN ENV_MANDATORY_REVIEW_AZURE_SENTINEL_FINDINGS

  OR NOT (

    coalesce(

      azure_federated_activity.approved_workflow_validated,

      false

    ) = true

    AND coalesce(

      azure_federated_activity.approved_workflow_scope_match,

      false

    ) = true

    AND azure_federated_activity.approved_start_time

    IS NOT NULL

    AND azure_federated_activity.approved_end_time

    IS NOT NULL

    AND azure_federated_activity.event_time BETWEEN

    azure_federated_activity.approved_start_time

    AND azure_federated_activity.approved_end_time

  )

)

EMIT

azure_federated_activity.tenant_id

AS tenant_id,

azure_federated_activity.subscription_id

AS subscription_id,

azure_federated_activity.normalized_federated_identity_id

AS normalized_federated_identity_id,

adfs_azure_federation_context.federation_acceptance_id

AS federation_acceptance_id,

adfs_azure_federation_context.federation_acceptance_time

AS federation_acceptance_time,

azure_federated_activity.source_qualified_record_id

AS source_qualified_record_id,

azure_federated_activity.event_time

AS event_time,

coalesce(

  azure_federated_activity.high_risk_behavior,

  false

) AS high_risk_behavior

matched_azure_federated_activity =

FROM filtered_azure_federated_activity

QUALIFY

row_number() OVER (

  PARTITION BY

  filtered_azure_federated_activity.source_qualified_record_id

  ORDER BY

  filtered_azure_federated_activity.federation_acceptance_time DESC

) = 1

FROM matched_azure_federated_activity

GROUP BY

matched_azure_federated_activity.tenant_id,

matched_azure_federated_activity.subscription_id,

matched_azure_federated_activity.normalized_federated_identity_id,

matched_azure_federated_activity.federation_acceptance_id

EMIT alert WHEN

count_distinct(

  CONCAT(

    matched_azure_federated_activity.source_qualified_record_id,

    "|",

    matched_azure_federated_activity.event_time

  )

) >= ENV_MIN_DISTINCT_AZURE_RISK_RECORDS

OR max(

  boolean_to_integer(

    matched_azure_federated_activity.high_risk_behavior

  )

) = 1

GCP

Detection Viability Assessment

Google Cloud can provide one supporting correlation rule for AD FS signing-key exposure and forged-token trust compromise when Cloud Audit Logs, Security Command Center, identity, service-account, resource, federation, and normalized AD FS telemetry are available.

Google Cloud telemetry does not independently prove that a SAML assertion was forged. Promotion requires confirmed missing AD FS issuance or authentication lineage supported by an independent federation anomaly, or prior DKM or signing-key compromise evidence combined with qualifying Google Cloud behavior.

Rule

Suspicious AD FS-Federated Google Cloud Access Followed by Privileged or Persistent Cloud Activity

Rule Format

Google Cloud correlation pseudologic

Detection Purpose

Detect privileged, credential-related, persistent, security-control, logging, identity-provider, or sensitive administrative Google Cloud behavior associated with a suspicious AD FS-federated identity.

Detection Logic

Correlate successful Google Cloud access through a monitored AD FS trust with qualifying administrative activity or a relevant Security Command Center finding associated with the same Google Cloud organization and normalized federated principal.

·        Require a successful AD FS federation acceptance.

·        Require a validated normalized federated-principal identifier.

·        Correlate Google Cloud activity within the configured post-federation window.

·        When multiple federation acceptances qualify, associate each Google Cloud record only with the most recent qualifying acceptance preceding the record.

·        Require qualifying Google Cloud behavior or a relevant Security Command Center finding representing qualifying behavior.

·        Require either a high-risk condition or the configured multi-record threshold.

·        Require confirmed missing AD FS lineage with an independent federation anomaly, or prior DKM or signing-key compromise evidence.

·        Exclude validated administrative, automation, infrastructure-as-code, managed-service, break-glass, and incident-response activity unless the affected resource, method, or finding requires mandatory review.

·        Do not promote based only on a federated sign-in, unavailable telemetry, routine administration, or an unbound security finding.

Required Telemetry

·        Google Cloud Admin Activity logs

·        Google Cloud Data Access logs where enabled

·        Security Command Center findings

·        Cloud IAM and service-account activity

·        Workforce Identity Federation or SAML federation configuration

·        Google Cloud organization, folder, project, principal, service-account, source, user-agent, and resource identifiers

·        Secret Manager, Cloud KMS, Cloud Storage, Compute Engine, GKE, Cloud Run, and App Engine activity where applicable

·        Logging, monitoring, audit-policy, and security-control changes

·        Normalized AD FS federation-acceptance, issuance, authentication, trust, claims, identity, source, and device context

·        Prior DKM-access and probable signing-key-material handling evidence

·        Approved administrative, automation, infrastructure-as-code, managed-service, break-glass, and incident-response context

Engineering Implementation Instructions

Use this pattern as implementation-ready Google Cloud federation and administrative-activity correlation pseudologic.

adfs_gcp_federation_context represents normalized AD FS federation-acceptance, issuance, authentication, trust, claims, identity, source, device, and prior key-compromise context.

gcp_federated_activity represents normalized Google Cloud audit, IAM, service-account, Security Command Center, resource, identity, workflow, and source-enrichment context.

Local teams must create, map, or enrich both views before deployment. The normalized federated-principal identifier must be derived from a validated mapped workforce principal, immutable federated subject, or equivalent stable identity mapping. Organization, project, source, device, and user-agent values may support correlation but must not independently identify the principal.

Security Command Center findings must be enriched with the associated normalized federated principal using available principal, organization, project, resource, and event-time context before entering the finding branch.

When more than one federation acceptance for the same organization and normalized federated principal falls within the correlation window, retain only the most recent qualifying acceptance preceding each Google Cloud record.

Approved workflow exclusions must match the organization, project, principal, method or finding, resource, source, and approved time window. Mandatory-review resources, methods, and findings must remain alertable.

DRI Assessment

High. The rule is anchored to federated-principal attribution and durable Google Cloud privilege, credential, persistence, security-control, logging, identity-provider, and sensitive administrative behaviors rather than to one exploit, token format, command, or attacker tool.

DRI

8.8 / 10

TCR Assessment

Operational confidence is moderate to high when qualifying Google Cloud behavior is associated with a suspicious AD FS federation acceptance and supported by confirmed missing lineage and an independent federation anomaly, or prior DKM or signing-key compromise evidence.

Operational TCR

8.3 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Google Cloud telemetry does not independently prove that a SAML assertion was forged.

Federated-principal identifiers may be transformed, omitted, truncated, or inconsistently retained.

Principal email, service-account identity, organization, project, source, and user-agent values provide attribution but are not inherently unique session identifiers.

Security Command Center findings may require enrichment to associate them with the originating federated principal.

Unavailable or failed AD FS lineage evaluation cannot be treated as confirmed missing lineage.

Legitimate automation, emergency administration, identity-provider maintenance, role testing, migration, security testing, managed-service activity, or incident response may resemble suspicious behavior.

Incomplete AD FS, Cloud Audit Logs, IAM, identity, finding, or enrichment telemetry can prevent reliable principal reconstruction.

Detection Query Pattern

Use this pattern as implementation-ready Google Cloud federation and administrative-activity correlation pseudologic and map all AD FS, Google Cloud audit, IAM, service-account, Security Command Center, identity, workflow, resource, source, and time-window fields to the target Chronicle, SIEM, data lake, or analytics environment before deployment.

adfs_gcp_federation_context represents a normalized federation view derived from AD FS authentication, token issuance, relying-party trust, claims, assertion, identity, source, device, DKM-access, signing-key-material handling, and federation-acceptance telemetry.

gcp_federated_activity represents a normalized Google Cloud view derived from Admin Activity logs, Data Access logs, IAM activity, service-account activity, Security Command Center findings, organization, folder, project, principal, resource, source, user-agent, workflow, and enrichment context.

Local teams must create, map, or enrich both views before deploying the Google Cloud federation correlation pattern.

matched_gcp_federated_activity =

FROM gcp_federated_activity,

adfs_gcp_federation_context

WHERE adfs_gcp_federation_context.federation_acceptance_id

IS NOT NULL

AND adfs_gcp_federation_context.federation_acceptance_time

IS NOT NULL

AND adfs_gcp_federation_context.federation_acceptance_successful

= true

AND adfs_gcp_federation_context.monitored_adfs_trust

= true

AND adfs_gcp_federation_context.organization_id

= gcp_federated_activity.organization_id

AND adfs_gcp_federation_context.normalized_federated_principal_id

= gcp_federated_activity.normalized_federated_principal_id

AND adfs_gcp_federation_context.normalized_federated_principal_id

IS NOT NULL

AND gcp_federated_activity.normalized_federated_principal_id

IS NOT NULL

AND gcp_federated_activity.event_time BETWEEN

adfs_gcp_federation_context.federation_acceptance_time

AND adfs_gcp_federation_context.federation_acceptance_time

+ ENV_ADFS_TO_GCP_ACTIVITY_WINDOW

AND gcp_federated_activity.source_qualified_record_id

IS NOT NULL

AND (

  (

    gcp_federated_activity.record_type = "activity"

    AND gcp_federated_activity.event_outcome = "success"

    AND gcp_federated_activity.method_name

    IN ENV_QUALIFYING_GCP_ACTIVITY_METHODS

  )

  OR (

    gcp_federated_activity.record_type = "finding"

    AND gcp_federated_activity.finding_provider_id

    IS NOT NULL

    AND gcp_federated_activity

    .security_command_center_finding_type

    IN ENV_RELEVANT_GCP_SECURITY_FINDINGS

    AND gcp_federated_activity

    .finding_represents_qualifying_gcp_behavior

    = true

  )

)

AND (

  (

    (

      adfs_gcp_federation_context

      .issuance_lineage_evaluation_complete

      = true

      AND adfs_gcp_federation_context

      .issuance_lineage_status

      = "not_found"

    )

    OR (

      adfs_gcp_federation_context

      .authentication_lineage_evaluation_complete

      = true

      AND adfs_gcp_federation_context

      .authentication_lineage_status

      = "not_found"

    )

  )

  AND (

    adfs_gcp_federation_context.claims_inconsistent

    = true

    OR adfs_gcp_federation_context

    .identity_state_inconsistent

    = true

    OR adfs_gcp_federation_context

    .source_or_device_anomalous

    = true

  )

  OR adfs_gcp_federation_context

  .prior_key_compromise_evidence

  = true

)

AND (

  gcp_federated_activity.resource_name

  IN ENV_MANDATORY_REVIEW_GCP_RESOURCES

  OR gcp_federated_activity.method_name

  IN ENV_MANDATORY_REVIEW_GCP_METHODS

  OR gcp_federated_activity

  .security_command_center_finding_type

  IN ENV_MANDATORY_REVIEW_GCP_FINDINGS

  OR NOT (

    coalesce(

      gcp_federated_activity.approved_workflow_validated,

      false

    ) = true

    AND coalesce(

      gcp_federated_activity.approved_workflow_scope_match,

      false

    ) = true

    AND gcp_federated_activity.approved_start_time

    IS NOT NULL

    AND gcp_federated_activity.approved_end_time

    IS NOT NULL

    AND gcp_federated_activity.event_time BETWEEN

    gcp_federated_activity.approved_start_time

    AND gcp_federated_activity.approved_end_time

  )

)

QUALIFY

row_number() OVER (

  PARTITION BY

  gcp_federated_activity.source_qualified_record_id

  ORDER BY

  adfs_gcp_federation_context.federation_acceptance_time DESC

) = 1

EMIT

gcp_federated_activity.organization_id

AS organization_id,

gcp_federated_activity.project_id

AS project_id,

gcp_federated_activity.normalized_federated_principal_id

AS normalized_federated_principal_id,

adfs_gcp_federation_context.federation_acceptance_id

AS federation_acceptance_id,

gcp_federated_activity.source_qualified_record_id

AS source_qualified_record_id,

gcp_federated_activity.event_time

AS event_time,

coalesce(

  gcp_federated_activity.high_risk_behavior,

  false

) AS high_risk_behavior

FROM matched_gcp_federated_activity

GROUP BY

matched_gcp_federated_activity.organization_id,

matched_gcp_federated_activity.project_id,

matched_gcp_federated_activity.normalized_federated_principal_id,

matched_gcp_federated_activity.federation_acceptance_id

EMIT alert WHEN

count_distinct(

  CONCAT(

    matched_gcp_federated_activity.source_qualified_record_id,

    "|",

    matched_gcp_federated_activity.event_time

  )

) >= ENV_MIN_DISTINCT_GCP_RISK_RECORDS

OR max(

  boolean_to_integer(

    matched_gcp_federated_activity.high_risk_behavior

  )

) = 1

S26 — Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on a single CVE identifier, exploit name, proof-of-concept name, DKM path, certificate thumbprint, token value, command string, file path, source IP, user-agent value, scanner result, campaign name, actor name, or static indicator as the basis for coverage.

Coverage Scope

The S25 rule set provides coverage for observable behavior associated with unusual identity-infrastructure administrative access, validated AD FS DKM access, probable signing-key-material handling, suspicious certificate or recovery-artifact activity, anomalous federation access without expected issuance or authentication lineage, identity-inconsistent claims, trusted identity impersonation, privileged or sensitive downstream activity, and supporting AWS, Azure, and GCP activity.

Coverage is strongest where Active Directory object-access auditing, AD FS authentication and issuance logs, certificate telemetry, endpoint telemetry, process and file telemetry, remote-administration telemetry, network telemetry, relying-party telemetry, cloud audit telemetry, identity context, user-state context, entitlement data, approved-workflow records, and SIEM correlation can be joined into bounded behavioral sequences.

Primary Coverage Areas

·        Unusual administrative or directory-protocol access to AD FS servers, domain controllers, backup systems, recovery systems, identity-management platforms, or privileged administrative workstations followed by rare or unapproved outbound communication

·        Successful read or control-access activity involving a validated AD FS DKM container or associated key object by an unexpected account, host, process, service, remote session, or administrative path

·        Permission, ownership, inheritance, or auditing changes affecting a validated AD FS DKM container outside an approved workflow

·        Suspicious directory-query, PowerShell, certificate-management, backup, recovery, archive, staging, export, or transfer activity near validated DKM access

·        Token-signing certificate, private-key, recovery-package, federation-configuration, backup, archive, or credential-bearing artifact access outside approved administrative activity

·        Unexpected token-signing certificate export, addition, replacement, promotion, rollover, or private-key permission change

·        Successful federation acceptance without expected AD FS issuance or upstream authentication lineage after telemetry completeness has been validated

·        Accepted federation activity containing claims, roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or entitlements inconsistent with the represented identity or relying-party policy

·        Federated use of dormant, disabled, terminated, service, emergency, executive, administrative, or otherwise high-value identities without expected operational context

·        Privileged application, SaaS, VPN, administrative, data-access, credential-creation, persistence, role-modification, or security-control activity following anomalous federation acceptance

·        Similar anomalous federation behavior across multiple relying parties, applications, identities, sessions, or cloud environments

·        Supporting AWS, Azure, and GCP activity following suspicious AD FS-federated access when reliable federation, identity, session, account, tenant, subscription, organization, project, source, resource, and time-window linkage exists

Traceability Mapping

Unusual Identity-Infrastructure Administrative Access Followed by Rare Egress

This behavior is covered where network telemetry identifies anomalous administrative or directory-protocol access to protected identity infrastructure followed by rare, newly observed, unapproved, or high-risk outbound communication from the initiating source or accessed identity-infrastructure asset.

Mapped Coverage

·        NDR / Network Behavioral Analytics provides the primary network-sequence rule for unusual administrative access followed by rare or unapproved egress

·        SentinelOne provides supporting endpoint coverage when the same sequence includes directory-query tools, certificate tooling, backup or recovery activity, archive creation, staging, transfer activity, or process-linked outbound communication

·        Splunk, Elastic, and QRadar provide correlation where network, asset, process, directory, certificate, AD FS, identity, and approved-workflow telemetry is normalized

·        SIGMA provides portable event-level support for identity-material handling and related behavioral conditions where the target backend performs the required temporal correlation

·        AWS, Azure, and GCP provide downstream support only when later cloud activity can be reliably linked to the same suspicious federation or identity-compromise context

Coverage Qualification

·        Administrative access alone is not sufficient

·        LDAP, LDAPS, SMB, RPC, WinRM, RDP, HTTPS management, or another protocol alone is not sufficient

·        Rare egress alone is not sufficient

·        A newly observed destination alone is not sufficient

·        Destination reputation alone is not sufficient

·        TCP 443 alone is not sufficient to establish administrative access

·        Coverage requires protected-asset mapping, administrative-path context, source or destination continuity, bounded event ordering, behavioral deviation, or corroborating directory, endpoint, certificate, AD FS, identity, or relying-party evidence

·        Approved administration, backup, recovery, migration, certificate-management, vulnerability validation, vendor support, monitoring, deployment, maintenance, and incident-response activity requires baseline validation rather than unconditional suppression

Validated AD FS DKM Access and DKM Control Change

This behavior is covered where Active Directory object-access and directory-change telemetry identifies access to the validated AD FS DKM container or associated key objects by an unexpected actor, source, process, remote session, or workflow.

Mapped Coverage

·        Splunk, Elastic, and QRadar provide primary SIEM correlation for validated DKM object access, access-right evaluation, actor and source context, DKM permission change, ownership change, inheritance change, auditing change, and nearby identity-infrastructure activity

·        SIGMA provides portable event-rule and temporal-correlation coverage for validated DKM access followed by probable federation key-material handling

·        SentinelOne provides supporting endpoint coverage for directory-query, PowerShell, certificate, backup, recovery, archive, staging, and transfer behavior associated with the same actor or source context

·        NDR / Network Behavioral Analytics provides supporting context where suspicious access paths, administrative relationships, or outbound communication surround the DKM activity

·        AWS, Azure, and GCP do not directly detect DKM access and require upstream AD FS or Active Directory evidence before cloud activity may be linked to this behavior

Coverage Qualification

·        A permissive DKM access-control list is not sufficient

·        Routine Active Directory object access is not sufficient

·        Directory access unrelated to the validated DKM object is not sufficient

·        A privileged identity accessing the DKM object is not automatically benign or malicious

·        Coverage requires validated DKM object identity, access-right interpretation, actor identity, source host, process or session context, event outcome, approved-workflow evaluation, and bounded correlation

·        Permission, ownership, inheritance, or auditing changes require validation against approved AD FS deployment, recovery, migration, backup, disaster-recovery, certificate-management, and incident-response activity

·        Directory auditing may establish access without proving which cryptographic material was retrieved or whether private-key recovery succeeded

Probable Federation Signing-Key-Material Handling

This behavior is covered where suspicious DKM access or identity-infrastructure activity is followed by certificate access, private-key interaction, export activity, recovery-package access, backup access, archive creation, staging, transfer, or other probable signing-material handling.

Mapped Coverage

·        SentinelOne provides primary endpoint coverage for suspicious federation-key and identity-material discovery, export, sensitive artifact creation, archive staging, process lineage, remote-administration context, and process-linked egress

·        Splunk, Elastic, and QRadar provide primary SIEM correlation where DKM access, certificate activity, private-key activity, file activity, backup or recovery activity, archive creation, staging, transfer, source, actor, and approved-workflow telemetry is normalized

·        SIGMA provides temporal-ordered coverage for validated DKM access followed by probable key-material handling through the same normalized actor and source context

·        NDR / Network Behavioral Analytics provides supporting coverage where probable collection or staging is followed by rare outbound communication

·        AWS, Azure, and GCP contribute only when later cloud activity can be tied to the same suspected key-compromise or anomalous federation context

Coverage Qualification

·        Certificate-store enumeration alone is not sufficient

·        Certificate access alone is not sufficient

·        Backup activity alone is not sufficient

·        Recovery-package access alone is not sufficient

·        Archive creation alone is not sufficient

·        A Personal Information Exchange file or other certificate artifact alone is not sufficient

·        Coverage requires suspicious identity-infrastructure context, validated DKM access, unusual actor or source context, anomalous process lineage, sensitive artifact classification, workflow deviation, transfer behavior, or corroborating AD FS or directory evidence

·        Approved certificate rollover, backup, recovery, migration, federation deployment, disaster-recovery testing, security testing, and incident-response activity requires complete workflow validation

·        Endpoint and SIEM telemetry can identify probable key-material handling but cannot independently prove successful private-key recovery

Federation Access Without Expected Issuance or Authentication Lineage

This behavior is covered where a relying party, SaaS platform, VPN, administrative application, or cloud service accepts federation access from a monitored AD FS trust, but the expected AD FS issuance or upstream authentication lineage cannot be found after logging completeness and architecture have been validated.

Mapped Coverage

·        Splunk, Elastic, and QRadar provide primary correlation across AD FS issuance, authentication, relying-party acceptance, MFA, Kerberos, password validation, VPN, device, application, claims, identity, and session context

·        SIGMA provides portable temporal-ordered correlation for successful federation acceptance followed by qualifying downstream activity through the same reconciled session context

·        AWS, Azure, and GCP provide supporting cloud-specific coverage where accepted AD FS-federated activity can be tied to the same normalized session or federated identity and qualifying cloud behavior

·        SentinelOne and NDR / Network Behavioral Analytics provide supporting context when suspicious identity-material collection, remote administration, source-path anomalies, or transfer behavior precedes the federation activity

Coverage Qualification

·        A missing AD FS issuance event alone is not sufficient

·        A missing upstream authentication event alone is not sufficient

·        A valid token signature is not sufficient to prove legitimate AD FS issuance

·        A successful federation sign-in alone is not sufficient

·        Missing MFA alone is not sufficient

·        Impossible travel alone is not sufficient

·        A rare source IP, device, user agent, location, or application alone is not sufficient

·        Coverage requires completed lineage evaluation, validated logging coverage, farm-node ingestion, retention validation, failover consideration, timestamp alignment, relying-party architecture validation, trusted-issuer validation, and a reconciled session or identity correlation key

·        Missing lineage must be supported by an independent claims, identity, source, device, key-compromise, or downstream-behavior signal before escalation

Identity-Inconsistent Claims and Trusted Identity Impersonation

This behavior is covered where accepted federation activity contains claims, roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or entitlements inconsistent with the represented identity, current directory state, application policy, or relying-party configuration.

Mapped Coverage

·        Splunk, Elastic, and QRadar provide primary correlation across claims, directory state, user status, group membership, role entitlement, application entitlement, relying-party policy, issuer, audience, subject, token lifetime, session identifiers, source, and device context

·        SIGMA provides portable event-level and temporal support where claims-inconsistency, identity-state inconsistency, monitored-trust state, and downstream activity fields are created by the target analytics environment

·        AWS, Azure, and GCP provide supporting coverage when a reconciled federated session or normalized federated identity performs qualifying cloud activity

·        SentinelOne and NDR / Network Behavioral Analytics provide supporting upstream evidence where probable signing-material handling, unusual administrative access, or rare egress precedes the identity anomaly

Coverage Qualification

·        An unusual role or group claim alone is not sufficient

·        A privileged claim alone is not sufficient

·        A long token lifetime alone is not sufficient

·        Use of a dormant, disabled, terminated, service, emergency, executive, administrative, or high-value identity alone is not sufficient

·        Coverage requires comparison against authoritative identity state, current entitlement, relying-party policy, normal application use, issuer and audience expectations, approved claim-rule changes, identity-synchronization state, and session context

·        Approved entitlement changes, partner-federation changes, identity synchronization, claims-rule updates, application migration, or emergency-access workflows require validation

·        Claims analysis can support suspected impersonation but cannot independently prove how the token was created

Privileged, Sensitive, Persistent, or Security-Control Activity After Anomalous Federation Access

This behavior is covered where suspicious federation acceptance is followed by privileged administration, sensitive data access, role modification, credential creation, persistence, logging degradation, security-control change, application administration, or lateral expansion.

Mapped Coverage

·        Splunk, Elastic, and QRadar provide primary cross-platform correlation between suspicious federation context and downstream application, SaaS, VPN, administrative, data-access, identity, credential, persistence, and security-control behavior

·        SIGMA provides portable temporal support where downstream qualifying behavior is normalized and linked to the same federation-session context

·        AWS provides supporting coverage for suspicious AD FS-federated AWS access followed by privileged, credential-related, persistent, logging, identity-provider, security-control, or sensitive administrative AWS activity

·        Azure provides supporting coverage for suspicious AD FS-federated Azure access followed by privileged, credential-related, persistent, security-control, logging, identity-provider, or sensitive administrative Azure activity

·        GCP provides supporting coverage for suspicious AD FS-federated Google Cloud access followed by privileged, persistent, credential-related, security-control, logging, IAM, service-account, or sensitive administrative activity

·        SentinelOne and NDR / Network Behavioral Analytics provide upstream corroboration where suspicious key-material handling, administrative access, source-path anomalies, or rare egress is visible

Coverage Qualification

·        Privileged activity alone is not sufficient

·        Sensitive data access alone is not sufficient

·        Role assignment alone is not sufficient

·        Credential creation alone is not sufficient

·        Logging or security-control change alone is not sufficient

·        Persistence activity alone is not sufficient

·        Coverage requires a successful federation acceptance through a monitored AD FS trust, reliable session or identity linkage, completed lineage evaluation or prior key-compromise evidence, qualifying downstream behavior, and approved-workflow evaluation

·        Cloud, SaaS, VPN, or application activity that cannot be linked to anomalous AD FS-federated access remains outside this traceability path

Multi-Relying-Party and Multi-Application Federation Abuse

This behavior is covered where the same represented identity, claims pattern, assertion identifier, session identifier, normalized federated identity, source infrastructure, device, or behavioral sequence appears across multiple relying parties, applications, cloud services, VPNs, or administrative systems within a bounded time window.

Mapped Coverage

·        Splunk, Elastic, and QRadar provide primary multi-application and multi-session correlation

·        SIGMA provides portable event-level support where the backend implements session-aware and time-bounded correlation

·        AWS, Azure, and GCP provide platform-specific downstream views that may expose the same anomalous federated identity or related session across cloud services

·        NDR / Network Behavioral Analytics provides supporting source-path and communication-pattern context

·        SentinelOne provides supporting endpoint context where identity-material collection, staging, transfer, or remote administration preceded the multi-application activity

Coverage Qualification

·        Use of multiple applications alone is not sufficient

·        A shared source IP alone is not sufficient

·        A repeated user agent alone is not sufficient

·        A shared represented identity alone is not sufficient

·        Coverage requires reliable identity, assertion, session, issuer, audience, application, source, device, claims, time-window, or prior key-compromise linkage

·        Shared VPN, proxy, partner, administrative, or corporate infrastructure must not be treated as proof of common malicious control

·        Session identifiers and claims may be transformed or unavailable across relying parties, reducing correlation confidence

AWS Coverage Disposition

AWS provides one supporting downstream correlation rule for suspicious AD FS-federated access followed by privileged or persistent AWS activity.

Coverage may include IAM and STS activity, role assumption, access-key activity, credential creation, policy modification, logging changes, security-control changes, Secrets Manager access, KMS activity, S3 activity, administrative operations, GuardDuty findings, Security Hub findings, and other qualifying cloud behavior.

AWS does not independently prove that a SAML assertion was forged. Promotion requires confirmed missing issuance or authentication lineage with independent corroboration, or prior DKM or signing-key compromise evidence combined with qualifying AWS behavior.

Reliable AWS account and canonical session-binding context must exist. Role ARN, federated subject, source identity, principal ID, account, source IP, region, user agent, or role-session name must not independently form the session-binding key.

Azure Coverage Disposition

Azure provides one supporting downstream correlation rule for suspicious AD FS-federated Azure access followed by privileged or persistent Azure activity.

Coverage may include Entra ID sign-in activity, Entra audit activity, Azure Activity events, Azure Resource Manager operations, role assignments, service-principal or managed-identity activity, Key Vault access, Storage access, logging changes, diagnostic-setting changes, security-control changes, Defender for Cloud findings, Sentinel findings, and other qualifying administrative behavior.

Azure does not independently prove that a SAML assertion was forged. Promotion requires confirmed missing issuance or authentication lineage supported by an independent federation anomaly, or prior DKM or signing-key compromise evidence combined with qualifying Azure behavior.

Each Azure activity or finding record must be associated with the most recent qualifying federation acceptance preceding that record after all existing activity, finding, lineage, corroboration, mandatory-review, and approved-workflow conditions have been applied.

GCP Coverage Disposition

GCP provides one supporting downstream correlation rule for suspicious AD FS-federated Google Cloud access followed by privileged or persistent Google Cloud activity.

Coverage may include Admin Activity, Data Access, IAM policy change, role modification, service-account activity, service-account credential activity, workforce or workload federation activity, Secret Manager access, Cloud KMS activity, Cloud Storage access, logging changes, Security Command Center findings, network or workload changes, and other qualifying administrative behavior.

GCP does not independently prove that a SAML assertion was forged. Promotion requires confirmed missing issuance or authentication lineage supported by an independent federation anomaly, or prior DKM or signing-key compromise evidence combined with qualifying Google Cloud behavior.

Each Google Cloud activity or finding record must be associated with the most recent qualifying federation acceptance preceding that record through the same organization and normalized federated identity context.

NDR / Network Behavioral Analytics Coverage Disposition

NDR / Network Behavioral Analytics provides one primary network-sequence rule that supplies supporting network evidence for this behavior family.

The rule covers unusual administrative access to protected identity infrastructure followed by rare or unapproved outbound communication. It supports identification of anomalous management paths, new source-to-asset relationships, rare protocols, abnormal timing, unusual transfer volume, repeated callbacks, newly observed destinations, suspicious destination categories, and identity-infrastructure-to-egress sequencing.

NDR cannot independently identify the specific DKM object accessed, confirm certificate or private-key recovery, inspect encrypted token claims, prove forged-token creation, establish trusted identity impersonation, or confirm downstream compromise.

SentinelOne Coverage Disposition

SentinelOne provides two primary endpoint rules for probable federation-key and identity-material collection, export, staging, transfer, and related process behavior.

Coverage may include suspicious directory-query activity, PowerShell use, certificate utility use, backup and recovery tooling, certificate or recovery artifact creation, archive creation, sensitive-file activity, remote-administration lineage, unusual process ancestry, anomalous source-host use, and process-linked outbound communication.

SentinelOne cannot independently prove validated DKM object access, successful signing-key recovery, forged-token creation, relying-party acceptance, or downstream identity compromise without directory, AD FS, certificate, relying-party, identity, or cloud telemetry.

Splunk Coverage Disposition

Splunk provides primary SIEM correlation across DKM access, DKM control changes, probable key-material handling, token lineage, claims consistency, identity state, relying-party acceptance, downstream activity, and cloud correlation.

Coverage depends on correct normalization of Active Directory, AD FS, endpoint, certificate, network, relying-party, MFA, VPN, application, SaaS, AWS, Azure, and GCP telemetry.

Splunk correlation must preserve event ordering, typed identity and session keys, telemetry-completeness state, approved-workflow context, duplicate suppression, and the distinction between exposure, suspicious access, probable acquisition, suspected forgery, identity impersonation, and downstream compromise.

Elastic Coverage Disposition

Elastic provides primary SIEM correlation across the same behavioral stages when ECS-compatible or locally normalized fields preserve DKM object context, actor and source identity, process and file activity, certificate activity, AD FS issuance and authentication lineage, claims and relying-party context, user state, downstream activity, and cloud telemetry.

Elastic coverage depends on reliable index coverage, field mapping, event ordering, entity resolution, enrichment, approved-workflow baselines, and sequence construction.

Elastic detections must not promote missing issuance, unusual claims, privileged access, or cloud activity without the required corroboration and lineage validation.

QRadar Coverage Disposition

QRadar provides primary correlation across directory, endpoint, certificate, AD FS, identity, relying-party, network, application, SaaS, and cloud events when DSM parsing, custom properties, reference data, building blocks, offense rules, and temporal correlation are correctly implemented.

Coverage depends on validated DKM object mappings, identity and source normalization, certificate and artifact classifications, federation-session reconciliation, approved-workflow reference sets, and downstream cloud enrichment.

QRadar offenses must preserve the distinction between suspicious identity-infrastructure activity and confirmed signing-key or forged-token compromise.

SIGMA Coverage Disposition

SIGMA provides portable event-rule and temporal-ordered correlation coverage for validated AD FS DKM access, probable key-material handling, federation acceptance without expected lineage, and qualifying downstream activity.

SIGMA is useful for traceability and backend translation but should not be treated as a complete backend-independent identity and session correlation system.

The target backend must implement local field creation, enrichment, typed actor and source keys, reconciled federation-session keys, event ordering, time windows, duplicate suppression, approved-workflow evaluation, lineage-completeness validation, and downstream correlation.

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the governing detection model is based on Active Directory object access, DKM control changes, certificate and key handling, federation issuance and authentication lineage, claims consistency, relying-party acceptance, identity use, administrative behavior, and downstream cloud or application activity rather than stable malicious file content.

YARA may provide limited investigative value only if responders recover a validated script, export utility, archive, tooling artifact, encoded payload, configuration artifact, credential artifact, certificate-theft artifact, token-construction artifact, or other reusable file or memory pattern independently linked to the incident.

Final YARA Outcome

No YARA rules survive.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not independently prove that DKM access resulted in key retrieval, that token-signing private-key recovery succeeded, that a token was forged, that a relying party accepted an illegitimately generated token, or that downstream activity resulted from signing-key compromise.

Coverage Weakens Under the Following Conditions

·        Active Directory object-access auditing is not enabled for the validated AD FS DKM container

·        DKM object identity, distinguished name, object GUID, ownership, inheritance, permissions, or auditing configuration is not validated

·        AD FS administrative, authentication, issuance, claims, trust, certificate, or configuration telemetry is unavailable, incomplete, delayed, rotated, or not ingested from every relevant farm node

·        Relying parties do not retain issuer, audience, subject, claims, assertion identifiers, session identifiers, certificate metadata, source, device, application, or result context

·        Raw federation assertions cannot be retained and normalized token metadata is incomplete

·        MFA, Kerberos, password-validation, VPN, privileged-access, device, and upstream authentication telemetry cannot be reconciled

·        Active Directory, AD FS, Entra ID, SaaS, VPN, AWS, Azure, GCP, and application systems use inconsistent identity or session identifiers

·        Endpoint telemetry is unavailable from domain controllers, AD FS servers, administrative workstations, backup systems, recovery systems, identity-management hosts, certificate-management systems, or suspected source hosts

·        Process creation, command line, parent process, remote-session, file, Registry, certificate, backup, archive, staging, transfer, and process-linked network telemetry is unavailable

·        Direct cryptographic API, private-key-operation, memory, or hardware-backed key telemetry is unavailable

·        Private-key recovery or token construction occurs offline on an unmonitored system

·        DKM material is obtained through backup media, recovery packages, directory exports, compromised administrators, or management platforms without a distinctive endpoint event

·        Federation access occurs days or weeks after the original DKM access and retention windows are insufficient

·        Applications create long-lived local sessions after accepting a federation token

·        Source attribution is obscured by VPN, proxy, NAT, browser, mobile, partner, cloud-hosting, residential-proxy, or corporate infrastructure

·        Approved certificate rollover, recovery, backup, migration, disaster-recovery testing, service-account maintenance, claims-rule change, federation testing, emergency administration, or incident response is not accurately modeled

·        Approved administrative tools, backup systems, management platforms, or privileged identities are excluded rather than behaviorally evaluated

·        AWS canonical session-binding context is incomplete or relies only on non-session-specific identifiers

·        Azure federation acceptance, normalized federated identity, activity, finding, lineage, and approved-workflow fields are incomplete

·        Google Cloud organization, normalized federated identity, activity, finding, lineage, and approved-workflow fields are incomplete

·        Defender for Cloud, Sentinel, GuardDuty, Security Hub, or Security Command Center findings cannot be tied to the originating federated identity or session

·        Downstream cloud, SaaS, VPN, application, administrative, or data-access activity cannot be linked to anomalous AD FS-federated access

·        Adversary activity blends into expected administrative, backup, recovery, certificate-management, migration, partner-access, managed-service, security-testing, monitoring, or incident-response workflows

·        The attacker uses a common identity, familiar device, trusted source path, normal business hours, expected application, ordinary claims, or low-volume activity

·        Patching, DKM permission hardening, certificate rollover, or ordinary account remediation occurs after exposure but historical access cannot be reconstructed

·        A clean AD FS host review is treated as proof that DKM theft, offline key recovery, or forged-token use did not occur

·        Vulnerable-state findings, public exploitation reporting, proof-of-concept availability, KEV status, scanner findings, or CVE references are treated as compromise evidence without local behavioral support

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across unusual identity-infrastructure administrative access, validated DKM access, DKM control changes, probable federation signing-key-material handling, anomalous federation acceptance without expected issuance or authentication lineage, identity-inconsistent claims, trusted identity impersonation, privileged or sensitive downstream activity, multi-application federation abuse, and supporting AWS, Azure, and Google Cloud activity.

Coverage is strongest where validated DKM object auditing, endpoint process and file telemetry, certificate and backup telemetry, AD FS issuance and authentication telemetry, relying-party logs, identity and entitlement context, network telemetry, cloud audit logs, approved-workflow records, and time-bounded SIEM correlation are available.

The rule set intentionally avoids treating CVE status, vulnerable versions, permissive DKM access controls, valid token signatures, missing issuance events, unusual claims, privileged identities, rare sources, cloud sign-ins, static commands, fixed paths, certificate thumbprints, file hashes, scanner results, campaign names, actor names, or any other isolated indicator as proof of compromise.

Detection confidence depends on correlating validated DKM activity, probable signing-material handling, authentication and issuance lineage, token and claims context, represented identity state, relying-party acceptance, downstream administrative or sensitive activity, and cloud behavior while preserving the distinction between exposure, suspicious access, probable acquisition, suspected forgery, trusted identity impersonation, and downstream compromise.

S27 — Behavior & Log Artifacts

Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, and validation for unusual identity-infrastructure administrative access, validated AD FS Distributed Key Manager access, DKM control changes, probable federation signing-key-material handling, suspicious certificate or recovery-artifact activity, anomalous federation acceptance without expected issuance or authentication lineage, identity-inconsistent claims, trusted identity impersonation, privileged downstream activity, multi-application federation abuse, and supporting AWS, Azure, and GCP activity.

The artifacts below are behavior-led. They should not be treated as proof of signing-key theft, successful private-key recovery, forged-token creation, illegitimate relying-party acceptance, identity impersonation, downstream compromise, or data theft unless they are correlated into a coherent sequence.

Primary Artifact Categories

·        Identity-infrastructure administrative-access and network-path artifacts

·        Active Directory DKM object-access and directory-control-change artifacts

·        Certificate, private-key, backup, recovery, archive, staging, export, and transfer artifacts

·        AD FS authentication, token-issuance, relying-party trust, claims, certificate, and configuration artifacts

·        Relying-party federation-acceptance, session, claims, identity, application, and entitlement artifacts

·        Dormant, disabled, terminated, service, emergency, executive, administrative, and high-value identity-use artifacts

·        Privileged, credential-related, persistent, security-control, logging, application-administration, and sensitive-access artifacts

·        Multi-relying-party, multi-application, multi-session, source-cluster, identity-cluster, and claims-cluster artifacts

·        Supporting AWS, Azure, and Google Cloud activity artifacts following suspicious AD FS-federated access

·        Actor, source, host, process, DKM object, certificate object, session, assertion, relying party, cloud identity, resource, and timestamp correlation artifacts

Identity-Infrastructure Administrative-Access and Network Artifacts

Relevant Artifacts

Protected identity-infrastructure asset, AD FS server, domain controller, backup server, recovery server, identity-management platform, certificate-management system, privileged administrative workstation, source host, destination host, source IP, destination IP, source ASN, source geography, protocol, destination port, administrative protocol, directory protocol, remote-session type, first-seen source-to-asset relationship, rare source, unusual timing, unusual transfer volume, repeated callback behavior, destination reputation, destination first-seen status, destination domain age, outbound destination, proxy action, firewall action, DNS query, network flow, process-linked connection, asset criticality, and event timestamp.

Useful Log Sources

·        NDR / Network Behavioral Analytics telemetry

·        Firewall logs

·        Proxy logs

·        DNS logs

·        VPN logs

·        Remote-access logs

·        Active Directory logs

·        AD FS logs

·        Windows event logs

·        Endpoint and EDR network telemetry

·        SentinelOne telemetry

·        NetFlow or equivalent flow telemetry

·        Asset inventory

·        Identity-infrastructure inventory

·        Administrative-path inventory

·        SIEM-normalized network telemetry

Detection Use

These artifacts support detection when unusual administrative or directory-protocol access to protected identity infrastructure is followed by rare, newly observed, unapproved, or high-risk outbound communication.

They are strongest when joined to validated DKM access, suspicious directory-query activity, certificate or recovery tooling, archive creation, staging, transfer behavior, AD FS changes, relying-party anomalies, or downstream cloud activity.

Investigation Use

Investigators should determine whether the access is expected for the source host, destination asset, administrator, service account, remote-session type, protocol, business process, backup workflow, recovery workflow, certificate-management workflow, migration, vendor support, monitoring, deployment, maintenance, disaster-recovery testing, vulnerability validation, security testing, or incident response.

They should also determine whether the activity was followed by DKM access, DKM control change, certificate or private-key interaction, backup or recovery activity, archive creation, transfer behavior, federation anomalies, claims inconsistency, privileged downstream activity, or supporting AWS, Azure, or Google Cloud behavior.

Non-Coverage Conditions

Administrative access alone is not sufficient.

LDAP, LDAPS, SMB, RPC, WinRM, RDP, HTTPS management, or another protocol alone is not sufficient.

Rare egress alone is not sufficient.

A newly observed source or destination alone is not sufficient.

Destination reputation alone is not sufficient.

These artifacts require protected-asset mapping, administrative-path context, source or destination continuity, bounded event ordering, behavioral deviation, or corroborating directory, endpoint, certificate, AD FS, relying-party, identity, or cloud evidence.

Validated AD FS DKM Access and Directory-Control Artifacts

Relevant Artifacts

DKM container distinguished name, DKM object GUID, associated key-object identifier, directory object class, actor identity, normalized actor identity, source host, source IP, process identity, remote-session identity, access-mask value, requested access right, read-property event, read-control event, object-open event, object-access event, operation outcome, object ownership, discretionary access control list, system access control list, access-control entry, inheritance setting, auditing setting, permission change, ownership change, inheritance change, auditing change, directory-change event, approved-workflow identifier, and event timestamp.

Useful Log Sources

·        Active Directory object-access auditing

·        Directory Service Access events

·        Directory Service Changes events

·        Domain-controller security logs

·        Windows event logs

·        AD FS administrative logs

·        AD FS configuration records

·        PowerShell logs

·        Remote-administration logs

·        Endpoint and EDR telemetry

·        SentinelOne telemetry

·        Identity-management platform logs

·        Privileged-access management logs

·        Change-management records

·        SIEM-normalized directory telemetry

Detection Use

These artifacts support detection when a validated AD FS DKM container or associated key object is accessed by an unexpected account, host, process, service, remote session, or administrative path.

They also support detection when permissions, ownership, inheritance, or auditing affecting the DKM container change outside an approved workflow.

Investigation Use

Investigators should confirm the exact DKM object, object GUID, distinguished name, associated key objects, actor identity, source host, process context, remote-session context, requested access right, event outcome, and approved-workflow state.

They should determine whether the access or control change aligns with AD FS deployment, certificate rollover, recovery, migration, backup, disaster-recovery testing, identity-platform maintenance, security testing, emergency administration, or incident response.

Non-Coverage Conditions

A permissive DKM access-control list is not sufficient.

Routine Active Directory object access is not sufficient.

Directory access unrelated to the validated DKM object is not sufficient.

A privileged actor accessing the DKM object is not automatically benign or malicious.

Directory auditing may establish that access occurred without proving which cryptographic material was retrieved or whether private-key recovery succeeded.

Federation Signing-Key, Certificate, Backup, Recovery, and Staging Artifacts

Relevant Artifacts

Certificate-store enumeration, certificate object, certificate thumbprint, certificate subject, certificate issuer, certificate serial number, certificate private-key association, private-key access, private-key permission change, certificate export, Personal Information Exchange file creation, recovery-package access, AD FS configuration export, backup-file access, backup restoration, archive creation, archive path, archive format, temporary staging directory, file creation, file read, file copy, file rename, file deletion, file transfer, removable-media use, network-share use, PowerShell activity, certificate utility use, backup utility use, recovery utility use, archive utility use, transfer utility use, process name, command line, parent process, process user, process integrity, remote-session context, destination, and event timestamp.

Useful Log Sources

·        SentinelOne endpoint telemetry

·        Windows process-creation logs

·        PowerShell logs

·        Certificate Services logs

·        CAPI2 or equivalent certificate telemetry

·        File-system auditing

·        File-integrity monitoring

·        Backup-platform logs

·        Recovery-platform logs

·        AD FS administrative logs

·        Windows event logs

·        EDR network telemetry

·        Proxy logs

·        Firewall logs

·        DNS logs

·        SIEM-normalized process, file, certificate, backup, and recovery telemetry

Detection Use

These artifacts support detection when suspicious DKM access or identity-infrastructure activity is followed by probable signing-key-material discovery, certificate interaction, private-key handling, recovery-package access, backup activity, export, archive creation, staging, transfer, or process-linked egress.

Investigation Use

Investigators should determine whether certificate, private-key, backup, recovery, archive, staging, export, or transfer activity is expected for the actor, host, process, AD FS farm, certificate lifecycle, backup workflow, recovery workflow, migration, federation deployment, disaster-recovery testing, security testing, or incident-response activity.

They should also determine whether the activity is tied to validated DKM access, unusual administrative access, unapproved process lineage, abnormal remote-session context, suspicious destination behavior, later federation anomalies, or downstream privileged activity.

Non-Coverage Conditions

Certificate enumeration alone is not sufficient.

Certificate access alone is not sufficient.

Backup activity alone is not sufficient.

Recovery-package access alone is not sufficient.

Archive creation alone is not sufficient.

A certificate-export file alone is not sufficient.

These artifacts require suspicious identity-infrastructure context, validated DKM access, unusual actor or source context, anomalous process lineage, sensitive artifact classification, workflow deviation, transfer behavior, or corroborating AD FS or relying-party evidence.

Endpoint telemetry can identify probable key-material handling but cannot independently prove successful signing-key recovery.

AD FS Authentication, Issuance, Trust, and Configuration Artifacts

Relevant Artifacts

AD FS farm node, federation service name, relying-party trust, claims-provider trust, issuer, audience, subject, NameID, authentication method, authentication context, token type, token-signing certificate, certificate thumbprint, certificate rollover state, primary certificate, secondary certificate, issuance timestamp, assertion identifier, activity identifier, correlation identifier, authentication event, token-issuance event, issuance success, issuance failure, claims-rule change, relying-party change, trust change, certificate addition, certificate replacement, certificate promotion, certificate rollover, private-key permission change, service-account activity, configuration change, logging change, farm-node health, failover state, and event timestamp.

Useful Log Sources

·        AD FS administrative logs

·        AD FS authentication logs

·        AD FS token-issuance logs

·        AD FS tracing where locally enabled

·        Windows event logs

·        Active Directory logs

·        Certificate-management logs

·        PowerShell logs

·        Change-management records

·        Federation configuration backups

·        Relying-party configuration records

·        SIEM-normalized AD FS telemetry

Detection Use

These artifacts support detection when expected authentication or issuance lineage is missing, certificate or trust configuration changes unexpectedly, claims-rule changes occur outside an approved workflow, or federation acceptance cannot be reconciled with the monitored AD FS farm.

Investigation Use

Investigators should validate logging coverage across all farm nodes, failover state, retention, timestamp alignment, trusted issuer, relying-party architecture, certificate lifecycle, recent claims-rule changes, relying-party changes, trust changes, certificate rollover, service-account maintenance, migration, recovery, and emergency administration.

Non-Coverage Conditions

A missing AD FS issuance event alone is not sufficient.

A missing authentication event alone is not sufficient.

A certificate rollover event alone is not sufficient.

A trust or claims-rule change alone is not sufficient.

Unavailable telemetry cannot be treated as confirmed missing lineage.

A valid token signature does not prove legitimate AD FS issuance.

Relying-Party Federation-Acceptance and Claims Artifacts

Relevant Artifacts

Relying-party application, SaaS platform, VPN, administrative application, cloud service, federation issuer, audience, subject, NameID, assertion identifier, session identifier, application-session identifier, token lifetime, authentication method, authentication strength, MFA context, role claim, group claim, entitlement claim, privileged claim, custom claim, claims-rule version, represented identity, normalized identity, source IP, source ASN, source geography, device ID, device state, user agent, application ID, result, acceptance timestamp, session creation, local-session creation, session refresh, and downstream event timestamp.

Useful Log Sources

·        Relying-party application logs

·        SaaS audit logs

·        VPN authentication logs

·        Web access logs

·        Identity-provider logs

·        Entra ID sign-in logs

·        Application audit logs

·        Privileged-access platform logs

·        MFA logs

·        Kerberos logs

·        Password-validation logs

·        Device-management logs

·        Cloud audit logs

·        SIEM-normalized federation and application telemetry

Detection Use

These artifacts support detection when a relying party accepts federation access from a monitored AD FS trust but expected issuance or authentication lineage cannot be found after telemetry completeness has been validated.

They also support detection when accepted claims, roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or entitlements are inconsistent with the represented identity or relying-party policy.

Investigation Use

Investigators should determine whether the issuer, audience, subject, NameID, claims, authentication method, session identifiers, source, device, application, represented identity, and token lifetime align with the current relying-party configuration and authoritative identity state.

They should compare the acceptance event with AD FS issuance, upstream authentication, MFA, Kerberos, password validation, VPN, device, identity, entitlement, and approved-workflow records.

Non-Coverage Conditions

A successful federation acceptance alone is not sufficient.

A missing issuance event alone is not sufficient.

A privileged claim alone is not sufficient.

An unusual claim alone is not sufficient.

A long token lifetime alone is not sufficient.

A rare source, device, application, location, or user agent alone is not sufficient.

These artifacts require completed lineage evaluation, validated telemetry coverage, trusted-issuer validation, relying-party policy comparison, authoritative identity-state comparison, and an independent claims, identity, source, device, key-compromise, or downstream-behavior signal.

Identity-State and Trusted Identity Impersonation Artifacts

Relevant Artifacts

User account state, enabled state, disabled state, terminated state, dormant state, last interactive use, last federation use, service-account designation, emergency-account designation, executive identity, administrative identity, high-value identity, group membership, privileged-role membership, application entitlement, access-policy state, HR termination state, identity-governance state, password change, credential reset, MFA registration, device registration, source familiarity, application familiarity, normal access schedule, normal source geography, normal device profile, and event timestamp.

Useful Log Sources

·        Active Directory

·        Identity-governance platforms

·        HR identity feeds

·        Privileged-access management platforms

·        Entra ID

·        MFA providers

·        Device-management platforms

·        Application entitlement systems

·        SaaS administration logs

·        VPN logs

·        SIEM identity-enrichment data

Detection Use

These artifacts support detection when federation activity represents a dormant, disabled, terminated, service, emergency, executive, administrative, or otherwise high-value identity without expected operational context.

They also support detection when claims or downstream activity conflict with current identity state, entitlement, application use, device state, source history, or access policy.

Investigation Use

Investigators should validate the represented identity’s current employment state, account state, privileged role, application entitlement, normal source, normal device, normal access schedule, recent access changes, emergency-access approval, service-account purpose, and federation-use history.

Non-Coverage Conditions

Use of a high-value identity alone is not sufficient.

Use of a dormant, disabled, terminated, service, or emergency identity alone is not sufficient.

A new source or device alone is not sufficient.

These artifacts require federation-session context, claims context, lineage evaluation, relying-party context, authoritative identity state, approved-workflow validation, or qualifying downstream behavior.

Privileged and Sensitive Downstream Activity Artifacts

Relevant Artifacts

Administrative action, role assignment, privilege grant, credential creation, access-key creation, service-principal creation, managed-identity activity, service-account credential activity, persistence action, logging change, diagnostic-setting change, security-control change, policy modification, identity-provider change, application configuration change, sensitive data access, secret access, key-management activity, storage access, export activity, snapshot creation, image export, lateral expansion, group membership change, administrator creation, API token creation, application-consent change, and event timestamp.

Useful Log Sources

·        Application audit logs

·        SaaS audit logs

·        VPN logs

·        Privileged-access management logs

·        Active Directory logs

·        Entra ID audit logs

·        AWS CloudTrail

·        Azure Activity logs

·        Google Cloud Audit Logs

·        Security-alerting platforms

·        SIEM-normalized administrative and sensitive-access telemetry

Detection Use

These artifacts support detection when suspicious federation acceptance is followed by privileged administration, credential creation, persistence, logging degradation, security-control change, application administration, sensitive data access, or lateral expansion.

Investigation Use

Investigators should determine whether the activity aligns with the same federated session, represented identity, normalized identity, application, source, device, cloud identity, account, tenant, subscription, organization, project, or resource context.

They should determine whether the activity is expected for approved administration, automation, infrastructure as code, CI/CD, managed service, emergency access, security tooling, deployment, maintenance, or incident response.

Non-Coverage Conditions

Privileged activity alone is not sufficient.

Sensitive data access alone is not sufficient.

Role assignment alone is not sufficient.

Credential creation alone is not sufficient.

Logging or security-control change alone is not sufficient.

Persistence activity alone is not sufficient.

These artifacts require reliable linkage to suspicious AD FS-federated access, completed lineage evaluation or prior key-compromise evidence, qualifying downstream behavior, and approved-workflow evaluation.

Multi-Relying-Party and Multi-Application Federation Artifacts

Relevant Artifacts

Related relying-party count, related application count, related cloud-environment count, represented identity, normalized federated identity, assertion identifier, session identifier, application-session identifier, issuer, audience, claims pattern, role pattern, group pattern, token lifetime, authentication method, source IP, source ASN, source geography, device ID, user agent, timing pattern, downstream behavior, and event timestamp.

Useful Log Sources

·        AD FS logs

·        Relying-party logs

·        SaaS audit logs

·        VPN logs

·        AWS audit logs

·        Azure audit logs

·        Google Cloud audit logs

·        Application logs

·        Identity analytics

·        NDR telemetry

·        SIEM correlation data

Detection Use

These artifacts support detection when the same represented identity, claims pattern, assertion identifier, session identifier, normalized federated identity, source infrastructure, device, or behavioral sequence appears across multiple relying parties, applications, cloud services, VPNs, or administrative systems within a bounded time window.

Investigation Use

Investigators should determine whether the activity reflects expected cross-application use, corporate VPN behavior, partner federation, administrative workflows, shared device use, shared proxy infrastructure, managed-service activity, identity synchronization, or legitimate cloud administration.

Non-Coverage Conditions

Use of multiple applications alone is not sufficient.

A shared source IP alone is not sufficient.

A repeated user agent alone is not sufficient.

A shared represented identity alone is not sufficient.

These artifacts require reliable identity, assertion, session, issuer, audience, application, source, device, claims, time-window, or prior key-compromise linkage.

AWS Federation and Cloud-Activity Artifacts

Relevant Artifacts

AWS account ID, canonical session-binding key, SAML provider, role ARN, principal ARN, assumed-role session, source identity, principal ID, federated subject, role-session name, source IP, user agent, region, event name, IAM action, STS action, access-key creation, policy change, Secrets Manager access, KMS activity, S3 access, CloudTrail change, logging change, GuardDuty finding, Security Hub finding, AWS Config event, Organizations event, resource ARN, session acceptance time, and event timestamp.

Useful Log Sources

·        AWS CloudTrail management events

·        AWS CloudTrail data events

·        AWS IAM and STS telemetry

·        IAM Identity Center logs

·        GuardDuty

·        Security Hub

·        AWS Config

·        AWS Organizations logs

·        VPC Flow Logs

·        Route 53 Resolver logs

·        Secrets Manager logs

·        KMS logs

·        S3 access logs

·        SIEM-normalized AWS telemetry

·        SIEM-forwarded AD FS federation context

Detection Use

These artifacts support AWS detection only when suspicious AD FS-federated access can be joined to qualifying privileged, credential-related, persistent, logging, identity-provider, security-control, or sensitive administrative AWS activity.

Investigation Use

Investigators should validate the AWS account, canonical session-binding key, federated subject, role, principal, source, region, event ordering, resource, and relationship to the originating AD FS federation acceptance.

They should determine whether the activity aligns with approved administration, automation, CI/CD, infrastructure as code, managed-service access, security tooling, break-glass use, or incident response.

Non-Coverage Conditions

AWS activity alone is not sufficient.

Role assumption alone is not sufficient.

AWS console access alone is not sufficient.

IAM activity alone is not sufficient.

A role ARN, federated subject, source identity, principal ID, account, source IP, region, user agent, or role-session name must not independently form the session-binding key.

AWS telemetry does not independently prove that a SAML assertion was forged.

Azure Federation and Cloud-Activity Artifacts

Relevant Artifacts

Tenant ID, subscription ID, normalized federated identity, federation acceptance identifier, federation acceptance time, source-qualified record identifier, Entra sign-in event, Entra audit event, Azure Activity event, Azure Resource Manager operation, role assignment, service-principal activity, managed-identity activity, Key Vault access, Storage access, logging change, diagnostic-setting change, security-control change, Defender for Cloud finding, Sentinel finding, resource ID, application ID, source IP, user agent, approved-workflow state, and event timestamp.

Useful Log Sources

·        Microsoft Entra ID sign-in logs

·        Microsoft Entra ID audit logs

·        Azure Activity logs

·        Azure Resource Manager events

·        Key Vault logs

·        Storage logs

·        Defender for Cloud

·        Microsoft Sentinel

·        Azure Policy logs

·        Diagnostic-setting logs

·        SIEM-normalized Azure telemetry

·        SIEM-forwarded AD FS federation context

Detection Use

These artifacts support Azure detection only when suspicious AD FS-federated access can be joined to qualifying privileged, credential-related, persistent, security-control, logging, identity-provider, or sensitive administrative Azure activity or an identity-linked Defender for Cloud or Sentinel finding.

Investigation Use

Investigators should validate the tenant, subscription, normalized federated identity, federation acceptance, source-qualified Azure record, resource, operation, finding, event ordering, and approved-workflow context.

Each Azure activity or finding record should be associated with the most recent qualifying federation acceptance preceding that record after all required activity, finding, lineage, corroboration, mandatory-review, and workflow conditions have been applied.

Non-Coverage Conditions

Azure activity alone is not sufficient.

Azure portal access alone is not sufficient.

Entra sign-in activity alone is not sufficient.

Role assignment alone is not sufficient.

A Defender for Cloud or Sentinel finding without federated-identity enrichment is not sufficient.

Azure telemetry does not independently prove that a SAML assertion was forged.

GCP Federation and Cloud-Activity Artifacts

Relevant Artifacts

Organization ID, folder ID, project ID, normalized federated identity, federation acceptance identifier, federation acceptance time, source-qualified record identifier, Admin Activity event, Data Access event, IAM policy change, role change, service-account activity, service-account credential activity, workforce identity federation activity, workload identity federation activity, Secret Manager access, Cloud KMS activity, Cloud Storage access, logging change, Security Command Center finding, resource name, principal email, service-account ID, source IP, user agent, approved-workflow state, and event timestamp.

Useful Log Sources

·        Google Cloud Admin Activity audit logs

·        Google Cloud Data Access audit logs

·        Google Cloud IAM logs

·        Service-account logs

·        Cloud Identity logs

·        Secret Manager logs

·        Cloud KMS logs

·        Cloud Storage logs

·        Security Command Center

·        Chronicle or SIEM-normalized Google Cloud telemetry

·        SIEM-forwarded AD FS federation context

Detection Use

These artifacts support Google Cloud detection only when suspicious AD FS-federated access can be joined to qualifying privileged, persistent, credential-related, security-control, logging, IAM, service-account, or sensitive administrative Google Cloud activity or an identity-linked Security Command Center finding.

Investigation Use

Investigators should validate the organization, project, normalized federated identity, federation acceptance, source-qualified activity or finding record, resource, method, event ordering, and approved-workflow context.

Each Google Cloud activity or finding record should be associated with the most recent qualifying federation acceptance preceding that record through the same organization and normalized federated identity context.

Non-Coverage Conditions

Google Cloud activity alone is not sufficient.

Google Cloud console access alone is not sufficient.

Service-account activity alone is not sufficient.

Cloud Storage, Secret Manager, or Cloud KMS access alone is not sufficient.

A Security Command Center finding without federated-identity enrichment is not sufficient.

Google Cloud telemetry does not independently prove that a SAML assertion was forged.

YARA Artifact Disposition

YARA has no deployable primary-rule artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report’s detection surface is based on Active Directory object access, DKM control changes, endpoint behavior, certificate and key handling, federation issuance and authentication lineage, claims consistency, relying-party acceptance, identity state, administrative activity, and downstream cloud behavior rather than stable malicious file content.

YARA may become useful only if a validated malicious script, export utility, archive, token-construction artifact, certificate-theft artifact, credential artifact, encoded payload, memory artifact, configuration artifact, or reusable tooling artifact is recovered and independently linked to the incident.

Final YARA Outcome

No YARA rules survive.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

This section provides implementation guidance for operationalizing the S25 rule set and S26 traceability model across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, Active Directory, AD FS, endpoint, EDR, certificate-management, backup, recovery, relying-party, SaaS, VPN, identity, cloud, SIEM, SOAR, and incident-response environments.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating a single CVE identifier, vulnerable-version observation, DKM path, certificate thumbprint, command string, file path, source IP, user agent, token value, missing event, unusual claim, privileged identity, cloud event, scanner finding, or static indicator as proof of compromise.

Implementation Strategy

Deploy the detection model in layered stages:

·        Identity-infrastructure asset, AD FS farm, domain-controller, backup, recovery, certificate-management, administrative workstation, exposure, ownership, and business-criticality context first

·        DKM object identity, distinguished name, object GUID, associated key object, permissions, ownership, inheritance, auditing, actor, source, process, remote-session, and access-right context second

·        Endpoint process, command-line, parent-process, remote-administration, certificate, backup, recovery, archive, staging, export, transfer, file, and process-linked network context third

·        AD FS authentication, issuance, trust, claims, certificate, configuration, farm-node, failover, and telemetry-completeness context fourth

·        Relying-party issuer, audience, subject, NameID, assertion, session, application, claims, source, device, acceptance, and local-session context fifth

·        Authoritative identity state, group membership, role entitlement, application entitlement, account state, HR state, privileged status, normal source, normal device, and access-policy context sixth

·        Privileged application, SaaS, VPN, administrative, credential-related, persistent, security-control, logging, sensitive-access, and multi-application correlation seventh

·        Supporting AWS, Azure, and Google Cloud federation and downstream activity correlation eighth

·        Alert promotion only after local telemetry validation, false-positive baselining, suppression governance, query validation, and triage-playbook alignment

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across Active Directory, AD FS, endpoint, EDR, certificate-management, backup, recovery, remote-administration, NDR, DNS, proxy, firewall, VPN, MFA, Kerberos, password-validation, relying-party, SaaS, application, identity-governance, HR, AWS, Azure, Google Cloud, SOAR, incident-response, and SIEM telemetry.

Minimum Normalization Requirements

·        Identity-infrastructure asset ID

·        Asset role

·        Asset criticality

·        AD FS farm ID

·        AD FS farm node

·        Federation service name

·        Domain-controller ID

·        Administrative workstation ID

·        Backup-system ID

·        Recovery-system ID

·        Certificate-management system ID

·        DKM distinguished name

·        DKM object GUID

·        DKM key-object identifier

·        DKM ownership

·        DKM permissions

·        DKM inheritance state

·        DKM auditing state

·        Directory actor identity

·        Normalized actor identity

·        Source host

·        Source IP

·        Source ASN

·        Source geography

·        Process ID

·        Process name

·        Parent process

·        Process user

·        Command line

·        Remote-session identifier

·        Requested access right

·        Directory operation

·        Directory event outcome

·        Certificate thumbprint

·        Certificate subject

·        Certificate issuer

·        Certificate serial number

·        Certificate private-key indicator

·        Certificate action

·        Private-key action

·        Backup action

·        Recovery action

·        Archive action

·        Export action

·        Staging action

·        Transfer action

·        File path

·        File name

·        File classification

·        Destination domain

·        Destination IP

·        Destination port

·        Destination reputation

·        Destination first-seen state

·        Proxy action

·        Firewall action

·        AD FS relying-party trust

·        Claims-provider trust

·        Issuer

·        Audience

·        Subject

·        NameID

·        Assertion identifier

·        Federation-session identifier

·        Application-session identifier

·        Authentication method

·        Authentication context

·        MFA state

·        Issuance event

·        Authentication event

·        Federation acceptance event

·        Issuance-lineage status

·        Authentication-lineage status

·        Telemetry-completeness state

·        Role claim

·        Group claim

·        Entitlement claim

·        Privileged claim

·        Token lifetime

·        Represented identity

·        Normalized federated identity

·        Account state

·        Employment state

·        Privileged-identity state

·        High-value-identity state

·        Group membership

·        Role entitlement

·        Application entitlement

·        Device ID

·        Device state

·        User agent

·        Application ID

·        Relying-party ID

·        AWS account and canonical session-binding key

·        Azure tenant, subscription, federation acceptance, normalized identity, and source-qualified record

·        GCP organization, project, federation acceptance, normalized identity, and source-qualified record

·        SOAR case ID

·        Incident-response case ID

·        Approved-workflow context

·        Event timestamp

·        Event source

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between suspicious identity-infrastructure access, DKM activity, probable signing-material handling, federation acceptance, downstream behavior, and cloud activity.

Recommended Starting Windows

·        Unusual identity-infrastructure administrative access to rare or unapproved egress within 60 minutes

·        Validated DKM access to certificate, backup, recovery, archive, staging, export, transfer, or probable key-material handling within 4 hours

·        DKM permission, ownership, inheritance, or auditing change to follow-on identity-infrastructure or federation activity within 8 hours

·        Probable signing-material handling to suspicious outbound communication within 60 minutes

·        AD FS token issuance within 5 minutes before federation acceptance and upstream authentication within 15 minutes before federation acceptance, evaluated backward from the federation-acceptance event

·        Federation acceptance without expected lineage to qualifying relying-party, application, SaaS, VPN, or administrative activity within 2 hours

·        Identity-inconsistent claims or suspicious represented-identity use to privileged, persistent, credential-related, security-control, logging, or sensitive activity within 8 hours

·        Related anomalous federation activity across multiple relying parties or applications within 8 hours

·        Suspicious AD FS-federated access to AWS, Azure, or Google Cloud qualifying activity within 24 hours

·        Continued privileged, persistent, security-control, logging, or sensitive activity after containment or federation remediation within 24 hours

These windows should be tightened in high-volume environments and extended only when actor continuity, source continuity, host continuity, DKM object lineage, process lineage, certificate or artifact lineage, federation-session continuity, identity continuity, relying-party continuity, cloud-session continuity, SOAR evidence, or incident-response evidence supports the extension.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until the following conditions are met:

·        Required telemetry is present and normalized

·        Required field mappings are validated

·        AD FS farm and farm-node inventory is reliable

·        Domain-controller and DKM object mapping is reliable

·        DKM distinguished name and object GUID are validated

·        DKM permission, ownership, inheritance, and auditing state are understood

·        Directory access-right interpretation is validated

·        Endpoint process, file, certificate, backup, recovery, archive, staging, transfer, and network mappings are reliable

·        AD FS authentication and issuance logging is validated across all relevant farm nodes

·        Relying-party architecture and trusted-issuer mappings are reliable

·        Federation-session and normalized-identity reconciliation is reliable

·        Identity-state and entitlement data is current

·        Event timing and ordering are reliable

·        Telemetry-completeness logic is validated

·        Approved workflow baselines are defined

·        False-positive sources are reviewed

·        High-volume expected workflows are suppressed or downgraded

·        AWS canonical session-binding logic is validated

·        Azure source-qualified record and federation-acceptance matching is validated

·        GCP source-qualified record and federation-acceptance matching is validated

·        Query performance is tested

·        Triage guidance is documented

·        Analyst review criteria are established

·        Local severity logic is calibrated

·        Alert-routing ownership is assigned

False-Positive Control

False-positive control should use approved-workflow baselines, scoped allowlists, reference sets, actor and source baselines, DKM access baselines, certificate lifecycle records, backup and recovery schedules, AD FS maintenance records, claims-rule change records, relying-party change records, identity-governance data, application-entitlement data, cloud automation inventories, break-glass records, managed-service records, security-tooling records, and incident-response case context.

Common False-Positive Sources

·        Approved AD FS administration

·        Approved Active Directory administration

·        Approved DKM access

·        Approved DKM permission review

·        Approved DKM ownership or auditing change

·        Approved certificate rollover

·        Approved certificate export

·        Approved private-key recovery

·        Approved backup activity

·        Approved disaster-recovery testing

·        Approved AD FS migration

·        Approved federation deployment

·        Approved relying-party changes

·        Approved claims-rule changes

·        Approved trust changes

·        Approved service-account maintenance

·        Approved identity synchronization

·        Approved privileged-access testing

·        Approved security testing

·        Approved vulnerability validation

·        Approved vendor support

·        Approved managed-service activity

·        Approved monitoring

·        Approved emergency administration

·        Approved incident-response collection

·        Approved cloud administration

·        Approved cloud automation

·        Infrastructure-as-code workflows

·        CI/CD workflows

·        Break-glass activity

·        Security-tooling activity

·        Approved credential rotation

·        Approved logging changes

·        Approved application administration

·        Approved role or entitlement changes

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent sequence rather than a single-event anomaly.

Triage Questions

·        Was unusual administrative or directory-protocol access observed against protected identity infrastructure

·        Was the source host, source IP, actor, process, remote session, protocol, timing, or administrative path unusual

·        Was the exact AD FS DKM container or associated key object accessed

·        Were DKM permissions, ownership, inheritance, or auditing changed

·        Was the actor expected to access or control the DKM object

·        Did directory-query, PowerShell, certificate, backup, recovery, archive, staging, export, or transfer activity occur

·        Was probable certificate or signing-key material created, accessed, exported, staged, archived, copied, or transferred

·        Did rare or unapproved outbound communication follow

·        Did an unexpected token-signing certificate addition, replacement, promotion, rollover, export, or private-key permission change occur

·        Did a relying party accept federation access without expected AD FS issuance or upstream authentication lineage

·        Was logging completeness validated across all relevant AD FS farm nodes

·        Were issuer, audience, subject, NameID, claims, authentication method, token lifetime, source, device, and application context consistent with policy

·        Did the represented identity align with current account state, employment state, group membership, role entitlement, and normal application use

·        Was the identity dormant, disabled, terminated, emergency, service, executive, administrative, or otherwise high value

·        Did privileged administration, credential creation, persistence, logging degradation, security-control change, sensitive access, or lateral expansion follow

·        Did similar federation behavior appear across multiple relying parties, applications, VPNs, SaaS platforms, or cloud environments

·        Did supporting AWS, Azure, or Google Cloud activity follow

·        Can the activity be linked by actor, source host, DKM object, process, artifact, assertion, session, represented identity, relying party, cloud session, account, tenant, subscription, organization, project, resource, SOAR case, or incident-response case

·        Is the activity explained by approved administration, certificate rollover, backup, recovery, migration, service-account maintenance, identity synchronization, partner federation, vendor support, managed service, security testing, emergency access, cloud automation, or incident response

Escalation Guidance

Escalate when multiple behavior classes align in sequence, especially when validated DKM access or DKM control change is followed by probable key-material handling, rare egress, anomalous federation acceptance, identity-inconsistent claims, trusted identity impersonation, privileged downstream activity, multi-application use, or cloud administrative behavior.

Higher-Priority Escalation Conditions

·        The validated AD FS DKM object was accessed by an unexpected actor, source host, process, or remote session

·        DKM permissions, ownership, inheritance, or auditing changed outside an approved workflow

·        DKM access and certificate, private-key, backup, recovery, archive, staging, export, or transfer activity align

·        Probable signing-material handling and rare or unapproved egress align

·        An unexpected token-signing certificate addition, replacement, promotion, rollover, export, or private-key permission change occurs

·        Federation acceptance occurs without expected issuance or authentication lineage after telemetry completeness is validated

·        Missing lineage is accompanied by claims inconsistency, identity-state inconsistency, source or device anomaly, or prior key-compromise evidence

·        A dormant, disabled, terminated, emergency, service, executive, administrative, or high-value identity is used unexpectedly

·        Suspicious federation access is followed by privileged administration, credential creation, persistence, logging degradation, security-control change, sensitive access, or lateral expansion

·        Similar anomalous federation activity appears across multiple relying parties or applications

·        AWS, Azure, or Google Cloud activity involves privileged roles, service accounts, managed identities, secrets, keys, storage, logging changes, security-control suppression, identity-provider changes, or sensitive administration

·        Multiple systems independently show aligned behavior

Deployment Guardrails

Do not deploy these detections as fully automated blocking or containment logic without local validation.

Do not treat a single CVE identifier, vulnerable version, DKM path, DKM access event, permissive access-control list, certificate thumbprint, certificate export, backup event, command string, file path, source IP, user agent, missing issuance event, unusual claim, privileged identity, cloud sign-in, cloud event, scanner finding, or static indicator as proof of compromise.

Do not attribute endpoint-only, network-only, directory-only, certificate-only, federation-only, claims-only, identity-only, application-only, or cloud-only anomalies to signing-key theft, forged-token creation, trusted identity impersonation, or downstream compromise without reliable actor, source, object, process, artifact, session, identity, relying-party, or cloud-resource lineage.

Do not enable high-confidence alerting until platform-specific schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, Active Directory fields, AD FS fields, endpoint mappings, certificate mappings, backup mappings, recovery mappings, federation-session mappings, identity mappings, cloud mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage readiness, and escalation criteria have been validated.

S29 — Detection Coverage Summary

Coverage Summary

The S25 detection set provides broad behavior-led coverage for unusual identity-infrastructure administrative access, validated AD FS DKM access, DKM control changes, probable federation signing-key-material handling, suspicious certificate or recovery-artifact activity, anomalous federation acceptance without expected issuance or authentication lineage, identity-inconsistent claims, trusted identity impersonation, privileged downstream activity, multi-application federation abuse, and supporting AWS, Azure, and Google Cloud activity.

Coverage is strongest when Active Directory object-access, AD FS authentication and issuance, endpoint, process, file, certificate, backup, recovery, remote-administration, NDR, DNS, proxy, firewall, relying-party, SaaS, VPN, identity, AWS, Azure, Google Cloud, and SIEM telemetry are normalized and correlated into bounded sequences.

The detection model intentionally avoids CVE-label-only matching, vulnerable-version-only matching, DKM-path-only matching, permissive-access-control-list conclusions, certificate-thumbprint-only matching, command-string-only matching, file-path-only matching, isolated source IPs, user-agent values, missing-event conclusions, unusual-claim-only conclusions, privileged-identity-only conclusions, cloud-event-only conclusions, scanner findings, campaign names, actor names, tool names, and other single-event conclusions.

Strong Coverage Areas

·        Unusual administrative access to protected identity infrastructure followed by rare or unapproved egress

·        Validated DKM object access by an unexpected actor, source host, process, service, remote session, or workflow

·        Permission, ownership, inheritance, or auditing changes affecting a validated DKM container

·        DKM access followed by probable certificate, private-key, backup, recovery, archive, staging, export, transfer, or key-material handling

·        Unexpected token-signing certificate addition, replacement, promotion, rollover, export, or private-key permission change

·        Federation acceptance without expected issuance or authentication lineage after telemetry completeness has been validated

·        Claims, roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or entitlements inconsistent with the represented identity or relying-party policy

·        Federated use of dormant, disabled, terminated, service, emergency, executive, administrative, or high-value identities without expected context

·        Privileged, credential-related, persistent, security-control, logging, application-administration, or sensitive activity after anomalous federation acceptance

·        Similar anomalous federation behavior across multiple relying parties, applications, sessions, or cloud environments

·        Supporting AWS, Azure, and Google Cloud activity when reliable federation, identity, session, account, tenant, subscription, organization, project, source, resource, and time-window linkage exists

Moderate Coverage Areas

·        DKM access where object-level auditing is enabled but process, source, remote-session, or access-right context is incomplete

·        Probable key-material handling where certificate, backup, recovery, archive, staging, export, or transfer telemetry is partial

·        Endpoint coverage where domain controllers, AD FS servers, administrative workstations, backup systems, recovery systems, or certificate-management hosts have incomplete telemetry

·        Federation-lineage analysis where one or more AD FS farm nodes, relying parties, authentication systems, or MFA providers have partial logging

·        Claims and identity-state analysis where entitlement, HR, device, application, or identity-governance data is incomplete

·        NDR visibility into unusual administrative access and rare egress without directory, endpoint, certificate, or AD FS enrichment

·        SIGMA portability across SIEM backends

·        AWS coverage where canonical session-binding context is incomplete

·        Azure coverage where federation acceptance, normalized federated identity, source-qualified records, finding enrichment, or approved-workflow context is partial

·        GCP coverage where organization, normalized federated identity, source-qualified records, Security Command Center enrichment, or approved-workflow context is partial

·        Multi-relying-party correlation where session identifiers or claims are transformed or unavailable across applications

Limited Coverage Areas

·        DKM access that is not audited at the object level

·        Key-material recovery performed offline on an unmonitored system

·        DKM material obtained through backup media, recovery packages, directory exports, compromised administrators, or management platforms without a distinctive endpoint event

·        Private-key operations that do not produce process, file, certificate, cryptographic API, memory, or hardware-backed key telemetry

·        Forged-token creation performed outside monitored enterprise infrastructure

·        Federation activity that occurs days or weeks after the original DKM access and exceeds retention or correlation windows

·        Relying parties that do not retain issuer, audience, subject, assertion, session, claims, source, device, certificate, or application context

·        Applications that create long-lived local sessions after initial federation acceptance

·        Attackers using familiar identities, normal claims, expected devices, trusted sources, normal business hours, and low-volume downstream activity

·        Activity that blends into approved certificate rollover, backup, recovery, migration, identity synchronization, partner federation, managed service, emergency access, security testing, cloud automation, or incident-response workflows

·        Cloud activity without reliable linkage to suspicious AD FS-federated access

·        Environments without sufficient AWS, Azure, or Google Cloud sensitive-service audit visibility

Non-Covered Areas

The S25 rule set does not directly prove:

·        Successful signing-key theft

·        Successful private-key recovery

·        Forged-token creation

·        Illegitimate token signing

·        Illegitimate relying-party acceptance

·        Trusted identity impersonation

·        Downstream application compromise

·        AWS compromise

·        Azure compromise

·        Google Cloud compromise

·        Data theft

·        Adversary attribution

·        Campaign attribution

These outcomes require investigation, corroborating telemetry, forensic evidence, and incident-specific validation.

System Coverage Summary

NDR / Network Behavioral Analytics

NDR provides one primary network-sequence rule for unusual administrative or directory-protocol access to protected identity infrastructure followed by rare or unapproved outbound communication.

NDR supplies supporting evidence for anomalous source-to-asset relationships, rare administrative paths, abnormal timing, unusual transfer volume, repeated callbacks, suspicious destinations, and identity-infrastructure-to-egress sequencing.

NDR does not independently identify the exact DKM object accessed, confirm private-key recovery, inspect encrypted token claims, prove token forgery, establish identity impersonation, or confirm downstream compromise.

SentinelOne

SentinelOne provides two primary endpoint rules for probable federation-key and identity-material discovery, export, artifact creation, archive staging, transfer, process lineage, remote-administration context, and process-linked egress.

SentinelOne is strongest where directory-query tools, PowerShell, certificate utilities, backup and recovery tooling, file activity, remote sessions, process ancestry, artifact creation, staging paths, and outbound connections can be correlated.

SentinelOne does not independently prove validated DKM object access, successful signing-key recovery, forged-token creation, relying-party acceptance, or downstream identity compromise.

Splunk

Splunk provides strong primary SIEM correlation across DKM access, DKM control changes, probable key-material handling, certificate activity, endpoint behavior, AD FS issuance and authentication lineage, relying-party acceptance, claims consistency, identity state, privileged downstream activity, multi-application behavior, and cloud correlation.

Splunk coverage depends on reliable normalization, event ordering, typed identity and session keys, telemetry-completeness state, approved-workflow context, duplicate suppression, and correct correlation windows.

Elastic

Elastic provides strong primary SIEM sequence and correlation coverage where Active Directory, AD FS, endpoint, certificate, backup, recovery, network, relying-party, identity, SaaS, VPN, AWS, Azure, and Google Cloud data are normalized into ECS-compatible or locally enriched fields.

Coverage depends on reliable EQL or equivalent sequencing, entity resolution, enrichment, transforms, value lists, exception handling, and federation-session reconciliation.

QRadar

QRadar provides strong primary correlation where DSM parsing, custom properties, reference data, building blocks, event ordering, offense grouping, and temporal correlation are validated across directory, endpoint, certificate, AD FS, relying-party, identity, application, SaaS, VPN, network, AWS, Azure, and Google Cloud telemetry.

Coverage depends on validated DKM mappings, identity and source normalization, certificate and artifact classifications, federation-session reconciliation, approved-workflow reference sets, and cloud enrichment.

SIGMA

SIGMA provides portable event-rule and temporal-ordered correlation coverage for validated DKM access, probable key-material handling, anomalous federation acceptance without expected lineage, and qualifying downstream activity.

SIGMA production value depends on field mappings, enrichment-field creation, backend translation, sequence support, correlation-key construction, event ordering, time-window implementation, duplicate suppression, and local exception handling.

YARA

YARA has zero deployable rules for this EXP report because no stable malicious file, script, export utility, archive family, token-construction artifact, certificate-theft artifact, memory artifact, or reusable tooling family is available.

AWS

AWS provides supporting downstream correlation when suspicious AD FS-federated access is joined to privileged, credential-related, persistent, logging, identity-provider, security-control, or sensitive administrative AWS activity.

Coverage depends on reliable AWS account context and a canonical session-binding key. Non-session-specific fields must not independently form the session-binding key.

AWS does not independently prove forged-token activity.

Azure

Azure provides supporting downstream correlation when suspicious AD FS-federated access is joined to privileged, credential-related, persistent, security-control, logging, identity-provider, sensitive administrative activity, or an identity-linked Defender for Cloud or Sentinel finding.

Each source-qualified Azure activity or finding record must be associated with the most recent qualifying federation acceptance preceding that record after all required filters have been applied.

Azure does not independently prove forged-token activity.

GCP

GCP provides supporting downstream correlation when suspicious AD FS-federated access is joined to privileged, persistent, credential-related, security-control, logging, IAM, service-account, sensitive administrative activity, or an identity-linked Security Command Center finding.

Each source-qualified Google Cloud activity or finding record must be associated with the most recent qualifying federation acceptance preceding that record through the same organization and normalized federated identity context.

Google Cloud does not independently prove forged-token activity.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with unusual identity-infrastructure administrative access, validated DKM access, DKM control changes, probable signing-material handling, anomalous federation acceptance, identity-inconsistent claims, trusted identity impersonation, privileged downstream activity, multi-application federation abuse, and supporting cloud behavior.

It is strongest when multiple telemetry classes align in sequence and weakest where signing-material access, private-key recovery, token construction, relying-party acceptance, or downstream use occurs without observable directory, endpoint, certificate, network, federation, identity, application, or cloud anomalies.

S30 — Intelligence Maturity Assessment

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy and moderate for direct compromise confirmation.

The detection model is mature because it focuses on durable behavioral relationships: unusual access to protected identity infrastructure, validated DKM access, DKM control change, probable signing-key-material handling, anomalous federation acceptance, missing issuance or authentication lineage, identity-inconsistent claims, trusted identity impersonation, privileged downstream behavior, multi-application federation abuse, and supporting cloud activity.

Direct compromise confirmation remains limited because enterprise telemetry generally does not expose signing-key theft, successful private-key recovery, forged-token creation, illegitimate signing, or attacker intent directly.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable behavior that can be detected across Active Directory, AD FS, endpoint, EDR, certificate-management, backup, recovery, NDR, DNS, proxy, firewall, relying-party, SaaS, VPN, identity-governance, AWS, Azure, Google Cloud, and SIEM platforms.

The behaviors are durable across CVE identifiers, exploit names, proof-of-concept names, DKM paths, certificate thumbprints, command strings, file paths, source infrastructure, user agents, scanner results, campaign names, actor names, tooling changes, and cloud-provider variation.

Strong Behavioral Anchors

·        Unusual identity-infrastructure administrative access followed by rare or unapproved egress

·        Validated DKM object access by an unexpected actor, source, process, service, remote session, or workflow

·        DKM permission, ownership, inheritance, or auditing changes outside an approved workflow

·        DKM access followed by probable certificate, private-key, backup, recovery, archive, staging, export, transfer, or key-material handling

·        Unexpected token-signing certificate addition, replacement, promotion, rollover, export, or private-key permission change

·        Federation acceptance without expected issuance or authentication lineage after telemetry completeness is validated

·        Claims, roles, groups, authentication methods, audiences, issuers, subjects, lifetimes, or entitlements inconsistent with the represented identity or relying-party policy

·        Federated use of dormant, disabled, terminated, service, emergency, executive, administrative, or high-value identities without expected context

·        Privileged, credential-related, persistent, security-control, logging, identity-provider, application-administration, or sensitive activity after anomalous federation access

·        Similar anomalous federation behavior across multiple relying parties, applications, sessions, or cloud environments

·        Supporting AWS, Azure, or Google Cloud activity following suspicious AD FS-federated access

Telemetry Maturity

Telemetry maturity is moderate to high.

Active Directory object-access auditing, AD FS authentication and issuance logs, endpoint telemetry, process and file telemetry, certificate telemetry, backup and recovery logs, relying-party logs, identity context, network telemetry, and cloud audit logs provide strong coverage where DKM object, actor, source, process, artifact, assertion, session, identity, application, resource, and timestamp fields are available and normalized.

Telemetry maturity decreases when DKM object auditing is absent, farm-node logging is incomplete, relying-party metadata is limited, session identifiers are unavailable, endpoint coverage is partial, certificate or recovery activity is not logged, identity-state data is stale, cloud findings cannot be tied to the originating federated identity, or approved-workflow baselines are weak.

Federation and Identity Maturity

Federation and identity maturity is moderate to strong.

AD FS and relying-party telemetry provide useful evidence when issuer, audience, subject, NameID, assertion, session, claims, authentication method, certificate, source, device, application, identity state, and entitlement context can be reconciled.

Maturity increases when every AD FS farm node is ingested, relying parties preserve federation metadata, upstream authentication and MFA telemetry is retained, trusted issuers and audiences are mapped, identity state is authoritative, and session or identity correlation keys are validated.

Federation telemetry does not independently prove that a token was forged. A valid signature, missing event, unusual claim, or privileged identity must not be treated as proof without corroboration.

Cloud Maturity

Cloud maturity is moderate.

AWS, Azure, and Google Cloud provide useful supporting downstream visibility when cloud activity can be joined to suspicious AD FS federation context through reliable session, identity, account, tenant, subscription, organization, project, resource, source, and event-ordering relationships.

Cloud platforms do not independently prove signing-key theft or forged-token creation.

AWS maturity depends on reliable canonical session binding.

Azure maturity depends on reliable federation-acceptance, normalized-identity, source-qualified record, finding-enrichment, and most-recent-acceptance logic.

Google Cloud maturity depends on reliable organization, normalized-identity, source-qualified record, finding-enrichment, and most-recent-acceptance logic.

Adversary-Resilience Maturity

Adversary-resilience maturity is high for behavior-led detection and moderate for high-confidence compromise attribution.

The detection model is resilient because it avoids brittle indicators and focuses on relationships an adversary may create when converting DKM or signing-material access into federation abuse, identity impersonation, privileged downstream behavior, or cloud activity.

The model is less resilient when adversaries use expected administrators, familiar source hosts, approved certificate workflows, standard backup or recovery tooling, normal business hours, ordinary claims, familiar devices, low-volume activity, approved cloud automation, or legitimate emergency-access paths.

It is also less resilient when key recovery and token construction occur offline, relying-party telemetry is incomplete, long-lived application sessions persist after token acceptance, or downstream activity is delayed beyond retention windows.

Operationalization Maturity

Operationalization maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires local validation of schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, Active Directory fields, DKM object mappings, AD FS fields, endpoint mappings, certificate mappings, backup and recovery mappings, federation-session mappings, identity mappings, cloud mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage logic, and alert-routing decisions.

Operational maturity increases when detection owners validate telemetry quality, confirm DKM object auditing, baseline approved AD FS administration, certificate rollover, backup, recovery, migration, federation testing, claims-rule changes, relying-party changes, service-account maintenance, identity synchronization, partner federation, cloud administration, automation, managed services, break-glass use, security testing, and incident-response workflows, and test the detection logic using realistic benign and suspicious event sequences.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with suspicious DKM access, probable signing-material handling, anomalous federation use, trusted identity impersonation, privileged downstream activity, and supporting cloud behavior.

It should not be used by itself to attribute activity to a specific adversary, campaign, exploit developer, infrastructure provider, malware family, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as exploitation timeline, directory logs, AD FS logs, certificate evidence, endpoint artifacts, process history, backup or recovery evidence, source infrastructure, relying-party logs, claims and session data, cloud activity, victimology, tradecraft, and external intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited direct visibility into signing-key theft

·        Limited direct visibility into successful private-key recovery

·        Limited direct visibility into forged-token creation

·        Limited direct visibility into illegitimate token signing

·        Limited direct visibility into attacker intent

·        Variable DKM object-access auditing

·        Variable directory access-right interpretation

·        Variable AD FS farm-node logging

·        Variable authentication and issuance retention

·        Variable relying-party federation metadata

·        Variable assertion and session identifier availability

·        Variable claims normalization

·        Variable identity-state and entitlement quality

·        Variable endpoint and EDR visibility on domain controllers, AD FS servers, administrative workstations, backup systems, recovery systems, and certificate-management systems

·        Variable certificate, private-key, backup, recovery, archive, staging, and transfer telemetry

·        Variable source IP and device stability

·        Variable multi-application session correlation

·        Variable AWS canonical session-binding quality

·        Variable Azure activity and finding enrichment

·        Variable Google Cloud activity and finding enrichment

·        Variable cloud data-event logging

·        Variable approved-workflow baselines

·        High false-positive potential when detections are deployed without local tuning

Maturity Improvement Priorities

Priority Improvements

·        Enable and validate object-level auditing for the AD FS DKM container and associated key objects

·        Maintain authoritative DKM distinguished name, object GUID, ownership, permissions, inheritance, and auditing records

·        Improve domain-controller, AD FS server, administrative workstation, backup, recovery, certificate-management, and identity-management endpoint coverage

·        Improve process, command-line, parent-process, remote-session, file, certificate, backup, recovery, archive, staging, transfer, and process-linked network telemetry

·        Improve AD FS administrative, authentication, issuance, claims, trust, certificate, configuration, and farm-node logging

·        Ingest all relevant AD FS farm nodes and validate retention, failover, and timestamp alignment

·        Improve relying-party issuer, audience, subject, NameID, assertion, session, claims, certificate, source, device, application, and acceptance logging

·        Improve MFA, Kerberos, password-validation, VPN, device, and upstream authentication correlation

·        Improve authoritative identity-state, HR-state, group-membership, role-entitlement, application-entitlement, and high-value-identity context

·        Improve federation-session and normalized-identity reconciliation across applications

·        Improve certificate lifecycle, certificate rollover, private-key access, backup, recovery, migration, and disaster-recovery workflow baselines

·        Improve NDR, DNS, proxy, firewall, destination reputation, destination first-seen, ASN, geography, and rare-egress normalization

·        Improve AWS canonical session-binding construction and validation

·        Improve Azure federation-acceptance, normalized-identity, source-qualified record, finding-enrichment, and approved-workflow mappings

·        Improve Google Cloud organization, normalized-identity, source-qualified record, Security Command Center enrichment, and approved-workflow mappings

·        Enable relevant cloud data-event logging for sensitive AWS, Azure, and Google Cloud services

·        Build approved-workflow baselines for AD FS administration, DKM access, certificate rollover, backup, recovery, migration, federation deployment, claims-rule change, relying-party change, service-account maintenance, identity synchronization, cloud administration, automation, managed services, break-glass use, security testing, and incident response

·        Test detection logic against realistic benign and suspicious sequences before alert promotion

Final Intelligence Maturity Assessment

The report’s intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for Active Directory, AD FS, endpoint, certificate, identity, relying-party, SIEM, and sequence correlation, moderate for AWS, Azure, and Google Cloud downstream correlation, and low to moderate for direct signing-key theft, forged-token creation, or attribution confirmation.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework that identifies suspicious identity-infrastructure access, validated DKM activity, probable signing-material handling, anomalous federation acceptance, identity-inconsistent claims, trusted identity impersonation, privileged downstream behavior, multi-application federation abuse, and supporting cloud activity.

It should not be used as a standalone proof model for successful signing-key theft, private-key recovery, forged-token creation, illegitimate token signing, trusted identity impersonation, downstream compromise, data theft, or adversary attribution without corroborating telemetry, forensic evidence, and incident-specific validation.

S31 — Telemetry Dependencies

AD FS federation signing-key exposure and forged-token trust compromise require telemetry capable of determining whether suspicious identity-infrastructure activity remained limited to vulnerable state, permissive access, enumeration, failed access, or approved administration, or progressed into unauthorized DKM access, probable signing-material acquisition, forged-token use, trusted identity impersonation, persistent access, sensitive information collection, security-control degradation, or downstream compromise. The central dependency is the ability to correlate AD FS and Active Directory inventory, DKM object state, directory auditing, endpoint activity, certificate and recovery telemetry, authentication and issuance records, relying-party acceptance, identity state, claims, session identifiers, cloud and application activity, network behavior, change-control evidence, incident-response records, and business context into one signing-material-to-trust-compromise investigation model.

AD FS, Active Directory, and Trust Inventory Context

·        Asset telemetry must identify AD FS farms, federation servers, Web Application Proxy systems, domain controllers, administrative workstations, privileged-access systems, identity-management platforms, certificate-management systems, backup systems, recovery platforms, cloud tenants, SaaS applications, VPNs, administrative portals, and other relying parties.

·        Trust telemetry must identify federation-service names, relying-party trusts, claims-provider trusts, partner relationships, token-signing certificates, token-decryption certificates, certificate roles, rollover schedules, trusted issuers, audiences, endpoints, token lifetimes, claims rules, authorization rules, and metadata-distribution dependencies.

·        Required fields include canonical asset identifier, asset role, AD FS farm identifier, farm node, federation-service name, domain, forest, DKM distinguished name, DKM object GUID, associated key-object identifier, certificate thumbprint, certificate role, certificate validity, relying-party identifier, issuer, audience, application owner, identity owner, business criticality, regulated-data exposure, cloud dependency, and remediation status where available.

·        This telemetry is required to determine which systems depend on the affected trust and whether suspected signing-material exposure could create broader enterprise authorization risk.

·        Current configuration must not replace historical state because DKM permissions, certificates, trusts, claims rules, metadata, identities, or application dependencies may have changed after suspicious activity.

DKM Object, Directory Access, and Privileged-Administration Telemetry

·        Active Directory telemetry must capture successful and failed object access, control access, permission changes, ownership changes, inheritance changes, auditing changes, delegated-right changes, group membership changes, privileged-session activity, and administrative access involving validated AD FS DKM containers and associated key objects.

·        Required fields include DKM distinguished name, object GUID, object class, accessed attribute, access right, operation, result, actor, actor SID, source host, source IP, process where available, logon identifier, remote-session context, domain controller, timestamp, and approved workflow context.

·        This telemetry is required to distinguish permissive DKM exposure from actual access and determine whether suspicious access was followed by certificate, backup, recovery, archive, staging, transfer, or private-key-related activity.

·        Directory access must be interpreted against approved AD FS installation, certificate rollover, service-account maintenance, backup, recovery, migration, disaster-recovery testing, security validation, directory administration, and incident-response workflows.

·        Historical DKM permission and auditing state must be preserved so investigators can determine whether unauthorized access existed before remediation.

Endpoint, Process, Remote-Administration, and File Telemetry

·        Endpoint telemetry must capture process creation, process ancestry, command line, executable path, user, integrity level, logon session, remote-session context, working directory, file activity, Registry activity, network connection, and timestamp.

·        Required visibility includes PowerShell, command processors, directory-query tools, certificate utilities, cryptographic utilities, backup software, recovery software, archive tools, encryption tools, transfer tools, remote-administration frameworks, management agents, and administrative consoles.

·        File telemetry must capture creation, access, export, copy, modification, rename, archive, encryption, staging, transfer, and deletion involving Personal Information Exchange files, certificate exports, recovery packages, federation configuration exports, identity backups, directory-query output, encrypted archives, and other sensitive identity artifacts.

·        Remote-administration telemetry must cover PowerShell remoting, WinRM, WMI, RDP, SMB, scheduled tasks, service control, privileged-access platforms, management agents, and administrative jump hosts.

·        This telemetry is required to connect suspicious identity-infrastructure access to probable signing-material collection or transfer.

·        Endpoint evidence must not be required to prove forged-token construction because private-key recovery and token creation may occur offline or on an unmonitored system.

Certificate, Private-Key, Backup, and Recovery Telemetry

·        Certificate telemetry must capture token-signing and token-decryption certificate enumeration, private-key permission access, export, backup, addition, replacement, promotion, rollover, deletion, store access, key-storage-provider activity, and certificate-state errors.

·        Backup and recovery telemetry must capture access to AD FS recovery packages, federation databases, directory backups, certificate backups, configuration archives, identity-management backups, restoration workflows, and recovery credentials.

·        Required fields include certificate identifier, thumbprint, subject, issuer, role, primary or secondary status, private-key availability, export status, process, actor, source system, artifact path, backup job, recovery operation, timestamp, and approved change record.

·        This telemetry is required to determine whether suspicious DKM access progressed into probable private-key acquisition or another signing-material handling path.

·        Direct private-key decryption, cryptographic API, memory, or hardware-key telemetry should be treated as high-value enrichment rather than a universal prerequisite.

·        Absence of certificate-export telemetry must not be used to rule out signing-material exposure through backups, recovery packages, directory data, or offline processing.

AD FS Authentication, Issuance, Claims, and Farm-Node Telemetry

·        AD FS telemetry must capture administrative activity, authentication, token issuance, claims processing, relying-party activity, trust changes, claim-rule changes, certificate changes, endpoint changes, service-account changes, tracing state, service state, configuration changes, and relevant faults.

·        Required fields include farm identifier, farm node, federation-service name, event type, actor, represented identity, issuer, audience, subject, NameID, authentication method, claims set, token lifetime, assertion identifier, federation-session identifier, certificate thumbprint, relying party, source IP, device context, result, and timestamp where available.

·        This telemetry is required to determine whether accepted federation access aligns with expected authentication and issuance lineage.

·        Every relevant farm node must be ingested, and failover, timestamp alignment, retention, event forwarding, and logging configuration must be validated before missing lineage is treated as suspicious.

·        Missing issuance or authentication records must not be treated as forged-token proof when telemetry completeness cannot be established.

Relying-Party, Session, Claims, and Identity-State Telemetry

·        Relying-party telemetry must capture federation acceptance, issuer, audience, subject, NameID, claims, authentication method, assertion identifier, application-session identifier, certificate thumbprint, source IP, device, application, result, local session creation, session duration, privilege, administrative action, and sensitive access where available.

·        Identity telemetry must capture authoritative account state, employment state, group membership, role entitlement, application entitlement, privileged status, service-account status, emergency-account status, normal applications, normal devices, normal sources, and historical access patterns.

·        Required session correlation should preserve assertion, federation-session, application-session, cloud-session, and normalized identity identifiers.

·        This telemetry is required to identify validly signed sessions that cannot be reconciled with expected issuance, authentication, identity state, entitlement, device, source, or application behavior.

·        Claims inconsistencies, missing MFA, impossible travel, rare sources, or high-value identity use must remain supporting evidence unless correlated with stronger lineage or compromise signals.

Cloud, SaaS, VPN, and Application Telemetry

·        Cloud telemetry must capture federated sign-ins, role assignments, credential additions, service-principal changes, application-credential changes, access-key creation, API-token creation, OAuth grants, privileged operations, logging changes, security-control changes, information-repository access, and relevant security findings.

·        SaaS, VPN, and application telemetry must capture authentication, session creation, session termination, authorization, administrative action, credential creation, role change, sensitive data access, security-control change, API activity, and persistence.

·        Required fields include cloud provider, tenant, account, subscription, organization, project, normalized federated identity, session identifier, source IP, device, application, role, operation, resource, result, timestamp, and approved workflow context.

·        AWS correlation depends on reliable canonical session binding.

·        Azure correlation depends on reliable federation-acceptance, normalized-identity, source-qualified activity, and finding enrichment.

·        Google Cloud correlation depends on reliable organization, project, normalized-identity, source-qualified activity, and Security Command Center enrichment.

·        Cloud or application activity alone cannot prove signing-key theft or forged-token creation and must be treated as downstream or supporting evidence.

Information-Repository and Sensitive-Access Telemetry

·        Information-repository telemetry should capture collection or access involving collaboration platforms, messaging platforms, SharePoint environments, code repositories, databases, document systems, backup repositories, legal systems, finance systems, HR platforms, and other sensitive data stores.

·        Required fields include represented identity, session, repository, resource, object, action, query, download, export, access volume, source, device, application, timestamp, sensitivity, and approved business context where available.

·        This telemetry is required to determine whether suspected forged federation access resulted in information collection rather than authentication alone.

·        Repository access must be tied to the suspected federation sequence through identity, session, issuer, audience, source, device, application, or bounded time window.

·        Routine user access, administration, backup, eDiscovery, reporting, migration, legal review, and approved bulk export must be available for false-positive control.

Network, DNS, Proxy, Firewall, VPN, and NDR Telemetry

·        Network telemetry must capture communication involving AD FS servers, domain controllers, administrative workstations, backup systems, recovery systems, identity-management hosts, certificate-management systems, relying parties, cloud services, SaaS applications, VPNs, and suspected source systems.

·        Outbound telemetry should identify rare destinations, newly observed domains, unapproved cloud storage, file transfer, tunneling, repeated callbacks, unusual transfer volume, email transfer, internal staging, and communication following DKM, certificate, backup, archive, or sensitive file activity.

·        Required fields include source host, source IP, source process where available, user where available, destination domain, destination IP, port, protocol, direction, timestamp, action, bytes, duration, session count, first-seen status, reputation, ASN, geography, VPN context, proxy chain, and approved destination context.

·        This telemetry is required to connect identity-infrastructure access, probable signing-material handling, later federation use, and downstream activity into one timeline.

·        Network telemetry must not be used as standalone proof of DKM access, key recovery, token forgery, or trusted identity impersonation.

Change-Control, Incident Response, Remediation, and Business Context

·        Change-control telemetry must capture approved AD FS administration, certificate rollover, backup, recovery, migration, disaster-recovery testing, service-account maintenance, trust changes, claim-rule changes, relying-party changes, identity synchronization, cloud administration, security testing, emergency access, and incident-response activity.

·        Incident-response records must capture affected farm, node, DKM object, actor, source, process, certificate, artifact, session, identity, relying party, cloud environment, application, repository, administrative action, containment step, action owner, timestamp, evidence source, validation status, and closure rationale.

·        Business context must identify federation owner, application owner, identity owner, cloud owner, data owner, regulated-data status, business criticality, partner dependency, customer dependency, outage tolerance, and recovery priority.

·        This telemetry is required to determine whether suspicious behavior was attacker-driven, administrator-driven, backup-related, recovery-related, migration-related, testing-related, emergency-related, or incident-response-related.

·        Remediation must not be considered complete until signing-material exposure, certificate trust, relying-party metadata, session state, credential persistence, privileged access, information access, security-control integrity, and post-remediation behavior have been explicitly validated.

S32 — Detection Limitations

Detection of AD FS federation signing-key exposure and forged-token trust compromise is limited by whether the organization can reconstruct the relationship between DKM exposure, unauthorized directory access, probable signing-material handling, private-key acquisition, token creation, federation acceptance, authentication and issuance lineage, represented identity, claims, relying-party access, persistent cloud changes, information collection, security-control modification, and remediation evidence. Environments that rely only on vulnerable-version status, CVE references, permissive DKM access, valid signatures, missing MFA, impossible travel, unusual claims, missing AD FS events, isolated cloud activity, or privileged application access will not have enough evidence for high-confidence compromise or impact determination.

Primary Limitations

·        Missing AD FS and Active Directory inventory may prevent identification of affected farms, nodes, domains, forests, DKM objects, certificates, administrative systems, backup systems, recovery systems, identity platforms, and relying parties.

·        Missing historical DKM permissions, ownership, inheritance, and auditing state may prevent validation of exposure before remediation.

·        Missing object-access auditing may prevent confirmation that an unauthorized principal accessed the validated DKM object.

·        Directory access records may show that an object was accessed without proving which protected material was retrieved.

·        Missing endpoint telemetry may prevent review of process ancestry, PowerShell activity, directory queries, certificate operations, backup access, archive creation, staging, transfer, and remote administration.

·        Missing certificate, private-key, backup, or recovery telemetry may prevent determination of whether probable key-material handling occurred.

·        Private-key recovery and forged-token construction may occur offline and leave no observable process or cryptographic event on an AD FS server.

·        Missing AD FS farm-node telemetry may create apparent issuance or authentication gaps.

·        Missing or inconsistent assertion, federation-session, application-session, or cloud-session identifiers may prevent reliable lineage reconstruction.

·        Relying parties may validate tokens locally and preserve little or no federation metadata.

·        Raw tokens may not be retained because of security, privacy, storage, or platform constraints.

·        Missing identity-state, HR-state, entitlement, device, source, and privileged-role data may prevent assessment of whether represented identity behavior was inconsistent.

·        Missing cloud, SaaS, VPN, application, or repository telemetry may prevent determination of downstream impact.

·        Cloud providers and relying parties may transform, omit, truncate, or normalize identity and session identifiers differently.

·        AWS canonical session binding may be incomplete or unreliable.

·        Azure federation, identity, source, and finding enrichment may be incomplete.

·        Google Cloud organization, identity, source, and Security Command Center enrichment may be incomplete.

·        Missing cloud data-event logging may prevent assessment of sensitive resource or information-repository access.

·        Missing DNS, proxy, firewall, NDR, VPN, or endpoint network telemetry may prevent review of rare egress, transfer, callback, tunneling, and source continuity.

·        Short retention may prevent reconstruction when signing-material access and token use are separated by days or weeks.

·        Poor timestamp normalization may break correlation among directory, endpoint, certificate, AD FS, relying-party, identity, cloud, application, and network telemetry.

·        Incomplete normalization of DKM object, actor, source, certificate, identity, issuer, audience, claims, session, application, resource, and business-owner fields may prevent reliable joins.

·        Missing change-control, certificate-management, backup, recovery, migration, federation testing, emergency access, security testing, and incident-response records may prevent reliable false-positive control.

Detection Boundary

·        A vulnerable or unpatched AD FS deployment is not proof of signing-key compromise.

·        A CVE match, KEV status, public exploit, proof-of-concept release, scanner finding, directory path, certificate thumbprint, token value, source IP, or actor name is not proof of compromise by itself.

·        A permissive DKM access-control condition is not proof that signing material was accessed.

·        Suspicious DKM access is not proof that private-key acquisition succeeded.

·        Certificate enumeration, export, backup, rollover, replacement, or recovery activity is not malicious without actor, source, process, workflow, and change context.

·        A valid signature does not prove legitimate AD FS issuance.

·        Missing AD FS issuance or authentication telemetry does not prove token forgery until logging coverage, farm-node ingestion, retention, failover, timestamp alignment, and relying-party behavior have been validated.

·        Missing MFA, impossible travel, unusual claims, rare sources, or privileged identity use should not be treated as forged-token proof without corroboration.

·        Cloud, SaaS, VPN, application, identity, endpoint, certificate, or network anomalies should not be attributed to signing-key compromise without DKM, signing-material, issuer, audience, session, identity, source, device, relying-party, resource, or bounded time-window linkage.

·        Persistent credentials or cloud roles should not be attributed to forged federation access without session, identity, operation, resource, and timeline correlation.

·        Information-repository access should not be attributed to forged federation access without identity, session, application, source, device, resource, or time-window linkage.

·        Legitimate certificate rollover, backup, recovery, migration, disaster-recovery testing, service-account maintenance, claims changes, federation testing, cloud administration, emergency access, security validation, and incident response can create overlapping signals.

·        Detection logic must not depend on another CyberDax alert, DRI score, TCR score, or post-alert analyst judgment as an input.

·        High-confidence conclusions should require validated multi-signal correlation across DKM access, key-material handling, federation lineage, claims, identity state, relying-party acceptance, downstream activity, and approved workflow evidence where applicable.

Operational Impact of Limitations

Detection coverage should be reduced, converted to hunt-only logic, or withheld when DKM object auditing, actor and source attribution, endpoint telemetry, certificate activity, farm-node logging, session identifiers, identity normalization, relying-party acceptance records, cloud correlation, approved-workflow baselines, or bounded sequence correlation are unavailable or unreliable. Suspicious activity may remain analytically important but unsuitable for high-confidence signing-key theft, token-forgery, identity-impersonation, persistence, information-collection, or downstream-compromise determination when the organization cannot validate the complete trust sequence.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making DKM access, signing-material handling, certificate trust, federation issuance, relying-party acceptance, represented identity use, cloud persistence, information-repository access, security-control state, and trust restoration measurable, governed, and recoverable. The objective is not only to patch AD FS or correct one DKM permission condition, but to prove that signing material is protected, suspicious access can be detected, forged-token activity can be investigated, affected trust can be replaced, and dependent applications can return safely to operation.

AD FS, DKM, and Trust Governance

·        Maintain complete inventory of AD FS farms, farm nodes, Web Application Proxy systems, domains, forests, DKM containers, associated key objects, federation-service accounts, token-signing certificates, token-decryption certificates, relying-party trusts, claims-provider trusts, partner relationships, and dependent applications.

·        Maintain authoritative DKM distinguished name, object GUID, ownership, permissions, inheritance, auditing state, authorized administrators, authorized systems, and approved access workflows.

·        Apply least privilege to DKM objects, AD FS administration, certificate management, backup, recovery, domain administration, service accounts, and identity-management platforms.

·        Remove unnecessary delegated access, broad group access, inherited rights, backup rights, replication rights, and standing privileged access capable of reaching signing material.

·        Require auditable ownership, periodic access review, exception approval, remediation closure, and emergency-change documentation.

Signing-Key and Certificate Protection

·        Protect token-signing private keys through hardware-backed key protection where supported, or through tightly controlled private-key access, export permissions, backup, recovery, and administrative workflows when software-based key storage is required.

·        Restrict certificate export, private-key access, backup, recovery-package creation, certificate-store administration, and key-storage-provider access.

·        Maintain authoritative inventories for primary, secondary, rollover, retired, and emergency signing certificates.

·        Require dual control, privileged-access workflow, change approval, session recording where feasible, and documented business justification for signing-key operations.

·        Protect certificate passwords, recovery secrets, configuration archives, identity backups, and recovery packages through encryption, access control, monitoring, and retention governance.

·        Require emergency replacement procedures that remove prior certificates from trust rather than only introducing a new certificate.

Directory and Privileged-Administration Hardening

·        Use dedicated privileged administrative workstations and time-bounded administrative access for AD FS, Active Directory, certificate-management, backup, and recovery operations.

·        Restrict remote administration to approved jump hosts, privileged-access platforms, administrative networks, and management VPN paths.

·        Require MFA and privileged-session approval where supported.

·        Baseline approved LDAP, PowerShell, certificate, backup, recovery, migration, claims-management, and federation-management workflows.

·        Alert on unexpected DKM access, permission change, ownership change, inheritance change, auditing change, backup-right use, and recently elevated account activity.

AD FS Logging and Federation-Lineage Hardening

·        Enable and validate AD FS administrative, authentication, issuance, claims, trust, certificate, configuration, service, and tracing telemetry across every relevant farm node.

·        Validate event forwarding, retention, failover behavior, timestamp synchronization, certificate history, and logging completeness.

·        Preserve issuer, audience, subject, NameID, authentication method, claims, assertion identifier, federation-session identifier, certificate thumbprint, relying party, source, device, and result where feasible.

·        Maintain expected issuance and authentication lineage baselines by identity, relying party, application, authentication method, device state, source network, claims set, issuer, audience, and time window.

·        Require relying parties to preserve sufficient federation and session metadata for investigation.

Identity, Claims, and Entitlement Hardening

·        Maintain authoritative identity-state, employment-state, group-membership, role-entitlement, application-entitlement, privileged-status, service-account, emergency-account, and dormant-account records.

·        Review and restrict claims rules that allow excessive, inherited, default, wildcard, or weakly governed privileges.

·        Validate that relying parties enforce issuer, audience, certificate, token lifetime, claims, account state, and entitlement requirements.

·        Monitor federation use by disabled, terminated, dormant, service, emergency, executive, administrative, and other high-value identities.

·        Restrict standing privileges and require time-bounded elevation for high-value applications and cloud control planes.

Cloud, SaaS, VPN, and Application Hardening

·        Reduce standing cloud roles, administrative privileges, application roles, VPN privileges, and SaaS administrative access available through AD FS federation.

·        Require strong logging for federated sign-ins, role changes, credential additions, service-principal changes, access-key creation, OAuth grants, API-token creation, application credentials, sensitive administration, and information-repository access.

·        Restrict creation of persistent cloud credentials or roles following federated access.

·        Require separate approval and monitoring for privileged cloud, backup, security, identity, developer, repository, finance, legal, HR, and regulated-data systems.

·        Ensure applications can invalidate local sessions after federation trust changes.

Session, Credential, and Persistence Hardening

·        Maintain procedures to invalidate federation, application, cloud, SaaS, VPN, API, refresh-token, and privileged sessions.

·        Rotate credentials, keys, secrets, tokens, service-principal credentials, application credentials, and access keys created or exposed during suspected forged access.

·        Review role assignments, group memberships, OAuth grants, service principals, application credentials, cloud accounts, local application accounts, and workload identities after suspected federation compromise.

·        Prevent account-level remediation from being treated as sufficient when signing material may remain exposed.

·        Require post-remediation monitoring for continued access through previously created sessions or credentials.

Security-Control and Logging Hardening

·        Protect AD FS tracing, directory auditing, event forwarding, endpoint monitoring, cloud logging, application auditing, identity-protection controls, and security-platform configuration from unauthorized change.

·        Use tamper protection, centralized policy, privileged change control, immutable or write-protected storage, health monitoring, and alerting where available.

·        Alert on confirmed control-state changes following suspicious DKM, signing-material, federation, or privileged identity activity.

·        Preserve directory, AD FS, certificate, endpoint, relying-party, identity, cloud, SaaS, VPN, application, repository, and network telemetry before remediation.

·        Validate that security and logging controls remain healthy after containment and recovery.

Incident Response and Trust-Restoration Hardening

·        Create response procedures for suspicious DKM access, probable key-material handling, signing-key exposure, anomalous federation acceptance, missing lineage, identity-inconsistent claims, privileged downstream activity, persistent cloud changes, information collection, and security-control degradation.

·        Require responders to validate affected farm, DKM object, actor, source, process, certificate, artifact, session, identity, claims, relying party, application, cloud environment, repository, administrative action, and remediation status.

·        Prepare decision paths for evidence preservation, privileged-access suspension, signing-certificate replacement, metadata distribution, removal of old trust, session invalidation, credential rotation, role review, cloud restriction, application shutdown, legal review, compliance escalation, cyber-insurance coordination, communications planning, partner coordination, and executive reporting.

·        Treat suspected signing-key exposure as an identity-provider trust incident, not only as a vulnerability-management or certificate-management event.

·        Require post-event validation that suspicious federation access, persistent credentials, privileged roles, security-control changes, information access, or downstream activity did not continue after remediation.

S34 — Defensive Control & Hardening Architect

Figure 6

The defensive architecture should treat AD FS, Active Directory, DKM objects, signing certificates, backup and recovery systems, relying parties, cloud services, SaaS platforms, VPNs, administrative portals, and sensitive applications as one governed federation-trust system rather than isolated identity components. The architecture must connect inventory, DKM protection, privileged-access governance, signing-key protection, federation-lineage visibility, identity-state validation, relying-party logging, downstream monitoring, incident containment, certificate replacement, session invalidation, and executive trust restoration into one signing-material-to-enterprise-impact assurance model.

Architecture Layer One — Federation Asset and Trust Governance

Federation asset and trust governance establishes which AD FS farms, domains, forests, DKM containers, service accounts, certificates, trusts, relying parties, cloud tenants, SaaS platforms, VPNs, and applications exist; who owns them; which identities and privileges they support; and which business processes depend on them. This layer captures inventory, ownership, business criticality, regulated-data exposure, partner dependency, trust configuration, certificate role, and remediation status.

Architecture Layer Two — DKM and Directory Access Control

DKM and directory access control determines which identities, systems, backup processes, recovery processes, and administrative workflows can access protected signing material. This layer captures DKM distinguished name, object GUID, permissions, ownership, inheritance, auditing, delegated rights, privileged groups, backup rights, access history, and approved workflows.

Architecture Layer Three — Signing-Key and Certificate Protection

Signing-key and certificate protection determines whether token-signing material can be exported, recovered, copied, archived, staged, transferred, or reused outside approved controls. This layer captures certificate stores, private-key protection, export policy, hardware-backed storage, recovery packages, backups, certificate passwords, rollover state, certificate roles, and emergency-replacement capability.

Architecture Layer Four — Privileged Administration and Endpoint Visibility

Privileged administration and endpoint visibility determine whether identity-infrastructure activity originated from an approved administrator, workstation, jump host, remote session, management platform, backup system, or recovery workflow. This layer captures process ancestry, command line, PowerShell, directory tools, certificate utilities, archive tools, transfer tools, remote administration, file activity, Registry activity, network activity, and privileged-session context.

Architecture Layer Five — AD FS Authentication and Issuance Lineage

AD FS authentication and issuance lineage determine whether accepted federation access corresponds to expected authentication, MFA, issuance, claims processing, farm-node activity, and certificate use. This layer captures authentication events, issuance events, claims, issuer, audience, subject, NameID, assertion identifiers, federation sessions, token lifetimes, certificate thumbprints, relying-party context, failover, retention, and telemetry completeness.

Architecture Layer Six — Identity, Claims, and Entitlement Validation

Identity, claims, and entitlement validation determine whether the represented identity, account state, employment state, privilege, group membership, role, application entitlement, authentication method, source, and device are consistent with legitimate access. This layer captures authoritative directory, HR, identity-governance, privileged-access, device, and application context.

Architecture Layer Seven — Relying-Party and Session Monitoring

Relying-party and session monitoring determine whether cloud services, SaaS platforms, VPNs, administrative portals, and internal applications accepted suspicious federation tokens and whether local sessions persisted after trust remediation. This layer captures federation acceptance, application sessions, cloud sessions, source, device, issuer, audience, claims, privilege, session duration, local credential creation, and session invalidation.

Architecture Layer Eight — Cloud, Persistence, and Sensitive-Access Monitoring

Cloud, persistence, and sensitive-access monitoring determine whether suspected forged federation access resulted in persistent cloud credentials, additional roles, service principals, OAuth grants, API tokens, access keys, application credentials, privileged actions, security-control changes, or sensitive information collection. This layer captures AWS, Azure, Google Cloud, SaaS, repository, collaboration, database, backup, security, finance, legal, HR, and regulated-data activity.

Architecture Layer Nine — Network Egress and Cross-System Correlation

Network egress and cross-system correlation determine whether DKM access, certificate handling, archive staging, transfer, token use, and downstream access form one coherent sequence. This layer captures DNS, proxy, firewall, NDR, VPN, destination reputation, first-seen status, source continuity, process linkage, byte volume, callbacks, tunneling, internal staging, and cloud communication.

Architecture Layer Ten — SOC Correlation and False-Positive Control

SOC correlation joins DKM object state, actor, source, process, remote session, certificate, backup, recovery, artifact, issuance, authentication, claims, session, identity state, relying party, cloud activity, application activity, repository access, network behavior, change-control records, and approved workflow baselines. This layer distinguishes attacker-driven activity from certificate rollover, backup, recovery, migration, federation testing, identity administration, cloud administration, emergency access, security validation, vendor support, and incident response.

Architecture Layer Eleven — Incident Response and Executive Trust Workflow

Incident response and executive trust workflow connects technical evidence to containment and business decisions. This layer captures incident severity, affected farms, certificates, identities, sessions, applications, cloud resources, repositories, persistent credentials, containment actions, certificate replacement, metadata distribution, old-trust removal, session invalidation, credential rotation, legal review, compliance review, partner coordination, communications planning, executive reporting, and confirmation that federation trust can be restored.

Architecture Outcome

The architecture should enable the organization to answer seven questions during an AD FS signing-key and forged-token incident:

·        Which farm, node, DKM object, key object, actor, source, process, certificate, backup, recovery package, artifact, session, identity, claims set, relying party, application, cloud resource, repository, business owner, or remediation action was affected?

·        Did the activity align with approved AD FS administration, certificate rollover, backup, recovery, migration, disaster-recovery testing, claims management, federation testing, emergency access, security validation, or incident response?

·        Did an unauthorized principal access validated DKM or signing-material sources?

·        Did suspicious access progress into probable private-key acquisition, anomalous federation-token use, or trusted identity impersonation?

·        Did federation access result in persistent cloud credentials, additional roles, privileged activity, security-control degradation, information collection, or broader downstream compromise?

·        Can the organization replace signing trust, distribute metadata, remove prior certificates, invalidate sessions, rotate credentials, remove persistence, preserve evidence, and restore dependent applications without false closure?

Can leadership make defensible decisions about federation trust, identity integrity, cloud exposure, sensitive-data exposure, partner impact, regulatory obligations, operational disruption, and return-to-service approval?

‍ ‍

S35 — Defensive Control Mapping Matrix

‍ ‍

Preventive Controls

‍ ‍

·        Maintain complete inventory of AD FS farms, nodes, domains, forests, DKM containers, key objects, service accounts, certificates, trusts, relying parties, cloud integrations, applications, owners, business criticality, and regulated-data dependencies.

‍ ‍

·        Enforce least privilege for DKM access, domain administration, AD FS administration, certificate management, backup, recovery, identity management, and privileged application access.

‍ ‍

·        Protect token-signing private keys through hardware-backed key protection where supported, or through tightly controlled private-key access, export permissions, backup, recovery, and administrative workflows when software-based key storage is required.

‍ ‍

·        Restrict certificate export, backup, recovery-package access, configuration export, directory backup, private-key permission changes, and identity-infrastructure archives.

‍ ‍

·        Use dedicated privileged administrative workstations, jump hosts, privileged-access platforms, administrative networks, and time-bounded access.

‍ ‍

·        Require MFA, dual control, change approval, and session recording for high-risk identity and certificate operations where supported.

‍ ‍

·        Restrict standing cloud roles, SaaS administration, VPN administration, application administration, and access to sensitive repositories through AD FS federation.

‍ ‍

·        Protect logging, auditing, endpoint controls, cloud logging, application auditing, and identity-protection systems from unauthorized change.

‍ ‍

·        Maintain tested emergency signing-certificate replacement, metadata-distribution, old-trust removal, session-invalidation, and credential-rotation procedures.

‍ ‍

Detective Controls

‍ ‍

·        Monitor validated DKM object access, permission changes, ownership changes, inheritance changes, auditing changes, delegated-right changes, and unusual privileged access.

‍ ‍

·        Monitor suspicious PowerShell, directory-query, certificate, backup, recovery, archive, staging, transfer, and remote-administration activity on identity-infrastructure systems.

‍ ‍

·        Monitor token-signing private-key access, certificate export, backup, addition, replacement, promotion, rollover, and permission changes.

‍ ‍

·        Compare successful federation acceptance against expected AD FS issuance, authentication, MFA, identity, device, source, claims, and session lineage.

‍ ‍

·        Monitor federation use by disabled, terminated, dormant, service, emergency, executive, administrative, and other high-value identities.

‍ ‍

·        Monitor identity-inconsistent roles, groups, authentication methods, audiences, issuers, subjects, token lifetimes, and application entitlements.

‍ ‍

·        Monitor persistent cloud credentials, additional roles, service principals, OAuth grants, access keys, API tokens, application credentials, and administrative accounts after anomalous federation access.

‍ ‍

·        Monitor privileged administration, security-control changes, logging changes, sensitive information collection, and multi-application activity after suspicious federation acceptance.

‍ ‍

·        Monitor rare outbound communication, archive transfer, cloud-storage upload, tunneling, callbacks, and source changes near probable signing-material handling.

‍ ‍

·        Require multi-signal correlation before high-confidence signing-key, token-forgery, impersonation, or downstream-compromise determination.

‍ ‍

Responsive Controls

‍ ‍

·        Preserve Active Directory, DKM, AD FS, endpoint, certificate, backup, recovery, relying-party, identity, cloud, SaaS, VPN, application, repository, and network evidence before remediation.

‍ ‍

·        Suspend suspicious privileged access and restrict affected administrative paths.

‍ ‍

·        Replace affected signing certificates when exposure cannot be ruled out.

‍ ‍

·        Distribute updated metadata and remove prior certificates from trust across every relying party.

‍ ‍

·        Invalidate federation, cloud, SaaS, VPN, application, API, refresh-token, and privileged sessions.

‍ ‍

·        Rotate exposed or potentially created credentials, access keys, API tokens, application credentials, service-principal secrets, and recovery secrets.

‍ ‍

·        Review group membership, role assignment, OAuth grants, service principals, application credentials, cloud accounts, administrative accounts, and persistent sessions.

‍ ‍

·        Investigate cloud control planes, SaaS administration, security systems, backup systems, developer systems, repositories, finance, legal, HR, and regulated-data platforms for downstream activity.

‍ ‍

·        Perform legal, compliance, privacy, cyber-insurance, communications, customer, partner, executive, and board-level review when trust compromise, identity impersonation, sensitive access, or incomplete containment is suspected.

‍ ‍

·        Confirm that signing trust, identity state, session state, credential state, application trust, security-control health, and post-remediation monitoring support closure.

‍ ‍

Governance Controls

‍ ‍

·        Maintain approved inventories for identity infrastructure, DKM objects, certificates, trusts, relying parties, cloud integrations, privileged identities, emergency accounts, service accounts, application owners, data owners, and control owners.

‍ ‍

·        Maintain approved workflows for AD FS administration, certificate rollover, backup, recovery, migration, disaster-recovery testing, service-account maintenance, claims changes, relying-party changes, identity synchronization, cloud administration, emergency access, security testing, and incident response.

‍ ‍

·        Require change control for DKM permission changes, certificate changes, trust changes, claims changes, service-account changes, role changes, cloud credential changes, and emergency federation remediation.

‍ ‍

·        Maintain escalation criteria for suspicious DKM access, probable key-material handling, missing lineage, identity-inconsistent claims, privileged federation use, persistent cloud changes, sensitive information collection, and post-remediation activity.

‍ ‍

·        Track unresolved AD FS trust, telemetry, session, identity, cloud, application, and recovery gaps in the enterprise risk register.

‍ ‍

Control Mapping Summary

‍ ‍

The strongest control posture combines prevention of unauthorized signing-material access, detection of DKM-to-token-abuse sequences, and response workflows that restore cryptographic trust, identity confidence, session integrity, application assurance, cloud security, and business continuity. Controls should be prioritized for AD FS environments supporting privileged administration, Microsoft 365, cloud control planes, SaaS platforms, VPNs, security systems, backup systems, developer platforms, regulated data, partner federation, and business-critical applications.

‍ ‍

S36 — CyberDax Intelligence Maturity Assessment

‍ ‍

Current Intelligence Maturity

‍ ‍

Moderate to High

‍ ‍

Maturity Rationale

‍ ‍

AD FS federation signing-key exposure and forged-token trust compromise form a mature behavior-led intelligence model because the assessment is not dependent on one CVE, exploit name, vulnerable version, proof-of-concept repository, directory path, certificate thumbprint, token value, source IP, actor, or static indicator. Organization-specific maturity depends on whether DKM access, probable signing-material handling, federation issuance, authentication lineage, claims, identity state, relying-party acceptance, persistent cloud changes, sensitive information collection, and downstream activity can be correlated across object, actor, source, process, artifact, certificate, session, identity, application, resource, and time.

‍ ‍

Strengths

‍ ‍

·        The governing behavior is durable across changing vulnerabilities, directory-permission conditions, backup paths, recovery methods, token-construction tools, certificates, identities, relying parties, cloud platforms, and campaign branding.

‍ ‍

·        The core sequence is analytically clear: unauthorized signing-material access, probable private-key acquisition, forged federation-token creation, trusted relying-party acceptance, identity impersonation, and conditional downstream persistence or information collection.

‍ ‍

·        Detection opportunities are strong where Active Directory object access, endpoint, certificate, backup, recovery, AD FS, relying-party, identity, cloud, SaaS, VPN, application, repository, and network telemetry can be correlated.

‍ ‍

·        S25 provides behavior-led coverage across NDR, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP while correctly allowing zero YARA viability where artifact-driven detection is weak.

‍ ‍

·        Defensive controls map directly to DKM governance, privileged-access reduction, signing-key protection, federation-lineage visibility, identity validation, relying-party logging, cloud persistence review, session invalidation, and trust restoration.

‍ ‍

·        Blocks 1 through 5 remain aligned to the EXP behavior model without reverting to a single-CVE, patch-only, certificate-only, or unusual-sign-in assessment.

‍ ‍

Maturity Gaps

‍ ‍

·        AD FS inventory may not reliably identify every farm node, DKM object, certificate role, relying party, cloud integration, application owner, or business dependency.

‍ ‍

·        DKM object auditing may be absent, incomplete, misconfigured, or retained for insufficient periods.

‍ ‍

·        Directory logs may not prove which cryptographic material was retrieved.

‍ ‍

·        Endpoint coverage may be incomplete on domain controllers, AD FS servers, administrative workstations, backup systems, recovery systems, or identity-management platforms.

‍ ‍

·        Certificate, private-key, backup, recovery, archive, staging, and transfer telemetry may be inconsistent.

‍ ‍

·        Direct visibility into successful private-key acquisition and forged-token construction is limited.

‍ ‍

·        AD FS farm-node ingestion, issuance retention, authentication retention, tracing, failover, and timestamp alignment may be incomplete.

‍ ‍

·        Relying parties may not preserve immutable assertion identifiers, claims, issuer details, certificate thumbprints, source context, device context, or local session identifiers.

‍ ‍

·        Identity-state, HR-state, role, group, entitlement, device, and application context may be stale or inconsistently normalized.

‍ ‍

·        AWS canonical session binding may be unreliable.

‍ ‍

·        Azure federation-acceptance, normalized-identity, source-qualified activity, and finding enrichment may be incomplete.

‍ ‍

·        Google Cloud organization, normalized-identity, source-qualified activity, and finding enrichment may be incomplete.

‍ ‍

·        Cloud and SaaS data-event logging may be absent for sensitive services.

‍ ‍

·        Network telemetry may lack actor, process, session, or artifact attribution.

‍ ‍

·        Change-control and approved-workflow baselines may be insufficient to distinguish legitimate identity operations from adversary behavior.

‍ ‍

·        Organizations may over-rely on vulnerable versions, permissive DKM access, missing MFA, unusual claims, valid signatures, missing events, or cloud anomalies.

‍ ‍

Maturity Improvement Priorities

‍ ‍

·        Maintain authoritative AD FS farm, farm-node, domain-controller, DKM object, certificate, trust, relying-party, cloud integration, and application inventories.

‍ ‍

·        Enable and validate object-level auditing for every AD FS DKM container and associated key object.

‍ ‍

·        Improve actor, SID, source-host, source-IP, process, logon-session, access-right, and timestamp attribution for DKM activity.

‍ ‍

·        Improve endpoint coverage on domain controllers, AD FS servers, administrative workstations, backup systems, recovery systems, certificate-management systems, and identity-management platforms.

‍ ‍

·        Improve certificate, private-key, backup, recovery, archive, staging, transfer, and process-linked network telemetry.

‍ ‍

·        Ingest all relevant AD FS farm nodes and validate authentication, issuance, claims, certificate, trust, configuration, retention, failover, and timestamp behavior.

‍ ‍

·        Improve relying-party issuer, audience, subject, NameID, assertion, session, claims, certificate, source, device, application, and acceptance logging.

‍ ‍

·        Improve MFA, Kerberos, password-validation, VPN, device, and upstream-authentication correlation.

‍ ‍

·        Improve authoritative identity-state, HR-state, group-membership, role-entitlement, application-entitlement, privileged-status, and high-value-identity context.

‍ ‍

·        Improve session and normalized-identity reconciliation across AD FS, relying parties, SaaS, VPN, AWS, Azure, and Google Cloud.

‍ ‍

·        Improve AWS canonical session binding.

‍ ‍

·        Improve Azure federation-acceptance, identity, source-qualified record, finding enrichment, and approved-workflow mappings.

‍ ‍

·        Improve Google Cloud organization, identity, source-qualified record, Security Command Center enrichment, and approved-workflow mappings.

‍ ‍

·        Enable relevant cloud and application data-event logging for sensitive information repositories.

‍ ‍

·        Build approved-workflow baselines for certificate rollover, backup, recovery, migration, federation testing, claims changes, relying-party changes, service-account maintenance, identity synchronization, cloud administration, automation, managed services, emergency access, security testing, and incident response.

‍ ‍

·        Test detection and response logic against realistic benign and suspicious sequences before alert promotion.

‍ ‍

Maturity Outlook

‍ ‍

Maturity can improve quickly when the organization prioritizes DKM auditing, signing-key protection, farm-node logging, federation-session reconciliation, identity-state quality, relying-party metadata, cloud correlation, information-repository logging, and trust-restoration capability. The highest-value improvements are those that prove whether unauthorized signing-material access occurred, whether suspicious access progressed into forged-token use, and whether the organization can restore cryptographic and application trust without relying on account-level remediation alone.

‍ ‍

S37 — Strategic Defensive Improvements

‍ ‍

Strategic improvement should focus on reducing the probability that access to Active Directory, backup, recovery, certificate, or identity-management infrastructure can become federation signing-key compromise and reducing the amount of enterprise trust exposed if signing material is obtained. The organization should treat AD FS signing-key exposure as a cross-functional resilience problem spanning identity, Active Directory, privileged access, certificate management, backup, recovery, cloud security, SaaS governance, application security, detection engineering, incident response, business continuity, legal, compliance, cyber insurance, communications, and executive governance.

‍ ‍

Priority One — Establish Federation Trust-Tier Governance

‍ ‍

·        Classify AD FS farms and relying parties by business criticality, privileged access, regulated-data exposure, cloud dependency, SaaS dependency, VPN dependency, partner trust, customer impact, and recovery complexity.

‍ ‍

·        Apply stronger DKM, certificate, privileged-access, logging, session, and recovery requirements to high-trust environments.

‍ ‍

·        Treat cloud control planes, Microsoft 365, security systems, backup platforms, identity platforms, developer systems, finance, legal, HR, and regulated-data applications as elevated trust tiers.

‍ ‍

·        Require explicit ownership and trust-restoration criteria for every elevated-trust relying party.

‍ ‍

Priority Two — Reduce Signing-Material Exposure

‍ ‍

·        Remove unnecessary DKM permissions, delegated rights, inherited rights, backup rights, standing administrative access, and broad group access.

‍ ‍

·        Protect token-signing private keys through hardware-backed key protection where supported, or through tightly controlled private-key access, export permissions, backup, recovery, and administrative workflows when software-based key storage is required.

‍ ‍

·        Restrict and monitor recovery packages, configuration archives, certificate backups, identity backups, certificate passwords, and recovery secrets.

‍ ‍

·        Require periodic access review and controlled emergency access for signing-material workflows.

‍ ‍

Priority Three — Reduce Privileged Identity and Session Risk

‍ ‍

·        Reduce standing privileges available through AD FS federation.

‍ ‍

·        Use time-bounded elevation, privileged-access approval, MFA, dedicated administrative workstations, and session recording where supported.

‍ ‍

·        Restrict use of dormant, service, emergency, executive, and high-value identities across sensitive relying parties.

‍ ‍

·        Maintain rapid federation, cloud, SaaS, VPN, application, API, and refresh-token invalidation capability.

‍ ‍

Priority Four — Harden Relying-Party Trust and Metadata Governance

‍ ‍

·        Maintain authoritative relying-party inventories, issuer and audience mappings, certificate mappings, claims requirements, token lifetimes, session behavior, and application owners.

‍ ‍

·        Require relying parties to reject retired signing certificates promptly.

‍ ‍

·        Test metadata distribution and certificate replacement regularly.

‍ ‍

·        Require applications to preserve sufficient federation and session telemetry and support emergency local-session invalidation.

‍ ‍

Priority Five — Build Sequence-Based Detection and Response

‍ ‍

·        Detect the durable sequence rather than isolated artifacts: suspicious DKM access, probable signing-material handling, anomalous federation acceptance, missing validated lineage, identity-inconsistent claims, privileged downstream behavior, persistent credentials, and information collection.

‍ ‍

·        Preserve DKM object, actor, source, process, certificate, artifact, assertion, session, identity, relying-party, cloud, resource, and time context.

‍ ‍

·        Route detections according to trust tier and business criticality without weakening evidence requirements.

‍ ‍

·        Require investigation playbooks to distinguish exposure, suspicious access, probable acquisition, suspected forgery, identity impersonation, and downstream compromise.

‍ ‍

Priority Six — Make Signing-Key Replacement and Trust Restoration Routine

‍ ‍

·        Predefine when signing certificates must be replaced because exposure cannot be ruled out.

‍ ‍

·        Maintain tested procedures for certificate generation, metadata distribution, prior-certificate removal, session invalidation, credential rotation, role review, application validation, partner coordination, and return to service.

‍ ‍

·        Do not treat patching, DKM permission hardening, password reset, MFA reset, account disablement, or endpoint remediation as sufficient trust restoration.

‍ ‍

·        Require explicit validation of signing trust, relying-party trust, session state, credential state, role state, security-control health, sensitive access, and post-remediation behavior.

‍ ‍

Priority Seven — Reduce Downstream Trust Concentration

‍ ‍

·        Limit the number of privileged, regulated, sensitive, and business-critical systems reachable through one federation trust.

‍ ‍

·        Separate administrative federation from ordinary workforce access where feasible.

‍ ‍

·        Reduce standing cloud roles, SaaS administration, repository access, backup administration, security administration, and application administration granted through federated identities.

‍ ‍

·        Require downstream trust review whenever signing-key exposure cannot be ruled out.

‍ ‍

Priority Eight — Integrate Executive and Business Decisioning

‍ ‍

·        Define escalation thresholds for suspected signing-key exposure affecting privileged administration, cloud control planes, Microsoft 365, security platforms, backup environments, partner federation, regulated data, finance, legal, HR, developer systems, and customer-facing applications.

‍ ‍

·        Maintain decision paths for application shutdown, privileged-access suspension, certificate replacement, session invalidation, customer impact, partner impact, legal review, compliance review, privacy review, cyber-insurance coordination, communications planning, and board reporting.

‍ ‍

·        Track unresolved DKM, signing-key, telemetry, session, application, cloud, partner, and recovery gaps in the enterprise risk register.

‍ ‍

·        Require leadership assurance that federation trust can be restored before normal operations resume.

‍ ‍

Strategic Outcome

‍ ‍

The target state is an environment in which unauthorized access to AD FS signing material is less likely, signing keys expose less reusable enterprise trust, suspicious federation activity can be reconstructed across identity and downstream systems, affected trust can be replaced rapidly, sessions and credentials can be invalidated comprehensively, and leadership can make defensible decisions about identity integrity, cloud exposure, sensitive information, partner impact, operational disruption, and return to service.

‍ ‍

S38 — Attack Economics & Organizational Impact Model

‍ ‍

‍ ‍

Figure 7

‍ ‍

AD FS federation signing-key exposure and forged-token trust compromise change intrusion economics by allowing an adversary who reaches protected federation signing material to convert one identity-infrastructure compromise into trusted access across multiple relying parties. A recovered token-signing private key can support creation of validly signed SAML tokens containing attacker-selected identities, claims, privileges, audiences, authentication context, and lifetimes without requiring compromise of each represented account, endpoint, application, cloud tenant, SaaS platform, VPN, administrative portal, or information repository individually.

‍ ‍

When suspicious DKM access, probable signing-material handling, anomalous federation acceptance, missing validated issuance lineage, identity-inconsistent claims, privileged downstream activity, persistent credential creation, information collection, or security-control modification align within one investigation window, the adversary can create disproportionate enterprise uncertainty. The organization’s cost expands when responders must determine whether signing material was only exposed or actually acquired, whether forged tokens were created or presented, which identities were impersonated, which relying parties accepted suspicious federation assertions, which sessions and credentials persisted, which information repositories were accessed, and whether cryptographic and application trust can be restored safely.

‍ ‍

Adversary Economic Advantage

‍ ‍

·        A single signing-key compromise can provide access across multiple relying parties because the adversary can create federation assertions that appear cryptographically valid to systems trusting the affected certificate.

‍ ‍

·        The adversary may not need to obtain the password, MFA factor, endpoint access, device registration, or active session of each impersonated identity.

‍ ‍

·        Forged SAML tokens can contain attacker-selected subjects, claims, roles, group memberships, authentication context, audiences, and validity periods within the constraints enforced by the relying party.

‍ ‍

·        One compromised federation trust can expose cloud control planes, Microsoft 365, SaaS platforms, VPNs, administrative portals, security systems, backup platforms, developer environments, repositories, finance systems, legal systems, HR platforms, regulated-data applications, and other business-critical services.

‍ ‍

·        Signing-material acquisition may occur through DKM access, certificate access, backups, recovery packages, configuration archives, identity-management systems, or offline processing, allowing the adversary to choose the least observable acquisition path.

‍ ‍

·        Forged-token creation may occur outside monitored identity infrastructure, reducing dependence on continued access to an AD FS server after signing material has been recovered.

‍ ‍

·        Valid signatures can reduce initial defender suspicion because relying parties may accept the token even when the assertion was not legitimately issued by the AD FS farm.

‍ ‍

·        Legitimate certificate rollover, backup, recovery, migration, identity administration, cloud administration, federation testing, emergency access, and incident-response activity can make malicious signing-material access or trust changes harder to classify quickly.

‍ ‍

·        Incomplete farm-node logging, session reconciliation, identity normalization, relying-party metadata, or cloud correlation can extend adversary dwell time by preventing rapid confirmation of forged-token use.

‍ ‍

·        Persistent cloud credentials, additional roles, service principals, OAuth grants, access keys, API tokens, application credentials, or local application accounts can preserve access after the signing certificate is replaced.

‍ ‍

·        A single forged privileged identity can create disproportionate downstream exposure through administrative actions, security-control modification, information collection, session creation, credential establishment, and trust expansion.

‍ ‍

·        The adversary benefits when defenders cannot quickly determine whether accepted federation access originated from legitimate authentication and issuance or from attacker-generated assertions.

‍ ‍

Defender Cost Expansion

‍ ‍

·        The organization must investigate both the suspected signing-material exposure and the reliability of the directory, endpoint, certificate, backup, recovery, AD FS, relying-party, identity, cloud, application, repository, network, change-control, and remediation evidence needed to confirm or disprove impact.

‍ ‍

·        Response teams may need to reconstruct DKM permissions, object access, actor attribution, source systems, process activity, certificate operations, backup access, recovery activity, archive staging, transfer behavior, authentication lineage, issuance lineage, assertion acceptance, represented identity, claims, sessions, downstream administration, and information access.

‍ ‍

·        Mitigation may require privileged-access suspension, signing-certificate replacement, federation-metadata distribution, removal of prior certificates from trust, session invalidation, credential rotation, cloud-role restriction, service-principal review, OAuth-grant review, application shutdown, relying-party validation, and extended post-remediation monitoring.

‍ ‍

·        Internal exposure scoping may be required across every AD FS farm node, domain controller, administrative workstation, backup system, recovery platform, identity-management system, certificate-management platform, relying party, cloud tenant, SaaS application, VPN, repository, sensitive data store, and business owner connected to the affected trust.

‍ ‍

·        Response cost increases when DKM object auditing, endpoint coverage, certificate telemetry, backup records, farm-node logging, assertion identifiers, session identifiers, identity state, relying-party metadata, cloud data events, or approved-workflow records are incomplete.

‍ ‍

·        Business impact increases when defenders must determine whether signing material was acquired, whether forged tokens were accepted, whether privileged identities were impersonated, whether persistent credentials were established, whether sensitive information was collected, and whether security controls or logging were modified.

‍ ‍

·        Investigation scope expands when the same signing certificate supports many relying parties, privileged applications, partner relationships, cloud environments, or regulated workloads.

‍ ‍

·        Operational disruption increases when applications cannot consume emergency federation metadata promptly, remove prior certificates reliably, invalidate local sessions, or provide sufficient evidence of accepted assertions.

‍ ‍

·        Legal, compliance, privacy, customer, partner, cyber-insurance, communications, executive, and board-level costs increase when identity impersonation, privileged access, sensitive-data exposure, partner-trust impact, or incomplete containment cannot be ruled out.

‍ ‍

·        Trust-restoration cost may continue after certificate replacement because previously created sessions, credentials, roles, grants, tokens, service principals, application accounts, and downstream changes must also be identified and remediated.

‍ ‍

Organizational Impact Model

‍ ‍

Federation Infrastructure and Trust Impact

‍ ‍

The organization must determine which AD FS farms, farm nodes, domains, forests, DKM containers, key objects, service accounts, certificates, claims-provider trusts, relying-party trusts, partner relationships, cloud integrations, SaaS platforms, VPNs, administrative portals, and internal applications were exposed, accessed, modified, dependent on affected signing trust, or included in remediation.

‍ ‍

Signing-Material Exposure and Acquisition Impact

‍ ‍

The organization must determine whether suspicious activity remained limited to vulnerable state, permissive DKM access, enumeration, failed access, or approved administration, or progressed into unauthorized object access, certificate access, backup or recovery access, probable private-key acquisition, artifact staging, transfer, or offline processing.

‍ ‍

Authentication, Issuance, and Federation-Lineage Impact

‍ ‍

The organization must determine whether accepted federation sessions corresponded to legitimate authentication, MFA, AD FS issuance, claims processing, farm-node activity, certificate use, and relying-party acceptance, or whether validly signed assertions lacked credible issuance lineage.

‍ ‍

Identity, Claims, and Privilege Impact

‍ ‍

The organization must determine which identities were represented, whether those identities were active, disabled, terminated, dormant, service, emergency, executive, administrative, or otherwise high value, and whether the asserted claims, roles, groups, authentication context, audiences, privileges, and token lifetimes were legitimate.

‍ ‍

Relying-Party and Session Impact

‍ ‍

The organization must determine which cloud services, SaaS platforms, VPNs, administrative portals, partner systems, and internal applications accepted suspicious federation assertions and whether local application, cloud, SaaS, VPN, API, refresh-token, or privileged sessions remained active after containment.

‍ ‍

Persistent Credential and Access Impact

‍ ‍

The organization must determine whether suspicious federation access resulted in additional cloud credentials, cloud roles, service principals, OAuth grants, access keys, API tokens, application credentials, local application accounts, group changes, role assignments, workload identities, or other persistent access mechanisms.

‍ ‍

Information-Repository and Sensitive-Data Impact

‍ ‍

The organization must determine whether forged or suspicious federation access resulted in collection, download, export, querying, copying, or administrative access involving collaboration platforms, messaging systems, SharePoint environments, code repositories, databases, document systems, backup repositories, legal systems, finance systems, HR platforms, regulated-data stores, or other sensitive repositories.

‍ ‍

Security-Control and Evidence-Reliability Impact

‍ ‍

The organization must determine whether AD FS tracing, directory auditing, event forwarding, endpoint monitoring, cloud logging, application auditing, identity-protection controls, security-platform configuration, or other evidence sources were stopped, modified, degraded, bypassed, restored, or rendered unreliable during the event window.

‍ ‍

Cloud and Application Trust Impact

‍ ‍

The organization must determine whether forged federation access affected AWS, Azure, Google Cloud, Microsoft 365, SaaS platforms, security systems, backup services, developer platforms, repositories, production applications, administrative portals, or partner environments and whether downstream privileges or resources were modified.

‍ ‍

Partner and External Trust Impact

‍ ‍

The organization must determine whether partner federation relationships, customer-facing services, externally hosted relying parties, managed-service providers, or third-party applications trusted the affected certificate and whether emergency metadata or certificate replacement must be coordinated outside the organization.

‍ ‍

Operational Availability and Business-Continuity Impact

‍ ‍

The organization must determine whether certificate replacement, metadata propagation, session invalidation, privileged-access suspension, application shutdown, cloud restrictions, relying-party validation, or incomplete trust assurance disrupted authentication, remote access, administration, collaboration, production services, customer operations, partner connectivity, or business-critical workflows.

‍ ‍

Containment and Trust-Restoration Impact

‍ ‍

The organization must restore cryptographic trust, identity confidence, session integrity, application trust, cloud assurance, credential state, role state, security-control health, and business continuity through evidence preservation, certificate replacement, metadata distribution, prior-certificate removal, session invalidation, credential rotation, persistence review, downstream investigation, application validation, partner coordination, legal assessment, compliance review, cyber-insurance coordination, executive reporting, and post-remediation monitoring.

‍ ‍

Governance Impact

‍ ‍

Leadership may need to treat confirmed or strongly suspected federation signing-key exposure as an executive-level identity-provider and enterprise-trust incident because one affected certificate may support privileged administration, cloud control planes, Microsoft 365, SaaS applications, VPNs, security platforms, backup systems, developer environments, partner federation, regulated-data services, customer-facing applications, and other business-critical operations.

‍ ‍

Economic Impact Summary

‍ ‍

AD FS federation signing-key exposure and forged-token trust compromise create economic advantage for adversaries because one recovered signing key can support trusted identity impersonation across multiple relying parties without requiring compromise of every account, device, credential, or application individually. The organization’s financial exposure grows when it cannot quickly determine whether signing material was acquired, whether forged tokens were created or accepted, which identities and claims were used, which sessions and credentials persisted, which systems or information repositories were accessed, whether security controls remained reliable, and whether cryptographic and application trust can be restored without continued operational uncertainty.

‍ ‍

S39 — Economic Impact & Organizational Exposure

‍ ‍

AD FS federation signing-key exposure and forged-token trust compromise expand organizational exposure by creating uncertainty over whether protected signing material remained secure, whether federation tokens were legitimately issued, whether trusted identities were impersonated, and whether downstream cloud, SaaS, VPN, administrative, security, backup, developer, repository, financial, legal, HR, customer, partner, or regulated-data systems were accessed. The governing risk is not limited to CVE-2026-56155, one DKM permission condition, one certificate, one recovery mechanism, one authentication weakness, one token-abuse method, one utility, one campaign, or one adversary. The material question is whether identity-infrastructure access or federation-control failure produced unauthorized trusted access before containment.

‍ ‍

Economic exposure rises when the affected federation trust supports privileged administration, Microsoft 365, AWS, Azure, Google Cloud, SaaS platforms, VPNs, security systems, backup platforms, identity infrastructure, developer environments, repositories, regulated applications, customer-facing services, partner federation, or business-critical operations. Exposure is highest when defenders cannot distinguish permissive DKM access from actual object access, probable signing-material acquisition from administrative certificate handling, legitimate federation issuance from forged or otherwise unauthorized federation access, or routine downstream behavior from attacker-driven persistence, privilege change, information collection, security-control modification, or trust expansion.

‍ ‍

Estimated Economic Exposure

‍ ‍

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate depends on whether activity remains limited to vulnerable state, excessive DKM permissions, suspicious enumeration, failed access, or approved administration; progresses into unauthorized DKM access, authentication-process abuse, probable signing-material acquisition, authentication-factor bypass, token replay, or suspicious federation acceptance; or results in trusted identity impersonation, persistent credential creation, privileged cloud or SaaS administration, sensitive information collection, security-control degradation, partner impact, operational disruption, destructive activity, ransomware deployment, or multi-application compromise.

‍ ‍

Economic exposure increases when the organization cannot quickly determine whether protected signing material was acquired, whether token construction occurred offline, whether accepted federation sessions corresponded to legitimate authentication and issuance, whether MFA and authentication-method requirements were satisfied, whether a token was replayed, whether represented identities and claims were valid, whether relying-party sessions persisted, whether downstream credentials or roles were created, whether sensitive repositories were accessed, and whether directory, endpoint, certificate, backup, recovery, AD FS, relying-party, identity, cloud, application, network, change-control, incident-response, and remediation evidence can be joined into a reliable sequence.

‍ ‍

Low Impact Scenario

‍ ‍

Estimated $500K - $3M

‍ ‍

This scenario applies when rapid investigation confirms a vulnerable or permissive AD FS or DKM condition, suspicious enumeration, failed access, or limited administrative activity without evidence of successful unauthorized DKM access, protected signing-material handling, certificate export, backup or recovery access, authentication-factor bypass, token replay, anomalous federation acceptance, missing validated issuance lineage, identity impersonation, persistent credential creation, privileged downstream activity, security-control modification, or sensitive information access. Available evidence supports a failed, contained, approved, or non-impacting event. Response remains limited to targeted patch and configuration validation, DKM permission hardening, object-auditing enablement, certificate review, focused hunting, evidence preservation, limited administrative review, short-term enhanced monitoring, and executive assurance that federation trust was not materially affected.

‍ ‍

Moderate Impact Scenario

‍ ‍

Estimated $5M - $35M

‍ ‍

This scenario applies when confirmed or strongly suspected unauthorized DKM access, probable signing-material handling, authentication-factor bypass, token replay, or unexplained federation acceptance affects one or more AD FS farms, domain controllers, administrative systems, identity-management platforms, certificate-management systems, backup platforms, recovery systems, relying parties, or privileged operational paths. Evidence may include unexpected protected-object access, permission or ownership changes, certificate interaction, recovery-package use, archive creation, transfer behavior, authentication-method inconsistency, repeated or duplicate token use, missing expected lineage, or downstream behavior associated with a suspicious federation session. The organization cannot immediately determine whether signing material was recovered, whether unauthorized tokens were accepted, which identities were represented, or which relying parties retained affected sessions. Response may require enterprise directory and federation investigation, endpoint and certificate analysis, signing-certificate replacement planning, relying-party coordination, metadata updates, session invalidation, cloud and SaaS investigation, privileged-role review, credential and token rotation, legal and compliance review, cyber-insurance coordination, executive reporting, and extended post-remediation monitoring.

‍ ‍

High Impact Scenario

‍ ‍

Estimated $40M - $200M+

‍ ‍

This scenario applies when confirmed or strongly suspected federation compromise becomes an enterprise-impact event involving forged-token acceptance, repeated unauthorized token use, privileged identity impersonation, cloud control-plane access, Microsoft 365 compromise, sensitive SaaS administration, VPN access, persistent cloud credentials, service-principal or OAuth-grant creation, security-control degradation, backup compromise, developer-platform or repository access, regulated-data exposure, customer or partner impact, lateral expansion, operational disruption, destructive activity, ransomware deployment, or broad multi-application compromise. The organization may need to treat identities, sessions, roles, credentials, applications, cloud resources, and sensitive information accessible through the affected federation relationship as exposed until reliable evidence proves otherwise. Response may require emergency signing-certificate replacement, removal of prior certificates from trust, accelerated metadata distribution, broad session invalidation, credential rotation, cloud-role restriction, application shutdown, privileged-access suspension, forensic investigation, persistence removal, information-access review, notification analysis, legal and regulatory escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of federation trust.

‍ ‍

Annualized Risk Exposure

‍ ‍

Estimated $6M - $45M+ for materially exposed enterprise environments where AD FS supports privileged administration, cloud services, SaaS platforms, VPNs, security systems, backup environments, identity platforms, customer applications, partner federation, or regulated workloads and where excessive DKM permissions, incomplete object auditing, broad administrative access, backup or recovery dependencies, inconsistent farm-node logging, limited assertion metadata, weak session correlation, short retention, large relying-party populations, third-party trust dependencies, or concentrated identity privileges increase incident likelihood and response burden.

‍ ‍

Exposure may exceed $40M - $200M+ when signing-key compromise or another federation-trust failure results in broad identity impersonation, cloud control-plane access, Microsoft 365 compromise, privileged SaaS administration, persistent credential creation, security-control degradation, regulated-data exposure, customer or partner impact, operational disruption, destructive activity, ransomware deployment, multi-application compromise, incomplete session invalidation, legal escalation, regulatory reporting, cyber-insurance review, communications response, or board-level intervention.

‍ ‍

Operational Dependency

‍ ‍

Operational dependency is high where AD FS provides authentication or authorization for Microsoft 365, cloud platforms, SaaS applications, VPNs, administrative portals, security systems, backup systems, identity platforms, developer environments, repositories, regulated applications, customer-facing services, partner systems, or business-critical operations. One affected signing certificate or federation-control weakness can create broad investigation and recovery requirements when multiple relying parties trust the affected identity provider or when privileged identities and sensitive applications depend on that trust.

‍ ‍

Dependency increases when signing certificates cannot be replaced, federation metadata cannot be distributed, prior certificates cannot be removed, sessions cannot be invalidated, or applications cannot be taken out of service without business disruption. Dependency is highest when third-party, partner-operated, vendor-managed, or locally validating relying parties retain limited federation metadata or cannot rapidly consume emergency trust changes.

‍ ‍

Federation and Application Trust

‍ ‍

Federation trust is reduced when the organization cannot prove that DKM permissions, protected-object access, signing certificates, certificate stores, recovery packages, backups, configuration archives, AD FS authentication, token issuance, claims processing, relying-party acceptance, authentication-factor enforcement, token-replay protections, and session state remained reliable during the investigation window.

‍ ‍

Application trust is further reduced when accepted federation sessions cannot be reconciled with expected authentication or issuance lineage; represented identities, claims, roles, authentication methods, audiences, or lifetimes conflict with authoritative state; identical or related tokens appear across inconsistent sessions or sources; or sessions, credentials, roles, grants, or accounts established through suspicious federation access remain active after containment.

‍ ‍

Visibility Confidence

‍ ‍

Visibility confidence is highest when Active Directory object-access, directory-change, endpoint, process, PowerShell, certificate, private-key, backup, recovery, AD FS authentication, MFA, token-issuance, claims, token identifiers, nonce or replay state, relying-party, identity-state, device, cloud, SaaS, VPN, application, information-repository, DNS, proxy, firewall, NDR, and change-control telemetry can be correlated through stable DKM-object, actor, source-host, process, certificate, assertion, federation-session, application-session, cloud-session, identity, issuer, audience, relying-party, resource, and timestamp mappings.

‍ ‍

Visibility confidence is reduced when object-level DKM auditing is absent, actor or source attribution is incomplete, endpoint coverage excludes identity infrastructure, certificate or recovery activity is not retained, farm nodes are inconsistently ingested, relying parties discard assertion metadata, MFA and authentication-method records cannot be reconciled, token or nonce state is unavailable, session identifiers cannot be joined, identity state is stale, cloud records cannot be bound to the federation session, or retention is insufficient to connect earlier identity-infrastructure activity with delayed token use.

‍ ‍

S25 depends on validated DKM object identity, actor and source attribution, signing-material classification, federation-acceptance records, authentication and issuance lineage, normalized identity, reliable session reconciliation, claims and entitlement context, approved-workflow baselines, and bounded-time correlation. It does not depend on CVE strings, exploit names, actor names, tool names, token values, certificate thumbprints, source IPs, missing MFA, unusual claims, or missing AD FS events as standalone detection inputs.

‍ ‍

Signing-Material and Credential Dependency

‍ ‍

Signing-material dependency is high when AD FS DKM objects, token-signing certificates, recovery packages, configuration archives, certificate backups, identity backups, private-key permissions, certificate passwords, recovery secrets, or administrative workflows can expose reusable federation signing material.

‍ ‍

Credential dependency becomes materially higher when suspicious federation access can create cloud credentials, service principals, OAuth grants, application credentials, access keys, API tokens, refresh tokens, privileged roles, local application accounts, persistent sessions, or workload identities that remain usable after signing-certificate replacement.

‍ ‍

Cloud, SaaS, VPN, and Application Dependency

‍ ‍

Cloud, SaaS, VPN, and application dependency is high when AD FS federation provides access to AWS, Azure, Google Cloud, Microsoft 365, administrative portals, security systems, backup platforms, developer systems, repositories, financial applications, legal platforms, HR systems, regulated workloads, or customer-facing applications.

‍ ‍

The organization must distinguish suspicious federation acceptance from confirmed downstream compromise. Federated sign-ins, unusual sources, identity anomalies, role activity, service-principal changes, credential creation, security findings, information access, or application administration become materially relevant only when telemetry ties them to the affected trust, represented identity, reconciled session, relying party, resource, or investigation window.

‍ ‍

Partner and Third-Party Dependency

‍ ‍

Partner and third-party dependency is high when external organizations, managed-service providers, vendors, hosted applications, subsidiaries, business-to-business partners, or customer environments trust the affected AD FS signing certificate.

‍ ‍

The organization may need to coordinate certificate replacement, metadata distribution, prior-certificate removal, session invalidation, evidence preservation, access review, and return-to-service validation with parties outside its direct administrative control. Delayed or incomplete external coordination can extend operational disruption and residual trust uncertainty.

‍ ‍

Customer, Partner, Workforce, and Regulatory Exposure

‍ ‍

Customer, partner, workforce, and regulatory exposure increases when suspicious federation access affects customer information, employee data, partner environments, privileged administration, regulated workloads, finance systems, legal systems, HR platforms, security infrastructure, backup environments, developer platforms, source-code repositories, or business-critical services.

‍ ‍

Exposure also increases when telemetry gaps prevent timely confirmation of whether identities were impersonated, authentication requirements were bypassed, tokens were replayed, information was accessed, roles or credentials were created, security controls were modified, partner systems accepted affected tokens, operational integrity changed, or containment was complete.

‍ ‍

Residual Economic Risk

‍ ‍

Residual economic risk remains after patching, DKM permission hardening, certificate replacement, password reset, MFA reset, account disablement, endpoint remediation, session revocation, cloud-role restriction, replay-protection enablement, or incident-response cleanup when the pre-remediation activity window cannot be reconstructed.

‍ ‍

Applying an AD FS security update or correcting DKM access reduces future exposure but does not prove that signing material, authentication controls, replay protections, or federation trust were not abused before remediation. Replacing the token-signing certificate reduces future use of that certificate only when updated metadata is distributed, the prior certificate is removed from trust, affected sessions are invalidated, persistent credentials and roles are remediated, and downstream activity is reviewed. Residual risk should remain elevated until historical directory, endpoint, certificate, backup, recovery, AD FS, relying-party, identity, cloud, application, repository, network, change-control, incident-response, and remediation evidence has been assessed.

‍ ‍

Proof-of-Concept Behavioral Coverage Assessment

‍ ‍

CVE-2026-56155 is the originating vulnerability anchor for this report. The vulnerability is an AD FS access-control-granularity weakness that can allow an authorized local attacker to elevate privileges. The S25 model directly covers the observable behavior when exploitation or follow-on activity produces unexpected access to a validated AD FS DKM object, DKM control changes, probable signing-material handling, suspicious certificate or recovery activity, anomalous federation acceptance, missing validated lineage with independent corroboration, identity-inconsistent claims, persistent credential creation, privileged downstream behavior, information access, or security-control modification. Vulnerable-version state, patch status, KEV inclusion, or CVE association alone does not establish local compromise. (NVD)

‍ ‍

CVE-2020-0837 is directly covered at the successful-exploitation outcome when exploitation produces accepted federation access with authentication factors, MFA state, identity context, source, session, privilege, or downstream behavior inconsistent with the represented identity or relying-party policy. S25 does not identify the specially crafted request or name the vulnerability, but it directly evaluates the resulting successful federation-acceptance and authentication-control failure through the implemented lineage, authentication-method, identity-context, and downstream-correlation model. (NVD)

‍ ‍

CVE-2018-8340 is directly covered at the successful-exploitation outcome when improper MFA-request handling results in accepted federation access with missing or inconsistent authentication context and qualifying identity, session, privilege, persistence, or downstream evidence. S25 covers the observable successful-abuse sequence without claiming identification of the vulnerability-specific request. (NVD)

‍ ‍

CVE-2025-59258 is related through AD FS information exposure but requires adaptation. Its established behavior involves sensitive information disclosure through AD FS log files rather than direct signing-key acquisition, forged-token creation, or federation-acceptance abuse. S25 can support investigation where local file access, process activity, archive staging, transfer, identity-infrastructure access, or later federation activity is present, but reliable coverage requires log-file-specific monitoring and validation of the exposed information.

‍ ‍

CVE-2023-35348 requires adaptation because Microsoft identifies it as an AD FS token-replay vulnerability. S25 may identify suspicious federation acceptance, session inconsistency, or downstream behavior, but reliable replay detection requires token identifiers, nonce or replay-cache state, duplicate-token correlation, protocol-aware validation, or equivalent relying-party evidence. (Microsoft Support)

‍ ‍

CVE-2022-30215 requires adaptation because the authoritative public description establishes an AD FS elevation-of-privilege vulnerability but does not provide enough exploitation detail to map it conclusively to DKM access, signing-material handling, MFA bypass, token replay, or forged-token acceptance. It should not be promoted to Direct Coverage until authoritative technical evidence establishes a behavior already implemented in S25. (Microsoft Security Response Center)

‍ ‍

CVE-2021-33779 requires adaptation because Microsoft identifies it as an AD FS token-replay vulnerability addressed through KDFv2. S25 may identify resulting suspicious federation access or downstream activity, but reliable coverage requires KDF version context, replay-specific evidence, token or nonce correlation, and provider- or relying-party telemetry not universally present in the current detection model. (Microsoft Learn)

‍ ‍

ADFSDump and ADFSpoof are directly covered procedure sets. Their documented workflow aligns with S25 coverage for AD FS configuration and directory collection, DKM interaction, signing-material recovery preparation, process and artifact activity, and anomalous federation use. Direct coverage represents observable procedure coverage, not reliable tool-name identification.

‍ ‍

FoggyWeb is directly covered as an AD FS post-compromise procedure set when it produces observable configuration-database or decrypted certificate access, process or module activity, archive or transfer behavior, suspicious communication, or related federation activity.

‍ ‍

APT29, including NOBELIUM and UNC2452-associated procedures, is directly covered at the procedure level where compromised SAML signing material is used to forge tokens and obtain trusted downstream access. Actor attribution requires independent intelligence and incident-specific evidence.

‍ ‍

Known exploitation, KEV inclusion, public exploit availability, vendor priority, scanner findings, and vulnerable-version state remain urgency, remediation, and exposure-management inputs. They are not proof that exploitation occurred in a particular environment.

‍ ‍

Detection Engineering Coverage Interpretation

‍ ‍

The S25 detection content provides direct behavioral coverage when activity produces one or more of these implemented outcomes:

‍ ‍

·        Successful or suspicious access involving a validated AD FS DKM container or associated key object from an unexpected actor, source, process, session, service, or administrative path

‍ ‍

·        Permission, ownership, inheritance, auditing, delegated-right, or protected-object changes affecting validated signing-material sources

‍ ‍

·        DKM access followed by certificate, private-key, backup, recovery, archive, staging, transfer, cryptographic, or process-linked network activity

‍ ‍

·        Unexpected token-signing certificate access, export, backup, addition, replacement, promotion, rollover, or private-key permission change

‍ ‍

·        Successful monitored federation acceptance that lacks expected validated authentication or issuance lineage and includes independent compromise or federation-anomaly evidence

‍ ‍

·        Successful federation acceptance with authentication methods, MFA state, identities, claims, roles, groups, audiences, issuers, subjects, token lifetimes, account states, devices, sources, or application use inconsistent with expected policy

‍ ‍

·        Privileged, persistent, credential-related, security-control, logging, identity-provider, administrative, or sensitive downstream activity associated with a suspicious reconciled federation session

‍ ‍

·        Similar anomalous federation behavior across multiple identities, applications, relying parties, cloud environments, or sessions within a bounded time window

‍ ‍

Detection coverage is behavior-led rather than vulnerability-led. The rules do not identify CVE-2026-56155, CVE-2020-0837, CVE-2018-8340, ADFSDump, ADFSpoof, FoggyWeb, Golden SAML, the SolarWinds compromise, APT29, NOBELIUM, UNC2452, or another vulnerability, utility, malware family, campaign, or adversary by name. They identify observable DKM, directory, signing-material, certificate, federation-lineage, authentication-method, identity, relying-party, cloud, application, persistence, information-access, security-control, and network behavior.

‍ ‍

Named CVE, tooling, malware, campaign, and adversary coverage is procedure-led. S25 can detect a documented procedure when that procedure produces behavior observable within the report’s detection model. It cannot identify the vulnerability, utility, malware family, campaign, or actor from those behaviors alone.

‍ ‍

Direct Coverage

‍ ‍

Direct coverage applies where documented exploitation or post-compromise procedures produce behavior already implemented inside the S25 model.

‍ ‍

Directly Covered CVEs

‍ ‍

·        CVE-2026-56155 — AD FS elevation of privilege and DKM signing-material exposure

‍ ‍

·        CVE-2020-0837 — AD FS authentication-factor bypass through specially crafted authentication requests

‍ ‍

·        CVE-2018-8340 — AD FS security-feature bypass through improper MFA-request handling

‍ ‍

These CVEs are directly covered at the behavioral level when exploitation produces observable DKM access, signing-material interaction, authentication-method or MFA inconsistency, missing expected lineage, suspicious federation acceptance, identity inconsistency, persistent credential creation, privileged downstream activity, information access, security-control modification, or post-remediation behavior. Direct coverage does not mean every exploitation attempt will be detected or that an alert identifies the specific CVE.

‍ ‍

Directly Covered Tooling and Malware Procedure Sets

‍ ‍

·        ADFSDump — AD FS configuration, directory, database, and token-forgery prerequisite collection

‍ ‍

·        ADFSpoof — AD FS signing-material recovery and forged federation-token generation

‍ ‍

·        FoggyWeb — AD FS configuration-database and decrypted certificate collection, transfer, and supporting post-compromise activity

‍ ‍

These entries represent coverage of documented procedures only. They do not represent utility or malware-family identification, universal detection, or complete coverage of every associated capability.

‍ ‍

Directly Covered APT or Activity-Group Procedure Sets

‍ ‍

·        APT29, including NOBELIUM and UNC2452-associated procedures — compromised SAML signing-certificate use, forged SAML token creation, trusted identity impersonation, and downstream access

‍ ‍

This entry represents procedure coverage only. Actor attribution requires independent intelligence concerning infrastructure, victimology, tooling, targeting, operational patterns, campaign context, and incident-specific evidence.

‍ ‍

Coverage With Adaptation

‍ ‍

Coverage with adaptation applies where related activity falls near the federation-trust behavior model but requires additional local telemetry, protocol visibility, mappings, enrichment, or correlation.

‍ ‍

·        CVE-2025-59258 requires AD FS log-file access monitoring, sensitive-field classification, process and user attribution, archive or transfer correlation, and validation of whether disclosed information can support later compromise.

‍ ‍

·        CVE-2023-35348 requires replay-specific token identifiers, nonce or replay-cache state, duplicate-token correlation, protocol-aware validation, and relying-party session evidence. General missing-lineage or downstream rules alone cannot distinguish replay from forgery, theft, or logging failure.

‍ ‍

·        CVE-2022-30215 requires additional authoritative exploitation detail and local mapping before determining whether the observed path involves DKM access, privilege change, authentication-process manipulation, signing-material access, or another behavior.

‍ ‍

·        CVE-2021-33779 requires KDF version context, token-replay indicators, nonce or derived-key correlation, duplicate-use evidence, and relying-party session visibility.

‍ ‍

·        Direct private-key recovery or token construction performed entirely offline requires forensic, memory, cryptographic, artifact, or later relying-party evidence because no local process or AD FS event may exist.

‍ ‍

·        DKM access recorded without attribute-level or protected-material visibility requires validated object mapping, access-right interpretation, actor attribution, source attribution, and nearby signing-material behavior.

‍ ‍

·        Forged-token acceptance by relying parties that retain no assertion identifier, issuer, audience, claims, certificate, source, device, or local-session context requires application-specific logging or alternative session reconciliation.

‍ ‍

·        Federated access that lacks expected AD FS lineage requires complete farm-node ingestion, failover validation, clock alignment, retention validation, authentication-source mapping, and relying-party architecture review before promotion.

‍ ‍

·        AWS activity requires canonical binding between the monitored federation acceptance and the specific AWS federated session.

‍ ‍

·        Azure activity requires reliable federation-acceptance, normalized-identity, source-qualified activity, and relevant finding enrichment.

‍ ‍

·        Google Cloud activity requires reliable organization, project, normalized principal, source-qualified activity, and Security Command Center enrichment.

‍ ‍

·        Persistent application sessions, refresh tokens, API tokens, OAuth grants, service principals, access keys, application credentials, local accounts, and workload identities require platform-specific session, credential, role, and resource mappings.

‍ ‍

·        Information-repository access requires local repository classification, identity and session binding, data-event logging, sensitivity context, normal-volume baselines, and approved business-workflow exclusions.

‍ ‍

·        MagicWeb-related authentication-process subversion requires specific AD FS binary, module, authentication-certificate, file-integrity, process, and memory telemetry because it manipulates the authentication process rather than following the core SAML signing-key-acquisition path.

‍ ‍

·        Tooling or adversary procedures that use approved administrative systems, legitimate certificate utilities, backup software, identity-management platforms, common archive tools, cloud services, corporate VPNs, familiar devices, or normal business hours require stronger process, identity, session, change-control, and bounded-time correlation.

‍ ‍

Non-Coverage Conditions

‍ ‍

Non-coverage applies where activity does not produce observable DKM access, signing-material interaction, certificate or recovery behavior, authentication-method inconsistency, federation acceptance, lineage inconsistency, identity anomaly, downstream activity, persistence, information access, security-control modification, or post-remediation evidence.

‍ ‍

Non-coverage applies when activity remains limited to:

‍ ‍

·        Vulnerable or unpatched AD FS version state

‍ ‍

·        CVE identifiers, KEV status, scanner findings, patch findings, advisory references, or exposure-management records without behavioral evidence

‍ ‍

·        Broad or permissive DKM access-control conditions without evidence that an unauthorized principal accessed the validated object

‍ ‍

·        Public proof-of-concept availability, repository names, tool names, malware names, campaign names, actor names, filenames, hashes, certificate thumbprints, token values, source IPs, or strings without local behavior

‍ ‍

·        DKM access that cannot be attributed to a validated object, actor, source, process, session, access right, or bounded time window

‍ ‍

·        Private-key recovery and forged-token creation performed offline when no artifact, relying-party acceptance, downstream activity, or other observable effect exists

‍ ‍

·        Validly signed federation access without enough telemetry to validate expected authentication, MFA, token-replay state, and issuance lineage

‍ ‍

·        Missing AD FS events caused by logging gaps, incomplete farm-node ingestion, failover, clock drift, ingestion delay, retention loss, or relying-party design

‍ ‍

·        Missing MFA, impossible travel, unusual claims, rare sources, high-value identity use, or anomalous application access without stronger lineage or compromise evidence

‍ ‍

·        Extranet-lockout bypass, browser-cache credential exposure, SSRF, XSS, denial of service, logout failure, or unrelated information disclosure that does not produce the report’s DKM, signing-material, federation-lineage, identity, or downstream behavior

‍ ‍

·        Legitimate certificate rollover, backup, recovery, migration, federation testing, service-account maintenance, identity synchronization, emergency access, security validation, vendor support, or incident-response activity that cannot be distinguished from adversary behavior

‍ ‍

·        Cloud, SaaS, VPN, application, repository, identity, endpoint, certificate, or network anomalies that cannot be tied to the affected federation trust, identity, session, relying party, resource, or investigation window

‍ ‍

·        Actor, campaign, malware-family, vulnerability, or tooling attribution based solely on behavior covered by S25

‍ ‍

·        Environments where required DKM mapping, identity normalization, session reconciliation, farm-node coverage, relying-party logging, approved-workflow context, or retention is unavailable

‍ ‍

Current Coverage Count

‍ ‍

Directly Covered CVEs: 3

‍ ‍

·        CVE-2026-56155

‍ ‍

·        CVE-2020-0837

‍ ‍

·        CVE-2018-8340

‍ ‍

Directly Covered Tooling and Malware Procedure Sets: 3

‍ ‍

·        ADFSDump

‍ ‍

·        ADFSpoof

‍ ‍

·        FoggyWeb

‍ ‍

Directly Covered APT or Activity-Group Procedure Sets: 1

‍ ‍

·        APT29, including NOBELIUM and UNC2452-associated procedures

‍ ‍

The three counts remain separate because CVEs, tooling or malware procedures, and actor procedures are different coverage units. No combined coverage total should be used.

‍ ‍

Coverage Qualification

‍ ‍

Coverage is strongest where suspicious access to a validated AD FS DKM object or suspicious federation acceptance can be joined with an unexpected actor or source, signing-material handling, certificate or recovery activity, validated missing authentication or issuance lineage, inconsistent MFA or authentication method, identity-inconsistent claims, privileged downstream behavior, credential persistence, sensitive information access, security-control modification, or post-remediation activity.

‍ ‍

Coverage is weaker for offline private-key recovery, offline token construction, incomplete DKM object auditing, missing attribute-level access details, token replay without replay-specific identifiers, inconsistent farm-node ingestion, relying parties that retain limited assertion metadata, weak identity normalization, missing session identifiers, locally persistent application sessions, shared egress, familiar source infrastructure, approved cloud services, legitimate administrative tooling, short retention, and environments where directory, endpoint, certificate, AD FS, relying-party, identity, cloud, application, repository, and network telemetry cannot be joined.

‍ ‍

The report does not claim universal CVE-2026-56155 detection, universal CVE-2020-0837 detection, universal CVE-2018-8340 detection, universal AD FS signing-key theft detection, universal Golden SAML detection, universal forged-token detection, universal MFA-bypass detection, universal token-replay detection, universal cloud or SaaS detection, ADFSDump identification, ADFSpoof identification, FoggyWeb identification, complete APT29 coverage, universal KEV coverage, or standalone attribution. Detection confidence depends on telemetry completeness, DKM object validation, actor and source attribution, process visibility, signing-material classification, farm-node ingestion, authentication and federation-lineage integrity, session reconciliation, identity-state quality, claims visibility, relying-party logging, cloud mapping, approved exceptions, query validation, retention, performance testing, false-positive testing, and SOC triage readiness.

‍ ‍

Executive Exposure Statement

‍ ‍

The organization’s economic exposure is highest when AD FS identity-infrastructure activity creates uncertainty over whether signing material, authentication controls, token-replay protections, federation trust, identity integrity, privileged sessions, cloud access, SaaS activity, VPN access, application authorization, persistent credentials, sensitive information, partner trust, and downstream infrastructure remained intact. The strategic risk is not only that CVE-2026-56155 or another AD FS vulnerability exists, DKM permissions were excessive, MFA handling was flawed, token-replay protections were incomplete, public token-forging tools exist, or a validly signed session appeared unusual. The material risk is that an adversary may have acquired trusted signing material, bypassed expected authentication controls, replayed or generated federation tokens outside the expected process, impersonated high-value identities, created persistent access, weakened security controls, collected sensitive information, affected multiple relying parties, or undermined confidence in enterprise identity infrastructure.

‍ ‍

S40 — References

‍ ‍

Vendor and Platform Security Advisories

‍ ‍

·        Microsoft Security Response Center — CVE-2026-56155 Active Directory Federation Services Elevation of Privilege Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2026-56155

‍ ‍

·        Microsoft Security Response Center — CVE-2025-59258 Active Directory Federation Services Information Disclosure Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2025-59258

‍ ‍

·        Microsoft Security Response Center — CVE-2023-35348 Active Directory Federation Services Security Feature Bypass Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2023-35348

‍ ‍

·        Microsoft Support — KB5029028: Manage the Token-Replay Vulnerability Associated With CVE-2023-35348 — hxxps://support[.]microsoft[.]com/topic/kb5029028-how-to-manage-the-token-replay-attack-vulnerability-associated-with-cve-2023-35348-6debd3ae-1aac-4e09-a9c7-907446afb0d7

‍ ‍

·        Microsoft Security Response Center — CVE-2022-30215 Active Directory Federation Services Elevation of Privilege Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2022-30215

‍ ‍

·        Microsoft Learn — What Is KDFv2 for AD FS, CVE-2021-33779 — hxxps://learn[.]microsoft[.]com/windows-server/identity/ad-fs/operations/what-is-kdfv2

‍ ‍

·        Microsoft Security Response Center — CVE-2020-0837 Active Directory Federation Services Spoofing Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2020-0837

‍ ‍

·        Microsoft Security Response Center — CVE-2018-8340 Active Directory Federation Services Security Feature Bypass Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2018-8340

‍ ‍

·        Microsoft Learn — Best Practices for Securing AD FS and Web Application Proxy — hxxps://learn[.]microsoft[.]com/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs

‍ ‍

·        Microsoft Learn — Token-Signing Certificates — hxxps://learn[.]microsoft[.]com/windows-server/identity/ad-fs/design/token-signing-certificates

‍ ‍

Government Vulnerability and Exploitation Records

‍ ‍

·        NVD — CVE-2026-56155 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-56155

‍ ‍

·        NVD — CVE-2025-59258 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-59258

‍ ‍

·        NVD — CVE-2023-35348 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2023-35348

‍ ‍

·        NVD — CVE-2022-30215 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2022-30215

‍ ‍

·        NVD — CVE-2021-33779 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2021-33779

‍ ‍

·        NVD — CVE-2020-0837 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2020-0837

‍ ‍

·        NVD — CVE-2018-8340 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2018-8340

‍ ‍

·        CISA — Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

‍ ‍

Threat Technique Framework

‍ ‍

·        MITRE ATT&CK — hxxps://attack[.]mitre[.]org/

‍ ‍

Original Security Research, Tooling, and Threat Analysis

‍ ‍

·        Mandiant — ADFSDump — hxxps://github[.]com/mandiant/ADFSDump

‍ ‍

·        Mandiant — ADFSpoof — hxxps://github[.]com/mandiant/ADFSpoof

‍ ‍

·        Microsoft Security — FoggyWeb: Targeted NOBELIUM Malware Leads to Persistent Backdoor — hxxps://www[.]microsoft[.]com/security/blog/2021/09/27/foggyweb-targeted-nobelium-malware-leads-to-persistent-backdoor/

‍ ‍

·        Microsoft Security — MagicWeb: NOBELIUM’s Post-Compromise Technique to Authenticate as Anyone — hxxps://www[.]microsoft[.]com/security/blog/2022/08/24/magicweb-nobeliums-post-compromise-trick-to-authenticate-as-anyone/

‍ ‍