[EXP] Windows Netlogon Remote Code Execution and Domain Controller Compromise Exposure

Report Type: EXP

Threat Category: Windows Netlogon Remote Code Execution and Domain-Controller Trust Compromise

Assessment Date: June 1, 2026

Primary Impact Domain: Active Directory / Domain-Controller Identity Control Plane

Secondary Impact Domains: Privileged Identity, Machine-Account Trust, Domain Trusts, Replication Permissions, Backup Infrastructure, Cloud and SaaS Administration, Source-Code and CI/CD Systems, Business-Critical Applications

Affected Asset Class: Windows Server Domain Controllers, Active Directory Infrastructure, Domain-Joined Systems, Privileged Accounts, Machine Accounts, Service Accounts, Identity-Integrated Enterprise Systems

Threat Objective Classification: Domain-Controller Compromise, Active Directory Trust Manipulation, Privileged Authentication Expansion, Replication-Like Access, Downstream Enterprise Access, and Identity-Control-Plane Disruption

BLUF

‍ Windows Netlogon remote code execution and domain-controller compromise exposure create critical enterprise risk because successful exploitation can place Active Directory trust, domain-controller integrity, machine-account state, privileged authentication, and downstream access control in question. The core risk is not limited to whether a Windows Server vulnerability exists; it is whether an attacker can compromise or create uncertainty around the systems that authenticate users, authorize access, maintain machine trust, support domain relationships, and protect business-critical systems. Suspicious Netlogon-adjacent or MS-NRPC activity becomes materially significant when followed by domain-controller account manipulation, machine-account password reset abuse, trust modification, privileged authentication expansion, replication-like access, security-control disruption, or movement into sensitive enterprise systems. Immediate executive action is required to validate domain-controller exposure, harden Netlogon and Active Directory control paths, confirm telemetry completeness, and ensure suspected domain-controller trust compromise is treated as an identity-plane incident.

Executive Risk Translation

Windows Netlogon remote code execution shifts the business risk from server vulnerability exposure to loss of confidence in the enterprise identity control plane. If domain-controller trust cannot be validated, leadership may need to assume that privileged credentials, machine-account relationships, domain trusts, replication permissions, service accounts, backup trust, and downstream access paths require investigation or restoration. That response can expand quickly into Active Directory integrity validation, privileged credential reset planning, domain-controller forensic review, domain trust review, endpoint and network scoping, backup assurance, legal and executive reporting, and broader recovery work across systems that depend on Active Directory.

S3 — Why This Matters Now

·        Domain controllers are enterprise trust anchors for authentication, authorization, privileged access, machine-account relationships, domain trust, and access to business-critical systems.

·        Netlogon-adjacent abuse can carry greater business impact than ordinary server exploitation because downstream systems may continue trusting domain-authenticated activity even when domain-controller integrity is uncertain.

·        Suspicious domain-controller interaction can force the organization to validate Active Directory state, privileged group membership, machine-account integrity, replication permissions, domain trusts, and authentication flows.

·        The highest-risk condition occurs when abnormal Netlogon, MS-NRPC, RPC, SMB, or domain-controller service activity is followed by machine-account changes, privileged authentication, domain trust modification, replication-like access, directory-service changes, or security-control disruption.

·        Legitimate domain join activity, trust repair, replication maintenance, backup operations, vulnerability scanning, patching, or identity-infrastructure administration can resemble suspicious behavior and increase triage burden.

·        Missing Netlogon diagnostic logging, incomplete Directory Services auditing, weak domain-controller EDR coverage, poor asset inventory, or missing change-control records can force broader investigation because identity-plane trust cannot be proven quickly.

·        Downstream access to identity infrastructure, backup systems, privileged management platforms, cloud consoles, SaaS administration portals, source-code systems, CI/CD platforms, databases, file servers, or sensitive applications can expand the incident beyond the domain-controller layer.

S4 — Key Judgments

·        Windows Netlogon remote code execution and domain-controller compromise exposure should be treated as an identity-control-plane risk, not only a vulnerability-management issue.

·        The primary enterprise risk is unauthorized or suspicious domain-controller interaction that may affect machine-account state, domain-controller trust, privileged authentication, replication permissions, or Active Directory integrity.

·        Suspicious Netlogon-adjacent activity followed by domain-controller account modification, machine-account password reset, domain trust change, privileged group modification, replication-permission change, or abnormal privileged authentication is the strongest executive risk signal.

·        Patch state, scanner output, exposed Netlogon services, isolated Netlogon errors, or single RPC connections should not be treated as confirmed compromise without supporting identity-plane, endpoint, network, or incident-response evidence.

·        Business exposure increases sharply when suspicious activity involves privileged users, domain-controller machine accounts, service accounts, identity administrators, security tools, backup infrastructure, cloud administrators, or accounts with broad downstream access.

·        Incomplete telemetry increases cost because the organization may need to prove Active Directory integrity through expanded forensic, identity, endpoint, network, and change-management review.

·        The most damaging outcome occurs when domain-controller compromise enables credential theft, privileged identity abuse, replication-like access, lateral movement, ransomware staging, backup compromise, cloud or SaaS administrative access, data theft, extortion, or loss of confidence in Active Directory.

S5 — Executive Risk Summary

Business Risk

Windows Netlogon remote code execution and domain-controller compromise exposure can undermine confidence in the organization’s ability to control, validate, and recover its core identity infrastructure. Risk increases when suspicious activity involves domain controllers, privileged accounts, machine accounts, domain trusts, replication permissions, backup systems, identity-management systems, endpoint-management platforms, cloud or SaaS administration, developer platforms, source-code systems, CI/CD environments, or sensitive business systems.

Technical Cause

The risk is driven by suspicious or unauthorized interaction with Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service paths that may precede or enable machine-account changes, domain-controller account manipulation, trust modification, privileged authentication expansion, replication-like access, directory-service object changes, endpoint execution on domain controllers, security-control disruption, or downstream movement from systems involved in suspicious domain-controller activity.

Threat Posture

The threat posture is elevated because suspected or confirmed Netlogon-linked domain-controller compromise can affect the enterprise identity control plane while downstream systems may continue accepting authentication and authorization decisions as legitimate. The posture becomes critical when suspicious domain-controller interaction is followed by machine-account modification, trust manipulation, privileged group changes, replication-permission changes, credential access, lateral movement, backup-system access, cloud or SaaS control-plane activity, ransomware staging, extortion, or broad loss of confidence in Active Directory.

Executive Decision Requirement

Executives must require measurable assurance that domain controllers are inventoried, exposed Netlogon paths are hardened, Active Directory object changes are auditable, privileged identity activity is governed, domain-controller telemetry is complete, suspicious Netlogon-adjacent activity can be correlated with downstream identity-plane behavior, and response teams can rapidly validate, contain, scope, and recover from suspected domain-controller trust compromise.

S6 — Executive Cost Summary

Windows Netlogon remote code execution and domain-controller compromise exposure create scenario-based financial exposure when an organization must prove or disprove whether Active Directory trust, domain-controller integrity, machine-account state, privileged authentication, replication permissions, and downstream system access remained intact. The estimated impact is driven by domain-controller forensic review, Active Directory object validation, privileged credential reset scope, machine-account and service-account review, domain trust validation, replication-permission review, Netlogon and authentication telemetry reconstruction, endpoint and network investigation, backup-trust validation, cloud and SaaS administrative scoping, legal and executive reporting, and potential ransomware or extortion response.

Low Impact Scenario

Rapid detection confirms attempted exploitation, suspicious Netlogon-adjacent activity, domain-controller service probing, isolated authentication instability, or a limited number of suspicious domain-controller events. No unauthorized domain-controller account manipulation is confirmed, no machine-account password reset abuse is identified, no domain trust change occurs, no privileged group change is detected, no replication-permission abuse is observed, no credential theft is confirmed, no ransomware or extortion activity occurs, and telemetry is sufficient to validate the domain-controller activity path quickly; estimated impact $1M – $4M.

Moderate Impact Scenario

Confirmed or strongly suspected domain-controller trust manipulation, machine-account modification, suspicious privileged authentication, replication-like access, or identity-plane uncertainty requires the organization to treat the event as a domain-controller trust incident even without confirmed ransomware, confirmed data theft, or full enterprise compromise. Response requires privileged credential reset planning, domain-controller forensic review, Active Directory object validation, machine-account and service-account scoping, domain trust review, replication-permission review, domain-controller hardening, endpoint and network investigation, SOC surge activity, change-management validation, backup-trust review, executive reporting, and downstream validation of identity infrastructure, cloud, SaaS, developer-platform, source-code, CI/CD, backup, and sensitive business-system exposure; estimated impact $8M – $30M.

High Impact Scenario

Netlogon-linked domain-controller compromise becomes an enterprise-impact pathway when it leads to or must be treated as broad Active Directory compromise, including domain or forest recovery, privileged-account reset at scale, domain-controller rebuild, identity-service outage, credential theft, replication abuse, ransomware staging, backup-system access, cloud or SaaS administrative exposure, source-code or CI/CD exposure, data theft, extortion, or broad loss of confidence in enterprise identity controls. The upper end of this range applies only when the organization must restore Active Directory trust, rebuild or recover domain-controller infrastructure, validate backup integrity, rotate high-risk credentials, scope downstream systems at enterprise scale, or recover business-critical systems affected through the compromised identity path; estimated impact $35M – $150M+.

S6A — Key Cost Drivers

·        Number and criticality of affected or suspicious domain controllers.

·        Whether suspicious activity involves writable domain controllers, privileged domain accounts, domain-controller machine accounts, service accounts, identity administrators, backup administrators, security administrators, or low-frequency high-privilege accounts.

·        Ability to reconstruct the activity path across Netlogon-adjacent events, MS-NRPC activity, RPC endpoint mapper traffic, SMB domain-controller service access, Windows Security logs, Directory Services events, authentication logs, EDR telemetry, NDR telemetry, and change-management records.

·        Scope of domain-controller forensic review, Active Directory object validation, machine-account review, service-account review, privileged group review, domain trust review, replication-permission review, and backup-trust validation.

·        Scope of privileged credential reset, administrator account validation, service-account rotation, domain-controller access review, emergency access review, and identity-management control validation.

·        Whether suspicious activity is followed by privileged authentication expansion, lateral movement, credential access, replication-like activity, security-control disruption, outbound communication, ransomware staging, data access, or extortion behavior.

·        Extent of downstream access to identity infrastructure, backup systems, endpoint-management systems, privileged management platforms, file servers, databases, cloud consoles, SaaS administration portals, source-code systems, CI/CD platforms, or sensitive business applications.

·        Completeness and reliability of Windows Security, Directory Services, System, Netlogon, EDR, NDR, authentication, VPN, DNS, proxy, firewall, cloud, SaaS, and SIEM telemetry.

·        Strength of domain-controller inventory, Active Directory site topology, replication partner inventory, administrative source baselines, approved maintenance records, trust repair records, domain join records, and backup or identity-management workflow documentation.

·        Need for external incident response, forensic support, Active Directory recovery specialists, legal review, cyber-insurance coordination, customer communication, regulatory analysis, executive reporting, board-level governance, or business restoration support when domain-controller trust cannot be validated quickly.

Most Likely Scenario Justification

Moderate scenario is most likely because suspected Windows Netlogon-linked domain-controller compromise can create significant investigation, containment, and assurance cost even when ransomware, confirmed data theft, or full enterprise compromise is not proven. The estimate moves toward the lower end when Netlogon and Active Directory telemetry is complete, no domain-controller account changes occurred, no machine-account password reset abuse is observed, privileged accounts are not involved, domain trusts and replication permissions remain unchanged, and change records reconcile quickly. The estimate moves toward the upper end when telemetry is incomplete, privileged or machine accounts are involved, domain-controller forensic review is required, Active Directory object changes require validation, downstream access must be scoped, or backup, cloud, SaaS, source-code, CI/CD, or sensitive business-system exposure cannot be ruled out quickly.

S6B — Compliance and Risk Context

Figure 1

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Windows Netlogon Domain-Controller Trust Compromise and Active Directory Control-Plane Exposure

Risk Description

Adversaries may exploit or abuse Windows Netlogon-adjacent domain-controller paths to affect domain-controller trust, manipulate machine-account state, modify domain-controller accounts, alter domain trusts, expand privileged authentication, access replication-related capabilities, modify sensitive Active Directory objects, impair security controls, or move downstream into systems that rely on Active Directory for authentication and authorization. This may reduce confidence in identity infrastructure, privileged access, endpoint trust, backup integrity, cloud and SaaS administration, developer systems, source-code repositories, CI/CD environments, and business-critical applications.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $8M – $35M+ for materially exposed enterprise environments with domain-controller dependency, broad internal domain-controller service reachability, incomplete Netlogon or Directory Services telemetry, privileged-account exposure, weak change-management validation, or high downstream dependency on Active Directory. Exposure may exceed $50M – $150M+ where confirmed domain-controller compromise requires enterprise-scale Active Directory recovery, privileged credential reset, domain or forest restoration, ransomware or extortion response, backup-trust validation, cloud or SaaS administrative scoping, or business-critical system restoration.

S7 — Risk Drivers

·        Domain controllers are central to enterprise authentication, authorization, machine-account trust, privileged access, and downstream application access.

·        Netlogon-adjacent activity directed at domain controllers can create uncertainty about whether identity-plane state remained trustworthy.

·        Suspicious activity involving machine-account changes, domain-controller account changes, domain trust modification, privileged group changes, replication permissions, or sensitive Active Directory objects materially increases business exposure.

·        Privileged, administrative, service, security, backup, identity-management, domain-controller machine, dormant, recently re-enabled, or low-frequency accounts can materially increase downstream risk.

·        Broad internal access to domain-controller services can make suspicious Netlogon, RPC, SMB, or authentication activity harder to distinguish from legitimate infrastructure activity.

·        Missing Netlogon diagnostic logging, incomplete Directory Services auditing, weak EDR coverage on domain controllers, metadata-only network visibility, or stale asset inventory can force broader investigation and assurance work.

·        Incomplete change-management records, weak domain join baselines, unclear trust repair processes, incomplete replication partner inventories, and undocumented identity-management workflows can increase false positives and response cost.

·        Downstream access to identity infrastructure, domain controllers, privileged management systems, jump hosts, backup systems, endpoint-management platforms, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD systems, databases, file servers, or sensitive applications increases operational and financial impact.

·        Security-control disruption, audit-policy change, log-clearing behavior, endpoint-control impairment, or monitoring gaps near suspicious domain-controller activity increase concern that the organization may not be seeing the full incident.

·        Ransomware staging, backup-system access, credential theft, data access, cloud or SaaS control-plane activity, source-code exposure, CI/CD exposure, or extortion behavior can expand the incident from identity infrastructure into enterprise-wide business disruption.

S8 — Bottom Line for Executives

Windows Netlogon remote code execution and domain-controller compromise exposure should be treated as a high-priority identity-control-plane risk because it can affect the systems that determine who and what the enterprise trusts. The executive question is not only whether vulnerable Windows Servers exist; it is whether the organization can prove that domain-controller trust, machine-account state, privileged authentication, replication permissions, domain trusts, Active Directory object integrity, and downstream access remained intact. Response must focus on validating identity-plane integrity, hardening exposed domain-controller paths, scoping privileged and machine-account activity, confirming telemetry completeness, and ensuring suspected domain-controller compromise can be contained before it becomes enterprise-wide trust failure.

S9 — Board-Level Takeaway

Windows Netlogon domain-controller compromise exposure turns Active Directory into a board-level resilience and trust issue. The risk is not limited to patching Windows Server; it is the possibility that attackers can compromise or cast doubt on the identity systems that authorize access across the enterprise. Leadership should require measurable assurance that domain controllers are hardened, Netlogon and Active Directory telemetry is complete, privileged identity is governed, machine-account and trust changes are auditable, suspicious domain-controller activity is escalated rapidly, and downstream access to identity, backup, cloud, SaaS, developer, source-code, CI/CD, and business-critical systems can be scoped with confidence.

S10 — Threat Overview

Windows Netlogon remote code execution and domain-controller compromise exposure describes adversary behavior intended to exploit or abuse Netlogon-adjacent domain-controller communication in a way that can place Active Directory trust, machine-account state, privileged authentication, and downstream identity control in question. The behavior is most relevant when suspicious Netlogon, MS-NRPC, RPC, SMB, or domain-controller service activity is followed by domain-controller account manipulation, machine-account password reset abuse, domain trust modification, privileged group change, replication-like access, abnormal authentication expansion, or security-control disruption.

·        This is not only a single-CVE, single-packet, or vulnerability-state model.

·        The core threat behavior is abuse of a domain-controller trust pathway where Active Directory integrity may need to be proven after suspicious Netlogon-adjacent activity.

·        The primary risk is loss of confidence in the domain-controller and identity-control layer used to authenticate users, authorize access, maintain machine trust, and support enterprise operations.

·        Netlogon, MS-NRPC, RPC, SMB, Windows Security, Directory Services, authentication, endpoint, and network evidence may be incomplete or difficult to reconcile while downstream systems continue trusting domain-authenticated activity.

·        The behavior can allow attackers to affect or create uncertainty around privileged identity, machine accounts, domain trusts, replication permissions, backup trust, cloud and SaaS administration, developer platforms, source-code systems, CI/CD environments, and sensitive business systems.

·        Current proof-point activity should support the relevance of the behavior class but should not narrow the report into a single-CVE or single-proof-of-concept analysis.

S11 — Threat Classification and Type

Threat Type

Domain-controller trust compromise and Active Directory control-plane exposure

Threat Sub-Type

Windows Netlogon remote code execution exposure, Netlogon-adjacent domain-controller service abuse, MS-NRPC trust manipulation, domain-controller account manipulation, machine-account password reset abuse, privileged authentication expansion, domain trust modification, replication-permission abuse, and downstream identity-plane compromise.

Operational Classification

Intrusion-enabling identity-control-plane compromise pathway

Primary Function

Exploit or abuse Netlogon-adjacent domain-controller communication paths to affect, manipulate, or create uncertainty around Active Directory trust, machine-account state, privileged authentication, domain-controller integrity, replication permissions, and downstream access control.

S12 — Campaign or Activity Overview

Figure 2

This report assesses Windows Netlogon remote code execution and domain-controller compromise exposure as a durable behavior class rather than a single campaign. The activity pattern involves adversaries attempting to exploit or abuse domain-controller Netlogon-adjacent service paths where successful or suspected activity can affect machine-account relationships, domain-controller trust, privileged identity, replication-related permissions, or Active Directory integrity.

·        The activity is best understood as an identity-control-plane trust failure rather than a simple vulnerability scan or isolated server exploit.

·        Adversaries may target domain-controller Netlogon, MS-NRPC, RPC endpoint mapper, SMB, authentication, machine-account, trust, or replication-adjacent paths.

·        The behavior may involve direct exploitation, internal staging, suspicious source-to-domain-controller service access, repeated MS-NRPC or RPC interaction, machine-account manipulation, privileged authentication expansion, or replication-like access.

·        The activity may remain limited to suspicious domain-controller interaction, or it may progress into Active Directory object modification, credential access, domain trust manipulation, privileged group changes, lateral movement, backup-system access, cloud or SaaS control-plane activity, developer-platform access, source-code exposure, CI/CD interaction, ransomware staging, or extortion.

·        The activity becomes highest risk when suspicious domain-controller interaction involves privileged accounts, domain-controller machine accounts, identity administrators, backup administrators, service accounts, security administrators, dormant accounts, recently re-enabled accounts, or low-frequency high-privilege accounts.

·        The report should remain focused on durable domain-controller compromise behavior and identity-plane exposure rather than one exploit string, one CVE, one proof-of-concept tool, one source host, one event ID, or one packet signature.

S13 — Targets and Exposure Surface

The exposure surface includes domain controllers, Netlogon and MS-NRPC service paths, Active Directory trust relationships, machine-account relationships, privileged identity paths, replication-related permissions, and downstream systems that depend on Active Directory for authentication and authorization.

·        Writable domain controllers and read-only domain controllers.

·        Netlogon, MS-NRPC, RPC endpoint mapper, SMB, and domain-controller service interfaces.

·        Active Directory domains, forests, trust relationships, replication topology, domain-controller sites, and domain-controller service exposure paths.

·        Domain-controller machine accounts, privileged domain accounts, service accounts, identity-administration accounts, backup-administration accounts, security-administration accounts, and emergency-access accounts.

·        Machine-account password reset workflows, domain join workflows, trust repair workflows, replication administration, privileged group administration, delegation settings, Group Policy, and sensitive directory-service object management.

·        Identity infrastructure, privileged management systems, jump hosts, endpoint-management systems, backup systems, source-code systems, CI/CD infrastructure, databases, file servers, and sensitive internal applications that rely on Active Directory.

·        Cloud consoles, cloud APIs, SaaS administration portals, identity administration portals, developer platforms, source-code repositories, CI/CD platforms, and privileged business applications accessed through domain-integrated identity paths.

·        Environments with incomplete Netlogon diagnostic logging, incomplete Directory Services auditing, limited domain-controller EDR coverage, metadata-only network telemetry, weak asset inventory, incomplete domain-controller topology documentation, or missing change-control records.

·        Environments that permit broad internal access to domain-controller services or have legacy systems, third-party integrations, or unclear administrative pathways that generate secure-channel noise.

S14 — Sectors / Countries Affected

Sectors Affected

·        Financial services.

·        Healthcare and life sciences.

·        Technology and software development.

·        Manufacturing and industrial operations.

·        Energy and utilities.

·        Retail and e-commerce.

·        Education and research institutions.

·        Government and public-sector organizations.

·        Telecommunications and managed infrastructure providers.

·        Legal, consulting, and professional services organizations with high-value identity dependencies.

·        Organizations with Active Directory dependency, domain-controller exposure, privileged domain access, third-party administration, cloud or SaaS administration, source-code systems, CI/CD environments, backup infrastructure, regulated data environments, or business-critical systems tied to domain authentication.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because Windows Server, Active Directory, and domain-controller infrastructure are broadly deployed across enterprise environments.

·        Countries with large enterprise networks, regulated industries, critical infrastructure, government operations, cloud administration dependencies, technology development, or high-value business-service environments may face elevated operational exposure.

·        Country-specific impact should be assessed by domain-controller exposure, Active Directory architecture, patch posture, privileged-account governance, segmentation, telemetry quality, backup resilience, change-management maturity, and incident-response readiness rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require enough technical capability to understand Windows domain-controller behavior, Netlogon and MS-NRPC interaction, RPC and SMB service exposure, machine-account relationships, domain trust behavior, privileged authentication, Active Directory object state, replication-related permissions, and downstream identity-dependent access. The behavior can be attempted through direct exploitation, internal staging, abuse of a compromised source host, or post-access identity manipulation, but effective use requires operational judgment and awareness of how domain-controller activity is logged, correlated, and validated.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may involve noisy probing, repeated domain-controller service access, internal scanning, or use of commodity proof-of-concept behavior from unmanaged or workstation-class systems. Higher-maturity activity involves staging from previously compromised internal hosts, using plausible administrative paths, pacing domain-controller interaction, blending with legacy secure-channel noise, delaying follow-on activity, or moving into privileged identity, backup, cloud, SaaS, developer-platform, source-code, CI/CD, or sensitive business-system access.

Operational Scale

Single-domain-controller to enterprise-scale

Operational scale ranges from suspicious activity against one domain controller to broader enterprise impact when attackers affect multiple domain controllers, privileged accounts, machine accounts, domain trusts, replication permissions, backup infrastructure, identity-management systems, endpoint-management systems, cloud or SaaS administration, developer platforms, source-code systems, CI/CD environments, or business-critical applications.

Escalation Likelihood

High

Escalation likelihood is high when suspicious Netlogon-adjacent activity involves privileged accounts, domain-controller machine accounts, identity administrators, backup administrators, service accounts, security administrators, dormant accounts, recently re-enabled accounts, low-frequency high-privilege accounts, or source systems outside approved administrative pathways. Escalation likelihood increases further when suspicious domain-controller interaction is followed by machine-account changes, privileged authentication expansion, domain trust modification, replication-like access, security-control disruption, credential access, lateral movement, backup-system access, ransomware staging, cloud or SaaS administrative activity, or extortion behavior.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        Domain controllers are high-value targets because they support authentication, authorization, privileged access, machine-account relationships, trust relationships, and access to business-critical systems.

·        Attackers benefit directly from compromising or creating uncertainty around Active Directory because downstream systems may continue treating domain-authenticated activity as legitimate.

·        Netlogon, MS-NRPC, RPC, SMB, and domain-controller service paths provide valuable opportunities when domain-controller exposure, internal segmentation, or administrative baselines are weak.

·        Privileged domain accounts, domain-controller machine accounts, service accounts, identity administrators, backup administrators, security administrators, dormant accounts, recently re-enabled accounts, and low-frequency high-privilege accounts create high-value access opportunities.

·        Broad internal access to domain-controller services can increase attacker opportunity and make malicious source-to-domain-controller activity harder to separate from normal infrastructure behavior.

·        Incomplete Netlogon, Windows Security, Directory Services, EDR, NDR, authentication, VPN, cloud, SaaS, or SIEM telemetry increases attacker opportunity and response uncertainty.

·        Internal systems reachable through Active Directory trust may include identity infrastructure, domain controllers, privileged management systems, jump hosts, backup systems, source-code systems, CI/CD platforms, databases, file servers, endpoint-management systems, and sensitive business applications.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup dependencies increase the value of domain-controller compromise beyond the Active Directory layer.

Most Likely Targets

·        Writable domain controllers and read-only domain controllers.

·        Organizations with exposed, poorly segmented, or difficult-to-monitor domain-controller service paths.

·        Environments with incomplete Windows Server, domain-controller, or Netlogon patch posture.

·        Privileged domain accounts, identity administrators, domain administrators, backup administrators, security administrators, service accounts, emergency-access accounts, stale accounts, dormant accounts, recently re-enabled accounts, and low-frequency high-privilege accounts.

·        Domain-controller machine accounts, machine-account password workflows, domain join workflows, trust repair workflows, and replication-administration paths.

·        Active Directory domains, forests, trusts, replication permissions, privileged groups, delegation settings, Group Policy, and sensitive directory-service objects.

·        Identity infrastructure, privileged management systems, jump hosts, firewall management systems, endpoint-management systems, backup systems, source-code systems, CI/CD infrastructure, databases, file servers, and sensitive internal applications.

·        Cloud consoles, SaaS administration portals, identity administration portals, developer platforms, source-code repositories, CI/CD platforms, and privileged business applications tied to domain-integrated identity.

·        Environments with incomplete Netlogon telemetry, weak domain-controller inventory, incomplete asset-role enrichment, broad internal domain-controller access, unclear administrative source baselines, missing change-management records, or limited incident-response readiness.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1: Netlogon-Adjacent Remote Service Exploitation or Abuse

The adversary reaches and attempts to exploit or abuse Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service behavior through internal access, a compromised source host, weak segmentation, or an exposed domain-controller service path. This stage should not be treated as internet-facing exploitation unless the environment actually exposes the relevant service externally.

·        T1210 — Exploitation of Remote Services.

Stage 2: Machine-Account or Domain-Controller Account Manipulation

If exploitation or abuse succeeds, the adversary may manipulate machine-account password state, domain-controller account properties, privileged group relationships, or other identity-plane account attributes. This mapping should be used only when account modification or account-control behavior is observed or strongly supported.

·        T1098 — Account Manipulation.

Stage 3: Active Directory Discovery and Domain Context Development

The adversary may enumerate domain systems, accounts, groups, domain-controller relationships, or reachable resources to identify follow-on paths. This stage should remain conditional and should not be treated as confirmed behavior unless discovery activity is observed.

·        T1018 — Remote System Discovery.

·        T1087 — Account Discovery.

Stage 4: Replication-Like Credential Access or Domain Secret Exposure

If the adversary obtains sufficient privilege or abuses domain-controller trust, they may attempt replication-like access to obtain credential material from Active Directory. This mapping should be reserved for observed or strongly supported replication-style credential access, not ordinary Netlogon probing.

·        T1003.006 — OS Credential Dumping: DCSync.

Stage 5: Lateral Movement Through Domain-Authenticated Access

After domain-controller trust manipulation, privileged authentication, credential access, or account manipulation, the adversary may use remote services to access additional systems. This mapping should be used when follow-on remote access or lateral movement is observed after the domain-controller interaction.

·        T1021 — Remote Services.

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

Windows Netlogon remote code execution and domain-controller compromise exposure begins when an adversary reaches or stages activity against a domain-controller service path. The attacker’s objective is to exploit or abuse Netlogon-adjacent, MS-NRPC, RPC, SMB, or related domain-controller communication in a way that may affect machine-account state, domain-controller trust, privileged authentication, replication-related permissions, or Active Directory integrity. The attack path is defined by domain-controller service reachability, suspicious Netlogon-adjacent interaction, potential machine-account or trust manipulation, identity-plane expansion, and downstream access to systems that depend on Active Directory.

Stage 1: Domain-Controller Service Reachability

The adversary reaches a domain-controller service path through internal access, a compromised source host, weak segmentation, broad internal service reachability, or an exposed domain-controller service path. This stage creates the opportunity to interact with Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service interfaces. Reachable domain-controller services are not compromise by themselves, but they establish the pathway that becomes material when paired with suspicious source context, repeated service interaction, authentication anomalies, or downstream identity-plane activity.

Stage 2: Suspicious Netlogon-Adjacent Interaction

The adversary attempts to exploit or abuse Netlogon-adjacent domain-controller behavior through repeated MS-NRPC, RPC, SMB, or domain-controller service interaction. The activity may originate from a workstation, unmanaged host, VPN-connected system, branch network, compromised server, or system without an approved domain-controller administration role. The key signal is not a single Netlogon error or scanner finding; it is abnormal source-to-domain-controller interaction that does not align with the expected host role, network segment, timing, administrative path, or change record.

Stage 3: Machine-Account or Domain-Controller Trust Manipulation

If exploitation or abuse succeeds, the adversary may affect machine-account password state, domain-controller account properties, privileged group relationships, domain trust configuration, replication permissions, or other Active Directory control-plane objects. This stage changes the incident from suspicious service interaction into a potential identity-plane trust event. The organization must determine whether domain-controller trust, machine-account relationships, privileged access, and Active Directory object integrity remained intact.

Stage 4: Privileged Authentication and Identity-Plane Expansion

After trust manipulation or suspected domain-controller compromise, the adversary may use privileged authentication, machine-account context, service-account access, replication-like access, or newly modified identity-plane state to expand access. This stage may include privileged logons, abnormal Kerberos or NTLM activity, service-ticket anomalies, access to identity infrastructure, or interaction with systems that rely on Active Directory for authorization. Risk increases when the activity involves domain administrators, identity administrators, backup administrators, security administrators, service accounts, or low-frequency high-privilege accounts.

Stage 5: Downstream Enterprise Access

If the activity is not contained, the adversary may move from the domain-controller trust path into downstream enterprise systems. This can include privileged management systems, jump hosts, endpoint-management platforms, backup systems, file servers, databases, source-code systems, CI/CD platforms, cloud consoles, SaaS administration portals, and sensitive business applications. The incident expands beyond the domain-controller layer when Active Directory trust is used to reach systems that support business operations, recovery, regulated data, or administrative control.

Stage 6: Recovery Trust and Business Impact Expansion

When domain-controller trust cannot be validated quickly, the organization may need to treat the event as a broader identity-control-plane incident. Response can expand into Active Directory integrity validation, privileged credential resets, service-account review, domain trust review, replication-permission review, domain-controller rebuild planning, backup-trust validation, cloud and SaaS scoping, endpoint investigation, and executive or legal reporting. Business impact increases because responders must prove both what the adversary did and whether the enterprise identity foundation remained trustworthy during the activity window.

S19 — Attack Chain Risk Amplification Summary

Windows Netlogon remote code execution and domain-controller compromise exposure amplifies risk because it targets identity systems that downstream enterprise services already trust. The chain becomes materially more dangerous when suspicious domain-controller interaction is followed by machine-account changes, privileged authentication, domain trust modification, replication-like access, directory-service changes, security-control disruption, or access to high-value systems.

·        Domain-controller service reachability creates a high-value pathway because Netlogon, MS-NRPC, RPC, SMB, and related services support core Active Directory operations.

·        Suspicious activity from unmanaged hosts, workstation networks, VPN ingress ranges, branch networks, newly observed systems, or non-administrative servers increases concern because these sources should not normally interact with domain controllers in high-risk ways.

·        Repeated Netlogon-adjacent, MS-NRPC, RPC, or SMB activity increases risk when it does not align with approved replication, monitoring, backup, identity-management, vulnerability-management, maintenance, or domain join workflows.

·        Machine-account password reset abuse, domain-controller account modification, domain trust change, privileged group change, or replication-permission change turns the activity into an identity-plane trust event.

·        Privileged authentication expansion after suspicious domain-controller interaction increases concern that the activity is moving from attempted exploitation into operational control.

·        Security-control disruption, audit-policy change, log-clearing behavior, endpoint-control impairment, or monitoring gaps near the activity window increase uncertainty and response burden.

·        Downstream access to identity infrastructure, privileged management systems, jump hosts, backup systems, endpoint-management platforms, cloud consoles, SaaS administration portals, source-code systems, CI/CD platforms, databases, file servers, or sensitive applications expands the impact beyond the domain-controller layer.

·        Backup-system access, ransomware staging, credential theft, data access, cloud or SaaS administrative activity, source-code exposure, CI/CD exposure, or extortion behavior can turn domain-controller compromise into enterprise-scale business disruption.

·        Incomplete Netlogon logging, weak Directory Services auditing, missing domain-controller EDR, metadata-only network visibility, stale asset inventory, or missing change records can force broader validation because the organization cannot quickly prove identity-plane integrity.

·        Response burden increases because teams must validate both adversary activity and the trustworthiness of Active Directory, privileged identity, domain-controller state, and downstream access paths.

S20 — Tactics, Techniques, and Procedures

Figure 3

Domain-Controller Service Access

Adversaries may reach domain-controller service paths from compromised internal systems, unmanaged hosts, workstation networks, VPN-connected systems, branch networks, or other sources outside approved administrative pathways. Relevant activity includes abnormal Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB, or domain-controller service access. This behavior becomes risk-relevant when source role, timing, destination, frequency, or change context does not match expected domain-controller operations.

Netlogon-Adjacent Exploitation or Abuse

Adversaries may attempt to exploit or abuse Netlogon-adjacent behavior to affect domain-controller trust, machine-account state, or identity-plane control. Activity may appear as repeated MS-NRPC interaction, abnormal RPC or SMB domain-controller access, new source-to-domain-controller paths, or secure-channel behavior that does not align with approved workflows. This tactic should not be inferred from patch state, scanner output, isolated Netlogon errors, or a single domain-controller connection.

Machine-Account and Trust Manipulation

Adversaries may attempt to manipulate machine-account password state, domain-controller account properties, domain trusts, privileged group relationships, replication permissions, delegation settings, or sensitive Active Directory objects. This procedure materially increases risk because it can affect the trust relationships that allow the domain to authenticate users, authorize systems, and maintain control-plane integrity.

Privileged Authentication and Replication-Like Access

Adversaries may use compromised trust, modified account state, privileged credentials, or domain-controller context to expand authentication or attempt replication-like access. Relevant signals include privileged logons, abnormal machine-account authentication, Kerberos or NTLM anomalies, service-ticket anomalies, replication-permission use, DCSync-like behavior, LSASS access, NTDS access, or credential-material access. These behaviors should remain conditional unless supported by authentication, Directory Services, endpoint, or incident-response evidence.

Downstream Movement and High-Value System Access

Adversaries may use domain-authenticated access to reach high-value internal systems after suspicious domain-controller activity. This may include access to identity infrastructure, jump hosts, privileged management systems, endpoint-management systems, backup systems, file servers, databases, cloud consoles, SaaS administration portals, developer platforms, source-code repositories, CI/CD platforms, or sensitive applications. This activity should be linked to the suspicious domain-controller window through timing, identity, source host, session, endpoint, network, or incident-response evidence.

Security-Control Disruption and Recovery-Path Exposure

Adversaries may impair logging, endpoint controls, monitoring, audit policy, backup trust, or recovery infrastructure after domain-controller compromise or suspected identity-plane manipulation. This behavior increases impact because it reduces visibility, complicates scoping, and can force broader restoration work. It should be treated as a high-risk follow-on path when it occurs near suspicious Netlogon-adjacent, identity-plane, or privileged-access activity.

S20A — Adversary Tradecraft Summary

Windows Netlogon remote code execution and domain-controller compromise exposure targets Active Directory trust rather than server exposure alone. The adversary objective is to exploit or abuse a domain-controller service path in a way that can affect machine-account state, domain-controller trust, privileged authentication, replication permissions, or downstream identity-dependent access. The tradecraft is effective because it can emerge from internal systems, blend with legitimate administrative workflows, and force responders to validate whether the enterprise identity foundation remained trustworthy.

·        The core tradecraft pattern is suspicious domain-controller service interaction followed by potential identity-plane impact.

·        The behavior is not dependent on a single CVE, exploit string, packet signature, public proof-of-concept tool, source host, event ID, or malware artifact.

·        Adversaries may use direct exploitation, compromised internal systems, weak segmentation, suspicious source-to-domain-controller paths, machine-account manipulation, privileged authentication expansion, or replication-like access.

·        The strongest operational risk occurs when suspicious Netlogon-adjacent activity is followed by domain-controller account manipulation, machine-account password reset abuse, domain trust modification, privileged group change, replication-permission change, credential access, lateral movement, security-control disruption, backup-system access, cloud or SaaS administrative activity, ransomware staging, or extortion.

·        Detection requires visibility into both suspicious domain-controller service activity and the identity-plane evidence that should follow or disprove compromise.

·        Response requires treating suspected domain-controller trust compromise as an identity-control-plane incident, not a routine server alert.

·        The behavior remains durable because the adversary objective is control over trusted identity relationships, regardless of the specific exploit variant, source system, timing, or tooling used.

S21 — Detection Strategy Overview

Detection Philosophy

Detection for Windows Netlogon remote code execution and domain-controller compromise exposure must prioritize Active Directory control-plane compromise behavior, domain-controller trust manipulation, and abnormal Netlogon secure-channel activity over vulnerability-state identification alone. The detection model should treat Netlogon abuse as a durable domain-compromise exposure pathway where exploitation may affect domain-controller trust relationships, machine-account behavior, privileged authentication, replication-related access, and downstream identity-service integrity. Coverage should focus on suspicious Netlogon activity that produces, closely precedes, or enables domain-controller account manipulation, privileged directory activity, replication-like behavior, abnormal authentication involving domain controllers, or security-control disruption.

Primary Detection Anchors

·        Unusual Netlogon secure-channel activity involving domain controllers.

·        Repeated MS-NRPC authentication behavior directed at domain controllers from non-standard source systems.

·        Netlogon activity from unmanaged hosts, VPN ingress paths, workstation networks, branch networks, or newly observed internal sources.

·        Domain-controller machine-account password reset, account modification, or trust-related change outside an approved administrative workflow.

·        Active Directory object changes involving domain-controller accounts, machine accounts, privileged groups, domain trusts, or directory replication permissions near suspicious Netlogon activity.

·        Privileged authentication, directory replication access, administrative-control changes, or security-control disruption occurring shortly after abnormal Netlogon behavior.

Detection Prioritization Model

·        Highest priority should be assigned to suspicious Netlogon activity followed by domain-controller machine-account modification, domain trust manipulation, privileged group changes, replication-like access, abnormal authentication from the affected domain controller, or security-control disruption.

·        High priority should be assigned to repeated Netlogon authentication attempts from non-domain-controller hosts, unmanaged systems, VPN ingress ranges, workstation networks, branch networks, or unusual internal network segments.

·        Medium priority should be assigned to Netlogon secure-channel anomalies from known systems when the activity is unusual for the host, account, site, source path, or time window but lacks confirmed downstream identity-plane impact.

·        Lower priority should be assigned to isolated Netlogon errors, domain join activity, trust repair, or machine-account changes that align with approved maintenance, known administrative systems, and validated change records.

Correlation Strategy (Strict Enforcement)

·        Correlate Netlogon activity with Windows Security events, domain-controller System events, Directory Services events, endpoint telemetry, authentication logs, and network telemetry.

·        Require temporal linkage between suspicious Netlogon activity and downstream domain-controller, Active Directory, or privileged-authentication behavior before escalating to suspected compromise.

·        Treat vulnerable-state findings, scanner output, exposed service inventory, and isolated Netlogon errors as exposure indicators, not compromise indicators.

·        Do not attribute domain join activity, trust repair, replication maintenance, machine-account reset activity, or administrative troubleshooting to exploitation unless suspicious source context and downstream identity-plane behavior are also present.

·        Prioritize correlation that captures probing, Netlogon abuse, domain-controller trust impact, privileged identity activity, security-control disruption, and post-exploitation expansion.

·        Preserve separate analytic outcomes for exposure, attempted exploitation, suspected domain-controller trust manipulation, and confirmed identity-plane compromise.

Telemetry Prioritization

·        Domain-controller Windows Security logs.

·        Domain-controller System logs.

·        Netlogon operational, diagnostic, and secure-channel logging where available.

·        Directory Services and Active Directory object-change events.

·        EDR telemetry from domain controllers and suspected source systems.

·        Network telemetry for MS-NRPC, SMB, RPC endpoint mapper, and domain-controller service access.

·        Authentication telemetry for Kerberos, NTLM, machine-account authentication, privileged logons, and service-ticket activity.

·        Change-management records for domain-controller maintenance, domain joins, machine-account resets, trust repair, and identity-infrastructure upgrades.

Detection Design Constraints

·        Detection must distinguish exposed vulnerable systems from active exploitation.

·        Detection must avoid relying on public exploit-tool names, static proof-of-concept artifacts, or narrow packet signatures as the primary detection strategy.

·        Detection must account for environments where payload inspection, Netlogon diagnostic logging, RPC-level visibility, or full domain-controller audit policy is unavailable.

·        Detection must avoid over-attribution when the only available signal is patch state, scanner output, an isolated Netlogon error, or legacy secure-channel noise.

·        Detection must preserve operational separation between administrative maintenance, domain join workflows, trust repair, replication operations, and unauthorized domain-controller trust manipulation.

·        Detection must use behavior-led correlation rather than single-event alerting wherever possible.

·        Detection must preserve report scope around the durable Netlogon-to-domain-controller compromise exposure model rather than reducing the report to a single CVE, while still allowing applicable CVEs to be covered in vulnerability context, references, and behavioral coverage mapping.

Baseline and Deployment Requirements

·        Establish a verified domain-controller inventory, including hostnames, IP addresses, Active Directory sites, replication partners, and domain-controller service exposure paths.

·        Baseline approved administrative jump hosts, identity-infrastructure management systems, domain join sources, trust repair workflows, replication administration paths, and machine-account reset patterns.

·        Baseline normal Netlogon source systems, RPC access patterns, authentication paths, machine-account behavior, and domain-controller maintenance windows.

·        Validate whether legacy systems, third-party integrations, or non-Windows dependencies require documented secure-channel exceptions.

·        Ensure exceptions are reviewed, time-bounded where possible, and not used to suppress suspicious identity-plane changes.

·        Confirm SIEM field mappings preserve source host, destination domain controller, account name, machine account, event ID, process lineage, network flow, authentication package, object-change details, and change-window context.

·        Confirm domain-controller audit policy captures authentication, directory-service changes, machine-account changes, privileged group changes, trust modifications, and replication-related activity.

Variant Resilience Requirements

·        Detection must remain effective against renamed exploit tools, modified proof-of-concept code, altered timing, internal staging, and non-public exploit variants.

·        Detection should prioritize repeated Netlogon authentication behavior, abnormal source-to-domain-controller access, trust manipulation, machine-account changes, and downstream identity-control abuse.

·        Detection must support both attempted-exploitation visibility and post-exploitation consequence visibility.

·        Detection must remain useful when packet payload inspection is unavailable by correlating endpoint, authentication, directory-service, and network metadata.

·        Detection must account for adversaries staging activity from previously compromised internal hosts, VPN-connected systems, or systems with partial administrative legitimacy.

·        Detection must not depend on the presence of malware, file creation, or persistent tooling because successful domain-controller compromise may initially present as identity-plane state change.

·        Detection must support future related vulnerability coverage without requiring the report to be rewritten around a single CVE.

Operational Detection Model

·        Treat suspicious Netlogon activity against a domain controller as an identity-plane incident candidate.

·        Escalate when Netlogon anomalies are followed by domain-controller machine-account changes, domain trust changes, privileged authentication, replication-like access, administrative-control changes, or security-tool disruption.

·        Use host role, source reputation, administrative path, change window, Active Directory site context, and object-change context to separate authorized maintenance from exploitation behavior.

·        Route high-confidence detections to identity, Active Directory, incident-response, and infrastructure owners because the primary risk is domain-control compromise rather than isolated endpoint execution.

·        Require incident triage to determine whether activity represents exposure, attempted exploitation, suspected trust manipulation, or confirmed domain-controller compromise.

·        Preserve escalation language that reflects confidence level and observed behavior rather than assuming full domain compromise from a single weak signal.

S22 — Primary Detection Signals

Primary Detection Signals

·        Abnormal Netlogon secure-channel activity directed at domain controllers from non-domain-controller systems, unmanaged hosts, VPN ingress paths, workstation networks, branch networks, or newly observed internal sources.

·        Repeated MS-NRPC authentication behavior involving a domain controller where the source host, source account, timing, frequency, or network path does not align with established baseline activity.

·        Domain-controller machine-account password reset, machine-account modification, or trust-related object change occurring outside an approved identity-infrastructure workflow.

·        Active Directory object changes involving domain-controller accounts, privileged groups, domain trusts, machine-account attributes, replication permissions, or domain-control relationships near suspicious Netlogon activity.

·        Privileged authentication, administrative session creation, replication-like access, or sensitive directory activity occurring shortly after abnormal Netlogon behavior.

·        Security logging disruption, endpoint-control impairment, defensive-tool tampering, or monitoring gaps appearing on or near a domain controller after abnormal Netlogon, RPC, or identity-plane activity.

Supporting Detection Signals

·        Netlogon errors, secure-channel failures, or authentication anomalies involving domain controllers and unusual source systems.

·        RPC endpoint mapper, SMB, and domain-controller service access from systems that do not normally interact directly with domain controllers.

·        NTLM, Kerberos, machine-account authentication, or service-ticket anomalies involving domain controllers, especially where authentication activity is followed by privileged access or directory modification.

·        Domain join, trust repair, machine-account reset, or domain-controller maintenance activity occurring outside approved change windows or from non-standard administrative systems.

·        New or unusual administrative sessions to domain controllers from hosts that recently generated abnormal Netlogon, RPC, SMB, or authentication activity.

·        Unexpected process execution, service execution, command execution, credential access, or administrative tooling activity on a source host that recently contacted a domain controller through suspicious Netlogon paths.

·        Change-management mismatch where domain-controller or Active Directory modifications occur without a corresponding approved maintenance record.

Exploit Attempt and Instability Signals

·        Repeated Netlogon authentication attempts against a domain controller from a single unusual source.

·        Bursts of domain-controller-directed RPC, SMB, or MS-NRPC activity from hosts without an established administrative, infrastructure, or replication role.

·        Netlogon secure-channel failures followed by successful authentication, domain-controller account modification, or directory-service change activity.

·        Authentication anomalies involving machine accounts, domain-controller accounts, service accounts, or privileged accounts near the suspected activity window.

·        Similar Netlogon, RPC, SMB, or domain-controller service interactions across multiple domain controllers from the same source system or source network.

·        Internal scanning, service enumeration, domain-controller discovery, or Active Directory discovery behavior preceding suspicious Netlogon activity.

·        Domain-controller service instability, authentication-service disruption, unexpected restart behavior, or logging irregularity following suspicious Netlogon activity.

Outbound Communication Signals

·        Outbound communication from a suspected source host to unfamiliar external infrastructure before or after domain-controller-directed Netlogon activity.

·        Newly observed command-and-control-like network behavior from a host that also generated suspicious Netlogon, RPC, SMB, or authentication activity.

·        External communication from a domain controller that deviates from established baseline destinations, protocols, timing, or administrative purpose.

·        DNS, HTTP, HTTPS, SMB, or tunnel-like outbound activity from a domain controller or suspected source host after suspicious Netlogon and identity-plane behavior.

·        Data staging, archive creation, unusual compression, or outbound transfer behavior from systems that gained privileged access after suspicious domain-controller interaction.

Persistence and Post-Exploitation Signals (Conditional)

·        Creation, modification, or unexpected use of privileged domain accounts after suspicious Netlogon activity.

·        Addition of accounts to Domain Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Backup Operators, or similarly sensitive groups.

·        Modification of domain trusts, replication permissions, delegation settings, Group Policy Objects, domain-controller security settings, or privileged access paths.

·        Creation or modification of scheduled tasks, services, startup items, administrative scripts, or management tooling on domain controllers or newly accessed systems.

·        Credential access behavior, LSASS interaction, directory database access, backup abuse, or suspicious use of domain replication capabilities.

·        Authentication from newly privileged accounts across multiple systems shortly after suspicious domain-controller activity.

·        Security-control weakening, audit-policy changes, endpoint-control tampering, log-clearing behavior, or defensive visibility reduction after suspected domain-controller compromise.

Lateral Movement and Expansion Signals (Conditional)

·        Administrative logons from the suspected source host to domain controllers, file servers, management servers, identity infrastructure, backup systems, or high-value business systems.

·        Remote service creation, WMI activity, PowerShell remoting, scheduled task creation, SMB administrative share access, or RDP activity following suspicious Netlogon behavior.

·        Kerberos ticket activity, NTLM authentication, privileged account use, or service-account use that expands from the domain-controller interaction point to broader enterprise assets.

·        Directory enumeration, share enumeration, account discovery, group discovery, domain trust discovery, or Active Directory topology discovery after suspicious Netlogon activity.

·        Movement from a compromised workstation, VPN-connected host, branch system, or server into domain-controller management paths.

·        Reuse of privileged credentials, machine-account context, or administrative tokens across systems after suspected trust manipulation.

·        Cross-site, cross-segment, or cross-domain authentication patterns that do not align with normal Active Directory site topology, replication design, or administrative practice.

Signal Usage Constraints

·        Do not treat patch state, vulnerability scan output, or exposed Netlogon services as evidence of exploitation by itself.

·        Do not treat isolated Netlogon errors as compromise indicators unless they correlate with suspicious source context, repeated behavior, or downstream identity-plane activity.

·        Do not escalate domain join activity, trust repair, machine-account resets, replication maintenance, or domain-controller troubleshooting as exploitation when the activity aligns with approved change records and known administrative systems.

·        Do not rely on exploit-tool names, proof-of-concept filenames, static command-line fragments, or narrow packet signatures as primary detection signals.

·        Do not infer domain compromise from a single weak signal without corroborating authentication, directory-service, endpoint, or network evidence.

·        Do not treat all domain-controller administrative activity as suspicious solely because it occurs near Netlogon traffic; validate source role, change window, administrative path, and downstream behavior.

·        Preserve separate analytic outcomes for exposure, attempted exploitation, suspected trust manipulation, post-exploitation activity, and confirmed domain-controller compromise.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        Domain-controller endpoint telemetry must capture process creation, parent-child process lineage, command-line execution, service creation, scheduled task activity, PowerShell execution, WMI activity, remote management activity, and administrative tool usage.

·        Source-host endpoint telemetry must capture process execution and network-initiating processes for systems that generate suspicious Netlogon, RPC, SMB, authentication, or domain-controller service activity.

·        Endpoint telemetry should identify whether suspicious domain-controller interaction originated from a workstation, server, VPN-connected host, branch system, administrative jump host, service host, unmanaged device, or identity-management system.

·        Process telemetry should preserve user context, machine-account context, logon session context, process hash, process path, command-line parameters, and parent process relationships where available.

·        Domain-controller process execution should be correlated with authentication, directory-service, and network telemetry before the activity is classified as authorized administration, attempted exploitation, post-exploitation activity, or confirmed identity-plane compromise.

Memory and Execution Telemetry

·        EDR memory and execution telemetry should capture credential-access behavior, LSASS interaction, suspicious handle access, code injection, abnormal module loading, unauthorized execution within privileged processes, and defensive-tool interference.

·        Domain controllers should be monitored for credential dumping behavior, suspicious access to sensitive authentication material, directory database access, backup abuse, and activity consistent with unauthorized control over domain identity infrastructure.

·        Source hosts should be monitored for tooling or behavior associated with domain discovery, domain-controller enumeration, credential access, remote execution, privileged authentication, or Active Directory reconnaissance after suspicious Netlogon activity.

·        Memory telemetry should increase confidence when identity-plane anomalies are followed by credential theft, process injection, suspicious privileged-process access, or post-exploitation behavior.

·        Detection logic should not require malware, memory artifacts, or credential-theft evidence as a precondition for escalation because Netlogon abuse may initially present as trust manipulation, account-state change, or abnormal authentication behavior.

Crash and Fault Telemetry

·        Domain-controller System logs should capture Netlogon service errors, authentication-service instability, unexpected service restarts, secure-channel failures, system faults, and abnormal restart patterns.

·        Crash and fault telemetry should be correlated with Netlogon, RPC, SMB, authentication, endpoint, and directory-service activity to determine whether instability appears operational, administrative, exploit-adjacent, or post-compromise.

·        Authentication-service disruption, Netlogon failure patterns, logging interruption, or domain-controller instability should receive higher priority when preceded by unusual source-to-domain-controller access.

·        Isolated service faults or Netlogon errors should not be treated as compromise indicators without suspicious source context, repeated activity, or downstream identity-plane behavior.

·        Fault telemetry should support triage of attempted exploitation, failed exploitation, operational disruption, and post-compromise service instability without forcing unsupported compromise conclusions.

File and Persistence Telemetry

·        File telemetry should capture creation, modification, deletion, and execution of administrative scripts, service binaries, scheduled-task payloads, tooling, archives, staging files, and temporary files on domain controllers and suspected source systems.

·        Persistence telemetry should capture service creation, scheduled task creation, startup modification, Group Policy changes, domain-controller configuration changes, unauthorized administrative tooling placement, and suspicious modification of management scripts.

·        Domain-controller file activity should be correlated with privileged authentication, object changes, network activity, and suspicious Netlogon behavior before being escalated as post-exploitation evidence.

·        Source-host file telemetry should capture exploit tooling, administrative utilities, discovery scripts, credential-access tools, lateral-movement tooling, and archive or staging behavior where available.

·        File and persistence telemetry should not be required to detect the initial Netlogon exposure pathway because successful abuse may not require persistent tooling on the domain controller.

Network and Outbound Communication Telemetry

·        Network telemetry must capture source host, destination domain controller, destination service, protocol, destination port, session timing, connection frequency, byte volume, directionality, and source network context for Netlogon, MS-NRPC, RPC endpoint mapper, SMB, and related domain-controller service access.

·        Network telemetry should identify direct domain-controller access from non-domain-controller systems, unmanaged hosts, VPN ingress ranges, workstation networks, branch networks, newly observed internal sources, and non-standard administrative paths.

·        RPC, SMB, and domain-controller service telemetry should be baselined against normal Active Directory site topology, replication paths, administrative jump hosts, identity-management systems, domain join workflows, and trust repair processes.

·        Outbound network telemetry should capture external communication from suspected source hosts or domain controllers after suspicious Netlogon, authentication, and identity-plane activity.

·        DNS, HTTP, HTTPS, SMB, tunnel-like traffic, unusual external destinations, command-and-control-like behavior, or anomalous transfer activity should be correlated with identity-plane events before being treated as post-exploitation evidence.

·        Network telemetry should support differentiation between scanning, failed exploitation, suspicious domain-controller interaction, authorized administration, and downstream compromise behavior.

Web and Application Telemetry (Conditional Availability)

·        Web and application telemetry is conditional and should be used where identity-management platforms, administrative portals, VPN gateways, remote-access services, privileged-access systems, or management platforms provide relevant source-path context.

·        VPN telemetry should capture user, device, source IP, assigned internal address, session duration, authentication outcome, geolocation context, and connection path for hosts that later interact suspiciously with domain controllers.

·        Administrative portal telemetry should capture identity-infrastructure management activity, domain-controller maintenance actions, privileged access requests, approval context, and change-window alignment.

·        Identity-management application logs should help validate whether machine-account changes, trust repair, privileged group changes, replication permission changes, or domain-controller administrative actions were approved and expected.

·        Web and application telemetry should enrich source attribution and change validation, but it should not replace domain-controller, authentication, directory-service, endpoint, or network telemetry.

Telemetry Availability Requirements

·        Domain-controller Windows Security logs must be available for authentication events, privileged logons, account changes, group changes, machine-account activity, security-policy changes, and sensitive logon behavior.

·        Directory Services telemetry must be available for Active Directory object changes involving domain-controller accounts, machine accounts, privileged groups, domain trusts, delegation, replication permissions, and Group Policy.

·        Domain-controller System and Netlogon-related telemetry should be available for service instability, secure-channel failures, authentication disruption, and operational fault context.

·        EDR telemetry should be available on domain controllers and suspected source systems wherever technically feasible.

·        Network telemetry should cover internal paths to domain controllers, including VPN, branch, workstation, server, administrative, identity-infrastructure, and management-network segments.

·        Authentication telemetry should capture Kerberos, NTLM, service-ticket behavior, machine-account authentication, privileged logons, service-account use, and abnormal authentication expansion.

·        Change-management telemetry or records must be available to validate domain join activity, trust repair, machine-account resets, domain-controller maintenance, replication administration, privileged access requests, and identity-infrastructure changes.

Telemetry Limitations and Gaps

·        Limited Netlogon diagnostic logging may reduce visibility into secure-channel behavior and require heavier reliance on authentication, directory-service, network, endpoint, and change-management correlation.

·        Encrypted or metadata-only network visibility may prevent packet-level confirmation of Netlogon behavior, but source-to-domain-controller access patterns remain useful for detection.

·        Environments without EDR coverage on domain controllers may lose visibility into post-exploitation process execution, credential access, persistence, and defensive-tool tampering.

·        Incomplete Active Directory auditing may limit visibility into machine-account changes, trust changes, privileged group modification, replication permission changes, delegation changes, and Group Policy manipulation.

·        Missing VPN, branch, remote-access, or privileged-access telemetry may reduce confidence when attributing suspicious domain-controller activity to a specific user, device, ingress path, or administrative approval flow.

·        Poor asset inventory may make it difficult to distinguish domain controllers, administrative systems, identity-management hosts, unmanaged devices, ordinary workstations, and approved replication partners.

·        Missing change-management context may increase false positives around domain join activity, trust repair, machine-account reset workflows, replication administration, and domain-controller maintenance.

·        Telemetry gaps should reduce confidence ratings and drive investigation requirements rather than force unsupported compromise conclusions.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Abnormal Netlogon secure-channel activity against domain controllers provides an early opportunity to identify suspicious domain-controller interaction before confirmed identity-plane compromise.

·        Repeated MS-NRPC, RPC endpoint mapper, SMB, or domain-controller service access from non-standard hosts provides a strong source-path signal when correlated with asset role, network segment, and administrative baseline.

·        Domain-controller machine-account password reset, account modification, trust modification, or replication-permission change outside approved workflows provides a high-value identity-plane detection opportunity.

·        Privileged authentication, administrative session creation, service-ticket activity, or replication-like behavior shortly after suspicious Netlogon activity provides a high-confidence correlation opportunity.

·        Active Directory object changes involving domain-controller accounts, privileged groups, domain trusts, delegation, Group Policy, replication permissions, or domain-control relationships provide durable post-exploitation detection anchors.

·        Source-host telemetry can identify whether suspicious domain-controller interaction originated from a workstation, VPN-connected host, unmanaged system, branch network, server, jump host, or identity-management system.

·        Change-management and privileged-access records provide required context for separating approved domain-controller maintenance from unauthorized trust manipulation or suspicious identity-plane activity.

High-Value Correlation Opportunities

·        Correlate unusual Netlogon activity with domain-controller machine-account changes, privileged group changes, trust changes, or replication-permission modifications within the same investigation window.

·        Correlate suspicious source-to-domain-controller network activity with endpoint process execution on the source host to identify discovery, remote execution, credential access, administrative tooling, or lateral-movement preparation.

·        Correlate Netlogon anomalies with Kerberos, NTLM, machine-account authentication, privileged logons, and service-ticket behavior to identify suspicious authentication expansion.

·        Correlate domain-controller System and Netlogon fault events with network bursts, repeated authentication attempts, and directory-service changes to identify failed exploitation, exploit-adjacent instability, or post-compromise disruption.

·        Correlate VPN, remote-access, branch, and privileged-access telemetry with later domain-controller interaction to identify suspicious ingress paths and compromised administrative routes.

·        Correlate outbound communication from a suspected source host or domain controller with identity-plane changes to identify possible command-and-control, staging, exfiltration, or downstream operator activity.

·        Correlate domain-controller security-control disruption, logging gaps, audit-policy changes, or endpoint-control impairment with prior Netlogon, authentication, and directory-service anomalies.

Detection Gaps

·        Limited Netlogon diagnostic logging may reduce direct visibility into secure-channel behavior and require greater reliance on authentication, directory-service, endpoint, network, and change-management correlation.

·        Metadata-only network telemetry may identify suspicious source-to-domain-controller access patterns but may not confirm protocol-level exploit behavior.

·        Missing EDR coverage on domain controllers may limit visibility into process execution, credential access, persistence, defensive-tool tampering, and post-exploitation behavior.

·        Incomplete Active Directory auditing may reduce visibility into machine-account changes, trust modifications, privileged group changes, delegation changes, replication-permission changes, and Group Policy manipulation.

·        Incomplete asset inventory may make it difficult to distinguish domain controllers, replication partners, identity-management systems, administrative jump hosts, unmanaged hosts, and ordinary workstations.

·        Missing VPN, branch, remote-access, privileged-access, or change-management telemetry may reduce confidence when attributing suspicious domain-controller activity to a user, device, ingress path, or approved maintenance workflow.

·        Legacy systems and third-party integrations may generate secure-channel noise that must be baselined before alerting can be promoted from hunt logic to operational detection.

Operational Blind Spots

·        Environments that permit broad internal access to domain-controller services may lack meaningful source-path control and increase the difficulty of separating expected traffic from suspicious Netlogon interaction.

·        Environments without domain-controller EDR coverage may detect suspicious identity-plane changes but miss the source process, tooling, credential-access behavior, or post-exploitation execution context.

·        Environments without strong privileged-access governance may struggle to distinguish authorized identity-infrastructure maintenance from unauthorized domain-controller manipulation.

·        Environments without reliable change-management records may generate false positives around domain join activity, trust repair, machine-account resets, replication administration, and domain-controller troubleshooting.

·        Environments with incomplete log retention may lose the pre-exploitation or early exploitation window needed to correlate Netlogon behavior with downstream identity-plane activity.

·        Environments with weak Active Directory auditing may detect authentication anomalies but miss the object changes required to confirm domain-controller trust manipulation.

False Positive Control Requirements

·        Validate whether the source system is an approved domain controller, replication partner, administrative jump host, identity-management system, or authorized maintenance system.

·        Validate whether the activity aligns with approved domain join, trust repair, replication maintenance, domain-controller troubleshooting, machine-account reset, or identity-infrastructure change workflows.

·        Validate whether secure-channel exceptions, legacy dependencies, or third-party integrations explain the observed Netlogon or authentication behavior.

·        Validate whether suspicious authentication activity is followed by meaningful identity-plane change before escalating to suspected compromise.

·        Validate whether domain-controller faults, restarts, or Netlogon errors align with maintenance, patching, service recovery, or known operational issues.

·        Validate whether outbound communication from a domain controller or suspected source host aligns with approved update services, monitoring tools, management platforms, identity services, or backup operations.

·        Use confidence-based escalation when telemetry is incomplete rather than forcing binary compromise conclusions from weak or isolated signals.

Hunt-to-Alert Promotion Criteria

·        Promote to alert logic when suspicious Netlogon activity from non-standard source systems repeatedly correlates with authentication anomalies, directory-service changes, privileged access, or domain-controller control-plane activity.

·        Promote to alert logic when domain-controller machine-account changes, trust changes, replication-permission changes, or privileged group changes occur near suspicious Netlogon or domain-controller service activity.

·        Promote to alert logic when suspicious source-to-domain-controller activity is followed by privileged authentication expansion, lateral movement, defensive-control disruption, or unauthorized administrative tooling.

·        Promote to alert logic when repeated domain-controller-directed MS-NRPC, RPC, SMB, or authentication activity originates from unmanaged systems, VPN ingress ranges, workstation networks, branch networks, or newly observed internal sources.

·        Keep as hunt logic when the signal is limited to scanner output, patch state, exposed service inventory, isolated Netlogon errors, or unexplained but non-repeated authentication noise.

·        Keep as hunt logic when required field mappings, asset-role context, baseline data, change-management validation, or domain-controller audit coverage are insufficient for reliable alerting.

Detection Engineering Gaps to Resolve Before S25 Deployment

·        Confirm field mappings for source host, destination domain controller, source network segment, account name, machine account, authentication package, event ID, object-change type, process lineage, network session metadata, and change-window context.

·        Confirm domain-controller inventory, replication topology, administrative jump hosts, identity-management systems, VPN address pools, branch ranges, approved service hosts, and authorized management paths.

·        Confirm whether Netlogon operational, diagnostic, and secure-channel logging is available and mapped into the SIEM.

·        Confirm whether Windows Security, System, Directory Services, EDR, authentication, network, VPN, privileged-access, and change-management data can be correlated within a reliable time window.

·        Confirm false-positive baselines for domain join workflows, trust repair, machine-account resets, replication administration, domain-controller patching, secure-channel exceptions, and third-party identity dependencies.

·        Confirm alert thresholds through local baseline testing before enabling production alert mode.

Confirm SOC triage procedures for separating exposure, attempted exploitation, suspected domain-controller trust manipulation, post-exploitation behavior, and confirmed identity-plane compromise.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR / Network Behavioral Analytics has three rules for this EXP report.

·        NDR / Network Behavioral Analytics is viable for detecting suspicious network behavior associated with Windows Netlogon remote code execution and domain-controller compromise exposure, including abnormal source-to-domain-controller Netlogon-adjacent traffic, MS-NRPC/RPC/SMB service interaction, repeated domain-controller access, source-path deviation, and downstream lateral-movement or outbound communication behavior.

·        NDR / Network Behavioral Analytics is strongest where network-flow telemetry, domain-controller asset inventory, Active Directory site topology, VPN ingress context, branch-network context, workstation subnet context, source-host role enrichment, authentication telemetry, directory-service telemetry, endpoint enrichment, change-management records, and SIEM correlation can be combined.

·        NDR / Network Behavioral Analytics can identify suspicious sequencing between non-standard source access, domain-controller service interaction, repeated MS-NRPC/RPC/SMB activity, authentication anomalies, directory-service changes, lateral movement, and outbound communication where correlated telemetry exists.

·        NDR / Network Behavioral Analytics is not a standalone source for confirming successful Netlogon exploitation, domain-controller compromise, credential theft, Active Directory trust manipulation, replication abuse, endpoint compromise, or actor attribution because network telemetry may not fully observe authentication state, machine-account changes, directory-service object changes, endpoint process execution, or administrative intent.

·        NDR / Network Behavioral Analytics rules must be correlated with Windows Security logs, domain-controller System logs, Directory Services events, authentication logs, EDR telemetry, VPN logs, privileged-access records, change-control records, and incident-response evidence before classifying activity as probable domain-controller compromise.

·        NDR / Network Behavioral Analytics detection content should be treated as high-value behavioral coverage for suspicious domain-controller interaction, exploitation-attempt scoping, identity-plane investigation, lateral-movement detection, and downstream compromise triage, not direct CVE confirmation or standalone compromise confirmation.

·        NDR / Network Behavioral Analytics rules should not generate high-confidence alerting from exposed Netlogon services alone, patch state alone, vulnerability scan output alone, isolated Netlogon errors alone, single RPC connection alone, ordinary SMB activity alone, or normal administrative domain-controller access alone.

Rule

Suspicious Netlogon / MS-NRPC Activity From Non-Standard Source to Domain Controller

Rule Format

NDR behavioral domain-controller service correlation rule suitable for network-flow telemetry, RPC telemetry, SMB telemetry, domain-controller service telemetry, VPN ingress enrichment, source-network enrichment, asset-role enrichment, domain-controller inventory, Active Directory site topology, authentication enrichment, directory-service enrichment, endpoint enrichment, change-management context, and SIEM correlation after domain-controller asset validation, source-role validation, protocol-field validation, timing-window tuning, baseline validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB, or domain-controller service activity directed at domain controllers from non-standard internal sources.

·        Identify source systems that interact with domain controllers in a manner inconsistent with approved domain-controller, replication, identity-management, administrative, monitoring, backup, or maintenance roles.

·        Prioritize activity from unmanaged systems, workstation networks, VPN ingress pools, branch networks, newly observed internal sources, or systems without an approved domain-controller interaction profile.

·        Support early escalation when suspicious domain-controller service access is followed by authentication anomalies, machine-account changes, domain trust changes, privileged group changes, replication-like behavior, or administrative-control activity.

·        Preserve separation between suspicious Netlogon-adjacent activity and confirmed compromise by requiring supporting authentication, directory-service, endpoint, change-management, or incident-response evidence before classifying the activity as probable domain-controller compromise.

·        This rule does not prove successful Netlogon exploitation, domain-controller compromise, credential theft, Active Directory takeover, replication abuse, endpoint compromise, or actor attribution without supporting Windows, Active Directory, endpoint, identity, or incident-response evidence.

Detection Logic

·        Identify network sessions from non-domain-controller systems to verified domain controllers involving Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB, or locally classified domain-controller service traffic.

·        Prioritize sources from unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal sources, or systems without an approved administrative or identity-infrastructure role.

·        Prioritize repeated domain-controller service interaction from the same source within a locally defined investigation window.

·        Prioritize activity where the source is not a known domain controller, replication partner, identity-management platform, monitoring system, backup system, administrative jump host, vulnerability management system, or authorized maintenance system.

·        Increase confidence when suspicious source-to-domain-controller activity occurs outside approved change windows, outside normal domain join workflows, outside trust repair activity, or outside documented identity-infrastructure maintenance.

·        Increase confidence when activity is followed by authentication anomalies, privileged logons, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, or security-control disruption.

·        Increase confidence when the source host also shows internal scanning, domain-controller discovery, Active Directory discovery, credential-access behavior, remote administration tooling, suspicious outbound communication, or lateral-movement preparation.

·        Reduce severity when behavior aligns with approved replication, monitoring, backup activity, identity-management activity, domain join operations, trust repair, domain-controller maintenance, patching, vulnerability management, security testing, or incident response.

·        Do not classify exposed Netlogon services, patch state, vulnerability scan output, isolated Netlogon errors, or single domain-controller service connections as exploitation evidence by themselves.

·        Do not treat suspicious source-to-domain-controller activity as confirmed compromise without downstream authentication, directory-service, endpoint, administrative-control, or incident-response evidence.

Required Telemetry

·        Network-flow telemetry.

·        RPC telemetry where available.

·        SMB telemetry where available.

·        Domain-controller service telemetry.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Destination port.

·        Protocol.

·        Application or service classification.

·        Connection count.

·        Session timing.

·        Byte volume.

·        Directionality.

·        Domain-controller asset inventory.

·        Active Directory site topology.

·        Replication partner inventory.

·        Identity-management system inventory.

·        Administrative jump-host inventory.

·        Monitoring-system inventory.

·        Backup-system inventory.

·        Vulnerability management system inventory.

·        VPN address pool inventory.

·        Branch network inventory.

·        Workstation subnet inventory.

·        Source-host asset role.

·        Source-host management status.

·        Source network segment.

·        Source first-seen timestamp where available.

·        Authentication logs where available.

·        Windows Security logs where available.

·        Directory Services events where available.

·        EDR telemetry where available.

·        Change-management records.

·        Approved domain join records where available.

·        Approved trust repair records where available.

·        Approved maintenance-window records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build domain-controller asset groups covering all writable domain controllers, read-only domain controllers, domain-controller IP ranges, Active Directory sites, domain-controller subnets, and domain-controller service exposure paths.

·        Build approved source groups covering domain controllers, replication partners, identity-management platforms, monitoring systems, backup systems, administrative jump hosts, privileged access workstations, vulnerability management systems, and authorized maintenance systems.

·        Build suspicious source groups covering unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal systems, non-administrative servers, and systems without a known domain-controller interaction role.

·        Build domain-controller service groups for Netlogon-adjacent traffic, MS-NRPC, RPC endpoint mapper, SMB, and locally observed domain-controller service classifications.

·        Build authentication-follow-on groups separately for Kerberos, NTLM, privileged logons, machine-account authentication, and service-ticket behavior rather than using those authentication signals as primary Netlogon-match criteria.

·        Build source-path deviation logic that evaluates whether the source host, source segment, asset role, and timing are expected for domain-controller interaction.

·        Build frequency logic using locally validated thresholds for repeated source-to-domain-controller connections, burst behavior, repeated attempts, and newly observed source activity.

·        Build follow-on correlation groups for authentication anomalies, privileged logons, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, security-control disruption, and EDR-observed suspicious source-host behavior.

·        Validate whether NDR, Windows Security, Directory Services, EDR, authentication, VPN, change-management, and SIEM telemetry can reliably join on source host, destination domain controller, source IP, destination IP, account, machine account, timestamp, event ID, and asset role.

·        Use short correlation windows for suspicious source-to-domain-controller network activity and immediate authentication anomalies.

·        Use moderate correlation windows for downstream directory-service changes, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, and endpoint activity.

·        Use longer correlation windows only when incident-response evidence, identity evidence, endpoint evidence, or repeated source behavior supports delayed linkage.

·        Add severity weighting for unmanaged source systems, VPN ingress sources, workstation networks, branch networks, newly observed sources, repeated MS-NRPC/RPC/SMB access, privileged account involvement, domain-controller account changes, trust changes, replication-permission changes, and change-management mismatch.

·        Treat source novelty, repeated connections, domain-controller targeting, and protocol concentration as confidence amplifiers, not standalone compromise criteria.

·        Use approved replication records, monitoring records, backup schedules, domain join records, trust repair records, administrative maintenance windows, vulnerability management records, security-testing records, and incident-response records as triage evidence.

·        Validate all environment variables, field mappings, domain-controller groups, approved source groups, suspicious source groups, protocol groups, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until field availability, domain-controller inventory, source-role enrichment, baseline thresholds, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to durable source-to-domain-controller service deviation rather than static CVE identifiers, exploit strings, packet signatures, file artifacts, public proof-of-concept names, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, timing, source host, command syntax, protocol pacing, or post-exploitation sequence.

·        The score is supported by the durability of non-standard Netlogon-adjacent interaction, repeated MS-NRPC/RPC/SMB activity, source-role deviation, domain-controller targeting, and downstream identity-plane correlation.

·        The score is constrained by metadata-only network visibility, incomplete domain-controller inventory, weak source-role enrichment, limited Netlogon protocol detail, broad internal access to domain-controller services, and legacy secure-channel noise.

·        The rule is durable as an early suspicious domain-controller interaction detector but should not be treated as standalone proof of successful exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on accurate domain-controller inventory, source-role enrichment, VPN range mapping, source network segmentation, domain-controller service baselines, and reliable network-flow telemetry.

·        Operational confidence is reduced where broad internal domain-controller access is normal, source-host roles are poorly documented, Netlogon diagnostic visibility is limited, or legacy systems generate secure-channel noise.

·        Operational confidence is reduced where domain join, trust repair, replication administration, backup, monitoring, vulnerability management, and identity-management workflows are not well baselined.

·        Full-telemetry confidence improves when suspicious network behavior is enriched with Windows Security logs, Directory Services events, EDR telemetry, authentication logs, VPN telemetry, privileged-access records, and change-control context.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of Netlogon exploitation or domain-controller compromise.

Limitations

·        This rule detects suspicious source-to-domain-controller service behavior, not confirmed exploitation by itself.

·        NDR may not observe machine-account password changes, directory-service object changes, authentication state, endpoint process execution, credential access, or administrative intent without enrichment.

·        Metadata-only network telemetry may identify suspicious access patterns but may not confirm protocol-level exploitation.

·        Legitimate replication, monitoring, backup, vulnerability management, domain join, trust repair, identity-management, administrative maintenance, and incident-response workflows can produce similar traffic.

·        Legacy systems and third-party integrations may generate secure-channel or domain-controller service noise.

·        The rule may miss activity that originates from an approved administrative system, uses normal source paths, or blends into established domain-controller service baselines.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR Windows Netlogon source-to-domain-controller behavioral query pattern requiring platform syntax validation, domain-controller inventory validation, approved source validation, source-role validation, protocol classification validation, timing-window tuning, baseline validation, and environment-specific allowlisting before production deployment.

NetworkEvent AS SuspiciousDcServiceAccess
WHERE SuspiciousDcServiceAccess.DestinationAsset IN ASSET_GROUP (
"Domain Controllers",
"Writable Domain Controllers",
"Read Only Domain Controllers",
"Active Directory Domain Controllers",
"Domain Controller Service Interfaces"
)
AND SuspiciousDcServiceAccess.ProtocolOrService IN ANY (
"NETLOGON",
"MS-NRPC",
"RPC_ENDPOINT_MAPPER",
"RPC",
"SMB_DOMAIN_CONTROLLER_SERVICE",
"DOMAIN_CONTROLLER_SERVICE"
)
AND SuspiciousDcServiceAccess.SourceAsset NOT IN ASSET_GROUP (
"Domain Controllers",
"Replication Partners",
"Identity Management Systems",
"Approved Administrative Jump Hosts",
"Approved Privileged Access Workstations",
"Approved Monitoring Systems",
"Approved Backup Systems",
"Approved Vulnerability Management Systems",
"Approved Maintenance Systems"
)
AND (
SuspiciousDcServiceAccess.SourceContext IN ANY (
"unmanaged_system",
"workstation_network",
"vpn_ingress_range",
"branch_network",
"newly_observed_internal_source",
"non_administrative_server",
"source_not_in_domain_controller_access_baseline"
)
OR SuspiciousDcServiceAccess.ConnectionPattern IN ANY (
"repeated_domain_controller_service_access",
"burst_rpc_or_smb_domain_controller_activity",
"repeated_msrpc_attempts",
"new_source_to_domain_controller_path",
"outside_normal_domain_controller_access_window"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_NETLOGON_IDENTITY_WINDOW (
SecurityEvent AS IdentityPlaneFollowOn
WHERE (
IdentityPlaneFollowOn.SourceAsset IN SAME_SOURCE(SuspiciousDcServiceAccess.SourceAsset)
OR IdentityPlaneFollowOn.TargetAsset IN SAME_DESTINATION(SuspiciousDcServiceAccess.DestinationAsset)
)
AND IdentityPlaneFollowOn.EventPattern IN ANY (
"privileged_logon_to_domain_controller",
"machine_account_change",
"domain_controller_account_change",
"domain_trust_change",
"privileged_group_change",
"replication_permission_change",
"directory_service_object_change",
"abnormal_machine_account_authentication",
"kerberos_or_ntlm_anomaly_after_domain_controller_service_access",
"security_control_disruption"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_SOURCE_HOST_CONTEXT_WINDOW (
EndpointOrNetworkEvent AS SourceHostFollowOn
WHERE SourceHostFollowOn.SourceAsset IN SAME_SOURCE(SuspiciousDcServiceAccess.SourceAsset)
AND SourceHostFollowOn.EventPattern IN ANY (
"internal_scanning",
"domain_controller_discovery",
"active_directory_discovery",
"credential_access_behavior",
"remote_administration_tooling",
"lateral_movement_preparation",
"suspicious_outbound_communication"
)
)
AND NOT ChangeContext IN ANY (
"approved_domain_join",
"approved_trust_repair",
"approved_replication_maintenance",
"approved_domain_controller_maintenance",
"approved_identity_management_workflow",
"approved_monitoring_activity",
"approved_backup_activity",
"approved_vulnerability_management",
"approved_security_testing",
"approved_incident_response"
)

Rule

Repeated Domain-Controller Service Access Across Multiple Domain Controllers

Rule Format

NDR behavioral multi-domain-controller access correlation rule suitable for network-flow telemetry, RPC telemetry, SMB telemetry, domain-controller service metadata, domain-controller inventory, Active Directory site topology, replication topology, source-role enrichment, source-network enrichment, VPN enrichment, asset inventory, identity-infrastructure inventory, endpoint enrichment, and SIEM correlation after domain-controller topology validation, source-role validation, multi-destination threshold tuning, protocol classification validation, and environment-specific allowlisting.

Detection Purpose

·        Detect source systems that repeatedly access multiple domain controllers through Netlogon-adjacent, MS-NRPC, RPC, SMB, or locally classified domain-controller service paths within a defined investigation window.

·        Identify behavior consistent with domain-controller discovery, exploitation-attempt activity, broad domain-controller service probing, identity-plane preparation, or suspicious access expansion.

·        Prioritize sources that are unmanaged, workstation-class, VPN-connected, branch-based, newly observed, or not approved for replication, monitoring, backup, domain-controller administration, or identity-management activity.

·        Support escalation when multi-domain-controller access is followed by authentication anomalies, privileged account use, machine-account changes, directory-service changes, lateral movement, or suspicious source-host endpoint behavior.

·        Preserve separation between multi-domain-controller service access and confirmed compromise by requiring corroborating identity, endpoint, network, change-management, or incident-response evidence before classifying activity as probable compromise.

·        This rule does not prove successful Netlogon exploitation, domain-controller compromise, domain-wide compromise, credential theft, replication abuse, or actor attribution without supporting evidence.

Detection Logic

·        Identify source systems contacting multiple verified domain controllers within a locally defined investigation window.

·        Focus on Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB, and locally classified domain-controller service traffic.

·        Keep Kerberos, NTLM, privileged logons, and machine-account authentication as follow-on confidence signals rather than primary multi-domain-controller match criteria.

·        Prioritize sources without known replication, monitoring, backup, identity-management, privileged access, vulnerability management, or administrative maintenance roles.

·        Increase confidence when the source contacts multiple domain controllers in a short burst, high-frequency pattern, repeated attempt pattern, or newly observed access pattern.

·        Increase confidence when multi-domain-controller access follows internal scanning, service enumeration, domain-controller discovery, Active Directory discovery, or network reconnaissance.

·        Increase confidence when the activity is followed by privileged authentication, directory-service object changes, domain trust changes, machine-account changes, replication-permission changes, lateral movement, or outbound communication.

·        Increase confidence when the source is associated with a VPN ingress range, branch segment, workstation subnet, unmanaged asset group, or newly observed internal network path.

·        Reduce severity when the source is an approved replication partner, monitoring platform, backup platform, identity-management system, vulnerability management system, administrative jump host, or authorized maintenance system.

·        Do not infer exploitation from multi-domain-controller contact alone because legitimate infrastructure systems may contact multiple domain controllers during normal operations.

·        Do not classify the activity as confirmed compromise without downstream authentication, directory-service, endpoint, administrative-control, or incident-response evidence.

Required Telemetry

·        Network-flow telemetry.

·        RPC telemetry where available.

·        SMB telemetry where available.

·        Domain-controller service telemetry.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Destination port.

·        Protocol.

·        Application or service classification.

·        Distinct destination count.

·        Session timing.

·        Connection frequency.

·        Byte volume.

·        Directionality.

·        Domain-controller inventory.

·        Active Directory site topology.

·        Replication topology.

·        Replication partner inventory.

·        Monitoring-system inventory.

·        Backup-system inventory.

·        Identity-management system inventory.

·        Administrative jump-host inventory.

·        Vulnerability management system inventory.

·        VPN address pool inventory.

·        Branch network inventory.

·        Workstation subnet inventory.

·        Source-host asset role.

·        Source-host management status.

·        Source first-seen timestamp where available.

·        Authentication logs where available.

·        Windows Security logs where available.

·        Directory Services events where available.

·        EDR telemetry where available.

·        Change-management records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build domain-controller groups covering all domain controllers, domain-controller IP ranges, Active Directory sites, and domain-controller service interfaces.

·        Build approved multi-domain-controller source groups covering domain controllers, replication partners, monitoring platforms, backup platforms, identity-management systems, vulnerability management systems, administrative jump hosts, and authorized maintenance systems.

·        Build suspicious source groups covering unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal systems, and systems without approved multi-domain-controller access patterns.

·        Build protocol groups covering Netlogon-adjacent traffic, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service traffic, and locally observed domain-controller service classifications.

·        Build authentication-follow-on groups separately for Kerberos, NTLM, machine-account authentication, privileged logons, service-ticket anomalies, and abnormal authentication expansion.

·        Build multi-destination logic that evaluates the number of distinct domain controllers contacted by a single source within locally validated timing windows.

·        Build frequency and burst logic for short-window access to multiple domain controllers, repeated attempts, abnormal connection pacing, or newly observed source-to-domain-controller paths.

·        Build reconnaissance context groups for internal scanning, service enumeration, domain-controller discovery, Active Directory discovery, LDAP probing, Kerberos probing, and SMB enumeration where available.

·        Build downstream correlation groups for privileged authentication, machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, lateral movement, and outbound communication.

·        Validate whether NDR, Windows Security, Directory Services, EDR, authentication, VPN, change-management, and SIEM telemetry can reliably join on source host, destination domain controller, source IP, destination IP, account, machine account, timestamp, event ID, asset role, and network segment.

·        Use short correlation windows for repeated multi-domain-controller network access and burst patterns.

·        Use moderate correlation windows for downstream authentication, directory-service, source-host endpoint, and lateral-movement behavior.

·        Use longer correlation windows only when incident-response evidence, repeated access patterns, or identity-plane activity supports delayed linkage.

·        Add severity weighting for number of distinct domain controllers contacted, source novelty, unmanaged status, VPN ingress source, workstation subnet source, branch source, reconnaissance context, authentication anomalies, and downstream identity-plane changes.

·        Treat multi-domain-controller access as a confidence amplifier, not standalone proof of exploitation.

·        Use approved replication records, monitoring records, backup records, vulnerability management records, identity-management records, administrative maintenance windows, security-testing records, and incident-response records as triage evidence.

·        Validate all environment variables, domain-controller groups, approved source groups, suspicious source groups, destination-count thresholds, protocol groups, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until multi-destination baselines, source-role enrichment, domain-controller topology, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to repeated multi-domain-controller service access and source-path deviation rather than static exploit strings, CVE identifiers, public proof-of-concept names, file artifacts, payload signatures, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, access timing, connection pacing, target order, or post-access behavior.

·        The score is supported by the durability of domain-controller discovery, repeated domain-controller service interaction, source-role mismatch, multi-destination access, and downstream identity-plane correlation.

·        The score is constrained by legitimate infrastructure systems that normally contact multiple domain controllers, including replication, monitoring, backup, vulnerability management, and identity-management systems.

·        The rule is durable as a suspicious domain-controller service interaction detector but should not be treated as standalone proof of successful exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.0 / 10

·        Operational confidence depends on accurate domain-controller topology, replication partner inventory, approved infrastructure source groups, source-role enrichment, and local multi-destination baselines.

·        Operational confidence is reduced where monitoring systems, backup systems, vulnerability management tools, identity-management platforms, or administrative systems commonly contact many domain controllers.

·        Operational confidence is reduced where Active Directory site topology, source network segmentation, and normal domain-controller service paths are poorly documented.

·        Full-telemetry confidence improves when repeated multi-domain-controller access is enriched with authentication logs, Directory Services events, EDR telemetry, VPN telemetry, asset inventory, and change-control context.

·        Even under full telemetry conditions, this rule should support suspicious activity escalation and scoping rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects repeated multi-domain-controller service access, not confirmed exploitation by itself.

·        Legitimate replication, monitoring, backup, vulnerability management, identity-management, administrative maintenance, and security-testing systems may contact multiple domain controllers.

·        NDR may not observe the purpose of the connection, authentication outcome, directory-service change, or source-host process context without enrichment.

·        Environments with weak domain-controller topology documentation may generate false positives.

·        The rule may miss activity that targets a single domain controller, uses an approved infrastructure source, or stays within normal multi-domain-controller access baselines.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR Windows Netlogon multi-domain-controller service access query pattern requiring platform syntax validation, domain-controller topology validation, approved source validation, multi-destination threshold validation, protocol classification validation, baseline tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS MultiDcServiceAccess
WHERE MultiDcServiceAccess.DestinationAsset IN ASSET_GROUP (
"Domain Controllers",
"Writable Domain Controllers",
"Read Only Domain Controllers",
"Active Directory Domain Controllers"
)
AND MultiDcServiceAccess.ProtocolOrService IN ANY (
"NETLOGON",
"MS-NRPC",
"RPC_ENDPOINT_MAPPER",
"RPC",
"SMB_DOMAIN_CONTROLLER_SERVICE",
"DOMAIN_CONTROLLER_SERVICE"
)
AND MultiDcServiceAccess.SourceAsset NOT IN ASSET_GROUP (
"Domain Controllers",
"Replication Partners",
"Approved Monitoring Systems",
"Approved Backup Systems",
"Approved Identity Management Systems",
"Approved Vulnerability Management Systems",
"Approved Administrative Jump Hosts",
"Approved Maintenance Systems"
)
AND DISTINCT_COUNT(
MultiDcServiceAccess.DestinationAsset
) BY MultiDcServiceAccess.SourceAsset WITHIN ENV_MULTI_DC_ACCESS_WINDOW

= ENV_MULTI_DC_THRESHOLD
AND (
MultiDcServiceAccess.SourceContext IN ANY (
"unmanaged_system",
"workstation_network",
"vpn_ingress_range",
"branch_network",
"newly_observed_internal_source",
"source_not_in_multi_dc_access_baseline"
)
OR MultiDcServiceAccess.ConnectionPattern IN ANY (
"short_window_multi_dc_access",
"high_frequency_domain_controller_access",
"repeated_failed_domain_controller_sessions",
"new_multi_dc_access_path",
"burst_rpc_or_smb_domain_controller_activity"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DISCOVERY_CONTEXT_WINDOW (
NetworkOrEndpointEvent AS DiscoveryContext
WHERE DiscoveryContext.SourceAsset IN SAME_SOURCE(MultiDcServiceAccess.SourceAsset)
AND DiscoveryContext.EventPattern IN ANY (
"internal_scanning",
"service_enumeration",
"domain_controller_discovery",
"active_directory_discovery",
"ldap_probing",
"kerberos_probing",
"smb_enumeration"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_IDENTITY_FOLLOWON_WINDOW (
SecurityEvent AS IdentityFollowOn
WHERE (
IdentityFollowOn.SourceAsset IN SAME_SOURCE(MultiDcServiceAccess.SourceAsset)
OR IdentityFollowOn.TargetAsset IN SAME_DESTINATION_SET(MultiDcServiceAccess.DestinationAsset)
)
AND IdentityFollowOn.EventPattern IN ANY (
"privileged_logon_to_domain_controller",
"machine_account_change",
"domain_controller_account_change",
"domain_trust_change",
"privileged_group_change",
"replication_permission_change",
"directory_service_object_change",
"abnormal_machine_account_authentication",
"kerberos_or_ntlm_anomaly_after_multi_dc_access"
)
)
AND NOT ChangeContext IN ANY (
"approved_replication_activity",
"approved_monitoring_activity",
"approved_backup_activity",
"approved_identity_management_workflow",
"approved_vulnerability_management",
"approved_domain_controller_maintenance",
"approved_security_testing",
"approved_incident_response"
)

Rule

Netlogon-Adjacent Domain-Controller Activity Followed by Lateral Movement or Outbound Communication

Rule Format

NDR behavioral domain-controller interaction follow-on correlation rule suitable for network-flow telemetry, domain-controller service telemetry, lateral-movement telemetry, outbound communication telemetry, DNS telemetry, proxy telemetry, firewall logs, source-host enrichment, domain-controller inventory, high-value asset inventory, authentication enrichment, directory-service enrichment, endpoint enrichment, change-management context, and SIEM correlation after upstream domain-controller interaction validation, downstream destination validation, outbound baseline validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service activity followed by network behavior consistent with lateral movement, operator staging, command-and-control, data movement, or downstream compromise activity.

·        Identify cases where suspicious domain-controller interaction becomes higher risk because the same source host or affected domain controller later communicates with high-value internal systems, administrative services, or unfamiliar external infrastructure.

·        Prioritize downstream access to identity infrastructure, domain controllers, file servers, management servers, backup systems, endpoint-management platforms, privileged management systems, jump hosts, source-code systems, CI/CD systems, databases, or sensitive business systems.

·        Support escalation when suspicious domain-controller interaction is followed by privileged authentication expansion, lateral movement, outbound communication, directory-service changes, or endpoint-observed suspicious behavior.

·        Preserve separation between suspicious follow-on behavior and confirmed compromise by requiring supporting authentication, directory-service, endpoint, outbound, file, persistence, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove successful Netlogon exploitation, credential theft, command-and-control, exfiltration, domain-controller compromise, downstream compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service activity from a non-standard source to a verified domain controller.

·        Correlate the same source host with subsequent lateral movement patterns, including SMB administrative share access, RDP, WMI, WinRM, remote service access, SSH, database access, management-plane access, or access to high-value internal systems.

·        Correlate the same source host or affected domain controller with outbound communication to unfamiliar, newly observed, rare, low-reputation, or unusual external destinations after suspicious domain-controller interaction.

·        Increase confidence when lateral movement or outbound communication follows privileged authentication, directory-service changes, machine-account changes, domain trust changes, replication-permission changes, or administrative-control activity.

·        Increase confidence when downstream activity targets identity infrastructure, backup systems, endpoint-management platforms, management servers, privileged access systems, file servers, source-code systems, CI/CD systems, or sensitive business systems.

·        Increase confidence when outbound communication involves rare DNS lookups, new external destinations, unusual protocol use, tunnel-like behavior, unexpected SMB egress, abnormal byte volume, or traffic inconsistent with the source or domain-controller baseline.

·        Increase confidence when EDR or endpoint telemetry shows discovery, credential access, remote administration tooling, persistence creation, tool staging, suspicious process execution, or security-control impairment.

·        Reduce severity when downstream communication aligns with approved administration, monitoring, backup, update services, vulnerability management, software deployment, identity-management workflows, incident response, or documented change-control activity.

·        Do not attribute downstream lateral movement or outbound communication to Netlogon exploitation without upstream suspicious domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat outbound communication, lateral movement, or administrative protocol use as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        Domain-controller service telemetry.

·        RPC telemetry where available.

·        SMB telemetry where available.

·        Lateral-movement network telemetry.

·        Outbound communication telemetry.

·        DNS logs where available.

·        Proxy logs where available.

·        Firewall logs.

·        Secure web gateway logs where available.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Destination port.

·        Protocol.

·        Application or service classification.

·        Session timing.

·        Connection count.

·        Byte volume.

·        Directionality.

·        Domain-controller inventory.

·        Identity infrastructure inventory.

·        High-value asset inventory.

·        Jump-host inventory.

·        Management-server inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Privileged management inventory.

·        File-server inventory.

·        Source-code and CI/CD inventory where available.

·        Sensitive business application inventory.

·        External destination reputation where available.

·        First-seen external destination context where available.

·        Source-host asset role.

·        Source-host management status.

·        Authentication logs where available.

·        Directory Services events where available.

·        EDR telemetry where available.

·        Change-management records.

·        Approved administration records.

·        Approved monitoring records.

·        Approved backup records.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Build upstream suspicious domain-controller interaction groups using non-standard source-to-domain-controller Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service activity.

·        Build high-value internal destination groups covering identity infrastructure, domain controllers, management servers, privileged management systems, jump hosts, backup systems, endpoint-management platforms, file servers, source-code systems, CI/CD systems, databases, and sensitive business applications.

·        Build lateral-movement protocol groups covering SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP, Kerberos, database protocols, management-plane access, and administrative protocols.

·        Build outbound-risk groups covering newly observed external destinations, rare domains, rare IPs, unusual ASNs, low-reputation destinations, tunnel-like protocols, unusual SMB egress, abnormal DNS behavior, abnormal byte volume, and destinations inconsistent with domain-controller or source-host baselines.

·        Build identity-plane follow-on groups for privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, and administrative-control activity.

·        Build endpoint follow-on groups for discovery, credential access, remote administration tooling, tool staging, persistence creation, suspicious process execution, security-control disruption, and outbound follow-on behavior.

·        Validate whether NDR, firewall, DNS, proxy, EDR, Windows Security, Directory Services, authentication, change-management, and SIEM telemetry can reliably join on source host, affected domain controller, destination asset, source IP, destination IP, account, timestamp, protocol, and asset role.

·        Use short correlation windows for immediate lateral movement or outbound communication after suspicious domain-controller interaction.

·        Use moderate correlation windows for delayed lateral movement, delayed outbound communication, repeated access attempts, or low-and-slow internal expansion.

·        Use longer correlation windows only when incident-response evidence, repeated access patterns, identity evidence, or endpoint evidence supports delayed linkage.

·        Add severity weighting for upstream suspicious domain-controller interaction, privileged account involvement, high-value internal destination access, administrative protocol use, identity-plane changes, newly observed external destinations, low-reputation external destinations, and endpoint-observed suspicious behavior.

·        Treat downstream lateral movement and outbound communication as confidence amplifiers, not standalone proof of Netlogon exploitation.

·        Use approved administrator records, monitoring records, backup schedules, patching records, software deployment records, vulnerability management records, identity-management records, change-control records, and incident-response records as triage evidence.

·        Validate all environment variables, upstream interaction groups, high-value asset groups, lateral-movement protocol groups, outbound-risk groups, identity-plane follow-on groups, endpoint follow-on groups, timing windows, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until upstream linkage, downstream destination validation, outbound baseline validation, asset inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious domain-controller interaction followed by downstream network expansion or outbound behavior rather than static exploit strings, CVE identifiers, packet signatures, payload artifacts, source IPs, or known command-and-control infrastructure.

·        The rule remains useful if an adversary changes exploit mechanics, source system, target order, lateral-movement method, outbound destination, timing, or post-exploitation sequence.

·        The score is supported by the durability of domain-controller interaction followed by lateral movement, privileged service access, high-value asset access, outbound communication, identity-plane changes, and endpoint-observed suspicious behavior.

·        The score is constrained by legitimate administrator activity, monitoring workflows, backup traffic, software deployment, vulnerability management, patching, and incomplete DNS, proxy, endpoint, or identity telemetry.

·        The rule is durable as a post-interaction expansion detector but should not be treated as standalone proof of Netlogon exploitation, command-and-control, exfiltration, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable upstream domain-controller interaction detection, high-value asset inventory, internal network visibility, outbound baseline data, DNS or proxy coverage, source-role enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where administrators, monitoring systems, backup systems, vulnerability management platforms, software deployment tools, and incident responders commonly access high-value systems or external destinations after domain-controller interaction.

·        Operational confidence is reduced where domain-controller outbound baselines, source-host baselines, and high-value asset inventories are incomplete.

·        Full-telemetry confidence improves when network expansion is enriched with authentication logs, Directory Services events, EDR telemetry, DNS logs, proxy logs, firewall logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation, compromise, or actor attribution.

Limitations

·        This rule detects suspicious follow-on network behavior after domain-controller interaction, not confirmed exploitation by itself.

·        NDR may not observe endpoint process execution, credential theft, directory-service object changes, administrative intent, or exact authentication state without enrichment.

·        Lateral movement and outbound communication patterns may overlap with approved administration, monitoring, backup, vulnerability management, patching, software deployment, and incident-response workflows.

·        Missing DNS, proxy, EDR, authentication, or Directory Services telemetry can reduce confidence.

·        Domain controllers and administrative systems may have legitimate outbound communication patterns that require local baseline tuning.

·        The rule may miss activity that does not produce visible lateral movement, uses expected administrative paths, communicates with approved destinations, or occurs outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR Windows Netlogon domain-controller interaction follow-on query pattern requiring platform syntax validation, upstream domain-controller interaction validation, lateral-movement protocol validation, outbound destination validation, identity-plane correlation validation, endpoint enrichment validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS SuspiciousDomainControllerInteraction
WHERE SuspiciousDomainControllerInteraction.DestinationAsset IN ASSET_GROUP (
"Domain Controllers",
"Writable Domain Controllers",
"Read Only Domain Controllers",
"Active Directory Domain Controllers"
)
AND SuspiciousDomainControllerInteraction.ProtocolOrService IN ANY (
"NETLOGON",
"MS-NRPC",
"RPC_ENDPOINT_MAPPER",
"RPC",
"SMB_DOMAIN_CONTROLLER_SERVICE",
"DOMAIN_CONTROLLER_SERVICE"
)
AND SuspiciousDomainControllerInteraction.SourceAsset NOT IN ASSET_GROUP (
"Domain Controllers",
"Replication Partners",
"Approved Identity Management Systems",
"Approved Administrative Jump Hosts",
"Approved Monitoring Systems",
"Approved Backup Systems",
"Approved Maintenance Systems"
)
AND SuspiciousDomainControllerInteraction.SourceContext IN ANY (
"unmanaged_system",
"workstation_network",
"vpn_ingress_range",
"branch_network",
"newly_observed_internal_source",
"source_not_in_domain_controller_access_baseline"
)
AND EVENT_NEAR WITHIN ENV_DC_FOLLOWON_ACTIVITY_WINDOW (
NetworkEvent AS FollowOnNetworkActivity
WHERE (
FollowOnNetworkActivity.SourceAsset IN SAME_SOURCE(SuspiciousDomainControllerInteraction.SourceAsset)
OR FollowOnNetworkActivity.SourceAsset IN SAME_DESTINATION(SuspiciousDomainControllerInteraction.DestinationAsset)
)
AND (
FollowOnNetworkActivity.ProtocolOrService IN ANY (
"SMB_ADMIN_SHARE",
"RDP",
"WMI",
"WINRM",
"REMOTE_SERVICE",
"SSH",
"LDAP",
"KERBEROS",
"DATABASE",
"MANAGEMENT_PLANE",
"ADMIN_PROTOCOL"
)
OR FollowOnNetworkActivity.DestinationAsset IN ASSET_GROUP (
"Identity Infrastructure",
"Domain Controllers",
"Jump Hosts",
"Privileged Management Systems",
"Management Servers",
"Backup Systems",
"Endpoint Management Platforms",
"File Servers",
"Source Code Systems",
"CI/CD Systems",
"Databases",
"Sensitive Business Applications"
)
OR FollowOnNetworkActivity.ExternalDestinationContext IN ANY (
"newly_observed_external_destination",
"rare_external_destination",
"low_reputation_destination",
"unusual_asn",
"unusual_domain",
"tunnel_like_protocol",
"unexpected_smb_egress",
"abnormal_byte_volume",
"destination_not_in_source_baseline"
)
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_IDENTITY_OR_ENDPOINT_CONTEXT_WINDOW (
SecurityOrEndpointEvent AS SupportingCompromiseContext
WHERE (
SupportingCompromiseContext.SourceAsset IN SAME_SOURCE(SuspiciousDomainControllerInteraction.SourceAsset)
OR SupportingCompromiseContext.TargetAsset IN SAME_DESTINATION(SuspiciousDomainControllerInteraction.DestinationAsset)
)
AND SupportingCompromiseContext.EventPattern IN ANY (
"privileged_authentication_expansion",
"machine_account_change",
"domain_trust_change",
"privileged_group_change",
"replication_permission_change",
"directory_service_object_change",
"credential_access_behavior",
"remote_administration_tooling",
"tool_staging",
"persistence_creation",
"security_control_disruption",
"suspicious_process_execution"
)
)
AND NOT ChangeContext IN ANY (
"approved_administrator_activity",
"approved_monitoring_activity",
"approved_backup_activity",
"approved_identity_management_workflow",
"approved_vulnerability_management",
"approved_patching_activity",
"approved_software_deployment",
"approved_security_testing",
"approved_incident_response"
)

SentinelOne

Detection Viability Assessment

SentinelOne has three rules for this EXP report.

·        SentinelOne is viable for detecting endpoint-side behavior associated with Windows Netlogon remote code execution and domain-controller compromise exposure, including suspicious source-host execution, domain-controller-directed network activity, credential-access behavior, remote administration tooling, domain-controller post-interaction activity, and downstream lateral movement from systems involved in suspicious domain-controller interaction.

·        SentinelOne is strongest where Deep Visibility telemetry, process telemetry, command-line telemetry, parent-child process relationships, Storyline context, file telemetry, network telemetry, DNS enrichment, identity enrichment, domain-controller inventory, suspicious Netlogon or NDR enrichment, Windows event enrichment, and SIEM correlation can be combined.

·        SentinelOne can identify suspicious source-host behavior before or after domain-controller interaction even when the initial Netlogon-adjacent network activity is observed through NDR, firewall, Windows, Active Directory, or SIEM telemetry rather than directly inside SentinelOne.

·        SentinelOne is not a standalone source for confirming Netlogon exploitation, domain-controller compromise, Active Directory takeover, replication abuse, credential theft, or actor attribution because endpoint telemetry may not fully observe Netlogon secure-channel state, MS-NRPC semantics, machine-account changes, domain trust changes, or directory-service object changes without external enrichment.

·        SentinelOne detections must be correlated with NDR telemetry, Windows Security logs, domain-controller System logs, Directory Services events, authentication telemetry, VPN logs, change-control records, and incident-response evidence before endpoint behavior is classified as Netlogon-linked compromise.

·        SentinelOne should be treated as endpoint confirmation, source-host triage, domain-controller post-interaction coverage, and lateral-movement behavior coverage for suspected domain-controller compromise exposure, not direct CVE confirmation or standalone proof of Netlogon exploitation.

·        SentinelOne rules should not generate high-confidence alerting from PowerShell execution alone, command-shell execution alone, remote administration tooling alone, credential-access indicators alone, network connections to a domain controller alone, or SentinelOne behavioral alerts alone without suspicious domain-controller interaction context or validated post-interaction linkage.

Rule

Source-Host Execution Preceding Suspicious Domain-Controller Netlogon / RPC Access

Rule Format

SentinelOne endpoint behavioral source-host correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, parent-child process relationships, Storyline context, network connection telemetry, DNS enrichment, file telemetry, suspicious Netlogon or NDR enrichment, source-host enrichment, domain-controller inventory, identity enrichment, and SIEM correlation after endpoint field validation, domain-controller destination validation, suspicious interaction-context validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious process execution, command-line activity, discovery behavior, credential-access preparation, or administrative tooling on a source host shortly before or during suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or domain-controller-directed access activity.

·        Identify endpoint behavior that may indicate domain-controller targeting, exploitation preparation, identity-plane compromise preparation, or suspicious administrative-path use without requiring SentinelOne to independently prove Netlogon exploitation.

·        Prioritize suspicious execution on unmanaged systems, workstations, VPN-connected hosts, branch systems, non-administrative servers, or systems without an approved domain-controller administration role.

·        Support escalation when suspicious source-host execution is followed by domain-controller-directed network connections, authentication anomalies, machine-account changes, domain trust changes, privileged group changes, or replication-like behavior.

·        Preserve separation between suspicious endpoint activity and confirmed compromise by requiring corroborating NDR, Windows, Active Directory, authentication, directory-service, or incident-response evidence before classifying activity as probable domain-controller compromise.

·        This rule does not prove successful Netlogon exploitation, domain-controller compromise, credential theft, Active Directory takeover, replication abuse, or actor attribution without supporting network, Windows, Active Directory, identity, or incident-response evidence.

Detection Logic

·        Identify suspicious process execution on source hosts that also initiate or are enriched with suspicious domain-controller service access.

·        Prioritize process execution involving PowerShell, command shell, WMI, WinRM, rundll32, regsvr32, mshta, wscript, cscript, certutil, bitsadmin, curl, wget, Python, remote administration tools, credential-access utilities, directory-discovery tools, or locally relevant living-off-the-land binaries.

·        Prioritize command lines involving encoded execution, hidden windows, execution-policy bypass, no-profile execution, remote retrieval, direct IP access, suspicious command chaining, credential access, domain discovery, domain-controller discovery, LDAP querying, Kerberos probing, SMB enumeration, or administrative share access.

·        Prioritize file writes, script creation, archive extraction, executable staging, DLL staging, or tooling placement in user-writable paths, temporary paths, administrative staging paths, or unusual directories.

·        Increase confidence when the same endpoint initiates Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or suspicious domain-controller access shortly before or after the endpoint activity.

·        Increase confidence when the source host is unmanaged, workstation-class, VPN-connected, branch-based, newly observed, or outside approved administrative pathways.

·        Increase confidence when endpoint behavior is followed by privileged authentication, machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, or suspicious lateral movement.

·        Reduce severity when activity aligns with approved administrator workflows, identity-management activity, vulnerability management, software deployment, domain join operations, trust repair, security testing, incident response, or documented change-control activity.

·        Do not classify suspicious process execution as Netlogon-linked compromise without domain-controller interaction context, suspicious NDR enrichment, Windows or Active Directory correlation, or incident-response validation.

·        Do not treat PowerShell, command shell, remote administration tooling, discovery tooling, or domain-controller network access as compromise evidence by itself.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation events.

·        Process termination events where available.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        User identity.

·        Device identity.

·        Working directory.

·        Integrity level.

·        Process start time.

·        SentinelOne Storyline context.

·        Network connection telemetry.

·        DNS enrichment where available.

·        File creation telemetry.

·        File modification telemetry.

·        Script execution telemetry.

·        Archive extraction telemetry where available.

·        DLL load telemetry where available.

·        PowerShell telemetry.

·        Command-shell telemetry.

·        WMI and WinRM telemetry where available.

·        Behavioral indicators.

·        Threat indicators.

·        Suspicious Netlogon or NDR enrichment.

·        Domain-controller destination enrichment.

·        Authentication enrichment where available.

·        Windows Security enrichment where available.

·        Directory Services enrichment where available.

·        Source-host asset role.

·        Source-host management status.

·        VPN ingress context where available.

·        Branch network context where available.

·        Approved administrator workflow records.

·        Approved vulnerability management records.

·        Approved software deployment records.

·        Approved security testing records.

·        Approved incident-response records.

·        Change-control records.

Engineering Implementation Instructions

·        Build source-host groups covering managed workstations, unmanaged systems, VPN-connected hosts, branch systems, administrative workstations, privileged access workstations, non-administrative servers, and systems with suspicious domain-controller interaction context.

·        Build domain-controller destination groups covering writable domain controllers, read-only domain controllers, domain-controller IP ranges, Active Directory sites, and domain-controller service interfaces.

·        Build suspicious execution groups covering PowerShell, command shell, WMI, WinRM, wscript, cscript, mshta, rundll32, regsvr32, certutil, bitsadmin, curl, wget, Python, remote administration tools, credential-access tools, directory-discovery tools, and locally relevant living-off-the-land binaries.

·        Build suspicious command-line groups for encoded execution, hidden execution, execution-policy bypass, no-profile execution, remote retrieval, direct IP access, suspicious command chaining, credential access, token access, LDAP querying, Kerberos probing, SMB enumeration, domain discovery, domain-controller discovery, and administrative share access.

·        Build file-staging groups for Downloads, Temp, AppData, ProgramData, Public, browser cache, user profile paths, administrative staging paths, script directories, archive extraction paths, and locally observed tooling locations.

·        Build suspicious domain-controller interaction enrichment groups using NDR, firewall, Windows Security, Directory Services, authentication, and SIEM context that identifies abnormal Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or source-to-domain-controller access behavior.

·        Build follow-on groups for privileged authentication, machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, lateral movement, suspicious outbound communication, and security-control disruption.

·        Validate SentinelOne field availability for process ancestry, command line, file path, user identity, device identity, Storyline ID, network connections, DNS enrichment, file writes, DLL loads, script execution, behavioral indicators, and timestamps.

·        Validate SIEM joins between SentinelOne telemetry, NDR telemetry, firewall logs, Windows Security logs, Directory Services events, authentication logs, domain-controller inventory, asset inventory, change-control records, and incident-response evidence.

·        Use short correlation windows when suspicious source-host execution occurs immediately before or after suspicious domain-controller service access.

·        Use moderate correlation windows when suspicious execution is followed by delayed authentication anomalies, directory-service changes, machine-account changes, or lateral movement.

·        Use longer correlation windows only when Storyline continuity, repeated source behavior, identity evidence, endpoint evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for suspicious Netlogon or NDR context, unmanaged source status, VPN ingress source, branch source, privileged account involvement, suspicious command-line content, credential-access behavior, domain-controller discovery, source-to-domain-controller connection, and downstream identity-plane changes.

·        Treat suspicious execution, source novelty, domain-controller connections, and behavioral indicators as confidence amplifiers, not standalone proof of Netlogon exploitation.

·        Build allowlists for approved administrator scripts, domain join workflows, trust repair workflows, identity-management workflows, vulnerability management tools, software deployment tools, security testing, incident response, and known automation.

·        Validate all environment variables, endpoint groups, source-host groups, domain-controller destination groups, command-line patterns, suspicious interaction enrichment, Storyline correlation, timing windows, parser behavior, exception logic, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until process grouping, command-line parsing, domain-controller destination validation, suspicious Netlogon enrichment, Storyline correlation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious source-host execution linked to domain-controller service interaction rather than static CVE identifiers, exploit strings, filenames, hashes, public proof-of-concept names, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, command syntax, staging path, execution method, timing, or post-exploitation sequence.

·        The score is supported by the durability of source-host discovery behavior, suspicious command execution, credential-access preparation, remote administration tooling, domain-controller service access, and downstream identity-plane correlation.

·        The score is constrained by legitimate administrator activity, software deployment, vulnerability management, identity-management workflows, incomplete command-line telemetry, weak NDR enrichment, and missing Storyline continuity.

·        The rule is durable as source-host endpoint coverage but should not be treated as standalone proof of successful Netlogon exploitation, domain-controller compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on SentinelOne process telemetry, command-line visibility, Storyline continuity, network connection telemetry, domain-controller destination enrichment, suspicious Netlogon or NDR enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where command lines are truncated, process ancestry is incomplete, network connections are not visible, domain-controller destination enrichment is weak, or SentinelOne telemetry cannot be joined to NDR and Windows event context.

·        Operational confidence is reduced in administrator, helpdesk, identity-management, vulnerability management, software deployment, security testing, and incident-response environments where similar execution may be legitimate.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with NDR telemetry, firewall logs, Windows Security logs, Directory Services events, authentication logs, asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support endpoint triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        SentinelOne cannot independently confirm Netlogon exploitation, domain-controller trust manipulation, machine-account change, domain trust change, or replication abuse without external enrichment.

·        Suspicious endpoint execution may be unrelated to domain-controller compromise unless timing, network, identity, directory-service, or incident-response evidence supports linkage.

·        PowerShell, command shell, remote administration tooling, discovery tools, and file staging may be legitimate in administrator, helpdesk, software deployment, vulnerability management, security testing, and incident-response workflows.

·        Missing command-line telemetry, incomplete process ancestry, weak Storyline continuity, missing network enrichment, or incomplete asset inventory can reduce confidence.

·        The rule may miss activity that uses approved tooling, blends with normal administrative workflows, executes outside the correlation window, or does not produce suspicious endpoint artifacts.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility source-host execution query pattern requiring tenant syntax validation, endpoint field validation, source-host role validation, domain-controller destination validation, suspicious Netlogon enrichment validation, command-line parsing validation, Storyline validation, approved workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

SentinelOneEndpointEvent AS SourceHostSuspiciousExecution
WHERE SourceHostSuspiciousExecution.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"Script Execution",
"DLL Load",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)
AND SourceHostSuspiciousExecution.AgentComputerName IN ASSET_GROUP (
"Managed User Endpoints",
"Unmanaged Systems",
"VPN Connected Hosts",
"Branch Systems",
"Administrative Workstations",
"Privileged Access Workstations",
"Non Administrative Servers",
"Endpoints With Suspicious Domain Controller Interaction Context"
)
AND (
SourceHostSuspiciousExecution.TgtProcName IN ANY (
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"wmic.exe",
"winrm.vbs",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"certutil.exe",
"bitsadmin.exe",
"curl.exe",
"wget.exe",
"python.exe",
"node.exe",
"nltest.exe",
"dsquery.exe",
"adfind.exe",
"ldapsearch.exe"
)
OR SourceHostSuspiciousExecution.TgtProcCmdLine CONTAINS ANY (
"-enc",
"-encodedcommand",
"executionpolicy bypass",
"-nop",
"-noprofile",
"-w hidden",
"downloadstring",
"invoke-webrequest",
"invoke-expression",
"frombase64string",
"nltest",
"dsquery",
"adfind",
"ldap",
"domain controller",
"admin$",
"c$",
"credential",
"token",
"dump",
"lsass",
"ntds",
"trust",
"replication"
)
OR SourceHostSuspiciousExecution.TgtFilePath CONTAINS ANY (
"\Downloads",
"\AppData",
"\Temp",
"\ProgramData",
"\Users\Public"
)
OR SourceHostSuspiciousExecution.BehavioralIndicator IN ANY (
"Suspicious Process Execution",
"Credential Access Behavior",
"Token Access",
"Remote Administration Tooling",
"Tool Staging",
"Domain Discovery",
"Suspicious Child Process",
"Outbound Follow On Communication"
)
)
AND EVENT_NEAR WITHIN ENV_DC_INTERACTION_CONTEXT_WINDOW (
SecurityOrNetworkEvent AS DomainControllerInteractionContext
WHERE DomainControllerInteractionContext.SourceAsset IN SAME_DEVICE(SourceHostSuspiciousExecution.AgentComputerName)
AND DomainControllerInteractionContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"source_not_in_domain_controller_access_baseline",
"repeated_domain_controller_service_access",
"new_source_to_domain_controller_path"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_IDENTITY_FOLLOWON_WINDOW (
SecurityEvent AS IdentityPlaneFollowOn
WHERE (
IdentityPlaneFollowOn.SourceAsset IN SAME_DEVICE(SourceHostSuspiciousExecution.AgentComputerName)
OR IdentityPlaneFollowOn.UserOrDevice IN SAME_USER_OR_DEVICE(SourceHostSuspiciousExecution.UserOrDevice)
)
AND IdentityPlaneFollowOn.EventPattern IN ANY (
"privileged_logon_to_domain_controller",
"machine_account_change",
"domain_controller_account_change",
"domain_trust_change",
"privileged_group_change",
"replication_permission_change",
"directory_service_object_change",
"abnormal_machine_account_authentication"
)
)
AND NOT SourceHostSuspiciousExecution.AgentComputerName IN ASSET_GROUP (
"Approved Administrator Workstations",
"Approved Identity Management Systems",
"Approved Software Deployment Systems",
"Approved Vulnerability Management Systems",
"Approved Security Testing Systems",
"Approved Incident Response Systems"
)
AND NOT SourceHostSuspiciousExecution.TgtProcCmdLine CONTAINS ANY (
"approved_admin_script",
"approved_domain_join",
"approved_trust_repair",
"approved_identity_management",
"approved_software_deployment",
"approved_vulnerability_scan",
"approved_security_testing",
"approved_incident_response"
)

Rule

Suspicious Activity on Domain Controller Following Netlogon-Adjacent Interaction

Rule Format

SentinelOne endpoint behavioral domain-controller post-interaction correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, Storyline context, file telemetry, network telemetry, behavioral indicators, domain-controller inventory, suspicious Netlogon or NDR enrichment, Windows Security enrichment, Directory Services enrichment, authentication enrichment, change-management context, and SIEM correlation after domain-controller asset validation, upstream interaction validation, endpoint field validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious process execution, credential-access behavior, remote administration tooling, persistence creation, file staging, or security-control disruption on a domain controller after suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service interaction.

·        Identify endpoint-side post-exploitation behavior on domain controllers that may indicate follow-on activity after attempted exploitation or successful compromise.

·        Prioritize domain-controller activity involving credential access, LSASS interaction, directory database access, backup abuse, suspicious script execution, service creation, scheduled task creation, or defensive-tool impairment.

·        Support escalation when domain-controller endpoint behavior aligns with suspicious source-to-domain-controller network activity, authentication anomalies, machine-account changes, trust changes, privileged group changes, or replication-permission changes.

·        Preserve separation between suspicious domain-controller endpoint activity and confirmed compromise by requiring corroborating network, authentication, directory-service, file, persistence, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove successful Netlogon exploitation, Active Directory takeover, credential theft, replication abuse, or actor attribution without supporting Windows, Active Directory, identity, network, or incident-response evidence.

Detection Logic

·        Identify suspicious endpoint activity on verified domain controllers after suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service interaction.

·        Detect process execution involving PowerShell, command shell, WMI, WinRM, script hosts, rundll32, regsvr32, certutil, bitsadmin, remote administration tools, credential-access utilities, backup utilities, directory-database access tools, or locally relevant living-off-the-land binaries.

·        Prioritize command lines involving credential access, LSASS access, NTDS access, shadow copy abuse, backup abuse, replication-related abuse, service creation, scheduled task creation, remote execution, security-tool tampering, log clearing, or suspicious outbound communication.

·        Prioritize file activity involving script creation, executable staging, DLL staging, archive extraction, credential-dump output, suspicious temporary files, administrative staging paths, or unauthorized tooling on domain controllers.

·        Increase confidence when domain-controller endpoint activity occurs shortly after suspicious source-to-domain-controller Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service activity.

·        Increase confidence when endpoint behavior is accompanied by privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, Directory Services changes, or security-control disruption.

·        Increase confidence when SentinelOne Storyline context links suspicious process execution, file activity, network activity, credential-access behavior, or outbound communication on the domain controller.

·        Reduce severity when activity aligns with approved domain-controller maintenance, patching, backup operations, identity-management workflows, monitoring activity, vulnerability management, security testing, incident response, or documented change-control activity.

·        Do not attribute domain-controller endpoint activity to Netlogon exploitation without upstream suspicious domain-controller interaction and supporting Windows, Active Directory, authentication, or incident-response evidence.

·        Do not treat domain-controller process execution, PowerShell use, backup utility use, or SentinelOne behavioral alerts as compromise evidence by themselves.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Domain-controller endpoint telemetry.

·        Process creation events.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        User identity.

·        Device identity.

·        Working directory.

·        Integrity level.

·        Timestamp.

·        SentinelOne Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        File execution telemetry.

·        DLL load telemetry where available.

·        Registry modification telemetry where available.

·        Scheduled task telemetry where available.

·        Service creation telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        Behavioral indicators.

·        Threat indicators.

·        Suspicious Netlogon or NDR enrichment.

·        Upstream source-host enrichment.

·        Windows Security enrichment where available.

·        Directory Services enrichment where available.

·        Authentication enrichment where available.

·        Domain-controller asset inventory.

·        Approved domain-controller maintenance records.

·        Approved backup schedules.

·        Approved patching records.

·        Approved identity-management records.

·        Approved monitoring records.

·        Approved incident-response records.

·        Change-control records.

Engineering Implementation Instructions

·        Build domain-controller endpoint groups covering writable domain controllers, read-only domain controllers, domain-controller IP ranges, Active Directory sites, and domain-controller hostnames protected by SentinelOne.

·        Build suspicious upstream interaction groups using NDR, firewall, Windows Security, Directory Services, authentication, and SIEM telemetry showing abnormal Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service activity directed at the domain controller.

·        Build suspicious domain-controller execution groups for PowerShell, command shell, WMI, WinRM, wscript, cscript, mshta, rundll32, regsvr32, certutil, bitsadmin, remote administration tools, credential-access utilities, backup utilities, directory-database access tools, and locally relevant living-off-the-land binaries.

·        Build credential and directory-access groups for LSASS access, NTDS access, shadow copy behavior, backup abuse, credential-dump output, replication-related abuse, sensitive registry access, and access to authentication material.

·        Build persistence and control-impact groups for scheduled task creation, service creation, registry modification, unauthorized agent deployment, security-tool disruption, audit-policy changes, log-clearing behavior, and defensive visibility reduction.

·        Build outbound follow-on groups for unusual DNS activity, new external destinations, low-reputation destinations, tunnel-like behavior, abnormal byte volume, unexpected SMB egress, and outbound communication inconsistent with domain-controller baselines.

·        Validate SentinelOne field availability for process ancestry, command line, Storyline ID, file activity, registry activity, service creation, scheduled tasks, network connections, DNS enrichment, user identity, device identity, behavioral indicators, and timestamps.

·        Validate SIEM joins between SentinelOne telemetry, NDR telemetry, firewall logs, Windows Security logs, Directory Services events, authentication logs, domain-controller inventory, change-management records, and incident-response evidence.

·        Use short correlation windows when suspicious domain-controller endpoint behavior occurs immediately after suspicious Netlogon-adjacent interaction.

·        Use moderate correlation windows for delayed credential access, file staging, persistence, defensive-tool tampering, outbound communication, or directory-service change activity.

·        Use longer correlation windows only when Storyline continuity, upstream domain-controller interaction, identity evidence, endpoint evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for domain-controller asset criticality, suspicious upstream interaction, credential-access behavior, NTDS access, LSASS access, shadow copy abuse, service creation, scheduled task creation, security-control disruption, and suspicious outbound communication.

·        Treat domain-controller endpoint behavior as a confidence amplifier unless linked through upstream domain-controller interaction, identity-plane evidence, directory-service evidence, or incident-response validation.

·        Build allowlists for approved domain-controller maintenance, patching, backup operations, identity-management workflows, monitoring activity, vulnerability management, security testing, EDR response, incident response, and known automation.

·        Validate all environment variables, domain-controller endpoint groups, upstream interaction groups, suspicious execution groups, credential-access groups, persistence groups, outbound follow-on groups, timing windows, parser behavior, exception logic, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until domain-controller endpoint coverage, upstream interaction validation, process lineage, Storyline joins, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious domain-controller endpoint activity after suspicious domain-controller interaction rather than static CVE identifiers, exploit strings, filenames, hashes, payload signatures, or public proof-of-concept artifacts.

·        The rule remains useful if an adversary changes exploit tooling, command syntax, staging path, execution method, persistence mechanism, credential-access method, or outbound destination.

·        The score is supported by the durability of credential access, NTDS access, LSASS access, suspicious command execution, persistence creation, security-control disruption, outbound follow-on behavior, and domain-controller context.

·        The score is constrained by legitimate domain-controller administration, backup activity, patching, identity-management workflows, EDR response, incomplete command-line telemetry, weak upstream linkage, and missing Storyline continuity.

·        The rule is durable as domain-controller post-interaction endpoint coverage but should not be treated as standalone proof of successful Netlogon exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on SentinelOne coverage on domain controllers, process telemetry, command-line visibility, Storyline continuity, file telemetry, network telemetry, upstream suspicious domain-controller interaction enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where domain controllers lack SentinelOne coverage, command lines are truncated, process ancestry is incomplete, upstream Netlogon or NDR enrichment is weak, or normal domain-controller maintenance is poorly documented.

·        Operational confidence is reduced where backup operations, patching, identity-management workflows, monitoring, EDR response, vulnerability management, or incident-response activity commonly produce similar behavior.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with NDR telemetry, Windows Security logs, Directory Services events, authentication logs, DNS logs, firewall logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support domain-controller compromise triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        SentinelOne cannot independently prove Netlogon exploitation, MS-NRPC abuse, machine-account manipulation, domain trust manipulation, or replication abuse without Windows, Active Directory, network, or SIEM enrichment.

·        Domain-controller administrative activity may resemble suspicious behavior during patching, backup, identity-management, monitoring, vulnerability management, EDR response, security testing, or incident response.

·        Missing command-line telemetry, incomplete process ancestry, weak Storyline continuity, missing network enrichment, or incomplete upstream interaction context can reduce confidence.

·        The rule may miss activity that does not produce endpoint artifacts, occurs through approved administrative tools, stays within expected maintenance activity, or happens outside the correlation window.

·        The rule should not infer full domain compromise without supporting authentication, directory-service, endpoint, network, or incident-response evidence.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility domain-controller post-interaction query pattern requiring tenant syntax validation, domain-controller asset validation, upstream interaction validation, endpoint field validation, process lineage validation, Storyline validation, approved workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

SentinelOneEndpointEvent AS DomainControllerSuspiciousActivity
WHERE DomainControllerSuspiciousActivity.AgentComputerName IN ASSET_GROUP (
"Domain Controllers",
"Writable Domain Controllers",
"Read Only Domain Controllers",
"Active Directory Domain Controllers"
)
AND DomainControllerSuspiciousActivity.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"File Execution",
"DLL Load",
"Registry Modified",
"Scheduled Task Created",
"Service Created",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)
AND EVENT_NEAR WITHIN ENV_DC_UPSTREAM_INTERACTION_WINDOW (
SecurityOrNetworkEvent AS UpstreamDomainControllerInteraction
WHERE UpstreamDomainControllerInteraction.TargetAsset IN SAME_DEVICE(DomainControllerSuspiciousActivity.AgentComputerName)
AND UpstreamDomainControllerInteraction.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"source_not_in_domain_controller_access_baseline",
"repeated_domain_controller_service_access",
"new_source_to_domain_controller_path"
)
)
AND (
DomainControllerSuspiciousActivity.TgtProcName IN ANY (
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"wmic.exe",
"winrm.vbs",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"certutil.exe",
"bitsadmin.exe",
"vssadmin.exe",
"wbadmin.exe",
"ntdsutil.exe",
"rclone.exe",
"procdump.exe"
)
OR DomainControllerSuspiciousActivity.TgtProcCmdLine CONTAINS ANY (
"-enc",
"-encodedcommand",
"executionpolicy bypass",
"downloadstring",
"invoke-webrequest",
"invoke-expression",
"lsass",
"ntds",
"ntds.dit",
"vssadmin",
"shadow",
"wbadmin",
"secrets",
"credential",
"token",
"dump",
"replication",
"trust",
"domain admin",
"enterprise admin",
"admin$",
"c$",
"clear-eventlog",
"wevtutil"
)
OR DomainControllerSuspiciousActivity.BehavioralIndicator IN ANY (
"Credential Access Behavior",
"Token Access",
"Persistence Attempt",
"Remote Administration Tooling",
"Tool Staging",
"Suspicious Child Process",
"Outbound Follow On Communication",
"Unauthorized Agent Deployment",
"Security Control Disruption"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DC_IDENTITY_CONTEXT_WINDOW (
SecurityEvent AS DomainControllerIdentityContext
WHERE DomainControllerIdentityContext.TargetAsset IN SAME_DEVICE(DomainControllerSuspiciousActivity.AgentComputerName)
AND DomainControllerIdentityContext.EventPattern IN ANY (
"privileged_logon_to_domain_controller",
"machine_account_change",
"domain_controller_account_change",
"domain_trust_change",
"privileged_group_change",
"replication_permission_change",
"directory_service_object_change",
"abnormal_machine_account_authentication",
"security_control_disruption"
)
)
AND NOT DomainControllerSuspiciousActivity.AgentComputerName IN ASSET_GROUP (
"Approved Domain Controller Maintenance Targets",
"Approved Backup Targets",
"Approved Vulnerability Management Targets",
"Approved Security Testing Targets",
"Approved EDR Response Targets",
"Approved Incident Response Targets"
)
AND NOT DomainControllerSuspiciousActivity.TgtProcCmdLine CONTAINS ANY (
"approved_domain_controller_maintenance",
"approved_backup_activity",
"approved_patching_activity",
"approved_identity_management",
"approved_vulnerability_scan",
"approved_security_testing",
"approved_edr_response",
"approved_incident_response"
)

Rule

Domain-Controller Interaction Followed by Endpoint Lateral Movement or Credential Access

Rule Format

SentinelOne endpoint behavioral lateral-movement and credential-access correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, Storyline context, network telemetry, file telemetry, behavioral indicators, source-host enrichment, domain-controller interaction enrichment, high-value asset inventory, authentication enrichment, directory-service enrichment, and SIEM correlation after source-host validation, domain-controller interaction validation, endpoint field validation, lateral-movement validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect endpoint behavior consistent with lateral movement, credential access, remote administration, or tool staging after suspicious domain-controller interaction.

·        Identify cases where suspicious Netlogon-adjacent or domain-controller service activity is followed by endpoint behavior on the source host or touched internal systems that suggests expansion beyond the initial domain-controller interaction.

·        Prioritize activity involving credential access, token access, remote service creation, WMI, WinRM, SMB administrative shares, RDP, script execution, tool staging, persistence, or access to high-value systems.

·        Support escalation when endpoint behavior is linked to suspicious domain-controller interaction, privileged authentication expansion, directory-service changes, or access to identity infrastructure and other high-value assets.

·        Preserve separation between suspicious lateral movement and confirmed compromise by requiring endpoint, identity, network, file, persistence, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, credential theft, lateral movement, downstream compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify source hosts or internal systems with suspicious endpoint behavior after suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service interaction.

·        Detect process execution involving PowerShell, command shell, WMI, WinRM, PsExec-like tooling, remote administration utilities, credential-access tools, token-access behavior, SMB administrative share use, RDP tooling, SSH tooling, archive utilities, or locally relevant living-off-the-land binaries.

·        Prioritize command lines involving credential access, LSASS access, NTDS access, token access, remote execution, service creation, scheduled task creation, administrative share access, domain discovery, lateral movement, or tool staging.

·        Prioritize endpoint behavior on systems accessed after suspicious domain-controller interaction, including identity infrastructure, jump hosts, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, file servers, and sensitive business systems.

·        Increase confidence when endpoint behavior occurs shortly after suspicious domain-controller service access, privileged authentication, machine-account changes, domain trust changes, privileged group changes, or replication-permission changes.

·        Increase confidence when SentinelOne Storyline context links suspicious execution, credential access, remote administration, network connections, file activity, or outbound communication.

·        Increase confidence when multiple internal systems show similar activity after the same source host, user, account, or suspicious domain-controller interaction window.

·        Reduce severity when activity aligns with approved administrator workflows, helpdesk actions, vulnerability management, backup operations, software deployment, identity-management workflows, security testing, EDR response, incident response, or documented maintenance.

·        Do not attribute endpoint lateral movement or credential access to Netlogon exploitation without suspicious domain-controller interaction and supporting endpoint, identity, network, directory-service, or incident-response evidence.

·        Do not treat endpoint behavioral alerts, remote administration tooling, credential-access indicators, or internal system access as compromise evidence by themselves.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation events.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        File execution telemetry.

·        DLL load telemetry where available.

·        Registry modification telemetry where available.

·        Scheduled task telemetry where available.

·        Service creation telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        User identity.

·        Device identity.

·        Hostname.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        Working directory.

·        Integrity level.

·        Timestamp.

·        Suspicious domain-controller interaction enrichment.

·        Internal access enrichment from NDR or SIEM.

·        Authentication enrichment where available.

·        Directory Services enrichment where available.

·        Asset criticality enrichment.

·        Domain-controller inventory.

·        Identity infrastructure inventory.

·        Jump-host inventory.

·        Privileged management inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Source-code and CI/CD inventory where available.

·        Sensitive application inventory.

·        Approved administrator workflow records.

·        Approved helpdesk workflow records.

·        Approved software deployment baselines.

·        Approved backup schedules.

·        Approved vulnerability management records.

·        Approved security testing records.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Build source-host groups covering endpoints with suspicious domain-controller interaction, unmanaged systems, VPN-connected systems, branch systems, administrative workstations, privileged access workstations, non-administrative servers, and systems involved in suspicious Netlogon-adjacent activity.

·        Build internal high-value asset groups covering domain controllers, identity infrastructure, jump hosts, privileged access workstations, privileged management systems, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, database servers, file servers, and sensitive business systems.

·        Build suspicious endpoint behavior groups for PowerShell, command shell, WMI, WinRM, PsExec-like tooling, remote administration tooling, credential-access behavior, token access, tool staging, persistence creation, scheduled task creation, service creation, registry modification, unauthorized agent deployment, suspicious child processes, and outbound follow-on communication.

·        Build lateral-movement groups for SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database clients, management-plane access, and administrative protocols.

·        Build linkage logic using source host, user identity, device identity, destination hostname, suspicious domain-controller interaction window, remote logon context, identity session, source IP, destination asset, and incident timeline.

·        Validate SentinelOne field availability for process ancestry, command line, Storyline ID, file activity, registry activity, service creation, scheduled tasks, network connections, user identity, device identity, and timestamp.

·        Validate SIEM joins between SentinelOne telemetry, NDR telemetry, Windows Security logs, Directory Services events, authentication logs, asset inventory, change-control records, and incident-response evidence.

·        Use short correlation windows when endpoint lateral movement or credential access occurs immediately after suspicious domain-controller interaction.

·        Use moderate correlation windows for delayed process execution, tool staging, credential access, persistence, outbound communication, or repeated access to internal systems.

·        Use longer correlation windows only when Storyline continuity, domain-controller interaction evidence, identity evidence, asset access evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for domain-controller interaction context, credential access, token access, privileged account involvement, high-value asset access, administrative protocol use, service creation, scheduled task creation, persistence, outbound follow-on, and multiple affected internal systems.

·        Treat endpoint alerts on touched systems as confidence amplifiers, not standalone proof of Netlogon exploitation or domain-controller compromise.

·        Build allowlists for approved administrator workflows, helpdesk actions, software deployment, backup activity, vulnerability management, EDR response, security testing, vendor support, maintenance windows, identity-management workflows, and incident-response activity.

·        Validate all environment variables, source-host groups, high-value asset groups, endpoint behavior groups, lateral-movement groups, linkage fields, timing windows, parser behavior, exception logic, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until domain-controller interaction linkage, destination validation, asset inventory, process lineage, Storyline joins, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to endpoint lateral movement and credential-access behavior following suspicious domain-controller interaction rather than static exploit strings, CVE identifiers, filenames, hashes, public proof-of-concept artifacts, or known infrastructure.

·        The rule remains useful if an adversary changes the initial exploit path, source host, tool choice, command syntax, staging path, internal destination order, or post-access sequence.

·        The score is supported by the durability of credential access, token access, remote administration tooling, SMB administrative share use, service creation, scheduled task creation, persistence, and high-value internal system access.

·        The score is constrained by legitimate administrator activity, helpdesk workflows, vulnerability management, backup activity, software deployment, EDR response, incomplete command-line telemetry, weak domain-controller interaction linkage, and incomplete Storyline continuity.

·        The rule is durable as endpoint lateral-movement coverage but should not be treated as standalone proof of Netlogon exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on SentinelOne endpoint telemetry, Storyline continuity, process telemetry, network telemetry, domain-controller interaction enrichment, high-value asset inventory, identity context, and SIEM join quality.

·        Operational confidence is reduced where endpoint telemetry cannot be tied to suspicious domain-controller interaction, internal access logs are incomplete, remote logon context is missing, or high-value asset inventory is weak.

·        Operational confidence is reduced where administrators, helpdesk users, vulnerability management tools, software deployment systems, backup systems, EDR responders, vendors, identity-management teams, or incident responders commonly perform similar activity.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with NDR telemetry, Windows Security logs, Directory Services events, authentication logs, internal resource telemetry, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support endpoint triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        SentinelOne cannot independently prove that lateral movement or credential access was caused by Netlogon exploitation without network, Windows, Active Directory, identity, or incident-response enrichment.

·        Suspicious endpoint behavior on internal systems may be unrelated to the domain-controller interaction unless timing, identity, device, session, or incident-response evidence supports linkage.

·        Legitimate administrator, helpdesk, software deployment, backup, vulnerability management, security testing, EDR response, vendor-support, identity-management, and incident-response workflows can produce similar endpoint behavior.

·        Missing remote logon context, incomplete process lineage, weak Storyline continuity, missing network enrichment, or incomplete asset inventory can reduce confidence.

·        The rule may miss activity that remains within approved tooling, uses expected administrator pathways, occurs outside the correlation window, or does not generate endpoint artifacts.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility domain-controller interaction to lateral-movement query pattern requiring tenant syntax validation, endpoint field validation, domain-controller interaction linkage validation, internal asset validation, Storyline validation, process lineage validation, approved workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

SentinelOneEndpointEvent AS PostDcInteractionEndpointActivity
WHERE PostDcInteractionEndpointActivity.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"File Execution",
"DLL Load",
"Registry Modified",
"Scheduled Task Created",
"Service Created",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)
AND EVENT_NEAR WITHIN ENV_DC_INTERACTION_CONTEXT_WINDOW (
SecurityOrNetworkEvent AS SuspiciousDomainControllerInteraction
WHERE (
SuspiciousDomainControllerInteraction.UserOrDevice IN SAME_USER_OR_DEVICE(PostDcInteractionEndpointActivity.UserOrDevice)
OR SuspiciousDomainControllerInteraction.SourceAsset IN SAME_DEVICE(PostDcInteractionEndpointActivity.AgentComputerName)
)
AND SuspiciousDomainControllerInteraction.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"repeated_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline"
)
)
AND (
PostDcInteractionEndpointActivity.TgtProcName IN ANY (
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"wmic.exe",
"winrm.vbs",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"psexec.exe",
"procdump.exe",
"rclone.exe",
"ssh.exe",
"python.exe",
"node.exe"
)
OR PostDcInteractionEndpointActivity.TgtProcCmdLine CONTAINS ANY (
"-enc",
"-encodedcommand",
"executionpolicy bypass",
"downloadstring",
"invoke-webrequest",
"invoke-expression",
"credential",
"token",
"dump",
"lsass",
"ntds",
"sam",
"shadow",
"secrets",
"admin$",
"c$",
"psexec",
"wmic",
"winrm",
"rclone",
"remote service",
"scheduled task",
"domain admin",
"enterprise admin"
)
OR PostDcInteractionEndpointActivity.BehavioralIndicator IN ANY (
"Credential Access Behavior",
"Token Access",
"Persistence Attempt",
"Remote Administration Tooling",
"Tool Staging",
"Suspicious Child Process",
"Outbound Follow On Communication",
"Unauthorized Agent Deployment"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_HIGH_VALUE_ACCESS_WINDOW (
SecurityOrNetworkEvent AS HighValueAccessContext
WHERE HighValueAccessContext.UserOrDevice IN SAME_USER_OR_DEVICE(PostDcInteractionEndpointActivity.UserOrDevice)
AND HighValueAccessContext.DestinationAsset IN ASSET_GROUP (
"Domain Controllers",
"Identity Infrastructure",
"Jump Hosts",
"Privileged Access Workstations",
"Privileged Management Systems",
"Management Servers",
"Backup Systems",
"Endpoint Management Platforms",
"Source Code Systems",
"CI/CD Systems",
"Database Servers",
"File Servers",
"Sensitive Business Systems"
)
)
AND NOT PostDcInteractionEndpointActivity.AgentComputerName IN ASSET_GROUP (
"Approved Software Deployment Systems",
"Approved Backup Systems",
"Approved Vulnerability Management Systems",
"Approved Security Testing Systems",
"Approved EDR Response Systems",
"Approved Incident Response Systems"
)
AND NOT PostDcInteractionEndpointActivity.TgtProcCmdLine CONTAINS ANY (
"approved_admin_script",
"approved_helpdesk_action",
"approved_software_deployment",
"approved_backup_activity",
"approved_vulnerability_scan",
"approved_security_testing",
"approved_edr_response",
"approved_identity_management",
"approved_incident_response"
)

Splunk

Detection Viability Assessment

Splunk has three rules for this EXP report.

·        Splunk is viable because this detection model requires multi-source SIEM correlation across Windows Security logs, domain-controller System logs, Directory Services events, authentication telemetry, network telemetry, EDR telemetry, VPN context, asset inventory, privileged-access context, and change-management records.

·        Splunk is strongest where Windows event data, authentication logs, domain-controller inventory, machine-account telemetry, directory-service object-change telemetry, network-flow data, endpoint telemetry, administrative-source baselines, and identity enrichment can be joined reliably.

·        Splunk can identify suspicious sequencing between non-standard domain-controller service access, Netlogon-adjacent activity, authentication anomalies, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, endpoint execution, and downstream lateral movement.

·        Splunk is not a standalone source for confirming successful Netlogon exploitation, domain-controller compromise, Active Directory takeover, credential theft, replication abuse, or actor attribution unless required telemetry is present and correlated across multiple stages of the activity chain.

·        Splunk detections must separate exposure, attempted exploitation, suspected domain-controller trust manipulation, post-exploitation behavior, and confirmed identity-plane compromise.

·        Splunk rules should not generate high-confidence alerting from patch state alone, vulnerability scan output alone, isolated Netlogon errors alone, single authentication anomalies alone, isolated machine-account events alone, or administrative activity that aligns with approved change records.

·        Splunk detection content should be treated as SIEM correlation coverage that supports triage, escalation, and scoping after field mapping, sourcetype validation, index validation, lookup validation, false-positive testing, and SOC workflow validation.

Rule

Suspicious Netlogon-Adjacent Activity Correlated With Domain-Controller Account or Trust Change

Rule Format

Splunk SPL-style staged correlation pattern suitable for Windows Security logs, domain-controller System logs, Directory Services events, network-flow telemetry, authentication telemetry, EDR enrichment, domain-controller inventory lookups, source-role enrichment, machine-account enrichment, privileged group enrichment, trust-change enrichment, change-management records, and SIEM correlation after index validation, sourcetype validation, field mapping, lookup validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Netlogon-adjacent or domain-controller service activity that correlates with domain-controller account changes, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or sensitive Active Directory object modification.

·        Identify cases where suspicious source-to-domain-controller interaction becomes higher risk because it is followed by identity-plane state change.

·        Prioritize activity involving non-standard source systems, unmanaged hosts, VPN ingress sources, workstation networks, branch networks, newly observed internal systems, or systems outside approved administrative paths.

·        Support escalation when network or authentication activity aligns with domain-controller account manipulation, trust manipulation, privileged identity change, or replication-related permission change.

·        Preserve separation between suspicious correlation and confirmed compromise by requiring corroborating Windows, Directory Services, endpoint, network, change-management, or incident-response evidence before classifying the activity as confirmed domain-controller compromise.

·        This rule does not prove successful Netlogon exploitation, Active Directory takeover, credential theft, replication abuse, or actor attribution without supporting evidence across multiple telemetry classes.

Detection Logic

·        Identify suspicious source-to-domain-controller traffic involving Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB domain-controller service, or locally classified domain-controller service activity.

·        Correlate suspicious source-to-domain-controller activity with Windows Security, Directory Services, or identity-plane events involving domain-controller accounts, machine accounts, domain trusts, privileged groups, replication permissions, or sensitive Active Directory object changes.

·        Prioritize sources not present in approved domain-controller, replication, identity-management, monitoring, backup, vulnerability management, or administrative jump-host groups.

·        Increase confidence when the source is unmanaged, VPN-connected, workstation-class, branch-based, newly observed, or outside expected domain-controller interaction paths.

·        Increase confidence when account or object changes occur shortly after repeated domain-controller service access, new source-to-domain-controller paths, or source activity outside a change window.

·        Increase confidence when the correlated activity includes privileged logons, machine-account authentication anomalies, domain-controller account changes, domain trust changes, replication-permission changes, privileged group changes, or security-control disruption.

·        Reduce severity when activity aligns with approved domain join, trust repair, replication maintenance, domain-controller maintenance, identity-management workflows, vulnerability management, security testing, backup activity, or documented incident response.

·        Do not treat vulnerable-state findings, scanner output, isolated Netlogon errors, or a single domain-controller connection as exploitation evidence by themselves.

·        Do not classify the activity as confirmed compromise without corroborating authentication, directory-service, endpoint, network, administrative-control, or incident-response evidence.

·        Do not treat machine-account changes or trust changes as malicious when they align with approved identity-infrastructure operations and known administrative systems.

Required Telemetry

·        Splunk Windows Security index or equivalent.

·        Splunk domain-controller System index or equivalent.

·        Splunk Directory Services index or equivalent.

·        Network-flow index or equivalent.

·        EDR index or equivalent where available.

·        Authentication index or equivalent.

·        VPN or remote-access index where available.

·        Change-management index or lookup.

·        Domain-controller inventory lookup.

·        Approved administrative source lookup.

·        Replication partner lookup.

·        Identity-management system lookup.

·        Monitoring-system lookup.

·        Backup-system lookup.

·        Vulnerability management system lookup.

·        VPN address pool lookup.

·        Branch network lookup.

·        Workstation subnet lookup.

·        Privileged group lookup.

·        Sensitive Active Directory object lookup.

·        Source host.

·        Destination domain controller.

·        Source IP.

·        Destination IP.

·        Destination port.

·        Protocol or service.

·        Account name.

·        Machine account.

·        Object distinguished name.

·        Object class.

·        Event code.

·        Action.

·        Change type.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build domain-controller lookup tables covering hostnames, fully qualified domain names, IP addresses, Active Directory sites, domain-controller subnets, writable domain controllers, read-only domain controllers, and domain-controller service interfaces.

·        Build approved source lookups for domain controllers, replication partners, identity-management platforms, monitoring systems, backup systems, vulnerability management systems, administrative jump hosts, privileged access workstations, and maintenance systems.

·        Build suspicious source logic for unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal systems, and systems outside the domain-controller access baseline.

·        Build protocol or service filters for Netlogon-adjacent traffic, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, and locally classified domain-controller service traffic.

·        Build identity-plane change filters for domain-controller account changes, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, delegation changes, Group Policy changes, and sensitive directory-service object changes.

·        Build authentication-follow-on filters for privileged logons, abnormal machine-account authentication, Kerberos or NTLM anomalies after suspicious domain-controller service access, and service-ticket anomalies.

·        Validate all Splunk indexes, sourcetypes, CIM mappings, event codes, field aliases, timestamp normalization, lookup keys, and join fields before deployment.

·        Validate whether source host, destination domain controller, source IP, destination IP, account, machine account, object distinguished name, event code, action, timestamp, and change-window context are reliably mapped.

·        Use short correlation windows for suspicious domain-controller service access followed by immediate authentication anomalies.

·        Use moderate correlation windows for domain-controller account changes, machine-account changes, trust changes, privileged group changes, replication-permission changes, and directory-service object changes.

·        Use longer correlation windows only when incident-response evidence, repeated source behavior, or identity-plane evidence supports delayed linkage.

·        Add severity weighting for non-standard source role, repeated domain-controller service access, domain-controller account change, trust change, privileged group change, replication-permission change, unmanaged source status, VPN ingress source, and change-management mismatch.

·        Treat network activity, authentication anomalies, and object changes as confidence amplifiers until correlated across the activity chain.

·        Use change-management records, domain join records, trust repair records, replication maintenance records, backup records, vulnerability management records, security-testing records, and incident-response records as triage evidence.

·        Validate false-positive rates using at least one representative business cycle that includes domain-controller maintenance, patching, domain joins, trust repair, backup operations, vulnerability scanning, and identity-management activity.

·        Do not enable alert mode until index availability, sourcetype validation, field mapping, lookup accuracy, join reliability, baseline thresholds, false-positive rate, query performance, SOC triage workflow, enrichment availability, and exception handling are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious domain-controller service access followed by identity-plane change rather than static CVE identifiers, exploit strings, filenames, hashes, packet signatures, or public proof-of-concept artifacts.

·        The rule remains useful if an adversary changes exploit tooling, source host, access timing, command syntax, protocol pacing, or post-exploitation sequence.

·        The score is supported by the durability of Netlogon-adjacent source-path deviation, domain-controller targeting, machine-account change, trust change, privileged group change, replication-permission change, and directory-service object-change correlation.

·        The score is constrained by incomplete Windows event coverage, inconsistent Directory Services auditing, weak lookup quality, missing network telemetry, poor field normalization, and legitimate administrative identity operations.

·        The rule is durable as SIEM correlation coverage but should not be treated as standalone proof of successful Netlogon exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on reliable Splunk ingestion for Windows Security logs, Directory Services events, network-flow telemetry, authentication logs, domain-controller inventory, source-role lookups, and change-management context.

·        Operational confidence is reduced where Windows event mappings are inconsistent, Active Directory auditing is incomplete, source-role enrichment is weak, domain-controller inventory is stale, or change-management records are unavailable.

·        Operational confidence is reduced where identity-management systems, replication workflows, backup systems, vulnerability management platforms, and administrative systems commonly generate similar domain-controller or object-change activity.

·        Full-telemetry confidence improves when Splunk correlates network telemetry, Windows Security logs, Directory Services events, EDR telemetry, authentication logs, VPN telemetry, asset inventory, privileged-access records, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects suspicious correlation between domain-controller service access and identity-plane change, not confirmed exploitation by itself.

·        Splunk cannot infer Netlogon exploitation unless the necessary network, Windows, Active Directory, endpoint, and identity context is present and correctly joined.

·        Legitimate domain join, trust repair, replication maintenance, backup, identity-management, vulnerability management, security testing, and incident-response workflows can produce similar signals.

·        Missing Directory Services auditing, weak field mapping, incomplete network telemetry, stale asset lookups, or missing change records can reduce confidence.

·        The rule may miss activity that uses approved administrative sources, avoids observable identity-plane changes, or occurs outside the configured correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use a Splunk staged correlation pattern that identifies suspicious source-to-domain-controller service activity, appends relevant identity-plane change activity, preserves correlation fields with eventstats, and applies timing, change-management, and severity logic after local validation. The pattern requires SPL syntax validation, index validation, sourcetype validation, CIM validation, lookup validation, timestamp validation, and environment-specific allowlisting before production deployment.

| tstats summariesonly=false count min(_time) as firstSeen max(_time) as lastSeen from datamodel=Network_Traffic.All_Traffic by All_Traffic.src All_Traffic.dest All_Traffic.dest_port All_Traffic.app All_Traffic.transport
| rename All_Traffic.src as src All_Traffic.dest as dest All_Traffic.dest_port as dest_port All_Traffic.app as app All_Traffic.transport as transport
| lookup domain_controller_assets dest OUTPUT dc_role dc_site dc_hostname
| where dc_role="domain_controller"
| where app IN ("netlogon","ms-nrpc","rpc_endpoint_mapper","rpc","smb_domain_controller_service","domain_controller_service")
| lookup approved_dc_sources src OUTPUT approved_source_role
| where isnull(approved_source_role)
| lookup source_context src OUTPUT source_role source_segment managed_status first_seen_source vpn_pool branch_network workstation_subnet
| eval suspicious_source=if(source_role IN ("unmanaged_system","workstation","vpn_connected_host","branch_system","non_administrative_server") OR managed_status="unmanaged" OR isnotnull(vpn_pool) OR isnotnull(branch_network) OR isnotnull(workstation_subnet),1,0)
| where suspicious_source=1 OR count>=ENV_DC_SERVICE_ACCESS_THRESHOLD
| eval correlation_src=src, correlation_dc=dest, interaction_first=firstSeen, interaction_last=lastSeen
| table correlation_src correlation_dc interaction_first interaction_last app dest_port count source_role source_segment managed_status dc_site dc_hostname
| append [
search index=windows OR index=wineventlog sourcetype IN ("WinEventLog:Security","XmlWinEventLog:Security","WinEventLog:Directory Service","XmlWinEventLog:Directory Service")
| where EventCode IN (4724,4738,4742,4728,4732,4756,4719,4739,5136,5137,5139,5141)
| eval identity_event_pattern=case(EventCode=4742,"machine_account_change", EventCode IN (4728,4732,4756),"privileged_group_change", EventCode IN (5136,5137,5139,5141),"directory_service_object_change", EventCode IN (4719,4739),"security_policy_or_domain_policy_change", true(),"identity_plane_change")
| lookup domain_controller_assets Computer OUTPUT dc_role as event_dc_role
| eval correlation_dc=Computer
| table time correlationdc Computer Target_Account_Name Account_Name ObjectDN EventCode identity_event_pattern event_dc_role
]
| eventstats values(interaction_first) as interaction_first values(interaction_last) as interaction_last values(correlation_src) as correlation_src values(app) as app values(dest_port) as dest_port values(count) as count values(source_role) as source_role values(source_segment) as source_segment values(managed_status) as managed_status by correlation_dc
| where isnotnull(identity_event_pattern)
| where time>=interactionfirst AND time<=relativetime(interaction_last,"+ENV_IDENTITY_FOLLOWON_WINDOW")
| lookup change_management_context correlation_src correlation_dc Target_Account_Name ObjectDN OUTPUT change_context
| where isnull(change_context) OR NOT change_context IN ("approved_domain_join","approved_trust_repair","approved_replication_maintenance","approved_domain_controller_maintenance","approved_identity_management_workflow","approved_backup_activity","approved_vulnerability_management","approved_security_testing","approved_incident_response")
| eval severity=case(identity_event_pattern IN ("machine_account_change","privileged_group_change","directory_service_object_change") AND count>=ENV_DC_SERVICE_ACCESS_THRESHOLD,"high", identity_event_pattern IN ("machine_account_change","privileged_group_change","directory_service_object_change"),"medium", true(),"low")
| table interaction_first interaction_last correlation_src correlation_dc app dest_port count source_role source_segment managed_status identity_event_pattern EventCode Target_Account_Name ObjectDN severity

Rule

Abnormal Domain-Controller Authentication Expansion After Suspicious Netlogon-Adjacent Activity

Rule Format

Splunk SPL-style authentication-expansion staged correlation pattern suitable for Windows Security logs, authentication telemetry, network-flow telemetry, domain-controller inventory, privileged account lookups, machine-account enrichment, source-role enrichment, VPN enrichment, EDR enrichment, and SIEM correlation after index validation, sourcetype validation, authentication-field mapping, domain-controller lookup validation, account-risk lookup validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious authentication expansion involving domain controllers after Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or suspicious source-to-domain-controller access activity.

·        Identify cases where a non-standard source interacts with a domain controller and is followed by privileged authentication, machine-account authentication anomalies, abnormal service-ticket behavior, administrative logons, or authentication expansion across internal systems.

·        Prioritize activity involving privileged accounts, domain-controller accounts, machine accounts, service accounts, low-frequency accounts, newly observed accounts, or accounts accessing systems outside their normal baseline.

·        Support escalation when authentication expansion follows suspicious domain-controller interaction and aligns with directory-service changes, endpoint behavior, lateral movement, or security-control disruption.

·        Preserve separation between suspicious authentication expansion and confirmed compromise by requiring corroborating network, Windows, endpoint, directory-service, change-management, or incident-response evidence.

·        This rule does not prove Netlogon exploitation, credential theft, domain compromise, lateral movement, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious source-to-domain-controller service access from non-standard sources.

·        Correlate suspicious domain-controller service access with subsequent authentication events involving privileged accounts, machine accounts, domain-controller accounts, service accounts, or accounts with unusual authentication expansion.

·        Detect authentication activity involving multiple internal destinations, rare user-to-host pairs, privileged logons to domain controllers, administrative logon types, abnormal machine-account authentication, Kerberos or NTLM anomalies, or service-ticket behavior inconsistent with the account baseline.

·        Increase confidence when authentication expansion occurs shortly after repeated domain-controller service access or a new source-to-domain-controller path.

·        Increase confidence when authentication expansion is followed by directory-service object changes, privileged group changes, machine-account changes, domain trust changes, replication-permission changes, or endpoint-observed suspicious behavior.

·        Increase confidence when the source is unmanaged, VPN-connected, workstation-class, branch-based, newly observed, or outside approved administrative pathways.

·        Reduce severity when activity aligns with approved administration, identity-management workflows, domain-controller maintenance, vulnerability management, backup operations, security testing, incident response, or documented change-control activity.

·        Do not classify authentication expansion as Netlogon-linked compromise without suspicious upstream domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat a single privileged logon, Kerberos event, NTLM event, or service-ticket event as compromise evidence by itself.

·        Do not treat authentication anomalies as domain-controller compromise when the activity aligns with approved administrative workflows and known source systems.

Required Telemetry

·        Splunk Windows Security index or equivalent.

·        Authentication index or equivalent.

·        Network-flow index or equivalent.

·        EDR index or equivalent where available.

·        Directory Services index or equivalent.

·        VPN or remote-access index where available.

·        Change-management index or lookup.

·        Domain-controller inventory lookup.

·        Privileged account lookup.

·        Machine-account lookup.

·        Service-account lookup.

·        Low-frequency account lookup where available.

·        Approved administrative source lookup.

·        Source-role enrichment lookup.

·        User baseline lookup.

·        Host baseline lookup.

·        Source host.

·        Destination host.

·        Source IP.

·        Account name.

·        Account domain.

·        Logon type.

·        Authentication package.

·        Ticket or service name where available.

·        Event code.

·        Action.

·        Result.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build suspicious domain-controller interaction searches using network-flow telemetry, domain-controller inventory, and approved source lookups.

·        Build privileged account groups for Domain Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Backup Operators, domain-controller administrators, identity administrators, and locally defined high-risk groups.

·        Build machine-account and service-account groups using naming conventions, directory inventory, and identity-management records.

·        Build authentication expansion logic for rare user-to-host pairs, multiple destination hosts, privileged logons to domain controllers, administrative logon types, abnormal machine-account authentication, Kerberos anomalies, NTLM anomalies, and service-ticket anomalies.

·        Build source-risk enrichment for unmanaged systems, VPN ingress ranges, workstation networks, branch networks, newly observed systems, and sources outside approved administrative paths.

·        Build follow-on correlation for domain-controller account changes, machine-account changes, privileged group changes, domain trust changes, replication-permission changes, directory-service object changes, lateral movement, endpoint credential-access behavior, and security-control disruption.

·        Validate all Splunk indexes, sourcetypes, CIM mappings, authentication fields, EventCode mappings, account fields, host fields, timestamp handling, lookup keys, and join logic before deployment.

·        Validate whether source host, source IP, destination host, account name, authentication package, logon type, event code, result, timestamp, source role, and account risk are reliably mapped.

·        Use short correlation windows for suspicious domain-controller service access followed by immediate privileged authentication.

·        Use moderate correlation windows for authentication expansion across multiple systems, delayed service-ticket activity, directory-service changes, or endpoint activity.

·        Use longer correlation windows only when incident-response evidence, repeated source activity, or identity-plane evidence supports delayed linkage.

·        Add severity weighting for privileged account use, machine-account anomalies, administrative logon types, rare user-to-host pairs, multiple destination hosts, unmanaged source status, VPN ingress source, and downstream identity-plane changes.

·        Treat authentication expansion as a confidence amplifier until correlated with upstream suspicious domain-controller activity and downstream identity-plane or endpoint evidence.

·        Use approved administrator records, identity-management records, backup schedules, vulnerability management records, domain-controller maintenance records, security-testing records, incident-response records, and change-management context as triage evidence.

·        Validate false-positive rates against normal administrative work, helpdesk operations, identity-management workflows, service-account behavior, backup activity, patching, vulnerability scanning, security testing, and incident response.

·        Do not enable alert mode until authentication field mapping, account enrichment, baseline thresholds, correlation reliability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to authentication expansion after suspicious domain-controller interaction rather than static CVE identifiers, exploit strings, packet signatures, filenames, hashes, or known malicious infrastructure.

·        The rule remains useful if an adversary changes tooling, source host, timing, authentication sequence, account choice, target order, or post-access behavior.

·        The score is supported by the durability of privileged authentication, abnormal machine-account authentication, rare user-to-host access, multi-host authentication expansion, and correlation with domain-controller service access.

·        The score is constrained by legitimate administrator activity, service-account behavior, identity-management workflows, backup operations, inconsistent authentication baselines, and incomplete field mapping.

·        The rule is durable as authentication-expansion coverage but should not be treated as standalone proof of successful exploitation, credential theft, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable Windows Security ingestion, authentication telemetry, account enrichment, domain-controller inventory, source-role lookups, baseline data, and Splunk correlation quality.

·        Operational confidence is reduced where privileged account inventories are stale, service-account baselines are weak, machine-account behavior is not well understood, or administrative activity commonly crosses many internal systems.

·        Operational confidence is reduced where logon type, authentication package, account name, source host, destination host, or service-ticket fields are missing or inconsistently normalized.

·        Full-telemetry confidence improves when authentication expansion is enriched with network telemetry, Directory Services events, EDR telemetry, VPN context, change-management records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support identity-plane triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects suspicious authentication expansion after domain-controller interaction, not confirmed exploitation by itself.

·        Splunk cannot determine credential theft, ticket misuse, or domain compromise from authentication logs alone without supporting telemetry.

·        Legitimate administrator, helpdesk, identity-management, backup, vulnerability management, patching, monitoring, and incident-response workflows can produce similar authentication patterns.

·        Missing account enrichment, weak baselines, incomplete authentication fields, or inconsistent normalization can reduce confidence.

·        The rule may miss activity that uses expected accounts, expected administrative paths, or low-and-slow authentication behavior within normal baselines.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use a Splunk staged authentication-expansion correlation pattern that identifies suspicious source-to-domain-controller service activity, appends authentication expansion involving privileged accounts, machine accounts, service accounts, or abnormal multi-host authentication behavior, preserves correlation fields with eventstats, and applies timing, change-management, and severity logic after local validation. The pattern requires SPL syntax validation, Windows authentication field validation, account enrichment validation, domain-controller lookup validation, source-role lookup validation, timing-window tuning, and environment-specific allowlisting before production deployment.

| tstats summariesonly=false count min(_time) as firstSeen max(_time) as lastSeen from datamodel=Network_Traffic.All_Traffic by All_Traffic.src All_Traffic.dest All_Traffic.app All_Traffic.dest_port
| rename All_Traffic.src as src All_Traffic.dest as dest All_Traffic.app as app All_Traffic.dest_port as dest_port
| lookup domain_controller_assets dest OUTPUT dc_role dc_site dc_hostname
| where dc_role="domain_controller"
| where app IN ("netlogon","ms-nrpc","rpc_endpoint_mapper","rpc","smb_domain_controller_service","domain_controller_service")
| lookup approved_dc_sources src OUTPUT approved_source_role
| where isnull(approved_source_role)
| lookup source_context src OUTPUT source_role source_segment managed_status vpn_pool branch_network workstation_subnet
| eval suspicious_dc_interaction=if(source_role IN ("unmanaged_system","workstation","vpn_connected_host","branch_system","non_administrative_server") OR managed_status="unmanaged" OR isnotnull(vpn_pool) OR isnotnull(branch_network) OR isnotnull(workstation_subnet) OR count>=ENV_DC_SERVICE_ACCESS_THRESHOLD,1,0)
| where suspicious_dc_interaction=1
| eval correlation_src=src, correlation_dc=dest, interaction_first=firstSeen, interaction_last=lastSeen
| table correlation_src correlation_dc interaction_first interaction_last app count source_role source_segment managed_status dc_site dc_hostname
| append [
search index=windows OR index=wineventlog sourcetype IN ("WinEventLog:Security","XmlWinEventLog:Security")
| where EventCode IN (4624,4625,4648,4672,4768,4769,4771,4776)
| eval correlation_src=coalesce(src_ip, Source_Network_Address, Workstation_Name, Computer)
| eval auth_pattern=case(EventCode=4672,"privileged_logon", EventCode=4648,"explicit_credential_use", EventCode=4769,"kerberos_service_ticket_activity", EventCode=4776,"ntlm_authentication", EventCode=4768,"kerberos_tgt_activity", true(),"authentication_activity")
| lookup privileged_accounts Account_Name OUTPUT privileged_account
| lookup machine_accounts Account_Name OUTPUT machine_account
| lookup service_accounts Account_Name OUTPUT service_account
| eventstats dc(Computer) as distinct_auth_destinations by Account_Name
| eval authentication_expansion=if(privileged_account=1 OR machine_account=1 OR service_account=1 OR distinct_auth_destinations>=ENV_AUTH_EXPANSION_THRESHOLD OR Logon_Type IN (3,9,10),1,0)
| where authentication_expansion=1
| table time correlationsrc Computer Account_Name Logon_Type Authentication_Package EventCode auth_pattern privileged_account machine_account service_account distinct_auth_destinations
]
| eventstats values(interaction_first) as interaction_first values(interaction_last) as interaction_last values(correlation_dc) as correlation_dc values(app) as app values(count) as count values(source_role) as source_role by correlation_src
| where isnotnull(auth_pattern)
| where time>=interactionfirst AND time<=relativetime(interaction_last,"+ENV_AUTH_FOLLOWON_WINDOW")
| lookup change_management_context correlation_src Account_Name Computer OUTPUT change_context
| where isnull(change_context) OR NOT change_context IN ("approved_administrator_activity","approved_identity_management_workflow","approved_backup_activity","approved_vulnerability_management","approved_domain_controller_maintenance","approved_security_testing","approved_incident_response")
| eval severity=case(privileged_account=1 AND distinct_auth_destinations>=ENV_AUTH_EXPANSION_THRESHOLD,"high", machine_account=1 OR service_account=1 OR auth_pattern IN ("privileged_logon","explicit_credential_use"),"medium", true(),"low")
| table interaction_first interaction_last correlation_src correlation_dc app count source_role Account_Name Computer Logon_Type Authentication_Package auth_pattern distinct_auth_destinations severity

Rule

Domain-Controller Service Anomaly Correlated With Endpoint Execution and Lateral Movement

Rule Format

Splunk SPL-style multi-source post-interaction staged correlation pattern suitable for network-flow telemetry, Windows Security logs, Directory Services events, EDR telemetry, authentication telemetry, DNS logs, proxy logs, firewall logs, domain-controller inventory, high-value asset inventory, source-role enrichment, change-management records, and SIEM correlation after index validation, sourcetype validation, endpoint-field mapping, network-field mapping, asset lookup validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious domain-controller service activity followed by endpoint execution, lateral movement, administrative protocol use, high-value asset access, outbound communication, or security-control disruption.

·        Identify cases where suspicious Netlogon-adjacent or domain-controller service interaction becomes higher risk because it is followed by observable post-interaction activity across endpoint and network telemetry.

·        Prioritize activity involving source hosts or domain controllers that later access identity infrastructure, jump hosts, management servers, backup systems, endpoint-management platforms, file servers, source-code systems, CI/CD systems, databases, or sensitive business applications.

·        Support escalation when endpoint execution, lateral movement, or outbound communication aligns with privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or directory-service changes.

·        Preserve separation between suspicious post-interaction behavior and confirmed compromise by requiring endpoint, identity, network, file, persistence, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, command-and-control, exfiltration, credential theft, downstream compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious domain-controller service activity involving Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or locally classified domain-controller service traffic from a non-standard source.

·        Correlate the same source host or affected domain controller with endpoint execution involving PowerShell, command shell, WMI, WinRM, service creation, scheduled task creation, credential-access behavior, tool staging, persistence, or suspicious process execution.

·        Correlate the same source host or affected domain controller with lateral movement involving SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database access, management-plane access, or administrative protocols.

·        Correlate the same source host or affected domain controller with outbound communication involving rare destinations, newly observed domains, low-reputation destinations, tunnel-like traffic, abnormal byte volume, unexpected SMB egress, or destinations outside normal baselines.

·        Increase confidence when post-interaction behavior follows privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or directory-service object changes.

·        Increase confidence when activity targets high-value assets, identity infrastructure, domain controllers, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, or sensitive business systems.

·        Reduce severity when behavior aligns with approved administrator workflows, backup schedules, monitoring activity, patching, software deployment, vulnerability management, identity-management workflows, security testing, incident response, or documented change-control activity.

·        Do not attribute endpoint execution, lateral movement, or outbound communication to Netlogon exploitation without suspicious upstream domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat lateral movement, administrative protocol use, outbound communication, or EDR activity as compromise evidence by itself.

·        Do not use this rule for actor attribution without incident-specific intelligence and validated behavioral correlation.

Required Telemetry

·        Splunk network-flow index or equivalent.

·        Splunk Windows Security index or equivalent.

·        Splunk Directory Services index or equivalent.

·        EDR index or equivalent.

·        DNS index where available.

·        Proxy index where available.

·        Firewall index where available.

·        Authentication index or equivalent.

·        Change-management index or lookup.

·        Domain-controller inventory lookup.

·        High-value asset inventory lookup.

·        Identity infrastructure lookup.

·        Jump-host lookup.

·        Management-server lookup.

·        Backup-system lookup.

·        Endpoint-management platform lookup.

·        Source-code and CI/CD inventory lookup where available.

·        Sensitive business application lookup.

·        Approved administrative source lookup.

·        Approved workflow lookup.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Account name.

·        Process name.

·        Process command line.

·        Parent process.

·        Destination port.

·        Protocol or service.

·        DNS query where available.

·        External destination context where available.

·        Event code.

·        Action.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build suspicious domain-controller interaction searches using network-flow telemetry, domain-controller inventory, approved source lookups, protocol filters, and source-role enrichment.

·        Build endpoint execution searches for PowerShell, command shell, WMI, WinRM, service creation, scheduled task creation, script execution, credential-access behavior, tool staging, suspicious process execution, and security-control disruption.

·        Build lateral-movement searches for SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database clients, management-plane access, and administrative protocols.

·        Build outbound-risk searches for newly observed external destinations, rare domains, unusual ASNs, low-reputation destinations, tunnel-like traffic, abnormal DNS behavior, abnormal byte volume, unexpected SMB egress, and destinations inconsistent with source or domain-controller baselines.

·        Build high-value asset groups covering identity infrastructure, domain controllers, jump hosts, privileged management systems, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, databases, file servers, and sensitive business applications.

·        Build identity-plane follow-on groups for privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, and administrative-control activity.

·        Validate all Splunk indexes, sourcetypes, CIM mappings, endpoint fields, network fields, authentication fields, lookup keys, timestamp normalization, process fields, and join fields before deployment.

·        Validate whether source host, destination host, process name, command line, account name, source IP, destination IP, event code, action, protocol, external destination, and timestamp are reliably mapped.

·        Use short correlation windows for immediate endpoint execution, lateral movement, or outbound communication after suspicious domain-controller service activity.

·        Use moderate correlation windows for delayed post-interaction activity, repeated internal access, credential access, persistence, or security-control disruption.

·        Use longer correlation windows only when incident-response evidence, endpoint continuity, identity evidence, or repeated access patterns support delayed linkage.

·        Add severity weighting for suspicious upstream domain-controller interaction, high-value asset access, privileged account involvement, suspicious process execution, credential-access behavior, security-control disruption, identity-plane changes, and outbound-risk context.

·        Treat endpoint execution, lateral movement, and outbound communication as confidence amplifiers, not standalone proof of Netlogon exploitation.

·        Use approved administrator records, monitoring records, backup records, patching records, software deployment records, vulnerability management records, identity-management records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate false-positive rates against administrative workflows, endpoint-management activity, backup activity, monitoring activity, software deployment, patching, vulnerability management, identity-management work, security testing, and incident response.

·        Do not enable alert mode until index availability, field mapping, endpoint-to-network joins, asset lookup accuracy, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious domain-controller interaction followed by endpoint execution, lateral movement, or outbound behavior rather than static CVE identifiers, exploit strings, file hashes, packet signatures, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, process choice, lateral-movement method, outbound destination, timing, or post-exploitation sequence.

·        The score is supported by the durability of post-interaction endpoint behavior, high-value asset access, lateral movement, credential-access behavior, security-control disruption, and outbound communication.

·        The score is constrained by legitimate administrator activity, endpoint-management workflows, backup traffic, software deployment, vulnerability management, incomplete EDR telemetry, and weak asset inventory.

·        The rule is durable as multi-source post-interaction coverage but should not be treated as standalone proof of successful exploitation, compromise, command-and-control, exfiltration, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable Splunk ingestion for network telemetry, EDR telemetry, Windows Security logs, Directory Services events, DNS logs, proxy logs, firewall logs, high-value asset inventory, and source-role enrichment.

·        Operational confidence is reduced where endpoint telemetry is incomplete, DNS or proxy logs are missing, high-value asset inventories are weak, process fields are inconsistent, or source-host joins are unreliable.

·        Operational confidence is reduced where administrators, backup systems, monitoring systems, software deployment systems, vulnerability management platforms, identity-management systems, or incident responders commonly perform similar post-interaction activity.

·        Full-telemetry confidence improves when Splunk correlates network telemetry, EDR telemetry, authentication logs, Directory Services events, DNS logs, proxy logs, firewall logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation, compromise, or actor attribution.

Limitations

·        This rule detects post-interaction endpoint and network behavior, not confirmed exploitation by itself.

·        Splunk cannot determine intent or compromise state unless endpoint, identity, network, directory-service, and incident-response evidence support the correlation.

·        Legitimate administrator, backup, monitoring, patching, software deployment, vulnerability management, identity-management, security testing, and incident-response workflows can produce similar behavior.

·        Missing EDR data, incomplete DNS or proxy logs, weak field mapping, stale asset inventories, or poor source-host joins can reduce confidence.

·        The rule may miss activity that uses expected administrative paths, communicates with approved destinations, avoids endpoint artifacts, or occurs outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use a Splunk staged post-interaction correlation pattern that identifies suspicious source-to-domain-controller service activity, appends endpoint execution, lateral movement, outbound communication, or high-value asset access activity, preserves correlation fields with eventstats, and applies timing, change-management, and severity logic after local validation. The pattern requires SPL syntax validation, index validation, sourcetype validation, endpoint-field mapping, network-field mapping, high-value asset lookup validation, timing-window tuning, and environment-specific allowlisting before production deployment.

| tstats summariesonly=false count min(_time) as firstSeen max(_time) as lastSeen from datamodel=Network_Traffic.All_Traffic by All_Traffic.src All_Traffic.dest All_Traffic.app All_Traffic.dest_port
| rename All_Traffic.src as src All_Traffic.dest as dc_dest All_Traffic.app as app All_Traffic.dest_port as dest_port
| lookup domain_controller_assets dc_dest OUTPUT dc_role dc_site dc_hostname
| where dc_role="domain_controller"
| where app IN ("netlogon","ms-nrpc","rpc_endpoint_mapper","rpc","smb_domain_controller_service","domain_controller_service")
| lookup approved_dc_sources src OUTPUT approved_source_role
| where isnull(approved_source_role)
| lookup source_context src OUTPUT source_role managed_status vpn_pool branch_network workstation_subnet
| eval suspicious_dc_interaction=if(source_role IN ("unmanaged_system","workstation","vpn_connected_host","branch_system","non_administrative_server") OR managed_status="unmanaged" OR isnotnull(vpn_pool) OR isnotnull(branch_network) OR isnotnull(workstation_subnet) OR count>=ENV_DC_SERVICE_ACCESS_THRESHOLD,1,0)
| where suspicious_dc_interaction=1
| eval correlation_src=src, correlation_dc=dc_dest, interaction_first=firstSeen, interaction_last=lastSeen
| table correlation_src correlation_dc interaction_first interaction_last app count source_role managed_status dc_site dc_hostname
| append [
search index=edr OR index=endpoint OR index=network OR index=firewall OR index=dns
| eval correlation_src=coalesce(src, src_ip, host, Computer)
| eval followon_pattern=case(process_name IN ("powershell.exe","pwsh.exe","cmd.exe","wmic.exe","winrm.vbs","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","psexec.exe","procdump.exe","rclone.exe"),"endpoint_execution_or_credential_access", like(process_command_line,"%encodedcommand%") OR like(process_command_line,"%executionpolicy bypass%") OR like(process_command_line,"%downloadstring%") OR like(process_command_line,"%invoke-webrequest%") OR like(process_command_line,"%credential%") OR like(process_command_line,"%token%") OR like(process_command_line,"%dump%") OR like(process_command_line,"%lsass%") OR like(process_command_line,"%ntds%") OR like(process_command_line,"%admin$%") OR like(process_command_line,"%scheduled task%"),"endpoint_execution_or_credential_access", app IN ("smb_admin_share","rdp","wmi","winrm","remote_service","ssh","ldap","kerberos","database","management_plane","admin_protocol"),"lateral_movement_or_outbound_activity", external_destination_context IN ("newly_observed_external_destination","rare_external_destination","low_reputation_destination","tunnel_like_protocol","abnormal_byte_volume","destination_not_in_source_baseline"),"lateral_movement_or_outbound_activity", true(),null())
| where isnotnull(followon_pattern)
| lookup high_value_assets dest OUTPUT asset_criticality asset_group
| table time correlationsrc host user process_name process_command_line dest app external_destination_context asset_group followon_pattern
]
| eventstats values(interaction_first) as interaction_first values(interaction_last) as interaction_last values(correlation_dc) as correlation_dc values(app) as app values(count) as count values(source_role) as source_role by correlation_src
| where isnotnull(followon_pattern)
| where time>=interactionfirst AND time<=relativetime(interaction_last,"+ENV_POST_DC_INTERACTION_WINDOW")
| lookup change_management_context correlation_src correlation_dc user OUTPUT change_context
| where isnull(change_context) OR NOT change_context IN ("approved_administrator_activity","approved_monitoring_activity","approved_backup_activity","approved_identity_management_workflow","approved_vulnerability_management","approved_patching_activity","approved_software_deployment","approved_security_testing","approved_incident_response")
| eval severity=case(followon_pattern="endpoint_execution_or_credential_access" AND source_role IN ("unmanaged_system","workstation","vpn_connected_host"),"high", followon_pattern="lateral_movement_or_outbound_activity" AND isnotnull(asset_group),"high", followon_pattern IN ("endpoint_execution_or_credential_access","lateral_movement_or_outbound_activity"),"medium", true(),"low")
| table interaction_first interaction_last correlation_src correlation_dc app count source_role followon_pattern host user process_name process_command_line dest asset_group external_destination_context severity

Elastic

Detection Viability Assessment

Elastic has three rules for this EXP report.

·        Elastic is viable for detecting Windows Netlogon remote code execution and domain-controller compromise exposure where Elastic Security ingests Windows event logs, Directory Services events, endpoint telemetry, network-flow telemetry, authentication telemetry, asset enrichment, identity enrichment, and change-management context.

·        Elastic is strongest where Elastic Defend, Winlogbeat, Elastic Agent, Packetbeat, network-flow integrations, Windows Security event ingestion, Directory Services auditing, and enrichment pipelines can be correlated through normalized host, user, source IP, destination IP, process, event code, asset-role, and identity fields.

·        Elastic can identify suspicious sequencing between non-standard source-to-domain-controller service access, Netlogon-adjacent activity, authentication anomalies, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, endpoint execution, lateral movement, and outbound communication.

·        Elastic is not a standalone source for confirming successful Netlogon exploitation, domain-controller compromise, Active Directory takeover, credential theft, replication abuse, or actor attribution unless endpoint, network, Windows, directory-service, identity, and incident-response evidence are correlated.

·        Elastic rules should not generate high-confidence alerting from patch state alone, vulnerability scan output alone, isolated Netlogon errors alone, single domain-controller network sessions alone, single authentication anomalies alone, or administrative activity that aligns with approved change records.

·        Elastic detection content should be treated as correlation and investigation coverage for suspicious domain-controller interaction, identity-plane change, source-host behavior, and post-interaction activity after index validation, field mapping, ECS normalization, enrichment validation, false-positive testing, and SOC workflow validation.

·        Elastic detections must preserve separation between exposed or vulnerable systems, suspicious interaction, suspected exploitation attempt, suspected identity-plane manipulation, post-exploitation behavior, and confirmed domain-controller compromise.

Rule

Suspicious Source-to-Domain-Controller Netlogon / RPC Activity With Identity-Plane Change

Rule Format

Elastic implementation pattern suitable for EQL, KQL, ES|QL, or detection-rule chaining after local validation of index names, data streams, ECS field mappings, event-code mappings, host identity fields, source and destination fields, domain-controller asset enrichment, approved-source enrichment, identity-plane event mappings, timing windows, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB domain-controller service, or locally classified domain-controller service activity from a non-standard source to a domain controller.

·        Correlate suspicious source-to-domain-controller activity with identity-plane changes involving machine accounts, domain-controller accounts, domain trusts, privileged groups, replication-related permissions, security policy, or sensitive Active Directory objects.

·        Prioritize sources that are unmanaged, workstation-class, VPN-connected, branch-based, newly observed, or outside approved domain-controller access paths.

·        Support escalation when domain-controller service activity is followed by authentication anomalies, machine-account changes, domain trust changes, privileged group changes, directory-service object changes, or endpoint-observed suspicious behavior.

·        Preserve separation between suspicious correlation and confirmed compromise by requiring corroborating Windows, Directory Services, endpoint, network, change-management, or incident-response evidence before classifying the activity as confirmed domain-controller compromise.

·        This rule does not prove successful Netlogon exploitation, Active Directory takeover, credential theft, replication abuse, or actor attribution without supporting evidence across multiple telemetry classes.

Detection Logic

·        Identify network events where a non-standard source communicates with a verified domain controller using Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB domain-controller service, or locally classified domain-controller service traffic.

·        Require explicit domain-controller destination matching using validated domain-controller hostnames, fully qualified domain names, IP addresses, Active Directory sites, or enrichment fields.

·        Exclude approved domain controllers, replication partners, identity-management systems, monitoring systems, backup systems, vulnerability management systems, administrative jump hosts, privileged access workstations, and authorized maintenance systems.

·        Prioritize suspicious sources from unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal systems, or systems outside the domain-controller access baseline.

·        Correlate suspicious source-to-domain-controller service activity with Windows Security or Directory Services events involving machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, security policy changes, or sensitive directory-service object changes.

·        Use locally validated correlation keys rather than assuming every identity-plane event will share the network source IP. Acceptable correlation keys may include domain-controller host, source host, source IP, related IP, user name, machine account, object distinguished name, incident timeline, or enrichment-generated correlation identifiers.

·        Increase confidence when suspicious source-to-domain-controller activity occurs shortly before identity-plane changes or authentication anomalies.

·        Increase confidence when the same source, account, machine account, or domain-controller context is associated with privileged logons, abnormal machine-account authentication, directory-service object changes, endpoint credential-access behavior, remote administration tooling, or lateral movement.

·        Reduce severity when activity aligns with approved domain join, trust repair, replication maintenance, domain-controller maintenance, identity-management workflows, vulnerability management, backup activity, security testing, incident response, or documented change-control activity.

·        Do not treat vulnerable-state findings, scanner output, isolated Netlogon errors, single RPC sessions, or single SMB sessions as exploitation evidence by themselves.

·        Do not classify machine-account changes, trust changes, or privileged group changes as malicious when they align with approved identity-infrastructure workflows and known administrative systems.

·        Do not classify the activity as confirmed compromise without corroborating authentication, directory-service, endpoint, network, administrative-control, or incident-response evidence.

Required Telemetry

·        Elastic Security event indices.

·        Elastic Defend endpoint telemetry where available.

·        Winlogbeat or Elastic Agent Windows Security event ingestion.

·        Directory Services event ingestion.

·        Domain-controller System event ingestion where available.

·        Network-flow telemetry.

·        Packetbeat, Zeek, firewall, or equivalent network telemetry where available.

·        Authentication telemetry.

·        VPN or remote-access telemetry where available.

·        Change-management data or lookup enrichment.

·        Domain-controller asset inventory.

·        Approved administrative source inventory.

·        Replication partner inventory.

·        Identity-management system inventory.

·        Monitoring-system inventory.

·        Backup-system inventory.

·        Vulnerability management system inventory.

·        VPN address pool inventory.

·        Branch network inventory.

·        Workstation subnet inventory.

·        Privileged group inventory.

·        Sensitive Active Directory object inventory.

·        Source host.

·        Destination domain controller.

·        Source IP.

·        Destination IP.

·        Destination port.

·        Network protocol.

·        Network application or service.

·        Account name.

·        Machine account.

·        Object distinguished name.

·        Object class.

·        Event code.

·        Event action.

·        Event timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build domain-controller asset lists covering hostnames, fully qualified domain names, IP addresses, Active Directory sites, domain-controller subnets, writable domain controllers, read-only domain controllers, and domain-controller service interfaces.

·        Build approved source lists for domain controllers, replication partners, identity-management systems, monitoring systems, backup systems, vulnerability management systems, administrative jump hosts, privileged access workstations, and maintenance systems.

·        Build suspicious source logic for unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal systems, and systems outside the domain-controller access baseline.

·        Build locally validated protocol and application mappings for Netlogon-adjacent traffic, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, and locally classified domain-controller service traffic. Do not assume these values will always appear in network.protocol; validate whether they appear in network.protocol, network.application, event.dataset, Zeek fields, Packetbeat fields, firewall application fields, or custom enrichment fields.

·        Build identity-plane change filters for machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, delegation changes, Group Policy changes, security policy changes, and sensitive directory-service object changes.

·        Validate Elastic index names, data streams, ECS field mappings, event-code mappings, host fields, user fields, source fields, destination fields, process fields, timestamp normalization, enrichment keys, and correlation fields before deployment.

·        Validate whether source host, destination domain controller, source IP, destination IP, user name, machine account, object distinguished name, event code, event action, timestamp, source role, and change-window context are reliably mapped.

·        Use short correlation windows for suspicious domain-controller service access followed by immediate authentication anomalies.

·        Use moderate correlation windows for machine-account changes, trust changes, privileged group changes, replication-permission changes, and directory-service object changes.

·        Use longer correlation windows only when incident-response evidence, repeated source behavior, or identity-plane evidence supports delayed linkage.

·        Add severity weighting for non-standard source role, repeated domain-controller service access, domain-controller account change, trust change, privileged group change, replication-permission change, unmanaged source status, VPN ingress source, and change-management mismatch.

·        Treat network activity, authentication anomalies, and object changes as confidence amplifiers until correlated across the activity chain.

·        Use change-management records, domain join records, trust repair records, replication maintenance records, backup records, vulnerability management records, security-testing records, and incident-response records as triage evidence.

·        Validate false-positive rates against at least one representative business cycle that includes domain-controller maintenance, patching, domain joins, trust repair, backup operations, vulnerability scanning, and identity-management activity.

·        Do not enable alert mode until index availability, ECS mapping, field mapping, enrichment accuracy, correlation reliability, baseline thresholds, false-positive rate, query performance, SOC triage workflow, and exception handling are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious domain-controller service access followed by identity-plane change rather than static CVE identifiers, exploit strings, filenames, hashes, packet signatures, or public proof-of-concept artifacts.

·        The rule remains useful if an adversary changes exploit tooling, source host, access timing, command syntax, protocol pacing, or post-exploitation sequence.

·        The score is supported by the durability of Netlogon-adjacent source-path deviation, domain-controller targeting, machine-account change, trust change, privileged group change, replication-permission change, and directory-service object-change correlation.

·        The score is constrained by incomplete Windows event coverage, inconsistent Directory Services auditing, weak enrichment quality, missing network telemetry, poor ECS normalization, and legitimate administrative identity operations.

·        The rule is durable as Elastic correlation coverage but should not be treated as standalone proof of successful Netlogon exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on reliable Elastic ingestion for Windows Security logs, Directory Services events, network-flow telemetry, authentication logs, domain-controller inventory, source-role enrichment, and change-management context.

·        Operational confidence is reduced where Windows event mappings are inconsistent, Active Directory auditing is incomplete, source-role enrichment is weak, domain-controller inventory is stale, or change-management records are unavailable.

·        Operational confidence is reduced where identity-management systems, replication workflows, backup systems, vulnerability management platforms, and administrative systems commonly generate similar domain-controller or object-change activity.

·        Full-telemetry confidence improves when Elastic correlates network telemetry, Windows Security logs, Directory Services events, Elastic Defend telemetry, authentication logs, VPN telemetry, asset inventory, privileged-access records, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects suspicious correlation between domain-controller service access and identity-plane change, not confirmed exploitation by itself.

·        Elastic cannot infer Netlogon exploitation unless the necessary network, Windows, Active Directory, endpoint, and identity context is present and correctly correlated.

·        Legitimate domain join, trust repair, replication maintenance, backup, identity-management, vulnerability management, security testing, and incident-response workflows can produce similar signals.

·        Missing Directory Services auditing, weak ECS field mapping, incomplete network telemetry, stale asset enrichment, or missing change records can reduce confidence.

·        The rule may miss activity that uses approved administrative sources, avoids observable identity-plane changes, or occurs outside the configured correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use an Elastic implementation pattern that first collects suspicious source-to-domain-controller service activity, then collects identity-plane change activity, then correlates those sets using locally validated keys and timing windows. This is not universal plug-and-play EQL, KQL, or ES|QL; exact syntax must be generated after index, data-stream, ECS, enrichment, and field validation.

network_event where
(
destination.domain in DOMAIN_CONTROLLER_ASSETS
or destination.ip in DOMAIN_CONTROLLER_ASSETS
)
and
(
network.protocol in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or network.application in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or event.dataset in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_DATASETS
or rule.name in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_CLASSIFIERS
)
and not source.ip in APPROVED_DOMAIN_CONTROLLER_SOURCES
and
(
source.asset.role in ("unmanaged_system", "workstation", "vpn_connected_host", "branch_system", "non_administrative_server")
or source.ip in VPN_ADDRESS_POOLS
or source.ip in BRANCH_NETWORKS
or source.ip in WORKSTATION_SUBNETS
or event.risk_score >= ENV_DC_SERVICE_ACCESS_THRESHOLD
)

identity_event where
event.code in ("4724", "4738", "4742", "4728", "4732", "4756", "4719", "4739", "5136", "5137", "5139", "5141")
and
(
host.name in DOMAIN_CONTROLLER_ASSETS
or winlog.computer_name in DOMAIN_CONTROLLER_ASSETS
or related.hosts intersects DOMAIN_CONTROLLER_ASSETS
or object.domain_controller in DOMAIN_CONTROLLER_ASSETS
)
and not labels.change_context in ("approved_domain_join", "approved_trust_repair", "approved_replication_maintenance", "approved_domain_controller_maintenance", "approved_identity_management_workflow", "approved_backup_activity", "approved_vulnerability_management", "approved_security_testing", "approved_incident_response")

correlate network_event and identity_event where
(
network_event.destination.ip == identity_event.host.ip
or network_event.destination.domain == identity_event.host.name
or network_event.destination.domain == identity_event.winlog.computer_name
or network_event.correlation.domain_controller == identity_event.correlation.domain_controller
or network_event.source.ip == identity_event.related.ip
or network_event.user.name == identity_event.user.name
or network_event.machine.account == identity_event.machine.account
)
and identity_event.timestamp between network_event.timestamp and network_event.timestamp + ENV_IDENTITY_FOLLOWON_WINDOW

derive identity_event_pattern from event.code where
"4742" maps to "machine_account_change"
"4728", "4732", and "4756" map to "privileged_group_change"
"5136", "5137", "5139", and "5141" map to "directory_service_object_change"
"4719" and "4739" map to "security_policy_or_domain_policy_change"
all remaining matched identity-plane events map to "identity_plane_change"

assign severity where
"high" requires identity_event_pattern in ("machine_account_change", "privileged_group_change", "directory_service_object_change") and repeated or high-risk domain-controller service access
"medium" requires identity_event_pattern in ("machine_account_change", "privileged_group_change", "directory_service_object_change") without confirmed high-risk repetition
"low" applies to remaining correlated identity-plane changes pending analyst validation

Rule

Abnormal Domain-Controller Authentication Expansion After Suspicious Netlogon-Adjacent Activity

Rule Format

Elastic implementation pattern suitable for EQL, KQL, ES|QL, or detection-rule chaining after local validation of Windows Security event ingestion, authentication field mappings, account enrichment, source-host enrichment, domain-controller asset enrichment, VPN or NAT transformations, host identity normalization, timing windows, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious authentication expansion involving domain controllers after Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or suspicious source-to-domain-controller access activity.

·        Identify cases where a non-standard source interacts with a domain controller and is followed by privileged authentication, machine-account authentication anomalies, abnormal service-ticket behavior, administrative logons, or authentication expansion across internal systems.

·        Prioritize activity involving privileged accounts, domain-controller accounts, machine accounts, service accounts, low-frequency accounts, newly observed accounts, or accounts accessing systems outside their normal baseline.

·        Support escalation when authentication expansion follows suspicious domain-controller interaction and aligns with directory-service changes, endpoint behavior, lateral movement, or security-control disruption.

·        Preserve separation between suspicious authentication expansion and confirmed compromise by requiring corroborating network, Windows, endpoint, directory-service, change-management, or incident-response evidence.

·        This rule does not prove Netlogon exploitation, credential theft, domain compromise, lateral movement, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious source-to-domain-controller service access from non-standard sources.

·        Correlate suspicious domain-controller service access with subsequent authentication events involving privileged accounts, machine accounts, domain-controller accounts, service accounts, or accounts with unusual authentication expansion.

·        Detect authentication activity involving multiple internal destinations, rare user-to-host pairs, privileged logons to domain controllers, administrative logon types, abnormal machine-account authentication, Kerberos or NTLM anomalies, or service-ticket behavior inconsistent with the account baseline.

·        Use locally validated source and identity correlation keys rather than assuming all authentication events share the original network source IP.

·        Increase confidence when authentication expansion occurs shortly after repeated domain-controller service access or a new source-to-domain-controller path.

·        Increase confidence when authentication expansion is followed by directory-service object changes, privileged group changes, machine-account changes, domain trust changes, replication-permission changes, or endpoint-observed suspicious behavior.

·        Increase confidence when the source is unmanaged, VPN-connected, workstation-class, branch-based, newly observed, or outside approved administrative pathways.

·        Reduce severity when activity aligns with approved administration, identity-management workflows, domain-controller maintenance, vulnerability management, backup operations, security testing, incident response, or documented change-control activity.

·        Do not classify authentication expansion as Netlogon-linked compromise without suspicious upstream domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat a single privileged logon, Kerberos event, NTLM event, or service-ticket event as compromise evidence by itself.

·        Do not treat authentication anomalies as domain-controller compromise when the activity aligns with approved administrative workflows and known source systems.

Required Telemetry

·        Elastic Security event indices.

·        Winlogbeat or Elastic Agent Windows Security event ingestion.

·        Authentication telemetry.

·        Network-flow telemetry.

·        Elastic Defend telemetry where available.

·        Directory Services event ingestion.

·        VPN or remote-access telemetry where available.

·        Change-management data or lookup enrichment.

·        Domain-controller asset inventory.

·        Privileged account inventory.

·        Machine-account inventory.

·        Service-account inventory.

·        Low-frequency account baseline where available.

·        Approved administrative source inventory.

·        Source-role enrichment.

·        User baseline enrichment.

·        Host baseline enrichment.

·        Source host.

·        Destination host.

·        Source IP.

·        Account name.

·        Account domain.

·        Logon type.

·        Authentication package.

·        Ticket or service name where available.

·        Event code.

·        Event action.

·        Event outcome.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build suspicious domain-controller interaction searches using network telemetry, domain-controller inventory, approved source inventory, and source-role enrichment.

·        Build privileged account groups for Domain Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Backup Operators, domain-controller administrators, identity administrators, and locally defined high-risk groups.

·        Build machine-account and service-account groups using naming conventions, directory inventory, and identity-management records.

·        Build authentication expansion logic for rare user-to-host pairs, multiple destination hosts, privileged logons to domain controllers, administrative logon types, abnormal machine-account authentication, Kerberos anomalies, NTLM anomalies, and service-ticket anomalies.

·        Build source-risk enrichment for unmanaged systems, VPN ingress ranges, workstation networks, branch networks, newly observed systems, and sources outside approved administrative paths.

·        Build follow-on correlation for domain-controller account changes, machine-account changes, privileged group changes, domain trust changes, replication-permission changes, directory-service object changes, lateral movement, endpoint credential-access behavior, and security-control disruption.

·        Validate Elastic index names, data streams, ECS mappings, authentication fields, event-code mappings, account fields, host fields, timestamp handling, enrichment keys, and correlation fields before deployment.

·        Validate whether source host, source IP, destination host, account name, authentication package, logon type, event code, event outcome, timestamp, source role, and account risk are reliably mapped.

·        Use short correlation windows for suspicious domain-controller service access followed by immediate privileged authentication.

·        Use moderate correlation windows for authentication expansion across multiple systems, delayed service-ticket activity, directory-service changes, or endpoint activity.

·        Use longer correlation windows only when incident-response evidence, repeated source activity, or identity-plane evidence supports delayed linkage.

·        Add severity weighting for privileged account use, machine-account anomalies, administrative logon types, rare user-to-host pairs, multiple destination hosts, unmanaged source status, VPN ingress source, and downstream identity-plane changes.

·        Treat authentication expansion as a confidence amplifier until correlated with upstream suspicious domain-controller activity and downstream identity-plane or endpoint evidence.

·        Use approved administrator records, identity-management records, backup schedules, vulnerability management records, domain-controller maintenance records, security-testing records, incident-response records, and change-management context as triage evidence.

·        Validate false-positive rates against normal administrative work, helpdesk operations, identity-management workflows, service-account behavior, backup activity, patching, vulnerability scanning, security testing, and incident response.

·        Do not enable alert mode until authentication field mapping, account enrichment, baseline thresholds, correlation reliability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to authentication expansion after suspicious domain-controller interaction rather than static CVE identifiers, exploit strings, packet signatures, filenames, hashes, or known malicious infrastructure.

·        The rule remains useful if an adversary changes tooling, source host, timing, authentication sequence, account choice, target order, or post-access behavior.

·        The score is supported by the durability of privileged authentication, abnormal machine-account authentication, rare user-to-host access, multi-host authentication expansion, and correlation with domain-controller service access.

·        The score is constrained by legitimate administrator activity, service-account behavior, identity-management workflows, backup operations, inconsistent authentication baselines, and incomplete field mapping.

·        The rule is durable as authentication-expansion coverage but should not be treated as standalone proof of successful exploitation, credential theft, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable Windows Security ingestion, authentication telemetry, account enrichment, domain-controller inventory, source-role enrichment, baseline data, and Elastic correlation quality.

·        Operational confidence is reduced where privileged account inventories are stale, service-account baselines are weak, machine-account behavior is not well understood, or administrative activity commonly crosses many internal systems.

·        Operational confidence is reduced where logon type, authentication package, account name, source host, destination host, or service-ticket fields are missing or inconsistently normalized.

·        Full-telemetry confidence improves when authentication expansion is enriched with network telemetry, Directory Services events, Elastic Defend telemetry, VPN context, change-management records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support identity-plane triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects suspicious authentication expansion after domain-controller interaction, not confirmed exploitation by itself.

·        Elastic cannot determine credential theft, ticket misuse, or domain compromise from authentication logs alone without supporting telemetry.

·        Legitimate administrator, helpdesk, identity-management, backup, vulnerability management, patching, monitoring, and incident-response workflows can produce similar authentication patterns.

·        Missing account enrichment, weak baselines, incomplete authentication fields, or inconsistent normalization can reduce confidence.

·        The rule may miss activity that uses expected accounts, expected administrative paths, or low-and-slow authentication behavior within normal baselines.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use an Elastic implementation pattern that first collects suspicious source-to-domain-controller service activity, then collects authentication expansion involving privileged accounts, machine accounts, service accounts, administrative logon types, or abnormal multi-host authentication behavior, then correlates those sets using locally validated keys and timing windows. This is not universal plug-and-play EQL, KQL, or ES|QL; exact syntax must be generated after index, data-stream, ECS, enrichment, and field validation.

network_event where
(
destination.domain in DOMAIN_CONTROLLER_ASSETS
or destination.ip in DOMAIN_CONTROLLER_ASSETS
)
and
(
network.protocol in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or network.application in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or event.dataset in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_DATASETS
or rule.name in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_CLASSIFIERS
)
and not source.ip in APPROVED_DOMAIN_CONTROLLER_SOURCES
and
(
source.asset.role in ("unmanaged_system", "workstation", "vpn_connected_host", "branch_system", "non_administrative_server")
or source.ip in VPN_ADDRESS_POOLS
or source.ip in BRANCH_NETWORKS
or source.ip in WORKSTATION_SUBNETS
or event.risk_score >= ENV_DC_SERVICE_ACCESS_THRESHOLD
)

authentication_event where
event.code in ("4624", "4625", "4648", "4672", "4768", "4769", "4771", "4776")
and
(
user.name in PRIVILEGED_ACCOUNTS
or user.name in MACHINE_ACCOUNTS
or user.name in SERVICE_ACCOUNTS
or winlog.event_data.LogonType in ("3", "9", "10")
or event.action in ("kerberos_service_ticket_activity", "ntlm_authentication", "explicit_credential_use", "privileged_logon")
or event.risk_score >= ENV_AUTH_EXPANSION_THRESHOLD
)
and not labels.change_context in ("approved_administrator_activity", "approved_identity_management_workflow", "approved_backup_activity", "approved_vulnerability_management", "approved_domain_controller_maintenance", "approved_security_testing", "approved_incident_response")

correlate network_event and authentication_event where
(
network_event.source.ip == authentication_event.source.ip
or network_event.source.ip == authentication_event.related.ip
or network_event.source.host.name == authentication_event.host.name
or network_event.source.host.name == authentication_event.winlog.event_data.WorkstationName
or network_event.user.name == authentication_event.user.name
or network_event.machine.account == authentication_event.user.name
or network_event.correlation.session_id == authentication_event.correlation.session_id
)
and authentication_event.timestamp between network_event.timestamp and network_event.timestamp + ENV_AUTH_FOLLOWON_WINDOW

derive authentication_expansion from authentication_event where
privileged account activity maps to "privileged_account_activity"
machine account activity maps to "machine_account_activity"
service account activity maps to "service_account_activity"
multi-host or rare user-to-host behavior maps to "multi_host_authentication_expansion"
remaining matched authentication behavior maps to "authentication_activity"

assign severity where
"high" requires privileged account activity with abnormal expansion or repeated domain-controller service access
"medium" requires machine-account activity, service-account activity, explicit credential use, administrative logon type, or privileged logon without confirmed expansion
"low" applies to remaining correlated authentication activity pending analyst validation

Rule

Domain-Controller Service Anomaly Correlated With Endpoint Execution and Lateral Movement

Rule Format

Elastic implementation pattern suitable for EQL, KQL, ES|QL, or detection-rule chaining after local validation of network telemetry, Elastic Defend telemetry, Windows Security telemetry, DNS or proxy telemetry, high-value asset enrichment, source-host normalization, process fields, destination fields, timing windows, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious domain-controller service activity followed by endpoint execution, lateral movement, administrative protocol use, high-value asset access, outbound communication, or security-control disruption.

·        Identify cases where suspicious Netlogon-adjacent or domain-controller service interaction becomes higher risk because it is followed by observable post-interaction activity across endpoint and network telemetry.

·        Prioritize activity involving source hosts or domain controllers that later access identity infrastructure, jump hosts, management servers, backup systems, endpoint-management platforms, file servers, source-code systems, CI/CD systems, databases, or sensitive business applications.

·        Support escalation when endpoint execution, lateral movement, or outbound communication aligns with privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or directory-service changes.

·        Preserve separation between suspicious post-interaction behavior and confirmed compromise by requiring endpoint, identity, network, file, persistence, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, command-and-control, exfiltration, credential theft, downstream compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious domain-controller service activity involving Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or locally classified domain-controller service traffic from a non-standard source.

·        Correlate the same source host, account, affected domain controller, or investigation timeline with endpoint execution involving PowerShell, command shell, WMI, WinRM, service creation, scheduled task creation, credential-access behavior, tool staging, persistence, or suspicious process execution.

·        Correlate the same source host, account, affected domain controller, or investigation timeline with lateral movement involving SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database access, management-plane access, or administrative protocols.

·        Correlate the same source host, account, affected domain controller, or investigation timeline with outbound communication involving rare destinations, newly observed domains, low-reputation destinations, tunnel-like traffic, abnormal byte volume, unexpected SMB egress, or destinations outside normal baselines.

·        Use locally validated correlation keys rather than assuming all follow-on activity shares the original network source IP.

·        Increase confidence when post-interaction behavior follows privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or directory-service object changes.

·        Increase confidence when activity targets high-value assets, identity infrastructure, domain controllers, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, or sensitive business systems.

·        Reduce severity when behavior aligns with approved administrator workflows, backup schedules, monitoring activity, patching, software deployment, vulnerability management, identity-management workflows, security testing, incident response, or documented change-control activity.

·        Do not attribute endpoint execution, lateral movement, or outbound communication to Netlogon exploitation without suspicious upstream domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat lateral movement, administrative protocol use, outbound communication, or Elastic Defend activity as compromise evidence by itself.

·        Do not use this rule for actor attribution without incident-specific intelligence and validated behavioral correlation.

Required Telemetry

·        Elastic Security event indices.

·        Elastic Defend telemetry.

·        Network-flow telemetry.

·        Windows Security event ingestion.

·        Directory Services event ingestion.

·        DNS telemetry where available.

·        Proxy telemetry where available.

·        Firewall telemetry where available.

·        Authentication telemetry.

·        Change-management data or lookup enrichment.

·        Domain-controller asset inventory.

·        High-value asset inventory.

·        Identity infrastructure inventory.

·        Jump-host inventory.

·        Management-server inventory.

·        Backup-system inventory.

·        Endpoint-management platform inventory.

·        Source-code and CI/CD inventory where available.

·        Sensitive business application inventory.

·        Approved administrative source inventory.

·        Approved workflow enrichment.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Account name.

·        Process name.

·        Process command line.

·        Parent process.

·        Destination port.

·        Network protocol.

·        Network application or service.

·        DNS query where available.

·        External destination context where available.

·        Event code.

·        Event action.

·        Event timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build suspicious domain-controller interaction searches using network-flow telemetry, domain-controller inventory, approved source inventory, protocol filters, and source-role enrichment.

·        Build endpoint execution searches for PowerShell, command shell, WMI, WinRM, service creation, scheduled task creation, script execution, credential-access behavior, tool staging, suspicious process execution, and security-control disruption.

·        Build lateral-movement searches for SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database clients, management-plane access, and administrative protocols.

·        Build outbound-risk searches for newly observed external destinations, rare domains, unusual ASNs, low-reputation destinations, tunnel-like traffic, abnormal DNS behavior, abnormal byte volume, unexpected SMB egress, and destinations inconsistent with source or domain-controller baselines.

·        Build high-value asset groups covering identity infrastructure, domain controllers, jump hosts, privileged management systems, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, databases, file servers, and sensitive business applications.

·        Build identity-plane follow-on groups for privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, and administrative-control activity.

·        Validate Elastic index names, data streams, ECS mappings, endpoint fields, network fields, authentication fields, enrichment keys, timestamp normalization, process fields, and correlation fields before deployment.

·        Validate whether source host, destination host, process name, command line, account name, source IP, destination IP, event code, action, protocol, external destination, and timestamp are reliably mapped.

·        Use short correlation windows for immediate endpoint execution, lateral movement, or outbound communication after suspicious domain-controller service activity.

·        Use moderate correlation windows for delayed post-interaction activity, repeated internal access, credential access, persistence, or security-control disruption.

·        Use longer correlation windows only when incident-response evidence, endpoint continuity, identity evidence, or repeated access patterns support delayed linkage.

·        Add severity weighting for suspicious upstream domain-controller interaction, high-value asset access, privileged account involvement, suspicious process execution, credential-access behavior, security-control disruption, identity-plane changes, and outbound-risk context.

·        Treat endpoint execution, lateral movement, and outbound communication as confidence amplifiers, not standalone proof of Netlogon exploitation.

·        Use approved administrator records, monitoring records, backup records, patching records, software deployment records, vulnerability management records, identity-management records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate false-positive rates against administrative workflows, endpoint-management activity, backup activity, monitoring activity, software deployment, patching, vulnerability management, identity-management work, security testing, and incident response.

·        Do not enable alert mode until index availability, ECS mapping, endpoint-to-network joins, asset enrichment accuracy, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious domain-controller interaction followed by endpoint execution, lateral movement, or outbound behavior rather than static CVE identifiers, exploit strings, file hashes, packet signatures, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, process choice, lateral-movement method, outbound destination, timing, or post-exploitation sequence.

·        The score is supported by the durability of post-interaction endpoint behavior, high-value asset access, lateral movement, credential-access behavior, security-control disruption, and outbound communication.

·        The score is constrained by legitimate administrator activity, endpoint-management workflows, backup traffic, software deployment, vulnerability management, incomplete Elastic Defend telemetry, and weak asset inventory.

·        The rule is durable as multi-source post-interaction coverage but should not be treated as standalone proof of successful exploitation, compromise, command-and-control, exfiltration, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable Elastic ingestion for network telemetry, Elastic Defend telemetry, Windows Security logs, Directory Services events, DNS logs, proxy logs, firewall logs, high-value asset inventory, and source-role enrichment.

·        Operational confidence is reduced where endpoint telemetry is incomplete, DNS or proxy logs are missing, high-value asset inventories are weak, process fields are inconsistent, or source-host joins are unreliable.

·        Operational confidence is reduced where administrators, backup systems, monitoring systems, software deployment systems, vulnerability management platforms, identity-management systems, or incident responders commonly perform similar post-interaction activity.

·        Full-telemetry confidence improves when Elastic correlates network telemetry, Elastic Defend telemetry, authentication logs, Directory Services events, DNS logs, proxy logs, firewall logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation, compromise, or actor attribution.

Limitations

·        This rule detects post-interaction endpoint and network behavior, not confirmed exploitation by itself.

·        Elastic cannot determine intent or compromise state unless endpoint, identity, network, directory-service, and incident-response evidence support the correlation.

·        Legitimate administrator, backup, monitoring, patching, software deployment, vulnerability management, identity-management, security testing, and incident-response workflows can produce similar behavior.

·        Missing Elastic Defend data, incomplete DNS or proxy logs, weak ECS field mapping, stale asset inventories, or poor source-host joins can reduce confidence.

·        The rule may miss activity that uses expected administrative paths, communicates with approved destinations, avoids endpoint artifacts, or occurs outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use an Elastic implementation pattern that first collects suspicious source-to-domain-controller service activity, then collects endpoint execution, lateral movement, outbound communication, or high-value asset access activity, then correlates those sets using locally validated keys and timing windows. This is not universal plug-and-play EQL, KQL, or ES|QL; exact syntax must be generated after index, data-stream, ECS, enrichment, and field validation.

network_event where
(
destination.domain in DOMAIN_CONTROLLER_ASSETS
or destination.ip in DOMAIN_CONTROLLER_ASSETS
)
and
(
network.protocol in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or network.application in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or event.dataset in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_DATASETS
or rule.name in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_CLASSIFIERS
)
and not source.ip in APPROVED_DOMAIN_CONTROLLER_SOURCES
and
(
source.asset.role in ("unmanaged_system", "workstation", "vpn_connected_host", "branch_system", "non_administrative_server")
or source.ip in VPN_ADDRESS_POOLS
or source.ip in BRANCH_NETWORKS
or source.ip in WORKSTATION_SUBNETS
or event.risk_score >= ENV_DC_SERVICE_ACCESS_THRESHOLD
)

followon_event where
(
process.name in ("powershell.exe", "pwsh.exe", "cmd.exe", "wmic.exe", "winrm.vbs", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "psexec.exe", "procdump.exe", "rclone.exe")
or process.command_line matches LOCALLY_VALIDATED_ENDPOINT_EXECUTION_PATTERN
or network.application in ("smb_admin_share", "rdp", "wmi", "winrm", "remote_service", "ssh", "ldap", "kerberos", "database", "management_plane", "admin_protocol")
or destination.risk.context in ("newly_observed_external_destination", "rare_external_destination", "low_reputation_destination", "tunnel_like_protocol", "abnormal_byte_volume", "destination_not_in_source_baseline")
or destination.ip in HIGH_VALUE_ASSETS
or destination.domain in HIGH_VALUE_ASSETS
)
and not labels.change_context in ("approved_administrator_activity", "approved_monitoring_activity", "approved_backup_activity", "approved_identity_management_workflow", "approved_vulnerability_management", "approved_patching_activity", "approved_software_deployment", "approved_security_testing", "approved_incident_response")

correlate network_event and followon_event where
(
network_event.source.ip == followon_event.source.ip
or network_event.source.ip == followon_event.related.ip
or network_event.source.host.name == followon_event.host.name
or network_event.user.name == followon_event.user.name
or network_event.machine.account == followon_event.user.name
or network_event.correlation.session_id == followon_event.correlation.session_id
or network_event.correlation.investigation_id == followon_event.correlation.investigation_id
)
and followon_event.timestamp between network_event.timestamp and network_event.timestamp + ENV_POST_DC_INTERACTION_WINDOW

derive followon_pattern from followon_event where
process execution or suspicious command-line activity maps to "endpoint_execution_or_credential_access"
administrative protocol or lateral-movement service activity maps to "lateral_movement_or_outbound_activity"
external destination anomaly maps to "lateral_movement_or_outbound_activity"
high-value asset access maps to "high_value_asset_access"
remaining matched follow-on behavior maps to "post_interaction_activity"

assign severity where
"high" requires endpoint execution from unmanaged, workstation, or VPN-connected source context, or high-value asset access with suspicious upstream domain-controller interaction
"medium" requires correlated endpoint execution, lateral movement, outbound communication, or high-value asset access without confirmed high-risk expansion
"low" applies to remaining correlated post-interaction activity pending analyst validation

QRadar

Detection Viability Assessment

QRadar has three rules for this EXP report.

·        QRadar is viable for detecting Windows Netlogon remote code execution and domain-controller compromise exposure where Windows Security logs, Directory Services events, authentication logs, network-flow telemetry, endpoint telemetry, VPN context, asset context, identity enrichment, and change-management records are available.

·        QRadar is strongest when offense rules can correlate domain-controller service activity, suspicious source behavior, identity-plane changes, authentication expansion, endpoint execution, lateral movement, and high-value asset access through normalized event fields, flow properties, reference sets, custom properties, and building blocks.

·        QRadar can identify suspicious sequencing between non-standard source-to-domain-controller service access, Netlogon-adjacent traffic, machine-account changes, domain trust changes, privileged group changes, abnormal authentication behavior, endpoint execution, and downstream lateral movement.

·        QRadar is not a standalone source for confirming successful Netlogon exploitation, domain-controller compromise, Active Directory takeover, credential theft, replication abuse, or actor attribution unless network, Windows, Directory Services, endpoint, identity, and incident-response evidence are correlated.

·        QRadar rules should not generate high-confidence alerting from patch state alone, vulnerability scan output alone, isolated Netlogon errors alone, isolated RPC or SMB flows alone, single authentication anomalies alone, or administrative activity that aligns with approved change records.

·        QRadar detections must separate exposure, attempted exploitation, suspected domain-controller trust manipulation, post-exploitation behavior, and confirmed identity-plane compromise.

·        QRadar detection content should be treated as SIEM correlation and offense-generation coverage after log-source validation, DSM parsing validation, custom-property validation, reference-set validation, tuning, false-positive testing, and SOC workflow validation.

Rule

Suspicious Source-to-Domain-Controller Netlogon / RPC Activity With Identity-Plane Change

Rule Format

QRadar rule and AQL-style implementation pattern suitable for Windows Security events, Directory Services events, network-flow telemetry, endpoint telemetry, authentication telemetry, domain-controller reference sets, approved-source reference sets, identity enrichment, custom event properties, custom flow properties, change-management context, and offense correlation after log-source validation, DSM validation, custom-property validation, reference-set validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB domain-controller service, or locally classified domain-controller service activity from a non-standard source to a domain controller.

·        Correlate suspicious source-to-domain-controller activity with identity-plane changes involving machine accounts, domain-controller accounts, domain trusts, privileged groups, replication-related permissions, security policy, or sensitive Active Directory objects.

·        Prioritize activity involving unmanaged systems, workstation networks, VPN ingress sources, branch networks, newly observed internal systems, or systems outside approved administrative paths.

·        Support escalation when domain-controller service activity is followed by identity-plane changes, authentication anomalies, endpoint behavior, or administrative-control disruption.

·        Preserve separation between suspicious correlation and confirmed compromise by requiring corroborating Windows, Directory Services, endpoint, network, change-management, or incident-response evidence before classifying the activity as confirmed domain-controller compromise.

·        This rule does not prove successful Netlogon exploitation, Active Directory takeover, credential theft, replication abuse, or actor attribution without supporting evidence across multiple telemetry classes.

Detection Logic

·        Identify source-to-domain-controller flow or event activity involving Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, or locally classified domain-controller service traffic.

·        Require explicit domain-controller destination matching using validated hostnames, fully qualified domain names, IP addresses, Active Directory sites, reference sets, or custom properties.

·        Exclude approved domain controllers, replication partners, identity-management systems, monitoring systems, backup systems, vulnerability management systems, administrative jump hosts, privileged access workstations, and maintenance systems.

·        Prioritize suspicious sources from unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed internal systems, or systems outside the domain-controller access baseline.

·        Correlate suspicious source-to-domain-controller service activity with Windows Security or Directory Services events involving machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, security policy changes, or sensitive directory-service object changes.

·        Use locally validated correlation keys rather than assuming all identity-plane events share the original source IP. Acceptable keys may include domain-controller host, source IP, source host, user name, machine account, object distinguished name, related IP, offense context, or custom correlation identifier.

·        Increase confidence when identity-plane changes occur shortly after suspicious domain-controller service access.

·        Increase confidence when the same source, account, machine account, domain controller, or offense context is associated with privileged logons, abnormal machine-account authentication, directory-service object changes, endpoint credential-access behavior, remote administration tooling, or lateral movement.

·        Reduce severity when activity aligns with approved domain join, trust repair, replication maintenance, domain-controller maintenance, identity-management workflows, vulnerability management, backup activity, security testing, incident response, or documented change-control activity.

·        Do not treat vulnerable-state findings, scanner output, isolated Netlogon errors, single RPC sessions, or single SMB sessions as exploitation evidence by themselves.

·        Do not classify machine-account changes, trust changes, or privileged group changes as malicious when they align with approved identity-infrastructure workflows and known administrative systems.

·        Do not classify the activity as confirmed compromise without corroborating authentication, directory-service, endpoint, network, administrative-control, or incident-response evidence.

Required Telemetry

·        QRadar Windows Security log source.

·        QRadar Directory Services log source.

·        QRadar domain-controller System log source where available.

·        QRadar flow telemetry.

·        Endpoint telemetry where available.

·        Authentication telemetry.

·        VPN or remote-access telemetry where available.

·        Change-management data or reference set.

·        Domain-controller reference set.

·        Approved administrative source reference set.

·        Replication partner reference set.

·        Identity-management system reference set.

·        Monitoring-system reference set.

·        Backup-system reference set.

·        Vulnerability management system reference set.

·        VPN address pool reference set.

·        Branch network reference set.

·        Workstation subnet reference set.

·        Privileged group reference set.

·        Sensitive Active Directory object reference set.

·        Custom event properties for account, machine account, object distinguished name, event ID, and change type.

·        Custom flow properties for network application, destination service, destination role, and source role.

·        Source host.

·        Destination domain controller.

·        Source IP.

·        Destination IP.

·        Destination port.

·        Protocol or service.

·        Account name.

·        Machine account.

·        Object distinguished name.

·        Event ID.

·        Event action.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build QRadar reference sets for domain controllers, approved domain-controller sources, replication partners, identity-management platforms, monitoring systems, backup systems, vulnerability management systems, administrative jump hosts, privileged access workstations, and maintenance systems.

·        Build source-risk reference sets for unmanaged systems, workstation networks, VPN ingress ranges, branch networks, newly observed systems, and systems outside the domain-controller access baseline.

·        Build locally validated service mappings for Netlogon-adjacent traffic, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, and locally classified domain-controller service traffic. Do not assume these values appear consistently in a single QRadar field; validate flow application, destination port, QID, event name, log-source type, custom properties, and network application classification.

·        Build identity-plane change filters for machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, delegation changes, Group Policy changes, security policy changes, and sensitive directory-service object changes.

·        Validate QRadar log sources, DSM parsing, QIDs, normalized fields, custom event properties, custom flow properties, reference-set membership, timestamp normalization, and correlation keys before deployment.

·        Validate whether source host, destination domain controller, source IP, destination IP, account name, machine account, object distinguished name, event ID, action, timestamp, source role, and change-window context are reliably mapped.

·        Use QRadar building blocks for suspicious source role, domain-controller destination, approved-source suppression, identity-plane event class, privileged-account context, and change-management suppression.

·        Use short correlation windows for suspicious domain-controller service access followed by immediate authentication anomalies.

·        Use moderate correlation windows for machine-account changes, trust changes, privileged group changes, replication-permission changes, and directory-service object changes.

·        Use longer correlation windows only when incident-response evidence, repeated source behavior, or identity-plane evidence supports delayed linkage.

·        Add severity weighting for non-standard source role, repeated domain-controller service access, machine-account change, trust change, privileged group change, replication-permission change, unmanaged source status, VPN ingress source, and change-management mismatch.

·        Treat network activity, authentication anomalies, and object changes as confidence amplifiers until correlated across the activity chain.

·        Use change-management records, domain join records, trust repair records, replication maintenance records, backup records, vulnerability management records, security-testing records, and incident-response records as triage evidence.

·        Validate false-positive rates against at least one representative business cycle that includes domain-controller maintenance, patching, domain joins, trust repair, backup operations, vulnerability scanning, and identity-management activity.

·        Do not enable alert mode until log-source availability, DSM parsing, custom-property mapping, reference-set accuracy, correlation reliability, false-positive rate, query performance, offense workflow, and exception handling are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious domain-controller service access followed by identity-plane change rather than static CVE identifiers, exploit strings, filenames, hashes, packet signatures, or public proof-of-concept artifacts.

·        The rule remains useful if an adversary changes exploit tooling, source host, access timing, command syntax, protocol pacing, or post-exploitation sequence.

·        The score is supported by the durability of Netlogon-adjacent source-path deviation, domain-controller targeting, machine-account change, trust change, privileged group change, replication-permission change, and directory-service object-change correlation.

·        The score is constrained by incomplete Windows event coverage, inconsistent Directory Services auditing, weak reference-set quality, missing flow telemetry, DSM parsing gaps, and legitimate administrative identity operations.

·        The rule is durable as QRadar correlation coverage but should not be treated as standalone proof of successful Netlogon exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on reliable QRadar ingestion for Windows Security logs, Directory Services events, flow telemetry, authentication logs, domain-controller inventory, source-role enrichment, and change-management context.

·        Operational confidence is reduced where Windows event mappings are inconsistent, Active Directory auditing is incomplete, source-role enrichment is weak, domain-controller inventory is stale, DSM parsing is incomplete, or change-management records are unavailable.

·        Operational confidence is reduced where identity-management systems, replication workflows, backup systems, vulnerability management platforms, and administrative systems commonly generate similar domain-controller or object-change activity.

·        Full-telemetry confidence improves when QRadar correlates flow telemetry, Windows Security logs, Directory Services events, endpoint telemetry, authentication logs, VPN telemetry, asset inventory, privileged-access records, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects suspicious correlation between domain-controller service access and identity-plane change, not confirmed exploitation by itself.

·        QRadar cannot infer Netlogon exploitation unless the necessary network, Windows, Active Directory, endpoint, and identity context is present and correctly correlated.

·        Legitimate domain join, trust repair, replication maintenance, backup, identity-management, vulnerability management, security testing, and incident-response workflows can produce similar signals.

·        Missing Directory Services auditing, weak DSM parsing, incomplete flow telemetry, stale reference sets, or missing change records can reduce confidence.

·        The rule may miss activity that uses approved administrative sources, avoids observable identity-plane changes, or occurs outside the configured correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use a QRadar implementation pattern that first collects suspicious source-to-domain-controller service activity, then collects identity-plane change activity, then correlates those sets using locally validated keys and timing windows. This is not universal plug-and-play AQL; exact QRadar rule logic, AQL syntax, custom properties, reference sets, and building blocks must be generated after local log-source, DSM, and field validation.

domain_controller_service_activity where
(
destinationip in DOMAIN_CONTROLLER_REFERENCE_SET
or destinationhostname in DOMAIN_CONTROLLER_REFERENCE_SET
or destinationfqdn in DOMAIN_CONTROLLER_REFERENCE_SET
)
and
(
application in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or qidname in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_QIDS
or destinationport in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_PORTS
or customproperty_domain_controller_service in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
)
and sourceip not in APPROVED_DOMAIN_CONTROLLER_SOURCE_REFERENCE_SET
and
(
sourceip in UNMANAGED_SOURCE_REFERENCE_SET
or sourceip in VPN_ADDRESS_POOL_REFERENCE_SET
or sourceip in BRANCH_NETWORK_REFERENCE_SET
or sourceip in WORKSTATION_SUBNET_REFERENCE_SET
or source_role in ("unmanaged_system", "workstation", "vpn_connected_host", "branch_system", "non_administrative_server")
or eventcount >= ENV_DC_SERVICE_ACCESS_THRESHOLD
)

identity_plane_change where
eventid in ("4724", "4738", "4742", "4728", "4732", "4756", "4719", "4739", "5136", "5137", "5139", "5141")
and
(
hostname in DOMAIN_CONTROLLER_REFERENCE_SET
or sourceip in DOMAIN_CONTROLLER_REFERENCE_SET
or customproperty_domain_controller in DOMAIN_CONTROLLER_REFERENCE_SET
or customproperty_related_host in DOMAIN_CONTROLLER_REFERENCE_SET
)
and change_context not in ("approved_domain_join", "approved_trust_repair", "approved_replication_maintenance", "approved_domain_controller_maintenance", "approved_identity_management_workflow", "approved_backup_activity", "approved_vulnerability_management", "approved_security_testing", "approved_incident_response")

correlate domain_controller_service_activity and identity_plane_change where
(
domain_controller_service_activity.destinationip == identity_plane_change.sourceip
or domain_controller_service_activity.destinationhostname == identity_plane_change.hostname
or domain_controller_service_activity.destinationfqdn == identity_plane_change.hostname
or domain_controller_service_activity.customproperty_domain_controller == identity_plane_change.customproperty_domain_controller
or domain_controller_service_activity.sourceip == identity_plane_change.customproperty_related_ip
or domain_controller_service_activity.username == identity_plane_change.username
or domain_controller_service_activity.machine_account == identity_plane_change.machine_account
or domain_controller_service_activity.offense_id == identity_plane_change.offense_id
)
and identity_plane_change.starttime between domain_controller_service_activity.starttime and domain_controller_service_activity.starttime + ENV_IDENTITY_FOLLOWON_WINDOW

derive identity_event_pattern from eventid where
"4742" maps to "machine_account_change"
"4728", "4732", and "4756" map to "privileged_group_change"
"5136", "5137", "5139", and "5141" map to "directory_service_object_change"
"4719" and "4739" map to "security_policy_or_domain_policy_change"
all remaining matched identity-plane events map to "identity_plane_change"

assign severity where
"high" requires identity_event_pattern in ("machine_account_change", "privileged_group_change", "directory_service_object_change") and repeated or high-risk domain-controller service access
"medium" requires identity_event_pattern in ("machine_account_change", "privileged_group_change", "directory_service_object_change") without confirmed high-risk repetition
"low" applies to remaining correlated identity-plane changes pending analyst validation

Rule

Abnormal Domain-Controller Authentication Expansion After Suspicious Netlogon-Adjacent Activity

Rule Format

QRadar rule and AQL-style implementation pattern suitable for Windows Security events, authentication telemetry, network-flow telemetry, endpoint telemetry, domain-controller reference sets, privileged-account reference sets, machine-account reference sets, service-account reference sets, approved-source reference sets, source-role enrichment, VPN enrichment, custom properties, building blocks, and offense correlation after log-source validation, DSM validation, custom-property validation, reference-set validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious authentication expansion involving domain controllers after Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or suspicious source-to-domain-controller access activity.

·        Identify cases where a non-standard source interacts with a domain controller and is followed by privileged authentication, machine-account authentication anomalies, abnormal service-ticket behavior, administrative logons, or authentication expansion across internal systems.

·        Prioritize activity involving privileged accounts, domain-controller accounts, machine accounts, service accounts, low-frequency accounts, newly observed accounts, or accounts accessing systems outside their normal baseline.

·        Support escalation when authentication expansion follows suspicious domain-controller interaction and aligns with directory-service changes, endpoint behavior, lateral movement, or security-control disruption.

·        Preserve separation between suspicious authentication expansion and confirmed compromise by requiring corroborating network, Windows, endpoint, directory-service, change-management, or incident-response evidence.

·        This rule does not prove Netlogon exploitation, credential theft, domain compromise, lateral movement, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious source-to-domain-controller service access from non-standard sources.

·        Correlate suspicious domain-controller service access with subsequent authentication events involving privileged accounts, machine accounts, domain-controller accounts, service accounts, or accounts with unusual authentication expansion.

·        Detect authentication activity involving multiple internal destinations, rare user-to-host pairs, privileged logons to domain controllers, administrative logon types, abnormal machine-account authentication, Kerberos or NTLM anomalies, or service-ticket behavior inconsistent with the account baseline.

·        Use locally validated source and identity correlation keys rather than assuming all authentication events share the original network source IP.

·        Increase confidence when authentication expansion occurs shortly after repeated domain-controller service access or a new source-to-domain-controller path.

·        Increase confidence when authentication expansion is followed by directory-service object changes, privileged group changes, machine-account changes, domain trust changes, replication-permission changes, or endpoint-observed suspicious behavior.

·        Increase confidence when the source is unmanaged, VPN-connected, workstation-class, branch-based, newly observed, or outside approved administrative pathways.

·        Reduce severity when activity aligns with approved administration, identity-management workflows, domain-controller maintenance, vulnerability management, backup operations, security testing, incident response, or documented change-control activity.

·        Do not classify authentication expansion as Netlogon-linked compromise without suspicious upstream domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat a single privileged logon, Kerberos event, NTLM event, or service-ticket event as compromise evidence by itself.

·        Do not treat authentication anomalies as domain-controller compromise when the activity aligns with approved administrative workflows and known source systems.

Required Telemetry

·        QRadar Windows Security log source.

·        QRadar authentication log source.

·        QRadar flow telemetry.

·        Endpoint telemetry where available.

·        Directory Services event ingestion.

·        VPN or remote-access telemetry where available.

·        Change-management data or reference set.

·        Domain-controller reference set.

·        Privileged account reference set.

·        Machine-account reference set.

·        Service-account reference set.

·        Low-frequency account baseline where available.

·        Approved administrative source reference set.

·        Source-role enrichment.

·        User baseline enrichment.

·        Host baseline enrichment.

·        Custom event properties for source host, account, logon type, authentication package, event ID, and event outcome.

·        Custom flow properties for source role, destination role, network application, and destination service.

·        Source host.

·        Destination host.

·        Source IP.

·        Account name.

·        Account domain.

·        Logon type.

·        Authentication package.

·        Ticket or service name where available.

·        Event ID.

·        Event action.

·        Event outcome.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build suspicious domain-controller interaction searches using QRadar flow telemetry, domain-controller reference sets, approved source reference sets, and source-role enrichment.

·        Build privileged account reference sets for Domain Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Backup Operators, domain-controller administrators, identity administrators, and locally defined high-risk groups.

·        Build machine-account and service-account reference sets using naming conventions, directory inventory, and identity-management records.

·        Build authentication expansion logic for rare user-to-host pairs, multiple destination hosts, privileged logons to domain controllers, administrative logon types, abnormal machine-account authentication, Kerberos anomalies, NTLM anomalies, and service-ticket anomalies.

·        Build source-risk reference sets for unmanaged systems, VPN ingress ranges, workstation networks, branch networks, newly observed systems, and sources outside approved administrative paths.

·        Build follow-on correlation for domain-controller account changes, machine-account changes, privileged group changes, domain trust changes, replication-permission changes, directory-service object changes, lateral movement, endpoint credential-access behavior, and security-control disruption.

·        Validate QRadar log sources, DSM parsing, QIDs, normalized fields, custom event properties, custom flow properties, reference-set membership, timestamp handling, and correlation fields before deployment.

·        Validate whether source host, source IP, destination host, account name, authentication package, logon type, event ID, event outcome, timestamp, source role, and account risk are reliably mapped.

·        Use QRadar building blocks for privileged account use, machine-account activity, service-account activity, administrative logon type, authentication expansion, approved-source suppression, and change-management suppression.

·        Use short correlation windows for suspicious domain-controller service access followed by immediate privileged authentication.

·        Use moderate correlation windows for authentication expansion across multiple systems, delayed service-ticket activity, directory-service changes, or endpoint activity.

·        Use longer correlation windows only when incident-response evidence, repeated source activity, or identity-plane evidence supports delayed linkage.

·        Add severity weighting for privileged account use, machine-account anomalies, administrative logon types, rare user-to-host pairs, multiple destination hosts, unmanaged source status, VPN ingress source, and downstream identity-plane changes.

·        Treat authentication expansion as a confidence amplifier until correlated with upstream suspicious domain-controller activity and downstream identity-plane or endpoint evidence.

·        Use approved administrator records, identity-management records, backup schedules, vulnerability management records, domain-controller maintenance records, security-testing records, incident-response records, and change-management context as triage evidence.

·        Validate false-positive rates against normal administrative work, helpdesk operations, identity-management workflows, service-account behavior, backup activity, patching, vulnerability scanning, security testing, and incident response.

·        Do not enable alert mode until authentication custom-property mapping, account enrichment, baseline thresholds, correlation reliability, false-positive rate, query performance, offense workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to authentication expansion after suspicious domain-controller interaction rather than static CVE identifiers, exploit strings, packet signatures, filenames, hashes, or known malicious infrastructure.

·        The rule remains useful if an adversary changes tooling, source host, timing, authentication sequence, account choice, target order, or post-access behavior.

·        The score is supported by the durability of privileged authentication, abnormal machine-account authentication, rare user-to-host access, multi-host authentication expansion, and correlation with domain-controller service access.

·        The score is constrained by legitimate administrator activity, service-account behavior, identity-management workflows, backup operations, inconsistent authentication baselines, incomplete custom-property mapping, and DSM parsing gaps.

·        The rule is durable as authentication-expansion coverage but should not be treated as standalone proof of successful exploitation, credential theft, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable Windows Security ingestion, authentication telemetry, account enrichment, domain-controller inventory, source-role enrichment, baseline data, and QRadar correlation quality.

·        Operational confidence is reduced where privileged account inventories are stale, service-account baselines are weak, machine-account behavior is not well understood, administrative activity commonly crosses many internal systems, or authentication custom properties are incomplete.

·        Operational confidence is reduced where logon type, authentication package, account name, source host, destination host, or service-ticket fields are missing or inconsistently parsed.

·        Full-telemetry confidence improves when authentication expansion is enriched with flow telemetry, Directory Services events, endpoint telemetry, VPN context, change-management records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support identity-plane triage and escalation rather than standalone confirmation of exploit success or actor attribution.

Limitations

·        This rule detects suspicious authentication expansion after domain-controller interaction, not confirmed exploitation by itself.

·        QRadar cannot determine credential theft, ticket misuse, or domain compromise from authentication logs alone without supporting telemetry.

·        Legitimate administrator, helpdesk, identity-management, backup, vulnerability management, patching, monitoring, and incident-response workflows can produce similar authentication patterns.

·        Missing account enrichment, weak baselines, incomplete authentication fields, inconsistent DSM parsing, or missing custom properties can reduce confidence.

·        The rule may miss activity that uses expected accounts, expected administrative paths, or low-and-slow authentication behavior within normal baselines.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use a QRadar implementation pattern that first collects suspicious source-to-domain-controller service activity, then collects authentication expansion involving privileged accounts, machine accounts, service accounts, administrative logon types, or abnormal multi-host authentication behavior, then correlates those sets using locally validated keys and timing windows. This is not universal plug-and-play AQL; exact QRadar rule logic, AQL syntax, custom properties, reference sets, and building blocks must be generated after local log-source, DSM, and field validation.

domain_controller_service_activity where
(
destinationip in DOMAIN_CONTROLLER_REFERENCE_SET
or destinationhostname in DOMAIN_CONTROLLER_REFERENCE_SET
or destinationfqdn in DOMAIN_CONTROLLER_REFERENCE_SET
)
and
(
application in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or qidname in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_QIDS
or destinationport in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_PORTS
or customproperty_domain_controller_service in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
)
and sourceip not in APPROVED_DOMAIN_CONTROLLER_SOURCE_REFERENCE_SET
and
(
sourceip in UNMANAGED_SOURCE_REFERENCE_SET
or sourceip in VPN_ADDRESS_POOL_REFERENCE_SET
or sourceip in BRANCH_NETWORK_REFERENCE_SET
or sourceip in WORKSTATION_SUBNET_REFERENCE_SET
or source_role in ("unmanaged_system", "workstation", "vpn_connected_host", "branch_system", "non_administrative_server")
or eventcount >= ENV_DC_SERVICE_ACCESS_THRESHOLD
)

authentication_expansion_event where
eventid in ("4624", "4625", "4648", "4672", "4768", "4769", "4771", "4776")
and
(
username in PRIVILEGED_ACCOUNT_REFERENCE_SET
or username in MACHINE_ACCOUNT_REFERENCE_SET
or username in SERVICE_ACCOUNT_REFERENCE_SET
or customproperty_logon_type in ("3", "9", "10")
or qidname in LOCALLY_VALIDATED_AUTHENTICATION_EXPANSION_QIDS
or customproperty_authentication_pattern in ("kerberos_service_ticket_activity", "ntlm_authentication", "explicit_credential_use", "privileged_logon")
or eventcount >= ENV_AUTH_EXPANSION_THRESHOLD
)
and change_context not in ("approved_administrator_activity", "approved_identity_management_workflow", "approved_backup_activity", "approved_vulnerability_management", "approved_domain_controller_maintenance", "approved_security_testing", "approved_incident_response")

correlate domain_controller_service_activity and authentication_expansion_event where
(
domain_controller_service_activity.sourceip == authentication_expansion_event.sourceip
or domain_controller_service_activity.sourceip == authentication_expansion_event.customproperty_related_ip
or domain_controller_service_activity.sourcehostname == authentication_expansion_event.hostname
or domain_controller_service_activity.username == authentication_expansion_event.username
or domain_controller_service_activity.machine_account == authentication_expansion_event.username
or domain_controller_service_activity.offense_id == authentication_expansion_event.offense_id
)
and authentication_expansion_event.starttime between domain_controller_service_activity.starttime and domain_controller_service_activity.starttime + ENV_AUTH_FOLLOWON_WINDOW

derive authentication_expansion from authentication_expansion_event where
privileged account activity maps to "privileged_account_activity"
machine account activity maps to "machine_account_activity"
service account activity maps to "service_account_activity"
multi-host or rare user-to-host behavior maps to "multi_host_authentication_expansion"
remaining matched authentication behavior maps to "authentication_activity"

assign severity where
"high" requires privileged account activity with abnormal expansion or repeated domain-controller service access
"medium" requires machine-account activity, service-account activity, explicit credential use, administrative logon type, or privileged logon without confirmed expansion
"low" applies to remaining correlated authentication activity pending analyst validation

Rule

Domain-Controller Service Anomaly Correlated With Endpoint Execution and Lateral Movement

Rule Format

QRadar rule and AQL-style implementation pattern suitable for flow telemetry, Windows Security events, Directory Services events, endpoint telemetry, authentication telemetry, DNS logs, proxy logs, firewall logs, domain-controller reference sets, high-value asset reference sets, source-role enrichment, change-management context, custom properties, building blocks, and offense correlation after log-source validation, DSM validation, custom-property validation, reference-set validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious domain-controller service activity followed by endpoint execution, lateral movement, administrative protocol use, high-value asset access, outbound communication, or security-control disruption.

·        Identify cases where suspicious Netlogon-adjacent or domain-controller service interaction becomes higher risk because it is followed by observable post-interaction activity across endpoint and network telemetry.

·        Prioritize activity involving source hosts or domain controllers that later access identity infrastructure, jump hosts, management servers, backup systems, endpoint-management platforms, file servers, source-code systems, CI/CD systems, databases, or sensitive business applications.

·        Support escalation when endpoint execution, lateral movement, or outbound communication aligns with privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or directory-service changes.

·        Preserve separation between suspicious post-interaction behavior and confirmed compromise by requiring endpoint, identity, network, file, persistence, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, command-and-control, exfiltration, credential theft, downstream compromise, or actor attribution without supporting evidence.

Detection Logic

·        Identify suspicious domain-controller service activity involving Netlogon-adjacent, MS-NRPC, RPC, SMB domain-controller service, or locally classified domain-controller service traffic from a non-standard source.

·        Correlate the same source host, account, affected domain controller, or offense context with endpoint execution involving PowerShell, command shell, WMI, WinRM, service creation, scheduled task creation, credential-access behavior, tool staging, persistence, or suspicious process execution.

·        Correlate the same source host, account, affected domain controller, or offense context with lateral movement involving SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database access, management-plane access, or administrative protocols.

·        Correlate the same source host, account, affected domain controller, or offense context with outbound communication involving rare destinations, newly observed domains, low-reputation destinations, tunnel-like traffic, abnormal byte volume, unexpected SMB egress, or destinations outside normal baselines.

·        Use locally validated correlation keys rather than assuming all follow-on activity shares the original network source IP.

·        Increase confidence when post-interaction behavior follows privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, or directory-service object changes.

·        Increase confidence when activity targets high-value assets, identity infrastructure, domain controllers, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, or sensitive business systems.

·        Reduce severity when behavior aligns with approved administrator workflows, backup schedules, monitoring activity, patching, software deployment, vulnerability management, identity-management workflows, security testing, incident response, or documented change-control activity.

·        Do not attribute endpoint execution, lateral movement, or outbound communication to Netlogon exploitation without suspicious upstream domain-controller interaction and supporting identity-plane, endpoint, network, or incident-response evidence.

·        Do not treat lateral movement, administrative protocol use, outbound communication, or endpoint telemetry as compromise evidence by itself.

·        Do not use this rule for actor attribution without incident-specific intelligence and validated behavioral correlation.

Required Telemetry

·        QRadar flow telemetry.

·        QRadar Windows Security log source.

·        QRadar Directory Services log source.

·        Endpoint telemetry where available.

·        DNS telemetry where available.

·        Proxy telemetry where available.

·        Firewall telemetry where available.

·        Authentication telemetry.

·        Change-management data or reference set.

·        Domain-controller reference set.

·        High-value asset reference set.

·        Identity infrastructure reference set.

·        Jump-host reference set.

·        Management-server reference set.

·        Backup-system reference set.

·        Endpoint-management platform reference set.

·        Source-code and CI/CD inventory where available.

·        Sensitive business application reference set.

·        Approved administrative source reference set.

·        Approved workflow reference set.

·        Custom event properties for source host, destination host, account, process name, command line, event ID, event action, and change context.

·        Custom flow properties for network application, external destination context, destination role, and asset criticality.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Account name.

·        Process name.

·        Process command line.

·        Parent process.

·        Destination port.

·        Protocol or service.

·        DNS query where available.

·        External destination context where available.

·        Event ID.

·        Event action.

·        Timestamp.

·        Change-window context.

·        Incident-response context where available.

Engineering Implementation Instructions

·        Build suspicious domain-controller interaction searches using QRadar flow telemetry, domain-controller reference sets, approved source reference sets, protocol filters, and source-role enrichment.

·        Build endpoint execution searches for PowerShell, command shell, WMI, WinRM, service creation, scheduled task creation, script execution, credential-access behavior, tool staging, suspicious process execution, and security-control disruption.

·        Build lateral-movement searches for SMB administrative shares, RDP, WMI, WinRM, remote services, SSH, LDAP utilities, Kerberos tooling, database clients, management-plane access, and administrative protocols.

·        Build outbound-risk searches for newly observed external destinations, rare domains, unusual ASNs, low-reputation destinations, tunnel-like traffic, abnormal DNS behavior, abnormal byte volume, unexpected SMB egress, and destinations inconsistent with source or domain-controller baselines.

·        Build high-value asset groups covering identity infrastructure, domain controllers, jump hosts, privileged management systems, management servers, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, databases, file servers, and sensitive business applications.

·        Build identity-plane follow-on groups for privileged authentication, machine-account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, and administrative-control activity.

·        Validate QRadar log sources, DSM parsing, QIDs, normalized fields, endpoint fields, flow fields, authentication fields, custom properties, reference-set membership, timestamp normalization, process fields, and correlation fields before deployment.

·        Validate whether source host, destination host, process name, command line, account name, source IP, destination IP, event ID, action, protocol, external destination, and timestamp are reliably mapped.

·        Use QRadar building blocks for suspicious upstream domain-controller interaction, high-value asset access, privileged account involvement, suspicious process execution, credential-access behavior, security-control disruption, and identity-plane changes.

·        Use short correlation windows for immediate endpoint execution, lateral movement, or outbound communication after suspicious domain-controller service activity.

·        Use moderate correlation windows for delayed post-interaction activity, repeated internal access, credential access, persistence, or security-control disruption.

·        Use longer correlation windows only when incident-response evidence, endpoint continuity, identity evidence, or repeated access patterns support delayed linkage.

·        Add severity weighting for suspicious upstream domain-controller interaction, high-value asset access, privileged account involvement, suspicious process execution, credential-access behavior, security-control disruption, identity-plane changes, and outbound-risk context.

·        Treat endpoint execution, lateral movement, and outbound communication as confidence amplifiers, not standalone proof of Netlogon exploitation.

·        Use approved administrator records, monitoring records, backup records, patching records, software deployment records, vulnerability management records, identity-management records, security-testing records, change-control records, and incident-response records as triage evidence.

·        Validate false-positive rates against administrative workflows, endpoint-management activity, backup activity, monitoring activity, software deployment, patching, vulnerability management, identity-management work, security testing, and incident response.

·        Do not enable alert mode until log-source availability, custom-property mapping, endpoint-to-flow joins, asset reference-set accuracy, false-positive rate, query performance, offense workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious domain-controller interaction followed by endpoint execution, lateral movement, or outbound behavior rather than static CVE identifiers, exploit strings, file hashes, packet signatures, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, process choice, lateral-movement method, outbound destination, timing, or post-exploitation sequence.

·        The score is supported by the durability of post-interaction endpoint behavior, high-value asset access, lateral movement, credential-access behavior, security-control disruption, and outbound communication.

·        The score is constrained by legitimate administrator activity, endpoint-management workflows, backup traffic, software deployment, vulnerability management, incomplete endpoint telemetry, weak asset inventory, and QRadar custom-property gaps.

·        The rule is durable as multi-source post-interaction coverage but should not be treated as standalone proof of successful exploitation, compromise, command-and-control, exfiltration, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable QRadar ingestion for flow telemetry, endpoint telemetry, Windows Security logs, Directory Services events, DNS logs, proxy logs, firewall logs, high-value asset inventory, and source-role enrichment.

·        Operational confidence is reduced where endpoint telemetry is incomplete, DNS or proxy logs are missing, high-value asset inventories are weak, process fields are inconsistent, custom properties are incomplete, or source-host joins are unreliable.

·        Operational confidence is reduced where administrators, backup systems, monitoring systems, software deployment systems, vulnerability management platforms, identity-management systems, or incident responders commonly perform similar post-interaction activity.

·        Full-telemetry confidence improves when QRadar correlates flow telemetry, endpoint telemetry, authentication logs, Directory Services events, DNS logs, proxy logs, firewall logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation, compromise, or actor attribution.

Limitations

·        This rule detects post-interaction endpoint and network behavior, not confirmed exploitation by itself.

·        QRadar cannot determine intent or compromise state unless endpoint, identity, network, directory-service, and incident-response evidence support the correlation.

·        Legitimate administrator, backup, monitoring, patching, software deployment, vulnerability management, identity-management, security testing, and incident-response workflows can produce similar behavior.

·        Missing endpoint data, incomplete DNS or proxy logs, weak DSM parsing, stale reference sets, or poor source-host joins can reduce confidence.

·        The rule may miss activity that uses expected administrative paths, communicates with approved destinations, avoids endpoint artifacts, or occurs outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Use a QRadar implementation pattern that first collects suspicious source-to-domain-controller service activity, then collects endpoint execution, lateral movement, outbound communication, or high-value asset access activity, then correlates those sets using locally validated keys and timing windows. This is not universal plug-and-play AQL; exact QRadar rule logic, AQL syntax, custom properties, reference sets, and building blocks must be generated after local log-source, DSM, and field validation.

domain_controller_service_activity where
(
destinationip in DOMAIN_CONTROLLER_REFERENCE_SET
or destinationhostname in DOMAIN_CONTROLLER_REFERENCE_SET
or destinationfqdn in DOMAIN_CONTROLLER_REFERENCE_SET
)
and
(
application in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
or qidname in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_QIDS
or destinationport in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_PORTS
or customproperty_domain_controller_service in LOCALLY_VALIDATED_DOMAIN_CONTROLLER_SERVICE_VALUES
)
and sourceip not in APPROVED_DOMAIN_CONTROLLER_SOURCE_REFERENCE_SET
and
(
sourceip in UNMANAGED_SOURCE_REFERENCE_SET
or sourceip in VPN_ADDRESS_POOL_REFERENCE_SET
or sourceip in BRANCH_NETWORK_REFERENCE_SET
or sourceip in WORKSTATION_SUBNET_REFERENCE_SET
or source_role in ("unmanaged_system", "workstation", "vpn_connected_host", "branch_system", "non_administrative_server")
or eventcount >= ENV_DC_SERVICE_ACCESS_THRESHOLD
)

followon_activity where
(
processname in ("powershell.exe", "pwsh.exe", "cmd.exe", "wmic.exe", "winrm.vbs", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "psexec.exe", "procdump.exe", "rclone.exe")
or commandline matches LOCALLY_VALIDATED_ENDPOINT_EXECUTION_PATTERN
or application in ("smb_admin_share", "rdp", "wmi", "winrm", "remote_service", "ssh", "ldap", "kerberos", "database", "management_plane", "admin_protocol")
or customproperty_external_destination_context in ("newly_observed_external_destination", "rare_external_destination", "low_reputation_destination", "tunnel_like_protocol", "abnormal_byte_volume", "destination_not_in_source_baseline")
or destinationip in HIGH_VALUE_ASSET_REFERENCE_SET
or destinationhostname in HIGH_VALUE_ASSET_REFERENCE_SET
)
and change_context not in ("approved_administrator_activity", "approved_monitoring_activity", "approved_backup_activity", "approved_identity_management_workflow", "approved_vulnerability_management", "approved_patching_activity", "approved_software_deployment", "approved_security_testing", "approved_incident_response")

correlate domain_controller_service_activity and followon_activity where
(
domain_controller_service_activity.sourceip == followon_activity.sourceip
or domain_controller_service_activity.sourceip == followon_activity.customproperty_related_ip
or domain_controller_service_activity.sourcehostname == followon_activity.hostname
or domain_controller_service_activity.username == followon_activity.username
or domain_controller_service_activity.machine_account == followon_activity.username
or domain_controller_service_activity.offense_id == followon_activity.offense_id
)
and followon_activity.starttime between domain_controller_service_activity.starttime and domain_controller_service_activity.starttime + ENV_POST_DC_INTERACTION_WINDOW

derive followon_pattern from followon_activity where
process execution or suspicious command-line activity maps to "endpoint_execution_or_credential_access"
administrative protocol or lateral-movement service activity maps to "lateral_movement_or_outbound_activity"
external destination anomaly maps to "lateral_movement_or_outbound_activity"
high-value asset access maps to "high_value_asset_access"
remaining matched follow-on behavior maps to "post_interaction_activity"

assign severity where
"high" requires endpoint execution from unmanaged, workstation, or VPN-connected source context, or high-value asset access with suspicious upstream domain-controller interaction
"medium" requires correlated endpoint execution, lateral movement, outbound communication, or high-value asset access without confirmed high-risk expansion
"low" applies to remaining correlated post-interaction activity pending analyst validation

SIGMA

Detection Viability Assessment

SIGMA has three implementation-ready rules for this EXP report.

·        SIGMA is viable for portable Windows detection coverage associated with Netlogon-related domain-controller compromise exposure when the rules are implemented as atomic detections and then correlated in the target backend.

·        SIGMA is strongest for this report when Windows Security events, Directory Services auditing, authentication telemetry, endpoint process telemetry, domain-controller inventory, privileged-account inventory, approved administrative-source context, and change-management records are available.

·        The SIGMA rules in this section are not standalone proof of successful Netlogon exploitation, domain-controller compromise, credential theft, Active Directory takeover, replication abuse, or actor attribution.

·        Each rule requires backend conversion, local field mapping, Windows event-source validation, Active Directory audit-policy validation, lookup enrichment, false-positive testing, query-performance testing, exception handling, SOC triage validation, and backend-side correlation before alert-mode deployment.

·        Netlogon-adjacent correlation should be performed after conversion in the target SIEM or detection platform, or through supported SIGMA correlation handling where available.

·        These rules should not generate high-confidence alerting from vulnerable-state findings alone, patch state alone, scanner output alone, exposed Netlogon services alone, isolated Netlogon errors alone, single authentication events alone, ordinary domain join activity alone, or administrative maintenance activity that aligns with approved change records.

Rule

Suspicious Sensitive Active Directory Object or Account Modification

Rule Format

SIGMA rule for Windows Security and Directory Services event sources, intended to detect sensitive Active Directory account, machine-account, trust, privilege, policy, replication, delegation, or directory-object changes. This rule is implementation-ready but not directly production-deployable until backend conversion, local field mapping, event-source validation, enrichment mapping, exception handling, false-positive testing, query-performance testing, and SOC triage validation are complete.

Detection Purpose

·        Detect sensitive Active Directory account, machine-account, privileged-group, trust, policy, replication, delegation, Group Policy, or directory-object modification activity.

·        Support Netlogon-related investigation by identifying identity-plane changes that may occur after suspicious domain-controller service interaction.

·        Prioritize changes involving domain-controller accounts, machine accounts, privileged groups, domain trusts, replication permissions, delegation attributes, Group Policy Objects, password or account-control attributes, and sensitive directory-service objects.

·        Provide portable SIGMA detection coverage that can be correlated in the backend with suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, authentication, endpoint, and domain-controller access activity.

·        This rule does not prove Netlogon exploitation or domain compromise by itself.

Detection Logic

·        Identify Windows Security and Directory Services events associated with password reset, account modification, machine-account modification, privileged-group membership change, domain-policy change, security-policy change, directory-object modification, directory-object creation, directory-object movement, or directory-object deletion.

·        Prioritize events involving domain-controller computer accounts, machine accounts, privileged groups, domain trust objects, Group Policy Objects, delegation-related attributes, service principal names, account-control attributes, replication-related objects, or password-related attributes.

·        Increase investigative priority when the same account, source host, affected domain controller, or incident window also includes suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, or repeated domain-controller service activity.

·        Increase investigative priority when the source system is not an approved domain controller, replication partner, identity-management platform, monitoring system, backup system, vulnerability management system, administrative jump host, privileged access workstation, or authorized maintenance system.

·        Increase investigative priority when the source context includes unmanaged system, workstation network, VPN ingress range, branch network, newly observed internal source, non-administrative server, or source outside the approved domain-controller access baseline.

·        Reduce severity when the activity aligns with approved domain join, trust repair, replication maintenance, domain-controller maintenance, identity-management workflow, backup activity, monitoring activity, vulnerability management, security testing, incident response, or validated change-control activity.

·        Do not classify the activity as confirmed compromise without corroborating authentication, directory-service, endpoint, network, administrative-control, or incident-response evidence.

Required Telemetry

·        Windows Security events.

·        Directory Services events.

·        Domain-controller System events where available.

·        Domain-controller inventory.

·        Domain-controller account inventory.

·        Machine-account inventory.

·        Privileged group inventory.

·        Sensitive Active Directory object inventory.

·        Domain trust inventory.

·        Replication-permission inventory.

·        Approved administrative source inventory.

·        Replication partner inventory.

·        Identity-management system inventory.

·        Monitoring-system inventory.

·        Backup-system inventory.

·        Vulnerability management system inventory.

·        Administrative jump-host inventory.

·        Change-management records.

·        Source host.

·        Destination domain controller.

·        Source IP where available.

·        Account name.

·        Machine account.

·        Object distinguished name.

·        Object class.

·        Attribute name.

·        Event ID.

·        Action.

·        Change type.

·        Timestamp.

·        Change-window context.

Engineering Implementation Instructions

·        Validate that Windows Security and Directory Services auditing are enabled for the required event types before deployment.

·        Validate local field mappings for EventID, Computer, SubjectUserName, TargetUserName, ObjectDN, ObjectClass, AttributeLDAPDisplayName, OperationType, SourceIp, WorkstationName, and timestamp.

·        Validate whether the backend parser preserves Directory Services fields consistently across event IDs 5136, 5137, 5139, and 5141.

·        Add enrichment for domain controllers, machine accounts, privileged groups, domain trusts, sensitive Active Directory objects, replication-related objects, approved administrative systems, and approved change windows.

·        Correlate converted rule output with suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, and repeated domain-controller service activity in the backend.

·        Use short correlation windows for immediate account or object changes after suspicious domain-controller service activity.

·        Use moderate correlation windows for trust, replication, privileged-group, delegation, and policy changes.

·        Use longer correlation windows only when incident-response evidence, repeated source behavior, authentication evidence, or endpoint evidence supports delayed linkage.

·        Suppress or downgrade activity that aligns with validated domain join, trust repair, replication maintenance, identity-management workflow, backup activity, monitoring activity, vulnerability management, security testing, incident response, or approved change control.

·        Do not enable alert mode until backend conversion, field mapping, lookup enrichment, false-positive baselining, query-performance testing, and SOC triage validation are complete.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to sensitive Active Directory modification behavior rather than CVE identifiers, exploit strings, packet signatures, filenames, hashes, or public proof-of-concept artifacts.

·        The rule remains useful if an adversary changes Netlogon exploit tooling, source host, command syntax, timing, target order, or post-exploitation sequence.

·        The score is supported by the durability of machine-account changes, privileged-group changes, domain trust changes, delegation changes, policy changes, replication-related changes, and sensitive directory-object modifications.

·        The score is constrained by legitimate administrative identity operations, incomplete Directory Services auditing, inconsistent field mappings, backend conversion differences, and weak change-management context.

·        The rule should support escalation and correlation, not standalone confirmation of Netlogon exploitation or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable Windows Security logging, Directory Services auditing, domain-controller inventory, privileged-object enrichment, approved-source enrichment, and change-management context.

·        Operational confidence is reduced where object fields are inconsistently mapped, Directory Services auditing is incomplete, domain-controller inventory is stale, or change-management records are unavailable.

·        Full-telemetry confidence improves when converted SIGMA output is correlated with network telemetry, authentication telemetry, EDR telemetry, VPN telemetry, privileged-access records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should not be used as standalone proof of exploit success, domain compromise, credential theft, replication abuse, or actor attribution.

Limitations

·        This rule detects sensitive Active Directory modification behavior, not confirmed Netlogon exploitation.

·        Legitimate domain join, trust repair, replication maintenance, domain-controller maintenance, identity-management, backup, monitoring, vulnerability management, security testing, and incident-response workflows can produce similar events.

·        Event availability depends on Windows audit policy, Directory Services auditing, domain-controller logging, and backend parser support.

·        Some fields used in SIGMA patterns may require local mapping or may not exist consistently across all backends.

·        Environment-specific suppression for known administrative systems should be applied only after local validation and should not suppress all machine-account activity by default.

·        The rule may miss activity that uses approved administrative systems, avoids sensitive object modification, blends into normal identity workflows, or occurs outside the backend correlation window.

·        Backend-side correlation with Netlogon-adjacent activity is required before making a Netlogon-related escalation claim.

Detection Query Pattern

title: Suspicious Sensitive Active Directory Object or Account Modification
id: 8c8f8e38-64d7-4c98-b70e-9f2d9b8fbf25
status: test
description: Detects sensitive Active Directory account, machine-account, trust, privilege, policy, replication, delegation, or directory-object modifications that should be correlated with suspicious domain-controller service activity in the backend.
author: CyberDax
logsource:
product: windows
service: security
detection:
selection_event:
EventID:
- 4724
- 4728
- 4732
- 4738
- 4739
- 4742
- 4756
- 4719
- 5136
- 5137
- 5139
- 5141
selection_sensitive_account:
TargetUserName|contains:
- '$'
- 'DC'
- 'Domain Admins'
- 'Enterprise Admins'
- 'Administrators'
- 'Backup Operators'
- 'Server Operators'
- 'Account Operators'
selection_sensitive_object:
ObjectClass:
- computer
- trustedDomain
- group
- groupPolicyContainer
- nTDSDSA
selection_sensitive_attribute:
AttributeLDAPDisplayName|contains:
- msDS-AllowedToDelegateTo
- unicodePwd
- servicePrincipalName
- userAccountControl
- member
- trustDirection
- trustType
- trustAttributes
condition: selection_event and 1 of selection_sensitive_*
fields:

·        EventID

·        Computer

·        SubjectUserName

·        TargetUserName

·        ObjectDN

·        ObjectClass

·        AttributeLDAPDisplayName

·        OperationType

·        SourceIp

·        WorkstationName
falsepositives:

·        Approved domain join activity

·        Approved trust repair

·        Approved replication maintenance

·        Domain-controller maintenance

·        Identity-management workflow

·        Backup or monitoring activity

·        Vulnerability management

·        Security testing

·        Incident response

·        Incomplete change-management enrichment
level: high

Rule

Abnormal Privileged or Machine-Account Authentication Activity

Rule Format

SIGMA rule for Windows Security authentication events, intended to detect privileged, machine-account, service-account, explicit-credential, Kerberos, NTLM, and administrative logon activity that may support backend correlation with suspicious Netlogon-adjacent domain-controller interaction. This rule is implementation-ready but not directly production-deployable until backend conversion, local field mapping, account-risk enrichment, source-role enrichment, false-positive testing, query-performance testing, and SOC triage validation are complete.

Detection Purpose

·        Detect abnormal privileged, machine-account, service-account, explicit-credential, Kerberos, NTLM, or administrative authentication activity.

·        Support Netlogon-related investigation by identifying authentication expansion that may occur after suspicious domain-controller service interaction.

·        Prioritize authentication involving privileged accounts, domain-controller accounts, machine accounts, service accounts, low-frequency accounts, newly observed accounts, dormant accounts, or accounts with sensitive access.

·        Provide portable SIGMA detection coverage that can be correlated in the backend with suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, identity-plane, endpoint, and domain-controller access activity.

·        This rule does not prove Netlogon exploitation, credential theft, ticket misuse, lateral movement, domain compromise, or actor attribution by itself.

Detection Logic

·        Identify Windows Security authentication events involving successful logons, failed logons, explicit credential use, Kerberos authentication, Kerberos service-ticket activity, Kerberos pre-authentication failures, and NTLM authentication.

·        Prioritize events involving privileged accounts, machine accounts, domain-controller accounts, service accounts, administrative logon types, rare user-to-host paths, repeated failed-then-successful authentication, or authentication outside normal account baseline.

·        Increase investigative priority when the same account, source host, affected domain controller, or incident window also includes suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, or repeated domain-controller service activity.

·        Increase investigative priority when authentication activity is followed by machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, directory-service object changes, endpoint suspicious behavior, lateral movement, or security-control disruption.

·        Reduce severity when activity aligns with approved administrator activity, identity-management workflow, replication maintenance, backup activity, monitoring activity, vulnerability management, security testing, incident response, known service-account baseline, or validated change-control activity.

·        Do not treat a single privileged logon, Kerberos event, NTLM event, service-ticket event, or failed authentication as compromise evidence by itself.

Required Telemetry

·        Windows Security events.

·        Authentication telemetry.

·        Kerberos authentication events.

·        NTLM authentication events.

·        Service-ticket events.

·        Privileged logon events.

·        Explicit credential use events.

·        Failed authentication events.

·        Successful authentication events.

·        Domain-controller inventory.

·        Domain-controller account inventory.

·        Privileged account inventory.

·        Machine-account inventory.

·        Service-account inventory.

·        Source-role enrichment.

·        User baseline enrichment.

·        Host baseline enrichment.

·        VPN address pool enrichment where available.

·        Branch network enrichment where available.

·        Workstation subnet enrichment where available.

·        Network-flow telemetry where available.

·        EDR telemetry where available.

·        Directory Services events where available.

·        Change-management records.

·        Approved administrative workflow records.

·        Approved maintenance records.

·        Incident-response records.

·        Source host.

·        Destination host.

·        Source IP.

·        Destination IP.

·        Account name.

·        User principal name.

·        Machine account.

·        Authentication package.

·        Logon type.

·        Ticket encryption type where available.

·        Service name where available.

·        Event ID.

·        Timestamp.

·        Session context where available.

Engineering Implementation Instructions

·        Validate local field mappings for EventID, Computer, TargetUserName, SubjectUserName, IpAddress, WorkstationName, LogonType, AuthenticationPackageName, ServiceName, TicketEncryptionType, FailureReason, Status, SubStatus, and timestamp.

·        Add account-risk enrichment for privileged accounts, domain-controller accounts, machine accounts, service accounts, low-frequency accounts, dormant accounts, newly observed accounts, and accounts with sensitive access.

·        Add source-role enrichment for domain controllers, replication partners, identity-management platforms, monitoring systems, backup systems, vulnerability management systems, administrative jump hosts, privileged access workstations, workstation networks, VPN ingress ranges, branch networks, and newly observed internal sources.

·        Correlate converted rule output with suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, and repeated domain-controller service activity in the backend.

·        Correlate converted rule output with downstream identity-plane changes, endpoint suspicious behavior, lateral movement, and security-control disruption.

·        Use short correlation windows for authentication anomalies immediately following suspicious domain-controller service activity.

·        Use moderate correlation windows for privileged authentication expansion, service-ticket anomalies, multi-host access, and failed-then-successful authentication.

·        Use longer correlation windows only when identity evidence, endpoint evidence, repeated source behavior, or incident-response evidence supports delayed linkage.

·        Suppress or downgrade activity that aligns with approved administrator activity, identity-management workflow, replication maintenance, backup activity, monitoring activity, vulnerability management, service-account baseline, security testing, incident response, or validated change control.

·        Do not enable alert mode until backend conversion, authentication-field mapping, account-risk enrichment, source-role enrichment, false-positive baselining, query-performance testing, and SOC triage validation are complete.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to privileged and machine-account authentication behavior rather than CVE identifiers, exploit strings, packet signatures, filenames, hashes, or known malicious infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, authentication timing, account selection, internal destination order, or credential-use sequence.

·        The score is supported by the durability of privileged authentication, machine-account authentication, explicit credential use, Kerberos and NTLM authentication behavior, administrative logon types, and authentication expansion.

·        The score is constrained by legitimate administrator activity, service-account activity, replication workflows, backup activity, weak account baselines, incomplete authentication logging, and backend-specific field normalization.

·        The rule should support escalation and correlation, not standalone confirmation of Netlogon exploitation, credential theft, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.0 / 10

·        Operational confidence depends on reliable Windows authentication telemetry, account-risk enrichment, source-role enrichment, domain-controller inventory, logon type mapping, Kerberos visibility, NTLM visibility, and service-account baselines.

·        Operational confidence is reduced where authentication logs are incomplete, logon types are inconsistently mapped, Kerberos or NTLM fields are unavailable, account baselines are weak, or service-account behavior is poorly documented.

·        Full-telemetry confidence improves when converted SIGMA output is correlated with network telemetry, Directory Services events, EDR telemetry, VPN telemetry, source-host context, asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should not be used as standalone proof of exploit success, credential theft, lateral movement, domain compromise, or actor attribution.

Limitations

·        This rule detects abnormal privileged or machine-account authentication activity, not confirmed exploitation by itself.

·        Legitimate administrator activity, identity-management workflows, replication maintenance, backup activity, monitoring, vulnerability management, service-account use, security testing, and incident-response activity can produce similar signals.

·        Authentication telemetry may not preserve source host, device, session, or network context consistently enough to prove linkage.

·        Some account-risk and baseline fields require backend enrichment and are not native SIGMA fields.

·        Service-account suppression should be implemented as a locally validated allowlist after baseline review, not as a broad static filter.

·        The rule may miss activity that uses approved accounts, approved administrative systems, normal authentication paths, or delayed authentication outside the backend correlation window.

·        Backend-side correlation with Netlogon-adjacent activity is required before making a Netlogon-related escalation claim.

Detection Query Pattern

title: Abnormal Privileged or Machine Account Authentication Activity
id: 20c94f15-9a27-4b24-830e-cf913f29a5dd
status: test
description: Detects privileged, machine-account, service-account, explicit-credential, Kerberos, NTLM, and administrative authentication activity that should be correlated with suspicious domain-controller service activity in the backend.
author: CyberDax
logsource:
product: windows
service: security
detection:
selection_event:
EventID:
- 4624
- 4625
- 4648
- 4768
- 4769
- 4771
- 4776
selection_sensitive_target:
TargetUserName|contains:
- admin
- '$'
- svc
- service
selection_sensitive_subject:
SubjectUserName|contains:
- admin
- '$'
- svc
- service
selection_krbtgt:
TargetUserName: krbtgt
selection_admin_logon:
LogonType:
- 3
- 9
- 10
selection_auth_package:
AuthenticationPackageName:
- NTLM
- Kerberos
condition: selection_event and (selection_sensitive_target or selection_sensitive_subject or selection_krbtgt or selection_admin_logon or selection_auth_package)
fields:

·        EventID

·        Computer

·        TargetUserName

·        SubjectUserName

·        IpAddress

·        WorkstationName

·        LogonType

·        AuthenticationPackageName

·        ServiceName

·        TicketEncryptionType

·        FailureReason

·        Status

·        SubStatus
falsepositives:

·        Approved administrator authentication

·        Known service-account authentication

·        Replication maintenance

·        Identity-management workflow

·        Backup or monitoring activity

·        Vulnerability management

·        Security testing

·        Incident response

·        Weak account baselines
level: medium

Rule

Suspicious Endpoint Execution or Credential-Access Behavior

Rule Format

SIGMA rule for Windows process creation telemetry, Sysmon-style telemetry, and EDR-normalized endpoint telemetry, intended to detect suspicious endpoint execution, credential-access preparation, remote administration, tool staging, and lateral-movement behavior that may support backend correlation with suspicious Netlogon-adjacent domain-controller interaction. This rule is implementation-ready but not directly production-deployable until backend conversion, local field mapping, endpoint telemetry validation, process-lineage validation, false-positive testing, query-performance testing, and SOC triage validation are complete.

Detection Purpose

·        Detect suspicious endpoint execution, credential-access behavior, tool staging, remote administration, service creation, scheduled task creation, administrative share access, and lateral-movement behavior.

·        Support Netlogon-related investigation by identifying endpoint behavior that may occur after suspicious domain-controller service interaction.

·        Prioritize activity involving PowerShell, command shell, WMI, WinRM, script hosts, rundll32, regsvr32, certutil, bitsadmin, curl, wget, PsExec-like tooling, credential-access utilities, backup utilities, directory-database utilities, shadow copy behavior, LSASS access, NTDS access, or suspicious staging paths.

·        Provide portable SIGMA detection coverage that can be correlated in the backend with suspicious Netlogon-adjacent, MS-NRPC, RPC, SMB, authentication, identity-plane, and domain-controller access activity.

·        This rule does not prove Netlogon exploitation, credential theft, lateral movement, downstream compromise, or actor attribution by itself.

Detection Logic

·        Identify suspicious process creation, script execution, command-line activity, tool staging, credential-access preparation, remote administration tooling, shadow copy behavior, backup abuse, service creation, scheduled task creation, administrative share use, or suspicious endpoint execution from user-writable or staging paths.

·        Prioritize activity involving PowerShell, command shell, WMI, WinRM, script hosts, rundll32, regsvr32, certutil, bitsadmin, curl, wget, PsExec-like tools, credential-access utilities, backup utilities, directory-database utilities, and locally relevant living-off-the-land binaries.

·        Increase investigative priority when the same source host, same account, same device, same affected domain controller, same remote logon context, or same incident window also includes suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, or repeated domain-controller service activity.

·        Increase investigative priority when endpoint behavior occurs on a domain controller, identity infrastructure, jump host, privileged management system, backup system, endpoint-management platform, file server, source-code system, CI/CD system, database server, or sensitive business system.

·        Increase investigative priority when endpoint behavior is accompanied by privileged authentication, machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, Directory Services changes, or security-control disruption.

·        Reduce severity when activity aligns with approved administrator workflow, helpdesk action, software deployment, backup activity, vulnerability management, EDR response, security testing, vendor support, identity-management workflow, incident response, or documented maintenance.

·        Do not treat endpoint behavioral alerts, remote administration tooling, credential-access indicators, PowerShell execution, or internal system access as compromise evidence by themselves.

Required Telemetry

·        Windows process creation telemetry.

·        Sysmon telemetry where available.

·        EDR-normalized endpoint telemetry where available.

·        Windows Security events where available.

·        Command-line telemetry.

·        Parent process.

·        Parent command line.

·        Process path.

·        Current directory.

·        Process hash.

·        Process signer and certificate metadata.

·        User identity.

·        Device identity.

·        Hostname.

·        Integrity level.

·        Timestamp.

·        File creation telemetry where available.

·        File modification telemetry where available.

·        File execution telemetry where available.

·        Registry modification telemetry where available.

·        Scheduled task telemetry where available.

·        Service creation telemetry where available.

·        Network connection telemetry where available.

·        DNS enrichment where available.

·        Domain-controller inventory.

·        Identity infrastructure inventory.

·        Jump-host inventory.

·        Privileged management inventory.

·        Backup-system inventory.

·        Endpoint-management inventory.

·        Source-code and CI/CD inventory where available.

·        Sensitive application inventory.

·        Approved administrator workflow records.

·        Approved helpdesk workflow records.

·        Approved software deployment baselines.

·        Approved backup schedules.

·        Approved vulnerability management records.

·        Approved security testing records.

·        Approved EDR response records.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Validate endpoint telemetry availability before deployment, especially process creation, command-line, parent process, current directory, user, device, timestamp, and hash fields.

·        Validate whether the target backend uses Sysmon field names, EDR-normalized field names, Windows Security field names, or a custom endpoint schema.

·        Validate process-name, image-path, command-line, current-directory, parent-process, user, device, and destination-field mappings after SIGMA conversion.

·        Add enrichment for domain controllers, identity infrastructure, jump hosts, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, file servers, database servers, sensitive business systems, approved administrative systems, and approved workflow context.

·        Correlate converted rule output with suspicious Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, RPC, SMB domain-controller service, and repeated domain-controller service activity in the backend.

·        Correlate converted rule output with privileged authentication, identity-plane changes, lateral movement, high-value asset access, and security-control disruption.

·        Use short correlation windows when suspicious endpoint execution occurs immediately after suspicious domain-controller service activity.

·        Use moderate correlation windows for delayed tool staging, credential-access preparation, persistence, outbound communication, or repeated internal access.

·        Use longer correlation windows only when endpoint continuity, identity evidence, domain-controller interaction evidence, asset access evidence, or incident-response evidence supports delayed linkage.

·        Suppress or downgrade activity that aligns with approved administrator workflow, helpdesk activity, software deployment, backup activity, vulnerability management, EDR response, security testing, vendor support, maintenance windows, identity-management workflow, incident response, or validated change control.

·        Do not enable alert mode until backend conversion, endpoint-field mapping, process-lineage validation, enrichment mapping, false-positive baselining, query-performance testing, and SOC triage validation are complete.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to endpoint execution, credential-access preparation, remote administration, tool staging, and lateral-movement behavior rather than CVE identifiers, exploit strings, filenames, hashes, public proof-of-concept artifacts, or known infrastructure.

·        The rule remains useful if an adversary changes exploit tooling, source host, tool choice, command syntax, staging path, internal destination order, persistence method, or post-access sequence.

·        The score is supported by the durability of credential-access behavior, token-access behavior, remote administration tooling, administrative share use, service creation, scheduled task creation, suspicious file staging, shadow copy behavior, and high-value system access.

·        The score is constrained by legitimate administrator activity, helpdesk workflows, vulnerability management, backup activity, software deployment, EDR response, incomplete command-line telemetry, weak domain-controller interaction linkage, and backend conversion differences.

·        The rule should support endpoint triage and correlation, not standalone confirmation of Netlogon exploitation, domain compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on endpoint telemetry, process telemetry, command-line visibility, process-lineage visibility, domain-controller interaction enrichment, high-value asset inventory, identity context, and backend-specific SIGMA conversion quality.

·        Operational confidence is reduced where endpoint telemetry cannot be tied to suspicious domain-controller interaction, internal access logs are incomplete, remote logon context is missing, process ancestry is incomplete, or high-value asset inventory is weak.

·        Full-telemetry confidence improves when converted SIGMA output is enriched with NDR telemetry, Windows Security logs, Directory Services events, authentication logs, internal resource telemetry, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should not be used as standalone proof of exploit success, credential theft, lateral movement, domain compromise, or actor attribution.

Limitations

·        This rule detects suspicious endpoint behavior, not confirmed Netlogon exploitation.

·        Legitimate administrator, helpdesk, software deployment, backup, vulnerability management, security testing, EDR response, vendor-support, identity-management, and incident-response workflows can produce similar endpoint behavior.

·        SIGMA backend conversion may not preserve all process, command-line, parent-child, network, or endpoint fields consistently.

·        Suspicious endpoint behavior may be unrelated to domain-controller interaction unless timing, identity, device, session, or incident-response evidence supports linkage.

·        Path-based and parent-process filters should be applied only as locally validated suppressions, not broad built-in exclusions.

·        The rule may miss activity that remains within approved tooling, uses expected administrator pathways, occurs outside the backend correlation window, or does not generate endpoint artifacts.

·        Backend-side correlation with Netlogon-adjacent activity is required before making a Netlogon-related escalation claim.

Detection Query Pattern

title: Suspicious Endpoint Execution or Credential Access Behavior
id: 0ec856e6-efcc-4b41-90d0-04d3d904f13e
status: test
description: Detects suspicious Windows endpoint execution, credential-access preparation, remote administration, tool staging, and lateral-movement behavior that should be correlated with suspicious domain-controller service activity in the backend.
author: CyberDax
logsource:
product: windows
category: process_creation
detection:
selection_process:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
- '\cmd.exe'
- '\wmic.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\wget.exe'
- '\psexec.exe'
- '\procdump.exe'
- '\rclone.exe'
- '\ssh.exe'
- '\python.exe'
- '\node.exe'
- '\vssadmin.exe'
- '\wbadmin.exe'
- '\ntdsutil.exe'
selection_command:
CommandLine|contains:
- '-enc'
- '-encodedcommand'
- 'executionpolicy bypass'
- '-nop'
- '-noprofile'
- '-w hidden'
- 'downloadstring'
- 'invoke-webrequest'
- 'invoke-expression'
- 'frombase64string'
- 'lsass'
- 'ntds'
- 'ntds.dit'
- 'vssadmin'
- 'shadow'
- 'wbadmin'
- 'secrets'
- 'credential'
- 'token'
- 'dump'
- 'replication'
- 'trust'
- 'domain admin'
- 'enterprise admin'
- 'admin$'
- 'c$'
- 'psexec'
- 'wmic'
- 'winrm'
- 'scheduled task'
- 'remote service'
selection_path:
Image|contains:
- '\Downloads'
- '\AppData'
- '\Temp'
- '\ProgramData'
- '\Users\Public'
CurrentDirectory|contains:
- '\Downloads'
- '\AppData'
- '\Temp'
- '\ProgramData'
- '\Users\Public'
condition: selection_command or (selection_process and selection_path)
fields:

·        UtcTime

·        Computer

·        User

·        Image

·        CommandLine

·        ParentImage

·        ParentCommandLine

·        CurrentDirectory

·        ProcessGuid

·        ParentProcessGuid

·        Hashes

·        IntegrityLevel
falsepositives:

·        Approved administrator scripts

·        Helpdesk activity

·        Software deployment

·        Backup operations

·        Vulnerability management

·        Security testing

·        EDR response

·        Identity-management workflow

·        Vendor support

·        Incident response
level: high

YARA

Detection Viability Assessment

YARA has zero primary rules for this EXP report.

·        YARA is not recommended for primary S25 detection because the governing detection model is behavior-led, not artifact-led.

·        The report’s strongest detection coverage comes from domain-controller service interaction patterns, Netlogon-adjacent activity, MS-NRPC and RPC exposure context, abnormal source-to-domain-controller paths, sensitive Active Directory object changes, privileged or machine-account authentication activity, domain-controller account changes, domain trust changes, replication-permission changes, privileged group changes, endpoint execution, credential-access preparation, lateral-movement behavior, and downstream identity-plane correlation.

·        YARA does not observe Netlogon negotiation, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, domain-controller authentication context, Active Directory object changes, privileged group changes, domain trust changes, replication-permission changes, Kerberos or NTLM authentication, machine-account authentication, source-to-domain-controller access baselines, endpoint-to-domain-controller session lineage, or backend SIEM correlation context.

·        YARA can support optional investigative hunting if responders recover a stable artifact during incident response, such as a webshell, loader, dropper, staged script, exploit payload, credential-access tool, remote-access tool, memory artifact, configuration artifact, encoded payload, suspicious binary, or reusable file-content pattern linked to suspicious domain-controller interaction or downstream activity.

·        Including a primary YARA rule would create unnecessary artifact dependency and would be weaker than the accepted behavior-led rule sets for NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, and SIGMA.

·        YARA should remain a conditional investigative control rather than a primary detection system unless stable artifact evidence becomes available from the affected environment.

·        YARA should not be used to infer successful Netlogon exploitation, domain-controller compromise, credential theft, Active Directory takeover, replication abuse, endpoint compromise, identity compromise, lateral movement, persistence, data access, or actor attribution without supporting endpoint, identity, network, file, memory, directory-service, authentication, or incident-response evidence.

Final Disposition

No primary YARA rule is included.

AWS

Detection Viability Assessment

AWS has three rules for this EXP report.

·        AWS is viable for detecting downstream cloud-control-plane, IAM, security-control, data-access, secrets-access, and workload-access activity that may follow Windows Netlogon remote code execution, domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, or unauthorized use of an identity path linked to domain-controller compromise indicators.

·        AWS is strongest where CloudTrail, IAM Identity Center, IAM, STS, GuardDuty, VPC Flow Logs, Route 53 Resolver logs, AWS Organizations logs, AWS Config, Security Hub, identity-provider logs, AWS Managed Microsoft AD logs where present, Windows Security telemetry, Active Directory telemetry, endpoint telemetry, NDR telemetry, source enrichment, account enrichment, and SIEM correlation can be combined.

·        AWS can identify suspicious post-domain-controller-compromise cloud behavior involving console access, role assumption, IAM changes, access-key creation, policy modification, security-control modification, sensitive data access, secret retrieval, key-management activity, workload access, cross-account activity, unusual API usage, and activity inconsistent with the user’s normal cloud role.

·        AWS is not a standalone source for confirming Netlogon exploitation, MS-NRPC exploitation, domain-controller compromise, Active Directory takeover, Kerberos abuse, NTLM abuse, endpoint compromise, credential theft, token theft, cloud compromise, or actor attribution.

·        AWS detections must be correlated with upstream Windows Security logs, Directory Services events, domain-controller telemetry, NDR evidence, EDR evidence, authentication telemetry, AWS Managed Microsoft AD evidence where present, source-path evidence, change-control records, and incident-response findings before classifying activity as probable Netlogon-linked compromise.

·        Each AWS rule requires upstream Windows, Active Directory, endpoint, network, authentication, SIEM, AWS Managed Microsoft AD, or incident-response evidence before making a Netlogon-linked escalation claim.

·        AWS rules should not generate high-confidence alerting from cloud activity alone, role assumption alone, access-key creation alone, console login alone, GuardDuty findings alone, unusual API usage alone, sensitive data access alone, or source-IP novelty alone without upstream domain-controller compromise indicators or validated identity-path linkage.

Rule

Netlogon-Linked AWS Console or API Activity From Domain-Controller Compromise Indicators

Rule Format

AWS cloud-control-plane correlation rule suitable for CloudTrail, IAM Identity Center, IAM, STS, GuardDuty, VPC Flow Logs, Route 53 Resolver logs, identity-provider telemetry, AWS Managed Microsoft AD logs where present, Windows and Active Directory correlation context, source enrichment, account enrichment, AWS account inventory, privileged-role inventory, and SIEM correlation after AWS field validation, identity-to-AWS linkage validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect AWS console or API activity that occurs after upstream Windows Netlogon or domain-controller compromise indicators and can be linked to the same user, source path, identity-provider session, device, access key, assumed-role session, authentication session, domain identity, or incident timeline.

·        Identify possible downstream cloud exposure following domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, or unauthorized use of an identity path tied to a suspected compromised domain environment.

·        Prioritize activity involving privileged AWS roles, unusual role assumption, administrative API calls, first-seen regions, first-seen services, sensitive account access, cross-account activity, cloud-security-control interaction, or access inconsistent with the user’s normal AWS role.

·        Preserve separation between suspicious AWS activity and confirmed compromise by requiring supporting Windows, Active Directory, endpoint, network, cloud, credential-access, token-access, change-control, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, AWS compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify AWS console access, API activity, role assumption, federated authentication, IAM Identity Center activity, STS activity, or CloudTrail events associated with a user, role, access key, federated principal, or identity that can be linked to upstream domain-controller compromise indicators.

·        Prioritize AWS activity after upstream evidence involving suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, abnormal source-to-domain-controller paths, sensitive Active Directory object modification, privileged group changes, domain trust changes, replication-permission changes, machine-account authentication anomalies, privileged authentication anomalies, or endpoint credential-access behavior.

·        Detect AWS activity involving privileged role use, administrative API calls, IAM changes, STS AssumeRole activity, console login, first-seen region use, first-seen service use, unusual source path, unusual user agent, access outside normal windows, activity outside expected role, or access to sensitive accounts.

·        Increase confidence when AWS activity shares the same user, federated identity, identity-provider session, source IP, device identity, authentication session, access key lineage, assumed-role session lineage, AWS Managed Microsoft AD identity context, or incident timeline as upstream domain-controller compromise indicators.

·        Increase confidence when AWS activity involves IAM, Organizations, CloudTrail, GuardDuty, Security Hub, Config, KMS, Secrets Manager, S3, EC2, Lambda, EKS, RDS, Backup, Systems Manager, AWS Managed Microsoft AD, or other sensitive services not normally used by the account.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, AWS CLI use, unusual session creation, suspicious federation behavior, or post-domain-controller-compromise administrative behavior.

·        Reduce severity when AWS activity aligns with approved cloud operations, administrator workflows, DevOps workflows, CI/CD maintenance, security testing, incident response, emergency access, vendor support, disaster recovery, access-key rotation, or documented change-control activity.

·        Do not attribute AWS activity to Netlogon-linked compromise without upstream domain-controller evidence, identity linkage, source-path linkage, device linkage, access-key lineage, assumed-role lineage, change-control review, or incident-response validation.

·        Do not treat AWS console activity, API activity, role assumption, GuardDuty findings, CloudTrail anomalies, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where available.

·        AWS IAM logs and configuration context.

·        AWS IAM Identity Center logs where available.

·        AWS STS events.

·        AWS Organizations logs where available.

·        AWS Config logs where available.

·        AWS Security Hub findings where available.

·        Amazon GuardDuty findings where available.

·        VPC Flow Logs where available.

·        Route 53 Resolver logs where available.

·        AWS Managed Microsoft AD logs where present.

·        AWS console login events.

·        CloudTrail userIdentity fields.

·        CloudTrail sourceIPAddress fields.

·        CloudTrail userAgent fields.

·        CloudTrail eventSource fields.

·        CloudTrail eventName fields.

·        CloudTrail recipientAccountId fields.

·        CloudTrail awsRegion fields.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Source IP, ASN, geography, hosting-provider, and first-seen source enrichment.

·        AWS account inventory.

·        AWS organization inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build suspicious upstream domain-controller indicator groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside domain-controller access baselines, sensitive Active Directory object changes, privileged group changes, domain trust changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, and endpoint credential-access behavior.

·        Build AWS identity groups covering IAM users, IAM roles, federated users, IAM Identity Center users, privileged roles, break-glass roles, automation roles, CI/CD roles, service accounts, cross-account roles, and externally trusted roles.

·        Build AWS sensitive service groups covering IAM, STS, Organizations, CloudTrail, GuardDuty, Security Hub, Config, KMS, Secrets Manager, S3, EC2, Lambda, EKS, RDS, Backup, Systems Manager, AWS Managed Microsoft AD, and other locally sensitive services.

·        Build AWS high-risk action groups for ConsoleLogin, AssumeRole, CreateAccessKey, AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy, CreatePolicyVersion, SetDefaultPolicyVersion, UpdateAssumeRolePolicy, CreateUser, CreateLoginProfile, AddUserToGroup, CreateRole, PassRole, DisableMFADevice, DeleteVirtualMFADevice, StopLogging, DeleteTrail, UpdateTrail, PutBucketPolicy, GetSecretValue, Decrypt, and security-control modification.

·        Build linkage logic using user identity, identity-provider session, source IP, device identity, authentication session, domain identity, access key, assumed-role session name, session issuer, AWS Managed Microsoft AD identity context, CloudTrail userIdentity fields, CloudTrail sourceIPAddress, CloudTrail userAgent, and incident timeline.

·        Build AWS anomaly groups for first-seen region, first-seen service, rare API call, unusual user agent, source-path mismatch, device mismatch, activity outside normal windows, activity outside expected role, sensitive account access, and cross-account activity.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for AWS account ID, AWS principal ID, user identity, role name, assumed-role session name, source IP, user agent, event source, event name, region, result, identity-provider session, device identity, access-key lineage, AWS Managed Microsoft AD identity context, upstream domain-controller indicator status, downstream-risk pattern, and change-control context.

·        Validate event-action normalization across CloudTrail, IAM Identity Center, IAM, STS, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, identity-provider logs, MFA logs, Windows Security logs, Directory Services events, domain-controller telemetry, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for identity-to-AWS linkage, upstream domain-controller correlation, identity-session correlation, source-path validation, device correlation, CloudTrail enrichment, AWS account enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when AWS console or API activity occurs immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed role assumption, administrative activity, secret access, S3 access, cloud API activity, or security-control interaction after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, CloudTrail continuity, source-infrastructure overlap, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, CloudTrail field availability, AWS account inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to domain-controller-linked AWS control-plane activity rather than static exploit strings, CVE identifiers, source IPs, user-agent values, domains, or isolated AWS anomalies.

·        The rule remains useful if an adversary changes AWS service target, API sequence, role path, source infrastructure, session timing, token use pattern, or post-compromise cloud activity.

·        The score is supported by the durability of upstream identity-path linkage, privileged role use, administrative API activity, first-seen service or region use, source-path mismatch, and AWS behavior outside normal account baselines.

·        The score is constrained by weak domain-to-cloud identity linkage, identity federation complexity, NAT, cloud session reuse, token reuse, assumed-role abstraction, incomplete CloudTrail coverage, and target-SIEM translation quality.

·        The rule is durable as downstream AWS exposure coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, or AWS compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable upstream domain-controller indicator mapping, CloudTrail coverage, IAM Identity Center telemetry, identity-provider logs, MFA logs, AWS account inventory, source enrichment, endpoint telemetry, Windows and Active Directory telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where NAT, SASE routing, identity federation, cloud session reuse, token reuse, assumed-role naming, inconsistent source IPs, or missing device identifiers make domain-to-AWS linkage uncertain.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders commonly perform AWS administrative actions after privileged domain activity.

·        Full-telemetry confidence improves when AWS events are enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, identity-provider context, MFA logs, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious AWS control-plane activity linked to upstream domain-controller compromise indicators, not Netlogon exploitation or AWS compromise by itself.

·        AWS may not preserve enough source-path, device, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        CloudTrail activity may be legitimate for cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders.

·        Domain-to-AWS linkage may be weak where NAT, SASE egress, cloud session reuse, token reuse, identity federation, assumed-role abstraction, or source IP transformation obscures path attribution.

·        The rule may miss AWS abuse that occurs from a different device, different source path, reused token, pre-existing cloud session, expected automation role, or outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS cloud-control-plane correlation pattern requiring target-SIEM translation validation, CloudTrail field validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, AWS account validation, sensitive action validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

CloudTrailEvent AS AwsControlPlaneActivity

WHERE AwsControlPlaneActivity.eventName IN ANY (
"ConsoleLogin",
"AssumeRole",
"CreateAccessKey",
"AttachUserPolicy",
"AttachRolePolicy",
"PutUserPolicy",
"PutRolePolicy",
"CreatePolicyVersion",
"SetDefaultPolicyVersion",
"UpdateAssumeRolePolicy",
"CreateUser",
"CreateLoginProfile",
"AddUserToGroup",
"CreateRole",
"PassRole",
"DisableMFADevice",
"DeleteVirtualMFADevice",
"StopLogging",
"DeleteTrail",
"UpdateTrail",
"PutBucketPolicy",
"GetSecretValue",
"Decrypt"
)

AND AwsControlPlaneActivity.userIdentity.type IN ANY (
"IAMUser",
"AssumedRole",
"FederatedUser",
"Root"
)

AND AwsControlPlaneActivity.recipientAccountId IN ASSET_GROUP (
"Sensitive AWS Accounts",
"Production AWS Accounts",
"Security Tooling Accounts",
"Identity Management Accounts",
"Backup Accounts",
"Developer Platform Accounts"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_AWS_CONTROL_PLANE_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(AwsControlPlaneActivity.userIdentity)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
AwsControlPlaneActivity.sourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR AwsControlPlaneActivity.User IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR AwsControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR AwsControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN AwsControlPlaneActivity.ActivityPattern IN ANY (
"first_seen_region",
"first_seen_service",
"rare_api_call",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role",
"sensitive_account_access",
"cross_account_activity"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_break_glass_use",
"approved_change_control"
)

Rule

Netlogon-Linked AWS IAM or Security-Control Modification

Rule Format

AWS IAM and security-control correlation rule suitable for CloudTrail, IAM, AWS Organizations, AWS Config, Security Hub, GuardDuty, identity-provider telemetry, AWS Managed Microsoft AD logs where present, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, privileged-role inventory, and SIEM correlation after AWS IAM field validation, privileged-action validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect AWS IAM, AWS Organizations, CloudTrail, GuardDuty, Security Hub, AWS Config, KMS, S3, or security-control modifications after upstream domain-controller compromise indicators.

·        Identify potential downstream cloud persistence, privilege escalation, defense evasion, access expansion, or security-control weakening following domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, or unauthorized use of a domain-linked identity path.

·        Prioritize changes involving privileged roles, access keys, trust policies, inline policies, managed policy attachment, role creation, role assumption paths, logging controls, monitoring controls, encryption controls, bucket policies, security findings, and organization-level controls.

·        Preserve separation between suspicious AWS modification and confirmed compromise by requiring upstream domain-controller evidence, identity linkage, source-path evidence, endpoint evidence, CloudTrail evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, AWS compromise, credential theft, token theft, persistence, privilege escalation, or actor attribution without supporting evidence.

Detection Logic

·        Identify IAM, Organizations, CloudTrail, GuardDuty, Security Hub, AWS Config, KMS, S3, or security-control modification events in CloudTrail or related AWS telemetry.

·        Correlate modification events with upstream domain-controller compromise context involving suspicious Netlogon-adjacent activity, source novelty, abnormal source-to-domain-controller paths, privileged account use, machine-account anomalies, sensitive Active Directory object changes, suspicious authentication behavior, endpoint credential-access behavior, or suspicious internal follow-on activity.

·        Prioritize IAM activity involving CreateAccessKey, CreateUser, CreateLoginProfile, CreateRole, UpdateAssumeRolePolicy, AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy, CreatePolicyVersion, SetDefaultPolicyVersion, PassRole, AddUserToGroup, CreatePolicy, or privilege-expanding trust-policy changes.

·        Prioritize security-control activity involving StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors, DeleteDetector, UpdateDetector, BatchDisableStandards, DisableSecurityHub, PutBucketPolicy, PutKeyPolicy, ScheduleKeyDeletion, or changes that reduce visibility, encryption, alerting, monitoring, or access control.

·        Increase confidence when changes affect production accounts, security tooling accounts, identity-management accounts, backup accounts, developer-platform accounts, cross-account trust paths, privileged roles, or sensitive data services.

·        Increase confidence when activity is rare for the user, rare for the account, outside normal access windows, uses unusual user agents, follows upstream domain-controller compromise indicators, or lacks approved change-control context.

·        Reduce severity when changes align with approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, incident response, vendor support, security testing, disaster recovery, or documented change-control activity.

·        Do not classify AWS IAM or security-control modification as Netlogon-linked compromise without upstream domain-controller evidence, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS IAM events.

·        AWS STS events.

·        AWS Organizations events where available.

·        AWS Config configuration history.

·        AWS Security Hub findings where available.

·        Amazon GuardDuty findings where available.

·        AWS KMS events where available.

·        Amazon S3 data and management events where available.

·        AWS Managed Microsoft AD logs where present.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        AWS account inventory.

·        AWS organization inventory.

·        Privileged role inventory.

·        Cross-account trust inventory.

·        Service-account inventory.

·        Security tooling inventory.

·        Sensitive data-service inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved security engineering records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build AWS IAM modification groups covering user creation, access-key creation, login-profile creation, role creation, role policy updates, trust-policy updates, managed-policy attachment, inline-policy changes, policy-version creation, default-policy-version changes, group membership changes, PassRole usage, and privilege-expanding trust relationships.

·        Build AWS security-control modification groups covering CloudTrail changes, GuardDuty changes, Security Hub changes, AWS Config changes, KMS policy changes, S3 bucket policy changes, logging changes, monitoring changes, encryption changes, and alerting-control changes.

·        Build sensitive AWS account groups covering production accounts, identity-management accounts, security tooling accounts, backup accounts, developer-platform accounts, shared-services accounts, and accounts containing sensitive workloads or sensitive data.

·        Build upstream domain-controller compromise context groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside approved baselines, sensitive Active Directory object changes, privileged group changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, and endpoint credential-access behavior.

·        Build linkage logic using user identity, role session name, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, CloudTrail userIdentity fields, CloudTrail sourceIPAddress, AWS Managed Microsoft AD identity context where present, and incident timeline.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for AWS account ID, principal ID, role name, assumed-role session name, event source, event name, source IP, user agent, region, request parameters, response elements, error code, identity-provider session, device identity, upstream domain-controller indicator context, source-path context, identity-linkage status, and change-control context.

·        Validate backend support for identity-to-AWS linkage, upstream domain-controller correlation, source-path validation, CloudTrail request-parameter parsing, AWS account enrichment, privileged-role enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when IAM or security-control changes occur immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed IAM changes, policy changes, role changes, logging changes, monitoring changes, encryption changes, or security-control modifications after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, CloudTrail continuity, or incident-response evidence supports delayed linkage.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, CloudTrail field availability, AWS account inventory, privileged-role inventory, change-control validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to AWS IAM and security-control modification after upstream domain-controller compromise indicators rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes initial access method, API sequence, role path, access-key usage, source infrastructure, or cloud persistence method.

·        The score is supported by the durability of IAM changes, policy changes, role changes, trust-policy modification, access-key creation, logging modification, monitoring-control changes, and security-control weakening after suspicious identity-compromise context.

·        The score is constrained by weak domain-to-AWS linkage, identity federation complexity, legitimate cloud administration, CI/CD automation, emergency access workflows, incomplete CloudTrail coverage, and target-SIEM translation quality.

·        The rule is durable as AWS persistence, privilege-escalation, and defense-evasion coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, or AWS compromise.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on CloudTrail coverage, IAM telemetry, AWS account inventory, privileged-role inventory, identity-provider logs, upstream domain-controller evidence, source enrichment, change-control records, and SIEM correlation quality.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security engineers, vendors, or incident responders commonly make IAM or security-control changes after privileged identity activity.

·        Operational confidence is reduced where assumed-role naming, identity federation, source IP transformation, cloud session reuse, token reuse, incomplete request-parameter parsing, or weak change-control integration obscures context.

·        Full-telemetry confidence improves when AWS modification events are enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, identity-provider context, MFA logs, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious AWS IAM or security-control modification linked to upstream domain-controller compromise indicators, not Netlogon exploitation or AWS compromise by itself.

·        CloudTrail may not provide enough device, source-path, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, DevOps workflows, CI/CD maintenance, security engineering, emergency access, vendor support, and incident response can produce similar IAM or security-control modifications.

·        The rule may miss abuse that uses existing privileges without modifying IAM or security controls, occurs from a different device, uses a pre-existing cloud session, or happens outside the correlation window.

·        AWS activity should not be attributed to Netlogon-linked compromise without upstream domain-controller evidence, identity linkage, source-path linkage, endpoint evidence, change-control review, or incident-response validation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS IAM and security-control modification correlation pattern requiring target-SIEM translation validation, CloudTrail field validation, IAM action validation, security-control action validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

CloudTrailEvent AS AwsIamOrSecurityModification

WHERE AwsIamOrSecurityModification.eventName IN ANY (
"CreateAccessKey",
"CreateUser",
"CreateLoginProfile",
"CreateRole",
"UpdateAssumeRolePolicy",
"AttachUserPolicy",
"AttachRolePolicy",
"PutUserPolicy",
"PutRolePolicy",
"CreatePolicy",
"CreatePolicyVersion",
"SetDefaultPolicyVersion",
"AddUserToGroup",
"PassRole",
"StopLogging",
"DeleteTrail",
"UpdateTrail",
"PutEventSelectors",
"DeleteDetector",
"UpdateDetector",
"BatchDisableStandards",
"DisableSecurityHub",
"PutBucketPolicy",
"PutKeyPolicy",
"ScheduleKeyDeletion"
)

AND AwsIamOrSecurityModification.recipientAccountId IN ASSET_GROUP (
"Production AWS Accounts",
"Security Tooling Accounts",
"Identity Management Accounts",
"Backup Accounts",
"Developer Platform Accounts",
"Shared Services Accounts",
"Sensitive Data Accounts"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_AWS_MODIFICATION_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(AwsIamOrSecurityModification.userIdentity)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
AwsIamOrSecurityModification.sourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR AwsIamOrSecurityModification.User IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR AwsIamOrSecurityModification.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR AwsIamOrSecurityModification.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN AwsIamOrSecurityModification.ActivityPattern IN ANY (
"privileged_role_modified",
"access_key_created",
"trust_policy_modified",
"policy_version_changed",
"logging_control_modified",
"monitoring_control_modified",
"security_control_disabled",
"encryption_control_modified",
"cross_account_trust_modified",
"activity_outside_expected_role"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_emergency_access",
"approved_security_engineering",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Rule

Netlogon-Linked AWS Data, Secrets, or Workload Access After Domain-Controller Compromise Indicators

Rule Format

AWS data and workload access correlation rule suitable for CloudTrail data events, S3 data events, KMS events, Secrets Manager events, Systems Manager events, EC2 events, Lambda events, RDS events, EKS events, VPC Flow Logs, Route 53 Resolver logs, GuardDuty findings, AWS Managed Microsoft AD logs where present, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, sensitive-asset inventory, and SIEM correlation after AWS data-event validation, workload validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect sensitive AWS data, secrets, key-management, workload, or remote-management access after upstream domain-controller compromise indicators.

·        Identify downstream cloud exposure where domain-controller compromise exposure may lead to secret retrieval, data access, workload discovery, remote command execution, snapshot access, backup access, or cloud-hosted system interaction.

·        Prioritize activity involving Secrets Manager, KMS decrypt operations, S3 data access, Systems Manager session or command activity, EC2 instance interaction, Lambda function access, RDS snapshot or backup access, EKS activity, or sensitive workload access inconsistent with the user’s normal role.

·        Preserve separation between suspicious AWS data or workload access and confirmed compromise by requiring upstream domain-controller evidence, identity linkage, source-path evidence, endpoint evidence, CloudTrail evidence, sensitive-asset context, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, AWS compromise, data theft, secret theft, workload compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify AWS data, secrets, key-management, workload, or remote-management events after upstream domain-controller compromise indicators.

·        Correlate AWS data or workload access with upstream activity involving suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, abnormal source-to-domain-controller paths, sensitive Active Directory object modification, privileged group changes, domain trust changes, replication-permission changes, machine-account authentication anomalies, privileged authentication anomalies, or endpoint credential-access behavior.

·        Prioritize GetSecretValue, Decrypt, GetObject, ListBuckets, ListObjects, StartSession, SendCommand, CreateSnapshot, CopySnapshot, DescribeInstances, GetFunction, ListFunctions, DescribeDBSnapshots, RestoreDBInstanceFromDBSnapshot, EKS cluster access, and other locally sensitive data or workload operations.

·        Increase confidence when access targets sensitive buckets, secrets, KMS keys, production instances, backup data, database snapshots, administrative Systems Manager paths, EKS clusters, or developer-platform workloads.

·        Increase confidence when activity is rare for the user, rare for the role, outside normal access windows, uses unusual user agents, occurs from an unusual source path, follows upstream domain-controller compromise indicators, or lacks approved change-control context.

·        Increase confidence when GuardDuty, Security Hub, endpoint telemetry, DNS telemetry, proxy telemetry, or VPC Flow Logs show supporting signs of unusual cloud access, data movement, command execution, or suspicious external communication.

·        Reduce severity when access aligns with approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, incident response, security testing, vendor support, disaster recovery, or documented change-control activity.

·        Do not classify AWS data, secrets, or workload access as Netlogon-linked compromise without upstream domain-controller evidence, source-path linkage, identity linkage, sensitive-asset context, or incident-response validation.

·        Do not treat AWS data access, secret access, KMS use, Systems Manager activity, workload access, GuardDuty findings, Security Hub findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where available.

·        Amazon S3 data events where available.

·        AWS KMS events.

·        AWS Secrets Manager events.

·        AWS Systems Manager events.

·        Amazon EC2 events.

·        AWS Lambda events.

·        Amazon RDS events where available.

·        Amazon EKS events where available.

·        AWS Backup events where available.

·        AWS Managed Microsoft AD logs where present.

·        VPC Flow Logs where available.

·        Route 53 Resolver logs where available.

·        GuardDuty findings where available.

·        Security Hub findings where available.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        AWS account inventory.

·        Sensitive S3 bucket inventory.

·        Secrets Manager inventory.

·        KMS key inventory.

·        Production workload inventory.

·        Backup inventory.

·        Database and snapshot inventory.

·        EKS cluster inventory.

·        Systems Manager managed-instance inventory.

·        Approved cloud operations records.

·        Approved backup operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build sensitive AWS data groups covering sensitive S3 buckets, production data buckets, backup buckets, regulated-data buckets, Secrets Manager secrets, KMS keys, RDS snapshots, database backups, EBS snapshots, Lambda functions, EKS clusters, Systems Manager managed instances, and production workloads.

·        Build AWS sensitive action groups for GetSecretValue, Decrypt, GetObject, ListBuckets, ListObjects, StartSession, SendCommand, CreateSnapshot, CopySnapshot, DescribeInstances, GetFunction, ListFunctions, DescribeDBSnapshots, RestoreDBInstanceFromDBSnapshot, DescribeCluster, and locally sensitive workload-access events.

·        Build upstream domain-controller compromise context groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside approved baselines, sensitive Active Directory object changes, privileged group changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, and endpoint credential-access behavior.

·        Build source-path and identity linkage logic using user identity, role session name, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, access-key lineage, CloudTrail userIdentity fields, CloudTrail sourceIPAddress, AWS Managed Microsoft AD identity context where present, and incident timeline.

·        Build downstream-risk groups for rare user activity, rare role activity, first-seen sensitive service, first-seen data asset, unusual user agent, source-path mismatch, device mismatch, outside normal access window, sensitive data access, secret access, key-management activity, backup access, workload remote-management activity, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for AWS account ID, principal ID, role name, assumed-role session name, event source, event name, source IP, user agent, region, resource ARN, bucket name, secret name, key ID, instance ID, function name, database snapshot identifier, EKS cluster name, response result, upstream domain-controller indicator context, identity-provider session, device identity, source-path context, identity-linkage status, and change-control context.

·        Validate event-action normalization across CloudTrail management events, CloudTrail data events, S3 data events, KMS events, Secrets Manager events, Systems Manager events, EC2 events, Lambda events, RDS events, EKS events, VPC Flow Logs, Route 53 Resolver logs, GuardDuty, Security Hub, Windows Security logs, Directory Services events, domain-controller telemetry, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for identity-to-AWS linkage, upstream domain-controller correlation, identity-session correlation, source-path validation, resource-ARN parsing, sensitive-asset enrichment, cloud-account enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when AWS data, secrets, or workload access occurs immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed secrets access, KMS use, S3 data access, Systems Manager activity, workload access, backup access, or snapshot activity after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, CloudTrail continuity, sensitive-asset context, or incident-response evidence supports delayed linkage.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, CloudTrail data-event availability, sensitive-asset inventory, AWS account inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to AWS data, secrets, key-management, and workload access after upstream domain-controller compromise indicators rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes the AWS service target, data-access sequence, role path, source infrastructure, session timing, or workload interaction pattern.

·        The score is supported by the durability of secret retrieval, KMS decrypt operations, sensitive S3 access, Systems Manager activity, workload access, backup access, snapshot interaction, and sensitive cloud-resource access after suspicious identity-compromise context.

·        The score is constrained by weak domain-to-AWS linkage, incomplete CloudTrail data events, identity federation complexity, legitimate cloud operations, backup operations, CI/CD automation, assumed-role abstraction, token reuse, cloud session reuse, and target-SIEM translation quality.

·        The rule is durable as AWS data and workload exposure coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, AWS compromise, or data theft.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on CloudTrail management events, CloudTrail data events, sensitive-asset inventory, AWS account inventory, identity-provider logs, upstream domain-controller evidence, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where S3 data events, KMS events, Secrets Manager events, Systems Manager events, workload events, or VPC Flow Logs are incomplete or not retained.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, backup operators, vendors, security teams, or incident responders commonly access sensitive AWS data or workloads after privileged identity activity.

·        Full-telemetry confidence improves when AWS data and workload activity is enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, identity-provider context, MFA logs, DNS logs, proxy logs, VPC Flow Logs, sensitive-asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support exposure scoping and escalation rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious AWS data, secrets, or workload access linked to upstream domain-controller compromise indicators, not Netlogon exploitation or AWS compromise by itself.

·        CloudTrail data events may not be enabled for all buckets, objects, workloads, or sensitive resources.

·        AWS may not provide enough device, source-path, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, backup operations, DevOps workflows, CI/CD jobs, incident response, vendor support, and security testing can produce similar behavior.

·        The rule may miss activity that uses existing cloud sessions, reused tokens, expected automation roles, unmanaged identities, different source paths, or actions outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS data, secrets, and workload access correlation pattern requiring target-SIEM translation validation, CloudTrail data-event validation, resource-field validation, sensitive-asset validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

CloudTrailEvent AS AwsSensitiveResourceAccess

WHERE AwsSensitiveResourceAccess.eventName IN ANY (
"GetSecretValue",
"Decrypt",
"GetObject",
"ListBuckets",
"ListObjects",
"StartSession",
"SendCommand",
"CreateSnapshot",
"CopySnapshot",
"DescribeInstances",
"GetFunction",
"ListFunctions",
"DescribeDBSnapshots",
"RestoreDBInstanceFromDBSnapshot",
"DescribeCluster"
)

AND AwsSensitiveResourceAccess.Resource IN ASSET_GROUP (
"Sensitive S3 Buckets",
"Production Data Buckets",
"Backup Buckets",
"Regulated Data Buckets",
"Secrets Manager Secrets",
"KMS Keys",
"RDS Snapshots",
"Database Backups",
"EBS Snapshots",
"Lambda Functions",
"EKS Clusters",
"Systems Manager Managed Instances",
"Production Workloads"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_AWS_SENSITIVE_ACCESS_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(AwsSensitiveResourceAccess.userIdentity)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
AwsSensitiveResourceAccess.sourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR AwsSensitiveResourceAccess.User IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR AwsSensitiveResourceAccess.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR AwsSensitiveResourceAccess.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN AwsSensitiveResourceAccess.ActivityPattern IN ANY (
"rare_user_activity",
"rare_role_activity",
"first_seen_sensitive_service",
"first_seen_data_asset",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"sensitive_data_access",
"secret_access",
"key_management_activity",
"backup_access",
"workload_remote_management_activity",
"activity_outside_expected_role"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_backup_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_emergency_access",
"approved_change_control"
)

Azure

Detection Viability Assessment

Azure has three rules for this EXP report.

·        Azure is viable for detecting downstream identity-plane, cloud-control-plane, resource-access, key-vault, workload, and administrative activity that may follow Windows Netlogon remote code execution, domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, hybrid identity abuse, or unauthorized use of an identity path linked to domain-controller compromise indicators.

·        Azure is strongest where Microsoft Entra ID sign-in logs, Entra ID audit logs, service-principal logs, managed-identity activity, Azure Activity logs, Azure Resource Manager events, Microsoft Defender for Cloud alerts, Microsoft Defender for Identity alerts, Microsoft Defender for Endpoint telemetry, Azure Key Vault logs, Storage logs, Azure Monitor logs, Microsoft Sentinel correlation, identity-provider telemetry, MFA context, Windows Security telemetry, Active Directory telemetry, endpoint telemetry, source enrichment, tenant inventory, subscription inventory, and SIEM correlation can be combined.

·        Azure can identify suspicious post-domain-controller-compromise cloud behavior involving privileged role use, Azure portal access, Entra ID administrative activity, Azure Resource Manager operations, role assignment, application or service-principal changes, conditional-access changes, Key Vault access, storage access, workload interaction, and activity inconsistent with the user’s normal cloud role.

·        Azure is not a standalone source for confirming Netlogon exploitation, MS-NRPC exploitation, domain-controller compromise, Active Directory takeover, Kerberos abuse, NTLM abuse, endpoint compromise, credential theft, token theft, cloud compromise, SaaS compromise, or actor attribution.

·        Azure detections must be correlated with upstream Windows Security logs, Directory Services events, domain-controller telemetry, NDR evidence, EDR evidence, authentication telemetry, Defender for Identity evidence, Microsoft Sentinel correlation, hybrid identity evidence, source-path evidence, change-control records, and incident-response findings before classifying activity as probable Netlogon-linked compromise.

·        Each Azure rule requires upstream Windows, Active Directory, endpoint, network, authentication, SIEM, Defender for Identity, Microsoft Sentinel, hybrid identity, or incident-response evidence before making a Netlogon-linked escalation claim.

·        Azure rules should not generate high-confidence alerting from cloud activity alone, role assignment alone, Azure portal access alone, Entra ID sign-in novelty alone, Key Vault access alone, storage access alone, Defender for Cloud alerting alone, Defender for Identity alerting alone, or source-IP novelty alone without upstream domain-controller compromise indicators or validated identity-path linkage.

Rule

Netlogon-Linked Azure Portal, Entra ID, or Resource Manager Activity From Domain-Controller Compromise Indicators

Rule Format

Azure cloud-control-plane and identity-plane correlation rule suitable for Microsoft Entra ID sign-in logs, Entra ID audit logs, Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Defender for Identity alerts, Defender for Endpoint telemetry, Azure Monitor logs, Microsoft Sentinel correlation, identity-provider telemetry, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, privileged-role inventory, tenant inventory, subscription inventory, and SIEM correlation after Azure field validation, identity-to-Azure linkage validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect Azure portal, Microsoft Entra ID, Azure Resource Manager, or administrative API activity that occurs after upstream Windows Netlogon or domain-controller compromise indicators and can be linked to the same user, device, source path, identity-provider session, authentication session, privileged role, domain identity, hybrid identity context, or incident timeline.

·        Identify possible downstream Azure exposure following domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, hybrid identity abuse, or unauthorized use of an identity path tied to a suspected compromised domain environment.

·        Prioritize activity involving privileged Azure roles, administrative portal access, Azure Resource Manager operations, first-seen subscriptions, first-seen resource groups, first-seen services, unusual source paths, unusual user agents, and access inconsistent with the user’s normal Azure role.

·        Preserve separation between suspicious Azure activity and confirmed compromise by requiring supporting Windows, Active Directory, endpoint, network, cloud, credential-access, token-access, change-control, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, Azure compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify Azure portal access, Entra ID sign-in activity, Azure Resource Manager activity, administrative API activity, privileged role use, service-principal activity, managed-identity activity, or Azure Activity events associated with a user, role, service principal, managed identity, federated identity, or identity path that can be linked to upstream domain-controller compromise indicators.

·        Prioritize Azure activity after upstream evidence involving suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, abnormal source-to-domain-controller paths, sensitive Active Directory object modification, privileged group changes, domain trust changes, replication-permission changes, machine-account authentication anomalies, privileged authentication anomalies, Defender for Identity alerts, or endpoint credential-access behavior.

·        Detect Azure activity involving privileged role use, administrative operations, Azure portal access, Resource Manager activity, first-seen subscription use, first-seen resource group use, first-seen service use, unusual source path, unusual user agent, access outside normal windows, activity outside expected role, or access to sensitive tenants, subscriptions, or resource groups.

·        Increase confidence when Azure activity shares the same user, device, identity-provider session, source IP, authentication session, privileged role, hybrid identity context, Entra ID session context, Defender identity context, or incident timeline as upstream domain-controller compromise indicators.

·        Increase confidence when Azure activity involves Microsoft Entra ID, Azure Resource Manager, subscriptions, management groups, Key Vault, Storage, virtual machines, network security groups, Azure Firewall, Azure Kubernetes Service, Azure SQL, Backup, Recovery Services, Defender for Cloud, Microsoft Sentinel, or other sensitive services not normally used by the account.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, Azure CLI use, PowerShell cloud-administration activity, unusual session creation, suspicious OAuth consent, suspicious service-principal activity, or post-domain-controller-compromise administrative behavior.

·        Reduce severity when Azure activity aligns with approved cloud operations, administrator workflows, DevOps workflows, CI/CD maintenance, security testing, incident response, emergency access, vendor support, disaster recovery, or documented change-control activity.

·        Do not attribute Azure activity to Netlogon-linked compromise without upstream domain-controller evidence, identity linkage, source-path linkage, device linkage, hybrid identity context, change-control review, or incident-response validation.

·        Do not treat Azure portal activity, Entra ID sign-in novelty, Resource Manager activity, role use, Defender for Cloud findings, Defender for Identity findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID audit logs.

·        Microsoft Entra ID risk events where available.

·        Microsoft Entra ID conditional-access logs where available.

·        Microsoft Entra ID MFA context.

·        Service-principal sign-in logs where available.

·        Managed-identity activity where available.

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Azure Monitor logs where available.

·        Microsoft Defender for Cloud alerts where available.

·        Microsoft Defender for Identity alerts where available.

·        Microsoft Defender for Endpoint telemetry where available.

·        Microsoft Sentinel logs where available.

·        Azure subscription inventory.

·        Azure tenant inventory.

·        Management group inventory where available.

·        Privileged role inventory.

·        Service-principal inventory.

·        Managed-identity inventory.

·        Azure portal access context.

·        User identity.

·        Device identity.

·        Source IP.

·        User agent.

·        Application ID.

·        Resource ID.

·        Subscription ID.

·        Tenant ID.

·        Operation name.

·        Result.

·        Timestamp.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Source IP, ASN, geography, hosting-provider, and first-seen source enrichment.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build upstream domain-controller indicator groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside domain-controller access baselines, sensitive Active Directory object changes, privileged group changes, domain trust changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, Defender for Identity alerts, and endpoint credential-access behavior.

·        Build Azure identity groups covering users, privileged users, administrators, service principals, managed identities, break-glass accounts, automation identities, CI/CD identities, externally trusted identities, guest users, third-party identities, and hybrid identities linked to Active Directory.

·        Build Azure sensitive service groups covering Microsoft Entra ID, Azure Resource Manager, subscriptions, management groups, Key Vault, Storage, virtual machines, network security groups, Azure Firewall, Azure Kubernetes Service, Azure SQL, Backup, Recovery Services vaults, Defender for Cloud, Microsoft Sentinel, and other locally sensitive services.

·        Build Azure high-risk action groups for privileged role use, owner or contributor activity, Azure portal administration, service-principal activity, managed-identity activity, resource creation, resource deletion, resource read activity against sensitive scopes, Key Vault access, Storage access, virtual machine command execution, and security-control interaction.

·        Build linkage logic using user identity, device identity, identity-provider session, source IP, user agent, authentication session, domain identity, Entra ID session context, Defender identity context, tenant ID, subscription ID, application ID, resource ID, and incident timeline.

·        Build Azure anomaly groups for first-seen subscription, first-seen resource group, first-seen service, rare operation, unusual user agent, source-path mismatch, device mismatch, activity outside normal windows, activity outside expected role, sensitive tenant access, and cross-tenant or cross-subscription activity.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for tenant ID, subscription ID, resource ID, user identity, device identity, service principal, managed identity, source IP, user agent, operation name, result, application ID, identity-provider session, Entra ID session context, Defender identity context, upstream domain-controller indicator status, downstream-risk pattern, and change-control context.

·        Validate event-action normalization across Entra ID sign-in logs, Entra ID audit logs, service-principal logs, managed-identity activity, Azure Activity logs, Azure Resource Manager events, Defender for Cloud, Defender for Identity, Defender for Endpoint, Azure Monitor, Microsoft Sentinel, identity-provider logs, MFA logs, Windows Security logs, Directory Services events, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for identity-to-Azure linkage, upstream domain-controller correlation, identity-session correlation, source-path validation, device correlation, Azure Activity enrichment, tenant enrichment, subscription enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when Azure portal, Entra ID, or Resource Manager activity occurs immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed role use, administrative activity, Key Vault access, Storage access, Resource Manager operations, or security-control interaction after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, Azure Activity continuity, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, Azure field availability, tenant inventory, subscription inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to domain-controller-linked Azure control-plane and identity-plane activity rather than static exploit strings, CVE identifiers, source IPs, user-agent values, domains, or isolated Azure anomalies.

·        The rule remains useful if an adversary changes Azure service target, API sequence, role path, source infrastructure, session timing, token use pattern, or post-compromise cloud activity.

·        The score is supported by the durability of upstream identity-path linkage, privileged role use, administrative operation, first-seen service or subscription use, source-path mismatch, and Azure behavior outside normal account baselines.

·        The score is constrained by weak domain-to-Azure linkage, identity federation complexity, NAT, cloud session reuse, token reuse, service-principal abstraction, incomplete Azure logging, and target-SIEM translation quality.

·        The rule is durable as downstream Azure exposure coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, or Azure compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable upstream domain-controller indicator mapping, Entra ID sign-in logs, Entra ID audit logs, Azure Activity logs, Defender for Identity alerts, identity-provider logs, MFA logs, tenant inventory, subscription inventory, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where NAT, identity federation, cloud session reuse, token reuse, service-principal naming, inconsistent source IPs, or missing device identifiers make domain-to-Azure linkage uncertain.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders commonly perform Azure administrative actions after privileged domain activity.

·        Full-telemetry confidence improves when Azure events are enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, Defender for Identity alerts, identity-provider context, MFA logs, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious Azure identity-plane or control-plane activity linked to upstream domain-controller compromise indicators, not Netlogon exploitation or Azure compromise by itself.

·        Azure may not preserve enough source-path, device, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Azure portal, Entra ID, and Azure Activity events may be legitimate for cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders.

·        Domain-to-Azure linkage may be weak where NAT, cloud session reuse, token reuse, identity federation, service-principal abstraction, or source IP transformation obscures path attribution.

·        The rule may miss Azure abuse that occurs from a different device, different source path, reused token, pre-existing cloud session, expected automation identity, or outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure identity-plane and control-plane correlation pattern requiring target-SIEM translation validation, Entra ID sign-in validation, Entra ID audit-field validation, Azure Activity field validation, Resource Manager operation validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, tenant and subscription validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

AzureActivityOrIdentityEvent AS AzureControlPlaneActivity

WHERE AzureControlPlaneActivity.OperationName IN ANY (
"UserLoggedIn",
"InteractiveUserSignIn",
"ServicePrincipalSignIn",
"ManagedIdentitySignIn",
"AzurePortalAccess",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Resources/subscriptions/resourceGroups/resources/read",
"Microsoft.Resources/deployments/read",
"Microsoft.Authorization/roleAssignments/read",
"Microsoft.Authorization/roleDefinitions/read",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.KeyVault/vaults/read",
"Microsoft.Storage/storageAccounts/read",
"Microsoft.ContainerService/managedClusters/read"
)

AND AzureControlPlaneActivity.IdentityType IN ANY (
"User",
"ServicePrincipal",
"ManagedIdentity",
"FederatedIdentity"
)

AND AzureControlPlaneActivity.SubscriptionId IN ASSET_GROUP (
"Sensitive Azure Subscriptions",
"Production Azure Subscriptions",
"Security Tooling Subscriptions",
"Identity Management Subscriptions",
"Backup Subscriptions",
"Developer Platform Subscriptions"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_AZURE_CONTROL_PLANE_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(AzureControlPlaneActivity.User)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
AzureControlPlaneActivity.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR AzureControlPlaneActivity.User IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR AzureControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR AzureControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN AzureControlPlaneActivity.ActivityPattern IN ANY (
"first_seen_subscription",
"first_seen_resource_group",
"first_seen_service",
"rare_operation",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role",
"sensitive_tenant_access",
"cross_subscription_activity"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_break_glass_use",
"approved_change_control"
)

Rule

Netlogon-Linked Azure Identity, Role, or Security-Control Modification

Rule Format

Azure identity, role, and security-control correlation rule suitable for Entra ID audit logs, Entra ID sign-in logs, Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Defender for Identity alerts, Azure Policy events, Key Vault logs, Storage logs, identity-provider telemetry, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, privileged-role inventory, tenant inventory, subscription inventory, and SIEM correlation after Azure identity-field validation, privileged-action validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect Azure identity, role, service-principal, application, conditional-access, policy, logging, monitoring, or security-control modifications after upstream domain-controller compromise indicators.

·        Identify potential downstream cloud persistence, privilege escalation, defense evasion, access expansion, or security-control weakening following domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, hybrid identity abuse, or unauthorized use of a domain-linked identity path.

·        Prioritize changes involving privileged role assignments, service-principal credentials, application credentials, app ownership, conditional-access policies, authentication methods, security defaults, logging controls, monitoring controls, policy assignments, network security groups, Key Vault permissions, and storage access controls.

·        Preserve separation between suspicious Azure modification and confirmed compromise by requiring upstream domain-controller evidence, identity linkage, source-path evidence, endpoint evidence, Azure audit evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, Azure compromise, credential theft, token theft, persistence, privilege escalation, or actor attribution without supporting evidence.

Detection Logic

·        Identify Entra ID, Azure Activity, Azure Resource Manager, Azure Policy, Defender for Cloud, Key Vault, Storage, or security-control modification events in Azure telemetry.

·        Correlate modification events with upstream domain-controller compromise context involving suspicious Netlogon-adjacent activity, source novelty, abnormal source-to-domain-controller paths, privileged account use, machine-account anomalies, sensitive Active Directory object changes, suspicious authentication behavior, Defender for Identity alerts, endpoint credential-access behavior, or suspicious internal follow-on activity.

·        Prioritize identity and role activity involving role assignment, group membership change, privileged role activation, app owner addition, application update, service-principal creation, service-principal credential creation, application credential creation, authentication-method change, conditional-access change, or privileged access configuration change.

·        Prioritize security-control activity involving policy assignment changes, diagnostic setting changes, log profile changes, Defender for Cloud changes, security alert suppression, network security group changes, Key Vault access-policy changes, storage access changes, or changes that reduce visibility, encryption, monitoring, alerting, or access control.

·        Increase confidence when changes affect production subscriptions, identity-management tenants, security tooling subscriptions, backup subscriptions, developer-platform subscriptions, privileged roles, sensitive applications, cross-tenant trust paths, Key Vaults, storage accounts, or sensitive workloads.

·        Increase confidence when activity is rare for the user, rare for the tenant, outside normal access windows, uses unusual user agents, follows upstream domain-controller compromise indicators, or lacks approved change-control context.

·        Reduce severity when changes align with approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, incident response, vendor support, security testing, disaster recovery, or documented change-control activity.

·        Do not classify Azure identity, role, or security-control modification as Netlogon-linked compromise without upstream domain-controller evidence, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

Required Telemetry

·        Microsoft Entra ID audit logs.

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID risk events where available.

·        Microsoft Entra ID conditional-access logs where available.

·        Microsoft Entra ID authentication-method logs where available.

·        Service-principal sign-in logs where available.

·        Managed-identity activity where available.

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Azure Policy events where available.

·        Defender for Cloud alerts where available.

·        Defender for Identity alerts where available.

·        Defender for Endpoint telemetry where available.

·        Azure Monitor logs where available.

·        Azure diagnostic setting logs where available.

·        Key Vault logs where available.

·        Storage account logs where available.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Tenant inventory.

·        Subscription inventory.

·        Privileged role inventory.

·        Service-principal inventory.

·        Application registration inventory.

·        Managed-identity inventory.

·        Cross-tenant trust inventory.

·        Security tooling inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved security engineering records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build Azure identity modification groups covering role assignment, role activation, group membership changes, privileged role changes, app owner additions, application updates, service-principal creation, service-principal credential additions, app credential additions, authentication-method changes, conditional-access changes, and privileged access configuration changes.

·        Build Azure security-control modification groups covering policy assignment changes, diagnostic setting changes, log profile changes, Defender for Cloud changes, alert suppression changes, network security group changes, Key Vault permission changes, storage access changes, monitoring changes, logging changes, encryption changes, and access-control changes.

·        Build sensitive Azure tenant and subscription groups covering production subscriptions, identity-management tenants, security tooling subscriptions, backup subscriptions, developer-platform subscriptions, shared-services subscriptions, and subscriptions containing sensitive workloads or sensitive data.

·        Build upstream domain-controller compromise context groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside approved baselines, sensitive Active Directory object changes, privileged group changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, Defender for Identity alerts, and endpoint credential-access behavior.

·        Build linkage logic using user identity, service-principal identity, managed identity, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, tenant ID, subscription ID, resource ID, Azure Activity fields, Entra ID audit fields, Defender identity context, and incident timeline.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for tenant ID, subscription ID, resource ID, user identity, service principal, managed identity, role name, app ID, source IP, user agent, operation name, result, request parameters, modified properties, identity-provider session, device identity, upstream domain-controller indicator context, source-path context, identity-linkage status, and change-control context.

·        Validate event-action normalization across Entra ID audit logs, Entra ID sign-in logs, Entra ID authentication-method logs, service-principal logs, managed-identity activity, Azure Activity logs, Azure Resource Manager events, Azure Policy, Defender for Cloud, Defender for Identity, Defender for Endpoint, Azure Monitor, Key Vault, Storage, Windows Security logs, Directory Services events, domain-controller telemetry, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for identity-to-Azure linkage, upstream domain-controller correlation, source-path validation, Azure audit-field parsing, tenant enrichment, subscription enrichment, privileged-role enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when identity, role, or security-control changes occur immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed identity changes, role changes, policy changes, logging changes, monitoring changes, encryption changes, or security-control modifications after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, Azure Activity continuity, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, Azure field availability, tenant inventory, subscription inventory, privileged-role inventory, change-control validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to Azure identity, role, and security-control modification after upstream domain-controller compromise indicators rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes initial access method, API sequence, role path, app credential usage, source infrastructure, or cloud persistence method.

·        The score is supported by the durability of role assignments, privileged role changes, service-principal credential changes, app credential changes, conditional-access changes, policy changes, diagnostic-setting changes, network security group changes, and security-control weakening after suspicious identity-compromise context.

·        The score is constrained by weak domain-to-Azure linkage, identity federation complexity, legitimate cloud administration, CI/CD automation, emergency access workflows, incomplete Azure logging, service-principal abstraction, and target-SIEM translation quality.

·        The rule is durable as Azure persistence, privilege-escalation, and defense-evasion coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, or Azure compromise.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Entra ID audit coverage, Azure Activity coverage, tenant inventory, subscription inventory, privileged-role inventory, identity-provider logs, upstream domain-controller evidence, source enrichment, change-control records, and SIEM correlation quality.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security engineers, vendors, or incident responders commonly make identity, role, or security-control changes after privileged identity activity.

·        Operational confidence is reduced where service-principal naming, identity federation, source IP transformation, cloud session reuse, token reuse, incomplete modified-property parsing, or weak change-control integration obscures context.

·        Full-telemetry confidence improves when Azure modification events are enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, Defender for Identity alerts, identity-provider context, MFA logs, DNS logs, proxy logs, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious Azure identity, role, or security-control modification linked to upstream domain-controller compromise indicators, not Netlogon exploitation or Azure compromise by itself.

·        Azure logs may not provide enough device, source-path, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, DevOps workflows, CI/CD maintenance, security engineering, emergency access, vendor support, and incident response can produce similar identity, role, or security-control modifications.

·        The rule may miss abuse that uses existing privileges without modifying identity or security controls, occurs from a different device, uses a pre-existing cloud session, or happens outside the correlation window.

·        Azure activity should not be attributed to Netlogon-linked compromise without upstream domain-controller evidence, identity linkage, source-path linkage, endpoint evidence, change-control review, or incident-response validation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure identity, role, and security-control modification correlation pattern requiring target-SIEM translation validation, Entra ID audit-field validation, Azure Activity field validation, privileged-action validation, security-control action validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

AzureActivityOrAuditEvent AS AzureIdentityOrSecurityModification

WHERE AzureIdentityOrSecurityModification.OperationName IN ANY (
"RoleAssignmentCreated",
"RoleAssignmentUpdated",
"AddMemberToRole",
"AddMemberToGroup",
"AddOwnerToApplication",
"AddPasswordCredential",
"AddKeyCredential",
"CreateServicePrincipal",
"UpdateServicePrincipal",
"UpdateApplication",
"UpdateConditionalAccessPolicy",
"UpdateAuthenticationMethodsPolicy",
"DisableSecurityDefaults",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/policyAssignments/write",
"Microsoft.Insights/diagnosticSettings/write",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.KeyVault/vaults/accessPolicies/write",
"Microsoft.Storage/storageAccounts/write"
)

AND AzureIdentityOrSecurityModification.SubscriptionId IN ASSET_GROUP (
"Production Azure Subscriptions",
"Security Tooling Subscriptions",
"Identity Management Subscriptions",
"Backup Subscriptions",
"Developer Platform Subscriptions",
"Shared Services Subscriptions",
"Sensitive Data Subscriptions"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_AZURE_MODIFICATION_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(AzureIdentityOrSecurityModification.User)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
AzureIdentityOrSecurityModification.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR AzureIdentityOrSecurityModification.User IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR AzureIdentityOrSecurityModification.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR AzureIdentityOrSecurityModification.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN AzureIdentityOrSecurityModification.ActivityPattern IN ANY (
"privileged_role_modified",
"service_principal_credential_added",
"application_credential_added",
"conditional_access_modified",
"authentication_method_modified",
"logging_control_modified",
"monitoring_control_modified",
"security_control_disabled",
"network_security_group_modified",
"key_vault_access_modified",
"cross_tenant_trust_modified",
"activity_outside_expected_role"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_emergency_access",
"approved_security_engineering",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Rule

Netlogon-Linked Azure Data, Secrets, or Workload Access After Domain-Controller Compromise Indicators

Rule Format

Azure data, secrets, and workload access correlation rule suitable for Key Vault logs, Storage logs, Azure Activity logs, Azure Resource Manager events, Azure SQL logs, virtual machine activity, AKS activity, Backup and Recovery Services logs, Defender for Cloud alerts, Defender for Identity alerts, Azure Monitor logs, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, sensitive-asset inventory, and SIEM correlation after Azure data-event validation, workload validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect sensitive Azure data, secrets, key-management, workload, or remote-management access after upstream domain-controller compromise indicators.

·        Identify downstream cloud exposure where domain-controller compromise exposure may lead to secret retrieval, storage access, workload discovery, remote command execution, backup access, database access, Kubernetes access, or cloud-hosted system interaction.

·        Prioritize activity involving Key Vault secret retrieval, key operations, Storage account access, blob access, virtual machine run command, Azure SQL access, AKS activity, backup vault access, Recovery Services activity, or sensitive workload access inconsistent with the user’s normal role.

·        Preserve separation between suspicious Azure data or workload access and confirmed compromise by requiring upstream domain-controller evidence, identity linkage, source-path evidence, endpoint evidence, Azure audit evidence, sensitive-asset context, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, Azure compromise, data theft, secret theft, workload compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

·        Identify Azure data, secrets, key-management, workload, or remote-management events after upstream domain-controller compromise indicators.

·        Correlate Azure data or workload access with upstream activity involving suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, abnormal source-to-domain-controller paths, sensitive Active Directory object modification, privileged group changes, domain trust changes, replication-permission changes, machine-account authentication anomalies, privileged authentication anomalies, or endpoint credential-access behavior.

·        Prioritize Key Vault secret access, key access, Storage account key retrieval, blob access, virtual machine run command, snapshot access, backup access, Azure SQL administrative access, AKS cluster interaction, and other locally sensitive data or workload operations.

·        Increase confidence when access targets sensitive Key Vaults, storage accounts, production workloads, backup vaults, databases, AKS clusters, administrative virtual machines, developer-platform workloads, or sensitive resource groups.

·        Increase confidence when activity is rare for the user, rare for the role, outside normal access windows, uses unusual user agents, occurs from an unusual source path, follows upstream domain-controller compromise indicators, or lacks approved change-control context.

·        Increase confidence when Defender for Cloud, Defender for Identity, endpoint telemetry, DNS telemetry, proxy telemetry, Azure Monitor, or network telemetry shows supporting signs of unusual cloud access, data movement, command execution, or suspicious external communication.

·        Reduce severity when access aligns with approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, incident response, security testing, vendor support, disaster recovery, or documented change-control activity.

·        Do not classify Azure data, secrets, or workload access as Netlogon-linked compromise without upstream domain-controller evidence, source-path linkage, identity linkage, sensitive-asset context, or incident-response validation.

·        Do not treat Azure data access, Key Vault access, storage access, VM run command, workload access, Defender for Cloud findings, Defender for Identity findings, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Key Vault diagnostic logs.

·        Storage account logs.

·        Blob access logs where available.

·        Azure SQL logs where available.

·        Virtual machine activity where available.

·        Azure VM run command events.

·        AKS activity where available.

·        Backup logs where available.

·        Recovery Services vault logs where available.

·        Defender for Cloud alerts where available.

·        Defender for Identity alerts where available.

·        Azure Monitor logs where available.

·        Network telemetry where available.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Tenant inventory.

·        Subscription inventory.

·        Sensitive storage account inventory.

·        Sensitive Key Vault inventory.

·        Key inventory.

·        Secret inventory.

·        Production workload inventory.

·        Backup inventory.

·        Database inventory.

·        AKS cluster inventory.

·        Virtual machine inventory.

·        Approved cloud operations records.

·        Approved backup operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build sensitive Azure data groups covering sensitive storage accounts, production storage accounts, regulated-data containers, Key Vault secrets, Key Vault keys, production virtual machines, Azure SQL databases, backup vaults, Recovery Services vaults, AKS clusters, developer-platform workloads, and sensitive resource groups.

·        Build Azure sensitive action groups for Key Vault secret retrieval, Key Vault key operations, storage account key listing, blob access, virtual machine run command, snapshot access, backup access, database administrative access, AKS cluster interaction, and locally sensitive workload-access events.

·        Build upstream domain-controller compromise context groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside approved baselines, sensitive Active Directory object changes, privileged group changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, Defender for Identity alerts, and endpoint credential-access behavior.

·        Build source-path and identity linkage logic using user identity, service-principal identity, managed identity, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, tenant ID, subscription ID, resource ID, Azure Activity fields, Defender identity context, and incident timeline.

·        Build downstream-risk groups for rare user activity, rare role activity, first-seen sensitive service, first-seen data asset, unusual user agent, source-path mismatch, device mismatch, outside normal access window, sensitive data access, secret access, key-management activity, backup access, workload remote-management activity, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for tenant ID, subscription ID, resource ID, resource group, user identity, service principal, managed identity, source IP, user agent, operation name, result, Key Vault name, secret name, key name, storage account, container name, blob name, VM name, database name, AKS cluster name, response result, upstream domain-controller indicator context, identity-provider session, device identity, source-path context, identity-linkage status, and change-control context.

·        Validate event-action normalization across Azure Activity logs, Azure Resource Manager events, Key Vault logs, Storage logs, Blob logs, Azure SQL logs, VM activity, AKS activity, Backup logs, Recovery Services logs, Defender for Cloud, Defender for Identity, Azure Monitor, Windows Security logs, Directory Services events, domain-controller telemetry, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for identity-to-Azure linkage, upstream domain-controller correlation, identity-session correlation, source-path validation, resource-ID parsing, sensitive-asset enrichment, tenant enrichment, subscription enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when Azure data, secrets, or workload access occurs immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed secret access, key use, storage access, VM run command, workload access, backup access, or database activity after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, Azure Activity continuity, sensitive-asset context, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, Azure data-event availability, sensitive-asset inventory, tenant inventory, subscription inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to Azure data, secrets, key-management, and workload access after upstream domain-controller compromise indicators rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes the Azure service target, data-access sequence, role path, source infrastructure, session timing, or workload interaction pattern.

·        The score is supported by the durability of secret retrieval, key operations, sensitive storage access, virtual machine run command, workload access, backup access, database interaction, and sensitive cloud-resource access after suspicious identity-compromise context.

·        The score is constrained by weak domain-to-Azure linkage, incomplete data-access logging, identity federation complexity, legitimate cloud operations, backup operations, CI/CD automation, service-principal abstraction, token reuse, cloud session reuse, and target-SIEM translation quality.

·        The rule is durable as Azure data and workload exposure coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, Azure compromise, or data theft.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Azure Activity logs, Key Vault logs, Storage logs, sensitive-asset inventory, tenant inventory, subscription inventory, identity-provider logs, upstream domain-controller evidence, source enrichment, endpoint telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where Key Vault logs, Storage logs, Blob logs, Azure SQL logs, VM activity, AKS activity, Backup logs, Recovery Services logs, Defender for Cloud telemetry, or Defender for Identity telemetry are incomplete or not retained.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, backup operators, vendors, security teams, or incident responders commonly access sensitive Azure data or workloads after privileged identity activity.

·        Full-telemetry confidence improves when Azure data and workload activity is enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, Defender for Identity alerts, identity-provider context, MFA logs, DNS logs, proxy logs, network telemetry, sensitive-asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support exposure scoping and escalation rather than standalone compromise confirmation.

Limitations

·        This rule detects suspicious Azure data, secrets, or workload access linked to upstream domain-controller compromise indicators, not Netlogon exploitation or Azure compromise by itself.

·        Azure data and resource-access logs may not be enabled for all storage accounts, Key Vaults, workloads, databases, or sensitive resources.

·        Azure may not provide enough device, source-path, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, backup operations, DevOps workflows, CI/CD jobs, incident response, vendor support, and security testing can produce similar behavior.

·        The rule may miss activity that uses existing cloud sessions, reused tokens, expected automation identities, unmanaged identities, different source paths, or actions outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure data, secrets, and workload access correlation pattern requiring target-SIEM translation validation, Azure data-event validation, Key Vault logging validation, Storage logging validation, resource-field validation, sensitive-asset validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

AzureActivityOrResourceEvent AS AzureSensitiveResourceAccess

WHERE AzureSensitiveResourceAccess.OperationName IN ANY (
"Microsoft.KeyVault/vaults/secrets/read",
"Microsoft.KeyVault/vaults/keys/read",
"Microsoft.KeyVault/vaults/decrypt/action",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
"Microsoft.Compute/virtualMachines/runCommand/action",
"Microsoft.Compute/snapshots/read",
"Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems/read",
"Microsoft.Sql/servers/databases/read",
"Microsoft.ContainerService/managedClusters/listClusterUserCredential/action",
"Microsoft.ContainerService/managedClusters/read"
)

AND AzureSensitiveResourceAccess.ResourceId IN ASSET_GROUP (
"Sensitive Storage Accounts",
"Production Storage Accounts",
"Regulated Data Containers",
"Key Vault Secrets",
"Key Vault Keys",
"Production Virtual Machines",
"Azure SQL Databases",
"Backup Vaults",
"Recovery Services Vaults",
"AKS Clusters",
"Developer Platform Workloads",
"Sensitive Resource Groups"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_AZURE_SENSITIVE_ACCESS_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(AzureSensitiveResourceAccess.User)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
AzureSensitiveResourceAccess.SourceIPAddress IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR AzureSensitiveResourceAccess.User IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR AzureSensitiveResourceAccess.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR AzureSensitiveResourceAccess.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN AzureSensitiveResourceAccess.ActivityPattern IN ANY (
"rare_user_activity",
"rare_role_activity",
"first_seen_sensitive_service",
"first_seen_data_asset",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"sensitive_data_access",
"secret_access",
"key_management_activity",
"backup_access",
"workload_remote_management_activity",
"activity_outside_expected_role"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_backup_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_emergency_access",
"approved_change_control"
)

GCP

Detection Viability Assessment

GCP has three rules for this EXP report.

·        GCP is viable for detecting downstream cloud-control-plane, IAM, service-account, federation, security-control, data-access, secret-access, and workload-access activity that may follow Windows Netlogon remote code execution, domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, hybrid identity abuse, or unauthorized use of an identity path linked to domain-controller compromise indicators.

·        GCP is strongest where Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Workforce Identity Federation logs, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, Secret Manager logs, Cloud KMS logs, Cloud Storage logs, Compute Engine logs, GKE logs, BigQuery logs, Cloud SQL logs, Cloud Build logs, Chronicle correlation, identity-provider telemetry, Windows Security telemetry, Active Directory telemetry, endpoint telemetry, source enrichment, project inventory, organization inventory, and SIEM correlation can be combined.

·        GCP can identify suspicious post-domain-controller-compromise cloud behavior involving console access, API activity, IAM changes, service-account key creation, service-account impersonation, workload identity activity, federation activity, organization-policy modification, logging or monitoring changes, sensitive data access, secret retrieval, key-management activity, workload access, cross-project activity, and activity inconsistent with the user’s normal cloud role.

·        GCP is not a standalone source for confirming Netlogon exploitation, MS-NRPC exploitation, domain-controller compromise, Active Directory takeover, Kerberos abuse, NTLM abuse, endpoint compromise, credential theft, token theft, cloud compromise, SaaS compromise, or actor attribution.

·        GCP detections must be correlated with upstream Windows Security logs, Directory Services events, domain-controller telemetry, NDR evidence, EDR evidence, authentication telemetry, Chronicle or SIEM correlation, hybrid identity evidence, source-path evidence, change-control records, and incident-response findings before classifying activity as probable Netlogon-linked compromise.

·        Each GCP rule requires upstream Windows, Active Directory, endpoint, network, authentication, SIEM, Chronicle, hybrid identity, or incident-response evidence before making a Netlogon-linked escalation claim.

·        GCP rules should not generate high-confidence alerting from cloud activity alone, IAM change alone, service-account activity alone, console access alone, Cloud Audit novelty alone, Security Command Center findings alone, data access alone, secret access alone, or source-IP novelty alone without upstream domain-controller compromise indicators or validated identity-path linkage.

Rule

Netlogon-Linked GCP Console, IAM, or API Activity From Domain-Controller Compromise Indicators

Rule Format

GCP cloud-control-plane and identity-plane correlation rule suitable for Cloud Audit Logs, Admin Activity logs, IAM logs, service-account activity, Workforce Identity Federation logs, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, Chronicle correlation, identity-provider telemetry, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, privileged-role inventory, organization inventory, project inventory, and SIEM correlation after GCP field validation, identity-to-GCP linkage validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

Detect GCP console, IAM, service-account, federation, or administrative API activity that occurs after upstream Windows Netlogon or domain-controller compromise indicators and can be linked to the same user, device, source path, identity-provider session, authentication session, privileged role, service account, domain identity, hybrid identity context, or incident timeline.

·        Identify possible downstream GCP exposure following domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, hybrid identity abuse, or unauthorized use of an identity path tied to a suspected compromised domain environment.

·        Prioritize activity involving privileged GCP roles, administrative console access, Google Cloud API use, first-seen projects, first-seen services, first-seen regions, service-account impersonation, Workforce Identity Federation activity, unusual source paths, unusual user agents, and access inconsistent with the user’s normal GCP role.

·        Preserve separation between suspicious GCP activity and confirmed compromise by requiring supporting Windows, Active Directory, endpoint, network, cloud, credential-access, token-access, change-control, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, GCP compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

Identify GCP console access, IAM activity, service-account activity, API activity, Workforce Identity Federation activity, privileged role use, or Cloud Audit events associated with a user, service account, federated principal, role, workload identity, or identity path that can be linked to upstream domain-controller compromise indicators.

·        Prioritize GCP activity after upstream evidence involving suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, abnormal source-to-domain-controller paths, sensitive Active Directory object modification, privileged group changes, domain trust changes, replication-permission changes, machine-account authentication anomalies, privileged authentication anomalies, or endpoint credential-access behavior.

·        Detect GCP activity involving privileged role use, administrative operations, service-account impersonation, project enumeration, first-seen project use, first-seen service use, first-seen region use, unusual source path, unusual user agent, access outside normal windows, activity outside expected role, or access to sensitive organizations, folders, projects, or workloads.

·        Increase confidence when GCP activity shares the same user, device, identity-provider session, source IP, authentication session, privileged role, service-account lineage, Workforce Identity Federation context, hybrid identity context, Chronicle identity context, or incident timeline as upstream domain-controller compromise indicators.

·        Increase confidence when GCP activity involves IAM, service accounts, organization policies, Cloud Audit Logs, Security Command Center, Cloud KMS, Secret Manager, Cloud Storage, Compute Engine, GKE, BigQuery, Cloud SQL, Cloud Build, Artifact Registry, or other sensitive services not normally used by the account.

·        Increase confidence when endpoint or identity telemetry shows credential access, token access, browser credential-store access, gcloud CLI use, cloud SDK activity, PowerShell or shell-based cloud administration, unusual session creation, suspicious federation behavior, or post-domain-controller-compromise administrative behavior.

·        Reduce severity when GCP activity aligns with approved cloud operations, administrator workflows, DevOps workflows, CI/CD maintenance, security testing, incident response, emergency access, vendor support, disaster recovery, or documented change-control activity.

·        Do not attribute GCP activity to Netlogon-linked compromise without upstream domain-controller evidence, identity linkage, source-path linkage, device linkage, service-account lineage, federation context, change-control review, or incident-response validation.

·        Do not treat GCP console activity, IAM activity, service-account activity, API activity, Security Command Center findings, Cloud Audit anomalies, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

Google Cloud Audit Logs.

·        Admin Activity logs.

·        Data Access logs where available.

·        IAM activity.

·        Service-account activity.

·        Service-account impersonation events.

·        Service-account key events.

·        Workforce Identity Federation logs where available.

·        Cloud Identity logs where available.

·        Security Command Center findings where available.

·        VPC Flow Logs where available.

·        Cloud DNS logs where available.

·        Cloud Logging exports where available.

·        Chronicle logs where available.

·        GCP console access context.

·        Cloud Audit principal fields.

·        Cloud Audit caller IP fields.

·        Cloud Audit user agent fields.

·        Cloud Audit service name fields.

·        Cloud Audit method name fields.

·        Organization ID.

·        Folder ID.

·        Project ID.

·        Resource name.

·        Region or location.

·        Result status.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Source IP, ASN, geography, hosting-provider, and first-seen source enrichment.

·        GCP organization inventory.

·        Folder inventory.

·        Project inventory.

·        Privileged role inventory.

·        Service-account inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

Build upstream domain-controller indicator groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside domain-controller access baselines, sensitive Active Directory object changes, privileged group changes, domain trust changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, and endpoint credential-access behavior.

·        Build GCP identity groups covering users, privileged users, administrators, service accounts, workload identities, federated identities, Workforce Identity Federation principals, break-glass accounts, automation identities, CI/CD identities, externally trusted identities, guest users, third-party identities, and hybrid identities linked to Active Directory.

·        Build GCP sensitive service groups covering IAM, service accounts, organization policies, Cloud Audit Logs, Security Command Center, Cloud KMS, Secret Manager, Cloud Storage, Compute Engine, GKE, BigQuery, Cloud SQL, Cloud Build, Artifact Registry, and other locally sensitive services.

·        Build GCP high-risk action groups for privileged role use, organization or project administration, service-account impersonation, service-account key activity, IAM policy reads against sensitive scopes, project enumeration, resource reads against sensitive projects, Cloud Storage access, Secret Manager access, KMS use, Compute Engine activity, GKE activity, BigQuery activity, Cloud SQL activity, and security-control interaction.

·        Build linkage logic using user identity, service-account identity, federated identity, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, organization ID, folder ID, project ID, resource name, Cloud Audit principal fields, Chronicle identity context, and incident timeline.

·        Build GCP anomaly groups for first-seen project, first-seen folder, first-seen service, first-seen region, rare operation, unusual user agent, source-path mismatch, device mismatch, activity outside normal windows, activity outside expected role, sensitive organization access, and cross-project or cross-folder activity.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for organization ID, folder ID, project ID, resource name, principal email, principal subject, service account, caller IP, user agent, service name, method name, status, region, location, identity-provider session, Chronicle identity context, upstream domain-controller indicator status, downstream-risk pattern, and change-control context.

·        Validate event-action normalization across Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account logs, Workforce Identity Federation logs, Cloud Identity logs, Security Command Center, VPC Flow Logs, Cloud DNS logs, Chronicle, identity-provider logs, MFA logs, Windows Security logs, Directory Services events, endpoint telemetry, DNS logs, proxy logs, and SIEM telemetry.

·        Validate backend support for identity-to-GCP linkage, upstream domain-controller correlation, identity-session correlation, source-path validation, device correlation, Cloud Audit enrichment, organization enrichment, project enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when GCP console, IAM, or API activity occurs immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed role use, service-account activity, administrative activity, sensitive resource reads, cloud API activity, or security-control interaction after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, Cloud Audit continuity, source-infrastructure overlap, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, GCP field availability, organization inventory, project inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to domain-controller-linked GCP control-plane and identity-plane activity rather than static exploit strings, CVE identifiers, source IPs, user-agent values, domains, or isolated GCP anomalies.

·        The rule remains useful if an adversary changes GCP service target, API sequence, role path, service-account path, source infrastructure, session timing, token use pattern, or post-compromise cloud activity.

·        The score is supported by the durability of upstream identity-path linkage, privileged role use, service-account activity, administrative operation, first-seen project or service use, source-path mismatch, and GCP behavior outside normal account baselines.

·        The score is constrained by weak domain-to-GCP linkage, identity federation complexity, NAT, cloud session reuse, token reuse, service-account abstraction, incomplete Cloud Audit logging, and target-SIEM translation quality.

·        The rule is durable as downstream GCP exposure coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, or GCP compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on reliable upstream domain-controller indicator mapping, Cloud Audit Logs, IAM telemetry, service-account telemetry, Workforce Identity Federation logs, identity-provider logs, MFA logs, organization inventory, project inventory, source enrichment, endpoint telemetry, Chronicle or SIEM correlation quality, and incident-response context.

·        Operational confidence is reduced where NAT, identity federation, cloud session reuse, token reuse, service-account naming, inconsistent source IPs, or missing device identifiers make domain-to-GCP linkage uncertain.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders commonly perform GCP administrative actions after privileged domain activity.

·        Full-telemetry confidence improves when GCP events are enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, identity-provider context, MFA logs, DNS logs, proxy logs, Chronicle context, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support downstream triage and exposure scoping rather than standalone compromise confirmation.

Limitations

This rule detects suspicious GCP identity-plane or control-plane activity linked to upstream domain-controller compromise indicators, not Netlogon exploitation or GCP compromise by itself.

·        GCP may not preserve enough source-path, device, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        GCP console, IAM, service-account, and Cloud Audit events may be legitimate for cloud administrators, DevOps users, CI/CD systems, security teams, vendors, or incident responders.

·        Domain-to-GCP linkage may be weak where NAT, cloud session reuse, token reuse, identity federation, service-account abstraction, or source IP transformation obscures path attribution.

·        The rule may miss GCP abuse that occurs from a different device, different source path, reused token, pre-existing cloud session, expected automation identity, or outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP identity-plane and control-plane correlation pattern requiring target-SIEM translation validation, Cloud Audit log validation, IAM field validation, service-account field validation, Workforce Identity Federation validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, organization and project validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

GcpAuditOrIdentityEvent AS GcpControlPlaneActivity

WHERE GcpControlPlaneActivity.MethodName IN ANY (
"google.iam.admin.v1.GetIamPolicy",
"google.iam.admin.v1.ListServiceAccounts",
"google.iam.admin.v1.GetServiceAccount",
"google.iam.credentials.v1.GenerateAccessToken",
"google.iam.credentials.v1.GenerateIdToken",
"google.iam.credentials.v1.SignBlob",
"google.iam.credentials.v1.SignJwt",
"google.cloud.resourcemanager.v3.Projects.GetProject",
"google.cloud.resourcemanager.v3.Projects.ListProjects",
"google.cloud.resourcemanager.v3.Folders.GetFolder",
"google.cloud.resourcemanager.v3.Organizations.GetOrganization",
"google.cloud.compute.v1.Instances.Get",
"google.container.v1.ClusterManager.GetCluster",
"google.cloud.kms.v1.KeyManagementService.ListCryptoKeys",
"google.cloud.secretmanager.v1.SecretManagerService.ListSecrets",
"storage.buckets.get",
"bigquery.datasets.get"
)

AND GcpControlPlaneActivity.PrincipalType IN ANY (
"User",
"ServiceAccount",
"FederatedIdentity",
"WorkloadIdentity"
)

AND GcpControlPlaneActivity.ProjectId IN ASSET_GROUP (
"Sensitive GCP Projects",
"Production GCP Projects",
"Security Tooling Projects",
"Identity Management Projects",
"Backup Projects",
"Developer Platform Projects"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_GCP_CONTROL_PLANE_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(GcpControlPlaneActivity.Principal)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
GcpControlPlaneActivity.CallerIp IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR GcpControlPlaneActivity.Principal IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR GcpControlPlaneActivity.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR GcpControlPlaneActivity.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN GcpControlPlaneActivity.ActivityPattern IN ANY (
"first_seen_project",
"first_seen_folder",
"first_seen_service",
"first_seen_region",
"rare_operation",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"activity_outside_expected_role",
"sensitive_organization_access",
"cross_project_activity"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_break_glass_use",
"approved_change_control"
)

Rule

Netlogon-Linked GCP IAM, Service-Account, or Security-Control Modification

Rule Format

GCP IAM, service-account, organization-policy, logging, monitoring, and security-control correlation rule suitable for Cloud Audit Logs, Admin Activity logs, IAM activity, service-account activity, Security Command Center findings, Cloud Logging configuration events, organization-policy logs, VPC firewall logs, Cloud KMS logs, identity-provider telemetry, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, privileged-role inventory, organization inventory, project inventory, and SIEM correlation after GCP identity-field validation, privileged-action validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

Detect GCP IAM, service-account, organization-policy, logging, monitoring, firewall, key-management, storage-permission, or security-control modifications after upstream domain-controller compromise indicators.

·        Identify potential downstream cloud persistence, privilege escalation, defense evasion, access expansion, or security-control weakening following domain-controller compromise exposure, privileged identity misuse, credential theft, token theft, hybrid identity abuse, or unauthorized use of a domain-linked identity path.

·        Prioritize changes involving IAM allow policy, privileged role binding, service-account creation, service-account key creation, service-account impersonation permissions, organization policies, logging sinks, audit log configuration, firewall rules, KMS key policies, storage permissions, Security Command Center settings, and cross-project trust paths.

·        Preserve separation between suspicious GCP modification and confirmed compromise by requiring upstream domain-controller evidence, identity linkage, source-path evidence, endpoint evidence, Cloud Audit evidence, change-control review, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, GCP compromise, credential theft, token theft, persistence, privilege escalation, or actor attribution without supporting evidence.

Detection Logic

Identify IAM, service-account, organization-policy, logging, monitoring, firewall, KMS, storage-permission, or security-control modification events in GCP telemetry.

·        Correlate modification events with upstream domain-controller compromise context involving suspicious Netlogon-adjacent activity, source novelty, abnormal source-to-domain-controller paths, privileged account use, machine-account anomalies, sensitive Active Directory object changes, suspicious authentication behavior, endpoint credential-access behavior, or suspicious internal follow-on activity.

·        Prioritize identity and privilege activity involving SetIamPolicy, service-account creation, service-account key creation, service-account key upload, service-account impersonation grants, privileged role binding, custom role creation, custom role update, workload identity binding, Workforce Identity Federation provider modification, group membership change, or cross-project trust modification.

·        Prioritize security-control activity involving audit log configuration change, logging sink change, organization-policy change, firewall rule change, KMS IAM change, storage IAM change, Security Command Center setting change, monitoring change, or changes that reduce visibility, encryption, monitoring, alerting, or access control.

·        Increase confidence when changes affect production projects, identity-management projects, security tooling projects, backup projects, developer-platform projects, privileged roles, sensitive service accounts, cross-project trust paths, KMS keys, storage buckets, or sensitive workloads.

·        Increase confidence when activity is rare for the user, rare for the project, outside normal access windows, uses unusual user agents, follows upstream domain-controller compromise indicators, or lacks approved change-control context.

·        Reduce severity when changes align with approved cloud operations, DevOps workflows, CI/CD maintenance, emergency access, security engineering, incident response, vendor support, security testing, disaster recovery, or documented change-control activity.

·        Do not classify GCP IAM, service-account, or security-control modification as Netlogon-linked compromise without upstream domain-controller evidence, source-path linkage, identity linkage, device linkage, change-control review, or incident-response validation.

Required Telemetry

Google Cloud Audit Logs.

·        Admin Activity logs.

·        IAM activity.

·        Service-account activity.

·        Service-account key events.

·        Service-account impersonation events.

·        Workforce Identity Federation logs where available.

·        Cloud Identity logs where available.

·        Organization Policy logs where available.

·        Cloud Logging configuration events.

·        Security Command Center findings where available.

·        Cloud Monitoring configuration logs where available.

·        VPC firewall rule events where available.

·        Cloud KMS logs where available.

·        Cloud Storage IAM events where available.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Organization inventory.

·        Folder inventory.

·        Project inventory.

·        Privileged role inventory.

·        Custom role inventory.

·        Service-account inventory.

·        Cross-project trust inventory.

·        Security tooling inventory.

·        Sensitive workload inventory.

·        Approved cloud operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved emergency access records.

·        Approved security engineering records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

Build GCP IAM modification groups covering IAM policy set, role binding, custom role creation, custom role update, service-account creation, service-account key creation, service-account key upload, service-account impersonation grant, group membership changes, workload identity binding, Workforce Identity Federation provider changes, and privilege-expanding trust relationships.

·        Build GCP security-control modification groups covering organization-policy changes, audit log configuration changes, logging sink changes, monitoring changes, Security Command Center setting changes, firewall rule changes, KMS IAM changes, storage IAM changes, encryption changes, alerting-control changes, and access-control changes.

·        Build sensitive GCP organization and project groups covering production projects, identity-management projects, security tooling projects, backup projects, developer-platform projects, shared-services projects, and projects containing sensitive workloads or sensitive data.

·        Build upstream domain-controller compromise context groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside approved baselines, sensitive Active Directory object changes, privileged group changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, and endpoint credential-access behavior.

·        Build linkage logic using user identity, service-account identity, federated identity, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, organization ID, folder ID, project ID, resource name, Cloud Audit fields, Chronicle identity context, and incident timeline.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for organization ID, folder ID, project ID, resource name, principal identity, service account, role name, caller IP, user agent, service name, method name, status, request parameters, modified policy bindings, identity-provider session, device identity, upstream domain-controller indicator context, source-path context, identity-linkage status, and change-control context.

·        Validate event-action normalization across Cloud Audit Logs, Admin Activity logs, IAM logs, service-account logs, Workforce Identity Federation logs, Cloud Identity logs, Organization Policy logs, Cloud Logging events, Security Command Center, Cloud Monitoring, VPC firewall rule events, Cloud KMS, Cloud Storage IAM logs, Windows Security logs, Directory Services events, domain-controller telemetry, endpoint telemetry, DNS logs, proxy logs, Chronicle, and SIEM telemetry.

·        Validate backend support for identity-to-GCP linkage, upstream domain-controller correlation, source-path validation, Cloud Audit request-parameter parsing, organization enrichment, project enrichment, privileged-role enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when IAM, service-account, or security-control changes occur immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed IAM changes, service-account changes, role changes, logging changes, monitoring changes, firewall changes, encryption changes, or security-control modifications after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, Cloud Audit continuity, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, GCP field availability, organization inventory, project inventory, privileged-role inventory, change-control validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to GCP IAM, service-account, and security-control modification after upstream domain-controller compromise indicators rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes initial access method, API sequence, role path, service-account usage, source infrastructure, or cloud persistence method.

·        The score is supported by the durability of IAM policy changes, role bindings, service-account key creation, service-account impersonation grants, organization-policy changes, logging changes, monitoring changes, firewall changes, and security-control weakening after suspicious identity-compromise context.

·        The score is constrained by weak domain-to-GCP linkage, identity federation complexity, legitimate cloud administration, CI/CD automation, emergency access workflows, incomplete Cloud Audit logging, service-account abstraction, and target-SIEM translation quality.

·        The rule is durable as GCP persistence, privilege-escalation, and defense-evasion coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, or GCP compromise.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Cloud Audit coverage, IAM telemetry, organization inventory, project inventory, privileged-role inventory, identity-provider logs, upstream domain-controller evidence, source enrichment, change-control records, Chronicle or SIEM correlation quality, and incident-response context.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, security engineers, vendors, or incident responders commonly make IAM, service-account, or security-control changes after privileged identity activity.

·        Operational confidence is reduced where service-account naming, identity federation, source IP transformation, cloud session reuse, token reuse, incomplete request-parameter parsing, or weak change-control integration obscures context.

·        Full-telemetry confidence improves when GCP modification events are enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, identity-provider context, MFA logs, DNS logs, proxy logs, Chronicle context, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone compromise confirmation.

Limitations

This rule detects suspicious GCP IAM, service-account, or security-control modification linked to upstream domain-controller compromise indicators, not Netlogon exploitation or GCP compromise by itself.

·        Cloud Audit logs may not provide enough device, source-path, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, DevOps workflows, CI/CD maintenance, security engineering, emergency access, vendor support, and incident response can produce similar IAM, service-account, or security-control modifications.

·        The rule may miss abuse that uses existing privileges without modifying identity or security controls, occurs from a different device, uses a pre-existing cloud session, or happens outside the correlation window.

·        GCP activity should not be attributed to Netlogon-linked compromise without upstream domain-controller evidence, identity linkage, source-path linkage, endpoint evidence, change-control review, or incident-response validation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP IAM, service-account, and security-control modification correlation pattern requiring target-SIEM translation validation, Cloud Audit field validation, IAM action validation, service-account action validation, security-control action validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

GcpAuditOrAdminEvent AS GcpIdentityOrSecurityModification

WHERE GcpIdentityOrSecurityModification.MethodName IN ANY (
"SetIamPolicy",
"google.iam.admin.v1.CreateServiceAccount",
"google.iam.admin.v1.CreateServiceAccountKey",
"google.iam.admin.v1.UploadServiceAccountKey",
"google.iam.admin.v1.UpdateServiceAccount",
"google.iam.admin.v1.DeleteServiceAccount",
"google.iam.admin.v1.CreateRole",
"google.iam.admin.v1.UpdateRole",
"google.cloud.orgpolicy.v2.OrgPolicy.UpdatePolicy",
"google.logging.v2.ConfigServiceV2.CreateSink",
"google.logging.v2.ConfigServiceV2.UpdateSink",
"google.logging.v2.ConfigServiceV2.DeleteSink",
"google.monitoring.v3.NotificationChannelService.UpdateNotificationChannel",
"google.cloud.securitycenter.settings.UpdateSecurityCenterSettings",
"v1.compute.firewalls.insert",
"v1.compute.firewalls.patch",
"v1.compute.firewalls.delete",
"cloudkms.cryptoKeys.setIamPolicy",
"storage.buckets.setIamPolicy"
)

AND GcpIdentityOrSecurityModification.ProjectId IN ASSET_GROUP (
"Production GCP Projects",
"Security Tooling Projects",
"Identity Management Projects",
"Backup Projects",
"Developer Platform Projects",
"Shared Services Projects",
"Sensitive Data Projects"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_GCP_MODIFICATION_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(GcpIdentityOrSecurityModification.Principal)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
GcpIdentityOrSecurityModification.CallerIp IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR GcpIdentityOrSecurityModification.Principal IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR GcpIdentityOrSecurityModification.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR GcpIdentityOrSecurityModification.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN GcpIdentityOrSecurityModification.ActivityPattern IN ANY (
"privileged_role_modified",
"service_account_key_created",
"service_account_impersonation_granted",
"iam_policy_modified",
"organization_policy_modified",
"logging_control_modified",
"monitoring_control_modified",
"security_control_disabled",
"firewall_rule_modified",
"kms_policy_modified",
"storage_policy_modified",
"cross_project_trust_modified",
"activity_outside_expected_role"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_emergency_access",
"approved_security_engineering",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_change_control"
)

Rule

Netlogon-Linked GCP Data, Secrets, or Workload Access After Domain-Controller Compromise Indicators

Rule Format

GCP data, secrets, and workload access correlation rule suitable for Cloud Audit Logs, Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine logs, GKE logs, BigQuery logs, Cloud SQL logs, Cloud Build logs, Artifact Registry logs, VPC Flow Logs, Cloud DNS logs, Security Command Center findings, upstream Windows and Active Directory correlation context, source enrichment, account enrichment, sensitive-asset inventory, organization inventory, project inventory, and SIEM correlation after GCP data-event validation, workload validation, upstream domain-controller indicator validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

Detect sensitive GCP data, secrets, key-management, workload, or remote-management access after upstream domain-controller compromise indicators.

·        Identify downstream cloud exposure where domain-controller compromise exposure may lead to secret retrieval, storage access, workload discovery, remote command execution, backup access, database access, Kubernetes access, build-system access, artifact access, or cloud-hosted system interaction.

·        Prioritize activity involving Secret Manager access, KMS decrypt operations, Cloud Storage data access, Compute Engine instance interaction, GKE cluster access, BigQuery access, Cloud SQL access, Cloud Build access, Artifact Registry access, snapshot access, or sensitive workload access inconsistent with the user’s normal role.

·        Preserve separation between suspicious GCP data or workload access and confirmed compromise by requiring upstream domain-controller evidence, identity linkage, source-path evidence, endpoint evidence, Cloud Audit evidence, sensitive-asset context, or incident-response validation before classifying compromise as confirmed.

·        This rule does not prove Netlogon exploitation, domain-controller compromise, GCP compromise, data theft, secret theft, workload compromise, credential theft, token theft, or actor attribution without supporting evidence.

Detection Logic

Identify GCP data, secrets, key-management, workload, or remote-management events after upstream domain-controller compromise indicators.

·        Correlate GCP data or workload access with upstream activity involving suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, abnormal source-to-domain-controller paths, sensitive Active Directory object modification, privileged group changes, domain trust changes, replication-permission changes, machine-account authentication anomalies, privileged authentication anomalies, or endpoint credential-access behavior.

·        Prioritize Secret Manager secret access, KMS decrypt operations, Cloud Storage object access, Compute Engine instance interaction, GKE credential retrieval, BigQuery data access, Cloud SQL access, snapshot access, Cloud Build interaction, Artifact Registry access, and other locally sensitive data or workload operations.

·        Increase confidence when access targets sensitive buckets, secrets, KMS keys, production workloads, backup data, database instances, snapshots, GKE clusters, build systems, artifact repositories, administrative instances, developer-platform workloads, or sensitive projects.

·        Increase confidence when activity is rare for the user, rare for the role, outside normal access windows, uses unusual user agents, occurs from an unusual source path, follows upstream domain-controller compromise indicators, or lacks approved change-control context.

·        Increase confidence when Security Command Center, endpoint telemetry, DNS telemetry, proxy telemetry, VPC Flow Logs, Cloud DNS logs, or Chronicle shows supporting signs of unusual cloud access, data movement, command execution, or suspicious external communication.

·        Reduce severity when access aligns with approved cloud operations, backup operations, DevOps workflows, CI/CD maintenance, incident response, security testing, vendor support, disaster recovery, or documented change-control activity.

·        Do not classify GCP data, secrets, or workload access as Netlogon-linked compromise without upstream domain-controller evidence, source-path linkage, identity linkage, sensitive-asset context, or incident-response validation.

·        Do not treat GCP data access, secret access, KMS use, workload access, Security Command Center findings, Cloud Audit anomalies, or source-IP novelty as compromise evidence by themselves.

Required Telemetry

Google Cloud Audit Logs.

·        Data Access logs where available.

·        Cloud Storage logs where available.

·        Secret Manager logs.

·        Cloud KMS logs.

·        Compute Engine logs where available.

·        GKE logs where available.

·        BigQuery logs where available.

·        Cloud SQL logs where available.

·        Cloud Build logs where available.

·        Artifact Registry logs where available.

·        VPC Flow Logs where available.

·        Cloud DNS logs where available.

·        Security Command Center findings where available.

·        Chronicle logs where available.

·        Identity-provider logs.

·        MFA logs.

·        Windows Security logs.

·        Directory Services events.

·        Domain-controller telemetry.

·        Authentication telemetry.

·        NDR telemetry where available.

·        EDR telemetry where available.

·        DNS or proxy logs where available.

·        Organization inventory.

·        Folder inventory.

·        Project inventory.

·        Sensitive Cloud Storage bucket inventory.

·        Secret Manager inventory.

·        KMS key inventory.

·        Production workload inventory.

·        Backup inventory.

·        Database inventory.

·        GKE cluster inventory.

·        Compute Engine inventory.

·        Cloud Build inventory.

·        Artifact Registry inventory.

·        Approved cloud operations records.

·        Approved backup operations records.

·        Approved DevOps workflow records.

·        Approved CI/CD maintenance records.

·        Approved vendor support records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

Build sensitive GCP data groups covering sensitive Cloud Storage buckets, production buckets, backup buckets, regulated-data buckets, Secret Manager secrets, KMS keys, production Compute Engine instances, Cloud SQL databases, BigQuery datasets, snapshots, GKE clusters, Cloud Build projects, Artifact Registry repositories, developer-platform workloads, and sensitive projects.

·        Build GCP sensitive action groups for Secret Manager secret access, KMS decrypt operations, Cloud Storage object access, Compute Engine instance access, GKE credential retrieval, BigQuery data access, Cloud SQL activity, snapshot access, Cloud Build interaction, Artifact Registry access, and locally sensitive workload-access events.

·        Build upstream domain-controller compromise context groups covering suspicious Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper activity, SMB domain-controller service access, new source-to-domain-controller paths, source activity outside approved baselines, sensitive Active Directory object changes, privileged group changes, replication-permission changes, abnormal machine-account authentication, privileged authentication anomalies, and endpoint credential-access behavior.

·        Build source-path and identity linkage logic using user identity, service-account identity, federated identity, identity-provider session, source IP, user agent, device identity, authentication session, domain identity, project ID, resource name, Cloud Audit fields, Chronicle identity context, and incident timeline.

·        Build downstream-risk groups for rare user activity, rare role activity, first-seen sensitive service, first-seen data asset, unusual user agent, source-path mismatch, device mismatch, outside normal access window, sensitive data access, secret access, key-management activity, backup access, workload remote-management activity, build-system access, artifact access, and activity outside expected role.

·        Validate target-SIEM translation behavior before production deployment.

·        Validate local field mappings for organization ID, folder ID, project ID, resource name, principal identity, service account, caller IP, user agent, service name, method name, status, bucket name, object name, secret name, key ID, instance ID, database name, GKE cluster name, BigQuery dataset, build ID, artifact repository, upstream domain-controller indicator context, identity-provider session, device identity, source-path context, identity-linkage status, and change-control context.

·        Validate event-action normalization across Cloud Audit Logs, Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine logs, GKE logs, BigQuery logs, Cloud SQL logs, Cloud Build logs, Artifact Registry logs, VPC Flow Logs, Cloud DNS logs, Security Command Center, Windows Security logs, Directory Services events, domain-controller telemetry, endpoint telemetry, DNS logs, proxy logs, Chronicle, and SIEM telemetry.

·        Validate backend support for identity-to-GCP linkage, upstream domain-controller correlation, identity-session correlation, source-path validation, resource-name parsing, sensitive-asset enrichment, organization enrichment, project enrichment, timing windows, exception handling, and query-performance controls.

·        Use short correlation windows when GCP data, secrets, or workload access occurs immediately after upstream domain-controller compromise indicators.

·        Use moderate correlation windows for delayed secret access, KMS use, Cloud Storage access, workload access, backup access, database activity, Kubernetes activity, build activity, or artifact activity after upstream domain-controller compromise indicators.

·        Use longer correlation windows only when identity evidence, endpoint evidence, domain-controller evidence, Cloud Audit continuity, sensitive-asset context, or incident-response evidence supports delayed linkage.

·        Validate SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements before enabling alert mode.

·        Do not enable alert mode until upstream linkage, source attribution, identity correlation, GCP data-event availability, sensitive-asset inventory, organization inventory, project inventory, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to GCP data, secrets, key-management, and workload access after upstream domain-controller compromise indicators rather than static exploit strings, CVE identifiers, source IPs, domains, or isolated cloud findings.

·        The rule remains useful if an adversary changes the GCP service target, data-access sequence, role path, service-account path, source infrastructure, session timing, or workload interaction pattern.

·        The score is supported by the durability of secret retrieval, KMS decrypt operations, sensitive Cloud Storage access, Compute Engine interaction, GKE credential access, BigQuery access, Cloud SQL access, build-system access, artifact access, and sensitive cloud-resource access after suspicious identity-compromise context.

·        The score is constrained by weak domain-to-GCP linkage, incomplete Data Access logs, identity federation complexity, legitimate cloud operations, backup operations, CI/CD automation, service-account abstraction, token reuse, cloud session reuse, and target-SIEM translation quality.

·        The rule is durable as GCP data and workload exposure coverage but should not be treated as standalone proof of Netlogon exploitation, domain-controller compromise, GCP compromise, or data theft.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Cloud Audit Logs, Data Access logs, sensitive-asset inventory, organization inventory, project inventory, identity-provider logs, upstream domain-controller evidence, source enrichment, endpoint telemetry, Chronicle or SIEM correlation quality, and incident-response context.

·        Operational confidence is reduced where Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine logs, GKE logs, BigQuery logs, Cloud SQL logs, Cloud Build logs, Artifact Registry logs, VPC Flow Logs, or Cloud DNS logs are incomplete or not retained.

·        Operational confidence is reduced where cloud administrators, DevOps users, CI/CD systems, backup operators, vendors, security teams, or incident responders commonly access sensitive GCP data or workloads after privileged identity activity.

·        Full-telemetry confidence improves when GCP data and workload activity is enriched with Windows Security logs, Directory Services events, domain-controller telemetry, NDR telemetry, EDR telemetry, identity-provider context, MFA logs, DNS logs, proxy logs, VPC Flow Logs, Cloud DNS logs, Chronicle context, sensitive-asset inventory, change-control records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support exposure scoping and escalation rather than standalone compromise confirmation.

Limitations

This rule detects suspicious GCP data, secrets, or workload access linked to upstream domain-controller compromise indicators, not Netlogon exploitation or GCP compromise by itself.

·        GCP Data Access logs may not be enabled for all buckets, objects, workloads, datasets, projects, or sensitive resources.

·        GCP may not provide enough device, source-path, identity-provider session, or domain-session context to prove linkage without external enrichment.

·        Legitimate cloud operations, backup operations, DevOps workflows, CI/CD jobs, incident response, vendor support, and security testing can produce similar behavior.

·        The rule may miss activity that uses existing cloud sessions, reused tokens, expected automation identities, unmanaged identities, different source paths, or actions outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP data, secrets, and workload access correlation pattern requiring target-SIEM translation validation, Data Access log validation, Cloud Storage logging validation, Secret Manager logging validation, KMS logging validation, resource-field validation, sensitive-asset validation, upstream domain-controller indicator validation, identity-linkage validation, source-path validation, timing-window tuning, and environment-specific exception handling before production deployment. This pattern is not intended as a strict drop-in SIEM rule without backend-specific translation.

GcpAuditOrDataEvent AS GcpSensitiveResourceAccess

WHERE GcpSensitiveResourceAccess.MethodName IN ANY (
"google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion",
"google.cloud.kms.v1.KeyManagementService.Decrypt",
"storage.objects.get",
"storage.objects.list",
"google.cloud.compute.v1.Instances.Get",
"google.cloud.compute.v1.Snapshots.Get",
"google.container.v1.ClusterManager.GetCluster",
"google.container.v1.ClusterManager.GetClusterCredentials",
"google.cloud.bigquery.v2.JobService.InsertJob",
"google.cloud.bigquery.v2.TableService.GetTable",
"google.cloud.sql.v1.SqlInstancesService.Get",
"google.devtools.cloudbuild.v1.CloudBuild.GetBuild",
"google.devtools.artifactregistry.v1.ArtifactRegistry.GetRepository",
"google.devtools.artifactregistry.v1.ArtifactRegistry.ListRepositories"
)

AND GcpSensitiveResourceAccess.ResourceName IN ASSET_GROUP (
"Sensitive Cloud Storage Buckets",
"Production Data Buckets",
"Backup Buckets",
"Regulated Data Buckets",
"Secret Manager Secrets",
"KMS Keys",
"Production Compute Instances",
"Cloud SQL Databases",
"BigQuery Datasets",
"Snapshots",
"GKE Clusters",
"Cloud Build Projects",
"Artifact Registry Repositories",
"Developer Platform Workloads",
"Sensitive GCP Projects"
)

AND EVENT_NEAR WITHIN ENV_NETLOGON_TO_GCP_SENSITIVE_ACCESS_WINDOW (
SecurityEvent AS UpstreamDomainControllerCompromiseContext
WHERE UpstreamDomainControllerCompromiseContext.User IN SAME_USER_OR_IDENTITY(GcpSensitiveResourceAccess.Principal)
AND UpstreamDomainControllerCompromiseContext.EventPattern IN ANY (
"suspicious_netlogon_adjacent_activity",
"suspicious_msrpc_to_domain_controller",
"suspicious_rpc_endpoint_mapper_to_domain_controller",
"suspicious_smb_domain_controller_service_access",
"new_source_to_domain_controller_path",
"source_not_in_domain_controller_access_baseline",
"sensitive_active_directory_object_change",
"privileged_group_change",
"domain_trust_change",
"replication_permission_change",
"abnormal_machine_account_authentication",
"privileged_authentication_anomaly",
"endpoint_credential_access_behavior"
)
)

AND (
GcpSensitiveResourceAccess.CallerIp IN SAME_SOURCE_OR_ALLOWED_TRANSFORM(UpstreamDomainControllerCompromiseContext.SourceIP)
OR GcpSensitiveResourceAccess.Principal IN SAME_USER(UpstreamDomainControllerCompromiseContext.User)
OR GcpSensitiveResourceAccess.IdentitySession IN SAME_IDENTITY_SESSION(UpstreamDomainControllerCompromiseContext.IdentitySession)
OR GcpSensitiveResourceAccess.Timestamp IN SAME_INCIDENT_WINDOW(UpstreamDomainControllerCompromiseContext.Timestamp)
)

AND OPTIONAL_CONFIDENCE_INCREASE WHEN GcpSensitiveResourceAccess.ActivityPattern IN ANY (
"rare_user_activity",
"rare_role_activity",
"first_seen_sensitive_service",
"first_seen_data_asset",
"unusual_user_agent",
"source_path_mismatch",
"device_mismatch",
"outside_normal_access_window",
"sensitive_data_access",
"secret_access",
"key_management_activity",
"backup_access",
"workload_remote_management_activity",
"build_system_access",
"artifact_access",
"activity_outside_expected_role"
)

AND NOT ChangeContext IN ANY (
"approved_cloud_operations",
"approved_backup_operations",
"approved_devops_workflow",
"approved_cicd_maintenance",
"approved_vendor_support",
"approved_security_testing",
"approved_incident_response",
"approved_emergency_access",
"approved_change_control"
)

S26 Threat-to-Rule Traceability Matrix

Traceability Summary

The S25 rule set provides behavior-led traceability from suspicious domain-controller interaction through identity-plane change, authentication expansion, endpoint execution, credential-access behavior, and downstream cloud exposure. The model does not depend on a single Netlogon exploit signature, static indicator, artifact, payload, or cloud-only anomaly.

The traceability model is intentionally layered. Upstream Windows, Active Directory, endpoint, network, authentication, SIEM, and incident-response evidence must establish the domain-controller compromise context before downstream cloud activity is treated as Netlogon-linked escalation.

Traceability Method

·        Map each major threat behavior to the S25 systems that provide meaningful detection or correlation coverage.

·        Separate direct behavioral coverage from downstream correlation coverage.

·        Preserve cloud-correlation guardrails so AWS, Azure, and GCP activity is not treated as Netlogon-linked compromise without upstream evidence.

·        Preserve YARA as a conditional investigative control only when stable artifacts are recovered.

·        Avoid treating any single event, alert, source, cloud action, authentication event, or endpoint behavior as standalone proof of exploitation or compromise.

Primary Threat Behavior

Suspicious Netlogon-adjacent or domain-controller service interaction.

Mapped S25 Rule Coverage

·        NDR / Network Behavioral Analytics provides primary coverage for abnormal source-to-domain-controller service interaction, MS-NRPC-adjacent activity, RPC endpoint mapper activity, SMB domain-controller service access, repeated domain-controller service access, source novelty, and access outside normal domain-controller peer baselines.

·        Splunk, Elastic, and QRadar provide backend correlation when network-derived domain-controller interaction context can be joined with Windows Security events, Directory Services events, authentication telemetry, and endpoint telemetry.

·        SIGMA provides portable implementation-ready patterns that can support correlation after conversion and local validation.

Traceability Rationale

This behavior establishes the upstream domain-controller interaction context for the report. It does not prove exploitation by itself, but it is the first required anchor for treating later identity, endpoint, or cloud behavior as potentially related to the Netlogon/domain-controller compromise model.

Coverage Qualification

High coverage when NDR and SIEM telemetry include domain-controller inventory, source-to-domain-controller baselines, RPC and SMB service visibility, Windows Security telemetry, Directory Services telemetry, authentication context, and asset enrichment.

Primary Threat Behavior

Sensitive Active Directory object, machine-account, privileged-group, trust, delegation, policy, or replication-permission modification.

Mapped S25 Rule Coverage

·        Splunk, Elastic, QRadar, and SIGMA provide coverage for sensitive Active Directory object modification, machine-account changes, privileged-group membership changes, domain trust changes, delegation attribute changes, account-control changes, password-related changes, Group Policy changes, and replication-related directory changes.

·        SentinelOne provides supporting endpoint context when directory changes follow suspicious execution, credential-access preparation, remote administration, or domain-controller interaction.

·        NDR / Network Behavioral Analytics provides upstream source-to-domain-controller context when directory changes occur after unusual internal access to domain-controller services.

Traceability Rationale

Sensitive Active Directory modification is a durable post-exploitation behavior because domain-controller compromise exposure becomes operationally significant when it enables identity control, privilege expansion, trust manipulation, policy modification, or replication-related access.

Coverage Qualification

High coverage when Directory Services auditing is enabled and correlated with domain-controller inventory, privileged-object inventory, machine-account inventory, administrative-source enrichment, and change-control context.

Primary Threat Behavior

Privileged, machine-account, service-account, Kerberos, NTLM, or explicit-credential authentication expansion.

Mapped S25 Rule Coverage

·        Splunk, Elastic, QRadar, and SIGMA provide coverage for privileged authentication activity, machine-account authentication, administrative logon types, explicit credential use, Kerberos authentication, NTLM authentication, failed-then-successful authentication, rare account-to-host paths, and authentication outside expected baselines.

·        SentinelOne supports correlation when authentication expansion is followed by endpoint execution, credential-access tooling, remote administration, persistence preparation, or lateral-movement behavior.

·        NDR / Network Behavioral Analytics supports correlation when authentication expansion follows suspicious domain-controller service interaction or abnormal internal source-to-domain-controller paths.

Traceability Rationale

Authentication expansion is the bridge between domain-controller compromise exposure and operational impact. It helps determine whether upstream domain-controller activity is followed by credential use, privilege use, service-account use, machine-account use, or lateral movement.

Coverage Qualification

Moderate to high coverage depending on authentication log quality, Kerberos and NTLM field availability, privileged-account inventory, service-account baselines, and identity-to-host correlation.

Primary Threat Behavior

Endpoint execution, credential-access preparation, tool staging, remote administration, or lateral-movement behavior.

Mapped S25 Rule Coverage

·        SentinelOne provides primary endpoint coverage for suspicious process execution, credential-access preparation, living-off-the-land execution, remote administration tooling, LSASS or credential material targeting, suspicious scripting, service creation, scheduled task behavior, and suspicious execution from staging paths.

·        Splunk, Elastic, QRadar, and SIGMA provide backend or portable correlation across endpoint execution, upstream domain-controller interaction, authentication anomalies, and sensitive Active Directory changes.

·        NDR / Network Behavioral Analytics supports source-path validation when endpoint behavior is tied to domain-controller service access, lateral movement, or internal reconnaissance.

Traceability Rationale

Endpoint behavior provides operational context that helps distinguish approved domain-controller administration from suspicious credential-access, staging, remote execution, persistence preparation, or lateral-movement behavior.

Coverage Qualification

High coverage when EDR telemetry includes process creation, command line, parent process, user, device, network connection, process lineage, file activity, and endpoint-to-network correlation. Coverage is reduced where command-line logging, process ancestry, or endpoint telemetry is incomplete.

Primary Threat Behavior

Downstream AWS control-plane, IAM, security-control, data-access, secrets-access, or workload-access activity after upstream domain-controller compromise indicators.

Mapped S25 Rule Coverage

·        AWS provides three downstream cloud-correlation rules covering console / API / control-plane activity, IAM or security-control modification, and data / secrets / workload access.

·        AWS rules require upstream Windows, Active Directory, endpoint, network, authentication, SIEM, AWS Managed Microsoft AD, or incident-response evidence before making a Netlogon-linked escalation claim.

·        Splunk, Elastic, QRadar, SentinelOne, and NDR / Network Behavioral Analytics provide the upstream correlation anchors needed to connect AWS activity to the domain-controller compromise model.

Traceability Rationale

AWS does not directly detect Netlogon exploitation. AWS coverage is valuable for identifying cloud follow-on behavior when compromised identities, federated identities, access keys, assumed roles, AWS Managed Microsoft AD context, or source-path evidence link AWS activity to the same incident timeline.

Coverage Qualification

Moderate to high coverage when CloudTrail, IAM, STS, IAM Identity Center, GuardDuty, Security Hub, VPC Flow Logs, AWS Managed Microsoft AD logs where present, identity-lineage enrichment, sensitive-asset inventory, and upstream SIEM correlation are available.

Primary Threat Behavior

Downstream Azure / Entra ID control-plane, identity, role, security-control, data, secrets, or workload activity after upstream domain-controller compromise indicators.

Mapped S25 Rule Coverage

·        Azure provides three downstream cloud-correlation rules covering Azure portal / Entra ID / Resource Manager activity, identity / role / security-control modification, and data / secrets / workload access.

·        Azure rules require upstream Windows, Active Directory, endpoint, network, authentication, SIEM, Defender for Identity, Microsoft Sentinel, hybrid identity, or incident-response evidence before making a Netlogon-linked escalation claim.

·        Splunk, Elastic, QRadar, SentinelOne, and NDR / Network Behavioral Analytics provide the upstream evidence required to connect Azure behavior to the domain-controller compromise model.

Traceability Rationale

Azure is especially relevant where Entra ID, hybrid identity, Defender for Identity, Microsoft Sentinel, AD FS, Entra Connect, privileged role assignment, Key Vault access, Storage access, or Azure Resource Manager activity may reflect follow-on cloud exposure after domain-controller compromise indicators.

Coverage Qualification

Moderate to high coverage when Entra ID sign-in logs, Entra ID audit logs, Azure Activity logs, Defender for Identity, Defender for Endpoint, Microsoft Sentinel, Key Vault logs, Storage logs, tenant inventory, subscription inventory, sensitive-asset inventory, and identity-lineage enrichment are available.

Primary Threat Behavior

Downstream GCP control-plane, IAM, service-account, security-control, data, secrets, or workload activity after upstream domain-controller compromise indicators.

Mapped S25 Rule Coverage

·        GCP provides three downstream cloud-correlation rules covering GCP console / IAM / API activity, IAM / service-account / security-control modification, and data / secrets / workload access.

·        GCP rules require upstream Windows, Active Directory, endpoint, network, authentication, SIEM, Chronicle, hybrid identity, or incident-response evidence before making a Netlogon-linked escalation claim.

·        Splunk, Elastic, QRadar, SentinelOne, and NDR / Network Behavioral Analytics provide the upstream evidence required to connect GCP activity to the domain-controller compromise model.

Traceability Rationale

GCP does not directly detect Netlogon exploitation. GCP coverage is valuable when identity misuse, service-account abuse, federation activity, Cloud Audit activity, Secret Manager access, Cloud KMS use, Cloud Storage access, BigQuery access, GKE activity, or workload access occurs after upstream domain-controller compromise indicators.

Coverage Qualification

Moderate to high coverage when Cloud Audit Logs, Data Access logs, IAM telemetry, service-account telemetry, Workforce Identity Federation logs, Security Command Center, Chronicle, organization inventory, project inventory, sensitive-asset inventory, and upstream SIEM correlation are available.

Primary Threat Behavior

Artifact, file, memory, payload, or tooling evidence recovered during incident response.

Mapped S25 Rule Coverage

·        YARA has no primary S25 rule for this report.

·        YARA remains a conditional investigative control only when responders recover stable artifacts such as a webshell, loader, dropper, staged script, exploit payload, credential-access tool, remote-access tool, memory artifact, configuration artifact, encoded payload, suspicious binary, or reusable file-content pattern linked to suspicious domain-controller interaction or downstream activity.

Traceability Rationale

The report’s governing detection model is behavior-led, not artifact-led. A primary YARA rule would create unnecessary artifact dependency unless stable victim-environment evidence is recovered.

Coverage Qualification

No primary YARA coverage. Conditional investigative coverage only when durable artifacts are available.

Traceability Gaps

·        No S25 rule should classify Netlogon exploitation as confirmed from a single event, single source, single authentication anomaly, single cloud event, single endpoint alert, or single directory change.

·        Cloud rules require upstream correlation and must not treat AWS, Azure, or GCP-only anomalies as Netlogon-linked compromise without supporting Windows, Active Directory, endpoint, network, authentication, SIEM, hybrid identity, or incident-response evidence.

·        YARA remains non-primary unless stable artifacts are recovered.

·        Coverage depends on local telemetry quality, audit-policy configuration, field mappings, enrichment, inventory accuracy, exception handling, and SOC validation.

·        Rule deployment remains dependent on local schema mapping, query translation, false-positive testing, query-performance testing, escalation criteria, and SOC triage readiness.

Traceability Outcome

The S25 rule set provides layered behavioral coverage across the full report model:

·        Upstream suspicious domain-controller interaction.

·        Sensitive Active Directory modification.

·        Privileged or machine-account authentication expansion.

·        Endpoint execution and credential-access behavior.

·        SIEM-backed multi-source correlation.

·        Portable SIGMA implementation-ready patterns.

·        Cloud-control-plane and sensitive-resource follow-on correlation across AWS, Azure, and GCP.

·        Conditional artifact hunting through YARA only when stable evidence is available.

S27 — Behavior & Log Artifacts

Behavioral Artifact Summary

This report’s primary artifacts are behavior-led rather than exploit-string-led. The strongest artifacts are suspicious domain-controller service interaction, Netlogon-adjacent activity, abnormal source-to-domain-controller paths, sensitive Active Directory modification, privileged or machine-account authentication expansion, endpoint execution, credential-access behavior, and downstream cloud-control-plane or sensitive-resource activity linked to upstream domain-controller compromise indicators.

Primary Behavior Artifacts

·        Abnormal source-to-domain-controller communication involving systems that do not normally interact with domain-controller services.

·        New or rare internal sources communicating with domain controllers over domain-controller-relevant services.

·        MS-NRPC-adjacent activity, RPC endpoint mapper activity, SMB domain-controller service access, or repeated domain-controller service interaction outside normal peer baselines.

·        Source-to-domain-controller paths inconsistent with approved administration, replication, monitoring, backup, vulnerability management, endpoint management, or identity infrastructure behavior.

·        Sensitive Active Directory object modification after suspicious domain-controller service interaction.

·        Privileged group, machine-account, domain-controller account, delegation, domain trust, Group Policy, account-control, or replication-permission changes.

·        Privileged, service-account, machine-account, Kerberos, NTLM, explicit-credential, or administrative logon activity following suspicious domain-controller interaction.

·        Failed-then-successful authentication patterns involving privileged, machine, service, or domain-adjacent accounts.

·        Endpoint activity following suspicious domain-controller interaction, including suspicious process execution, credential-access preparation, remote administration, living-off-the-land execution, service creation, scheduled task activity, or tool staging.

·        Downstream AWS, Azure, or GCP activity linked to suspicious domain-controller compromise context through identity path, source path, device context, session context, access-key lineage, service-account lineage, hybrid identity context, or incident timeline.

·        Cloud identity, IAM, role, policy, service-principal, service-account, logging, monitoring, security-control, key-management, storage, data, secrets, workload, backup, Kubernetes, database, or developer-platform activity following upstream domain-controller compromise indicators.

Primary Log Artifacts

·        NDR or network behavioral analytics telemetry involving domain-controller communication.

·        RPC endpoint mapper activity involving domain controllers.

·        SMB activity involving domain-controller services.

·        Netlogon-adjacent traffic where visible.

·        Windows Security logs.

·        Directory Services events.

·        Active Directory object-change events.

·        Privileged group membership change events.

·        Machine-account creation, modification, reset, or authentication events.

·        Domain-controller account change events.

·        Domain trust modification events.

·        Delegation attribute change events.

·        Group Policy modification events.

·        Replication-permission modification events.

·        Kerberos authentication logs where available.

·        NTLM authentication logs where available.

·        Explicit credential use events.

·        Administrative logon events.

·        Failed and successful authentication events involving privileged, service, machine, or domain-adjacent accounts.

·        Endpoint and EDR process telemetry.

·        Endpoint command-line telemetry.

·        Endpoint file, registry, service, scheduled-task, DLL-load, and persistence telemetry where available.

·        Endpoint network connection telemetry.

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        SIEM correlation events.

·        AWS CloudTrail, IAM, STS, IAM Identity Center, GuardDuty, Security Hub, Config, VPC Flow Logs, Route 53 Resolver, S3, KMS, Secrets Manager, Systems Manager, workload, and data-access logs where available.

·        Azure Entra ID, Azure Activity, Azure Resource Manager, Defender for Identity, Defender for Endpoint, Microsoft Sentinel, Key Vault, Storage, Azure Monitor, workload, and data-access logs where available.

·        GCP Cloud Audit Logs, Admin Activity logs, Data Access logs, IAM logs, service-account activity, Workforce Identity Federation logs, Security Command Center, VPC Flow Logs, Cloud DNS, Secret Manager, Cloud KMS, Cloud Storage, BigQuery, GKE, Cloud SQL, Cloud Build, and Artifact Registry logs where available.

·        Change-control records.

·        Approved administrator workflow records.

·        Approved vendor-support records.

·        Approved security-testing records.

·        Incident-response records.

Domain-Controller and Active Directory Artifacts

·        Suspicious domain-controller service interaction from non-standard or first-seen internal sources.

·        Repeated or unusual communication to domain controllers over RPC, SMB, or Netlogon-adjacent service paths.

·        Domain-controller service access followed by privileged authentication, sensitive directory change, endpoint execution, or cloud-control-plane activity.

·        Sensitive Active Directory object modification involving users, groups, computers, domain controllers, trusts, delegation settings, privileged groups, Group Policy, or replication rights.

·        Domain Admins, Enterprise Admins, Account Operators, Server Operators, Backup Operators, or equivalent privileged group changes.

·        Machine-account changes inconsistent with approved domain operations.

·        Domain-controller account changes.

·        Domain trust changes.

·        Delegation attribute changes.

·        Replication-permission changes.

·        Group Policy changes affecting authentication, security controls, logging, privileged access, or domain-controller behavior.

·        Directory changes that occur without corresponding approved change-control, administrative workflow, or maintenance context.

Identity and Authentication Artifacts

·        Privileged account logon from unusual hosts, sources, devices, or time windows.

·        Machine-account authentication inconsistent with expected device, domain-controller, or service behavior.

·        Explicit credential use involving privileged, service, administrative, or machine-account identities.

·        Kerberos or NTLM activity outside expected account, host, or service baselines.

·        Failed-then-successful authentication involving privileged or domain-adjacent accounts.

·        Administrative logon types involving domain controllers, high-value servers, identity infrastructure, management systems, or jump hosts.

·        Service-account use inconsistent with expected automation, application, or workload behavior.

·        Authentication activity involving accounts associated with recent sensitive Active Directory changes.

·        Authentication expansion following suspicious domain-controller service interaction.

·        Identity-provider, MFA, federation, hybrid identity, or cloud identity activity linked to the same account, source, device, session, or incident timeline.

Endpoint and Host Artifacts

·        Suspicious process execution on domain controllers, administrative hosts, jump hosts, source systems, or systems that recently interacted with domain controllers.

·        PowerShell, command shell, WMI, WinRM, PsExec-like behavior, remote service creation, scheduled task creation, script execution, or living-off-the-land execution after suspicious domain-controller interaction.

·        LSASS access, credential material targeting, memory access behavior, credential dumping preparation, token access, or browser credential-store access.

·        Tool staging in temporary, user-writable, administrative-share, ProgramData, AppData, Public, download, or unusual execution paths.

·        Suspicious child processes spawned by administrative tooling, scripting engines, remote management utilities, security tools, or identity-management tools.

·        Endpoint behavior followed by privileged authentication, Active Directory modification, cloud-control-plane activity, or sensitive-resource access.

·        Suspicious activity on internal systems reached after privileged or domain-adjacent authentication expansion.

·        Outbound follow-on communication from systems involved in suspicious domain-controller interaction, credential-access behavior, or lateral movement.

Network and Internal Access Artifacts

·        Abnormal internal access to domain controllers from workstations, servers, management hosts, or user systems not normally associated with domain-controller administration.

·        First-seen source-to-domain-controller paths.

·        Rare source-to-domain-controller service use.

·        Destination diversity inconsistent with normal user, host, or service behavior.

·        Cross-segment access involving domain controllers, identity infrastructure, administrative systems, jump hosts, backup systems, endpoint-management platforms, or high-value servers.

·        Administrative protocol use outside expected account or host role.

·        LDAP, Kerberos, SMB, RDP, SSH, WinRM, WMI, database, file-share, or management-plane access following suspicious domain-controller interaction.

·        Failed internal authentication bursts.

·        Credential validation patterns.

·        Share enumeration.

·        Access to identity infrastructure or privileged systems outside the user’s normal operational profile.

·        Internal systems involved in suspicious domain-controller interaction later initiating unusual outbound communication, cloud access, tool retrieval, data movement, or command-and-control-like traffic.

Cloud and SaaS Artifacts

·        AWS CloudTrail activity, IAM activity, STS activity, IAM Identity Center activity, access-key creation, role assumption, IAM policy changes, CloudTrail changes, GuardDuty changes, Security Hub changes, S3 access, Secrets Manager access, KMS decrypt activity, Systems Manager activity, workload access, or sensitive account access after upstream domain-controller compromise indicators.

·        Azure Entra ID sign-in activity, Entra ID audit activity, Azure Activity events, Azure Resource Manager operations, role assignments, service-principal changes, application credential changes, conditional-access changes, Key Vault access, Storage access, VM run command, AKS activity, backup access, or sensitive workload access after upstream domain-controller compromise indicators.

·        GCP Cloud Audit Log activity, Admin Activity logs, IAM activity, service-account activity, service-account key creation, service-account impersonation, organization-policy changes, logging changes, monitoring changes, firewall changes, Secret Manager access, Cloud KMS decrypt activity, Cloud Storage access, BigQuery activity, GKE activity, Cloud SQL activity, Cloud Build activity, Artifact Registry activity, or sensitive workload access after upstream domain-controller compromise indicators.

·        SaaS administration, source-code access, repository cloning, developer-platform activity, CI/CD workflow modification, secret access, API token creation, application consent changes, audit-log access, security-control changes, or data export linked to upstream domain-controller compromise indicators.

·        Cloud, SaaS, identity, source-code, and developer-platform anomalies should remain downstream investigative leads unless linked to upstream domain-controller evidence, identity compromise, credential theft, token theft, or incident-response validation.

YARA and Artifact-Led Evidence

·        YARA has no primary behavioral artifact role for this report.

·        YARA becomes useful only if responders recover stable file, memory, payload, configuration, script, binary, loader, dropper, webshell, remote-access, credential-access, or encoded-content artifacts linked to suspicious domain-controller interaction or downstream activity.

·        Artifact-led evidence should support scoping, enrichment, retrospective hunting, and incident-response validation, not replace the behavior-led detection model.

·        YARA should not be used to infer Netlogon exploitation, domain-controller compromise, credential theft, identity compromise, cloud compromise, persistence, lateral movement, data access, or actor attribution without supporting telemetry.

Artifact Interpretation Constraints

·        Suspicious domain-controller communication is not proof of exploitation by itself.

·        Netlogon-adjacent activity is not proof of successful domain-controller compromise by itself.

·        A single Windows Security event is not proof of exploitation.

·        A single Directory Services change is not proof of compromise without context.

·        A privileged authentication event is not malicious by itself.

·        Machine-account activity may reflect legitimate domain operations unless correlated with abnormal source, timing, object change, authentication, endpoint, or incident-response context.

·        Source novelty, host novelty, account novelty, ASN novelty, geography novelty, or device novelty should be treated as a confidence amplifier, not standalone compromise evidence.

·        Endpoint alerts, cloud anomalies, SaaS anomalies, identity anomalies, developer-platform anomalies, or YARA artifact matches should not be attributed to Netlogon-linked compromise without temporal and behavioral linkage.

·        Confirmed compromise should require evidence from multiple linked stages of the chain, such as suspicious domain-controller interaction followed by sensitive Active Directory modification, privileged authentication expansion, endpoint compromise evidence, credential or token access, control-plane activity, persistence, data access, or incident-response validation.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

SOC Implementation Summary

SOC implementation should treat this report as a staged domain-controller compromise exposure model. The operational goal is to separate expected domain-controller behavior, suspicious domain-controller service interaction, suspected Netlogon-adjacent activity, sensitive Active Directory change, authentication expansion, endpoint follow-on behavior, downstream cloud or SaaS investigative leads, and confirmed compromise into distinct triage outcomes.

Initial Triage Priorities

·        Confirm whether the affected environment contains exposed, sensitive, or high-value domain controllers within the report scope.

·        Confirm domain-controller inventory, replication partners, approved administrative sources, monitoring systems, backup systems, vulnerability-management systems, endpoint-management platforms, and identity infrastructure.

·        Confirm whether Windows Security logs, Directory Services events, authentication telemetry, endpoint telemetry, NDR telemetry, and SIEM correlation are available.

·        Confirm whether Kerberos, NTLM, explicit credential use, machine-account authentication, and privileged-account activity can be queried and joined.

·        Confirm whether Active Directory object-change auditing captures sensitive object changes, before and after values where available, privileged group changes, machine-account changes, trust changes, delegation changes, Group Policy changes, and replication-permission changes.

·        Confirm whether endpoint telemetry is available for domain controllers, administrative hosts, jump hosts, likely source systems, and high-value internal systems.

·        Confirm whether AWS, Azure, GCP, SaaS, source-code, developer-platform, and CI/CD logs can be joined to identity, source, device, session, and incident timelines.

·        Confirm whether approved administrative workflows, change-control records, incident-response records, vendor-support records, security-testing records, and maintenance windows are available to analysts.

Triage Workflow

·        Start with the strongest upstream anchor, such as suspicious source-to-domain-controller communication, MS-NRPC-adjacent activity, RPC endpoint mapper activity, SMB domain-controller service access, source novelty, or domain-controller service interaction outside normal peer baselines.

·        Validate asset role, source role, domain-controller role, account role, and approved administrative context before treating activity as suspicious.

·        Join network-derived domain-controller activity to Windows Security events, Directory Services events, authentication telemetry, endpoint telemetry, and SIEM context.

·        Review sensitive Active Directory changes involving privileged groups, machine accounts, domain-controller accounts, domain trusts, delegation attributes, Group Policy, account-control attributes, password-related changes, and replication permissions.

·        Review authentication behavior involving privileged accounts, service accounts, machine accounts, Kerberos, NTLM, explicit credentials, failed-then-successful activity, administrative logons, and rare account-to-host paths.

·        Review endpoint follow-on activity on source systems, administrative hosts, domain controllers, jump hosts, and high-value systems.

·        Review downstream AWS, Azure, GCP, SaaS, source-code, developer-platform, and CI/CD activity only when timing, source path, user identity, device identity, identity session, cloud identity, or incident-response evidence supports linkage.

·        Apply change-control, approved administration, maintenance, monitoring, backup, vulnerability management, security testing, incident response, disaster recovery, and automation context before escalation.

SOC Outcome Categories

·        Expected domain-controller administration or infrastructure behavior.

·        Suspicious domain-controller service interaction requiring enrichment and baseline review.

·        Suspected Netlogon-adjacent activity requiring Windows, Active Directory, endpoint, and network correlation.

·        Sensitive Active Directory change requiring change-control and identity review.

·        Authentication expansion requiring privileged-account, service-account, machine-account, and host-path review.

·        Endpoint follow-on behavior requiring process, command-line, file, service, scheduled-task, and credential-access review.

·        Downstream investigative lead involving AWS, Azure, GCP, SaaS, source-code, CI/CD, or developer-platform activity.

·        Probable domain-controller compromise exposure requiring incident-response escalation.

·        Confirmed downstream compromise requiring containment, scoping, eradication, and recovery.

Hunt-Mode Deployment Guidance

·        Deploy new or revised detections in hunt mode before alert mode.

·        Validate parser behavior, field availability, field naming, timestamp alignment, event IDs, object identifiers, user identifiers, device identifiers, source IP handling, machine-account naming, cloud identity mapping, and SIEM normalization.

·        Validate timing windows for domain-controller service interaction, Active Directory modification, authentication expansion, endpoint follow-on activity, cloud activity, SaaS activity, and developer-platform activity.

·        Validate exception handling for approved administration, domain-controller maintenance, Active Directory maintenance, backup systems, monitoring systems, vulnerability scanning, security testing, identity-service maintenance, endpoint-management activity, cloud operations, CI/CD workflows, infrastructure-as-code deployment, incident response, and documented change-control activity.

·        Review historical matches to identify normal domain-controller operations, normal privileged authentication, normal service-account behavior, normal machine-account behavior, normal directory changes, normal endpoint administration, normal cloud administration, and normal incident-response patterns.

·        Tune severity thresholds before enabling alert mode.

·        Confirm that SOC analysts have access to enrichment fields, supporting logs, triage notes, approved workflow context, and escalation criteria.

Alert-Mode Promotion Criteria

·        Promote detections to alert mode only after field mappings are validated.

·        Promote detections only after telemetry completeness assumptions are tested.

·        Promote detections only after timing windows are tuned against local data.

·        Promote detections only after false-positive patterns are reviewed.

·        Promote detections only after query performance is validated.

·        Promote detections only after SOC triage procedures are documented.

·        Promote detections only after enrichment sources are available to analysts.

·        Promote detections only after exception logic is reviewed.

·        Promote detections only after incident-response evidence requirements are understood.

·        Promote detections only when alert routing, severity, ownership, and escalation paths are defined.

Escalation Guidance

·        Escalate when suspicious domain-controller service interaction is followed by sensitive Active Directory object modification.

·        Escalate when suspicious domain-controller service interaction is followed by privileged, service-account, machine-account, Kerberos, NTLM, explicit-credential, or administrative authentication expansion.

·        Escalate when suspicious domain-controller activity is followed by endpoint credential access, token access, suspicious process execution, persistence, tool staging, remote administration, lateral movement, or suspicious outbound communication.

·        Escalate when suspicious domain-controller activity is followed by AWS, Azure, or GCP IAM changes, role assignment, service-principal changes, service-account changes, access-key creation, token creation, logging changes, monitoring changes, security-control changes, secret access, key-management activity, storage access, workload access, or data export.

·        Escalate when multiple accounts, devices, domain controllers, internal systems, cloud resources, SaaS tenants, source-code systems, or developer platforms show related activity within the same incident window.

·        Escalate when evidence from at least two stages of the chain supports probable domain-controller compromise exposure.

·        Escalate when incident-response evidence validates credential theft, token theft, endpoint compromise, identity compromise, cloud compromise, persistence, lateral movement, or data access.

Containment and Response Considerations

·        Preserve relevant Windows, Active Directory, endpoint, network, authentication, SIEM, and cloud logs before retention windows expire.

·        Isolate or investigate source systems involved in suspicious domain-controller interaction.

·        Review domain controllers for suspicious process execution, service creation, scheduled task activity, file writes, credential-access behavior, and unauthorized administrative activity.

·        Disable, reset, or restrict affected accounts where appropriate.

·        Rotate or reset exposed privileged, service, machine, application, cloud, or automation credentials where appropriate.

·        Revoke active identity-provider sessions, refresh tokens, access tokens, API tokens, access keys, service-account keys, application credentials, SSH keys, certificates, and secrets where appropriate.

·        Review privileged group membership, domain trust configuration, delegation settings, Group Policy, account-control attributes, replication permissions, and sensitive Active Directory object changes.

·        Review AWS, Azure, GCP, SaaS, source-code, CI/CD, and developer-platform activity linked to suspicious domain-controller compromise context.

·        Conduct incident-response scoping before making attribution or confirmed-compromise statements.

·        Validate recovery actions against business-critical identity, authentication, cloud, and administrative dependencies.

Analyst Guardrails

·        Do not treat suspicious domain-controller communication as proof of exploitation by itself.

·        Do not treat Netlogon-adjacent activity as proof of successful compromise by itself.

·        Do not treat a single Windows event, Active Directory change, authentication event, endpoint alert, or cloud event as proof of compromise.

·        Do not treat cloud, SaaS, source-code, CI/CD, or developer-platform anomalies as Netlogon-linked unless source path, identity path, device path, session context, timing, or incident-response evidence supports linkage.

·        Do not treat missing telemetry as malicious until telemetry completeness, ingestion delay, parser behavior, timestamp skew, retention limits, and join reliability have been validated.

·        Do not infer actor attribution from S25 detection logic alone.

·        Do not deploy SIGMA patterns directly without backend conversion, local field mapping, and validation.

·        Do not use YARA as primary detection unless a stable recovered artifact exists and is validated.

S29 — Detection Coverage Summary

Coverage Summary

The Block 4 detection model provides strong behavior-led coverage for suspicious domain-controller interaction, sensitive Active Directory modification, privileged authentication expansion, endpoint follow-on behavior, credential-access activity, and downstream cloud-control-plane exposure. Coverage is strongest when network telemetry, Windows Security logs, Directory Services events, endpoint telemetry, authentication logs, cloud logs, asset inventory, change-control records, and incident-response evidence can be correlated.

Strong Coverage Areas

·        Suspicious source-to-domain-controller service interaction.

·        Domain-controller service access outside normal peer baselines.

·        MS-NRPC-adjacent activity where network or SIEM telemetry provides sufficient visibility.

·        RPC endpoint mapper and SMB domain-controller service activity.

·        Sensitive Active Directory object modification.

·        Privileged group, machine-account, domain-controller account, trust, delegation, Group Policy, account-control, and replication-permission changes.

·        Privileged, service-account, machine-account, Kerberos, NTLM, explicit-credential, and administrative authentication expansion.

·        Endpoint activity after suspicious domain-controller interaction, including suspicious execution, credential access, token access, tool staging, persistence, remote administration, and suspicious activity on internal systems.

·        Cloud, SaaS, source-code, CI/CD, developer-platform, identity, and control-plane activity linked to upstream domain-controller compromise indicators.

·        AWS, Azure, and GCP IAM, security-control, data, secrets, key-management, workload, storage, backup, Kubernetes, database, and developer-platform activity after upstream domain-controller compromise indicators.

Moderate Coverage Areas

·        Netlogon-adjacent behavior where packet-level MS-NRPC visibility is limited.

·        Suspicious domain-controller service access without confirmed follow-on activity.

·        Source-infrastructure novelty without downstream identity, endpoint, or cloud behavior.

·        Active Directory changes where before and after values are incomplete.

·        Endpoint behavior where domain-controller interaction context is inferred through SIEM, NDR, or identity enrichment rather than directly visible in endpoint telemetry.

·        Authentication expansion where Kerberos, NTLM, explicit-credential, machine-account, or service-account context is incomplete.

·        Cloud, SaaS, identity, developer-platform, or CI/CD anomalies where domain-controller linkage is partial.

·        Delayed or low-and-slow post-compromise activity that remains close to normal administrative baselines.

·        Suspicious activity involving valid credentials, reused sessions, reused tokens, expected cloud sessions, or expected administrator tooling.

Limited Coverage Areas

·        Artifact-only detection when no stable file, payload, script, memory artifact, webshell, binary, or reusable file-content pattern is recovered.

·        YARA-based detection without validated incident artifacts.

·        Environments without reliable domain-controller inventory.

·        Environments without source-to-domain-controller baselines.

·        Environments without Directory Services auditing.

·        Environments without endpoint telemetry on domain controllers, administrative hosts, source systems, or high-value internal systems.

·        Environments without Kerberos, NTLM, explicit-credential, machine-account, service-account, or privileged-authentication context.

·        Source attribution in environments affected by NAT, SASE routing, proxy infrastructure, shared jump hosts, third-party access paths, or incomplete device identifiers.

·        Cloud and SaaS activity that occurs through pre-existing sessions, reused tokens, different devices, different source paths, or outside validated correlation windows.

·        Endpoint activity on unmanaged systems, third-party-managed systems, personal devices, contractor devices, or assets without EDR coverage.

Systems With Primary Rule Coverage

·        NDR / Network Behavioral Analytics.

·        SentinelOne.

·        Splunk.

·        Elastic.

·        QRadar.

·        SIGMA.

·        AWS.

·        Azure.

·        GCP.

Systems With Conditional or No Primary Rule Coverage

·        YARA has no primary rules for this report.

·        YARA remains conditional and artifact-dependent.

·        YARA may support investigative hunting only if responders recover stable artifacts linked to suspicious domain-controller interaction or downstream activity.

Coverage Strength by Detection Phase

·        Initial domain-controller interaction coverage is strong where NDR, firewall, Windows, and SIEM telemetry capture source-to-domain-controller paths and domain-controller service use.

·        Active Directory modification coverage is strong where Directory Services auditing captures sensitive object changes and before / after values where available.

·        Authentication expansion coverage is moderate to strong where Kerberos, NTLM, explicit-credential, privileged-account, service-account, and machine-account telemetry can be joined.

·        Endpoint follow-on coverage is moderate to strong where EDR telemetry and network or identity enrichment can be joined.

·        Cloud downstream coverage is moderate to strong where AWS, Azure, and GCP audit logs, identity logs, source-path evidence, device evidence, and incident timelines can be correlated.

·        Artifact-based coverage is limited unless validated artifacts are recovered.

Coverage Confidence

·        High confidence applies when multiple linked stages are present, including suspicious domain-controller interaction, sensitive Active Directory modification, privileged authentication expansion, endpoint evidence, cloud activity, and incident-response validation.

·        Medium confidence applies when suspicious domain-controller interaction exists with partial Active Directory, authentication, endpoint, or cloud context.

·        Low confidence applies to isolated source novelty, isolated domain-controller communication, isolated authentication events, isolated directory changes, isolated endpoint alerting, isolated cloud activity, or isolated artifact matches.

·        Confirmed compromise confidence requires evidence beyond S25 detection logic, including validated incident-response findings, endpoint compromise evidence, identity compromise evidence, cloud compromise evidence, credential or token theft evidence, persistence, data access, or other confirmed downstream activity.

Coverage Limitations

·        Coverage depends on local telemetry availability, parser quality, timestamp alignment, field mappings, source identifiers, object identifiers, identity mappings, source-path context, asset inventories, and enrichment.

·        Coverage depends on whether network and SIEM telemetry retain enough detail to reconstruct source-to-domain-controller interaction.

·        Coverage depends on whether Windows Security, Directory Services, endpoint, authentication, and cloud telemetry can be joined reliably.

·        Coverage depends on whether NAT, SASE architecture, proxy infrastructure, shared jump hosts, third-party access paths, cloud federation, or reused sessions reduce attribution quality.

·        Coverage depends on whether cloud, SaaS, source-code, CI/CD, and developer-platform logs are retained and normalized.

·        Coverage depends on whether SOC analysts can access enrichment, change-control records, approved workflow records, and incident-response context.

·        Coverage should not be interpreted as universal prevention, universal exploit detection, or standalone attribution.

S30 — Intelligence Maturity Assessment

Intelligence Maturity Summary

The detection model for this report reflects a mature behavior-led intelligence posture. It moves beyond CVE-only, IOC-only, exploit-string-only, and artifact-only detection by focusing on domain-controller interaction, Active Directory control, authentication expansion, endpoint follow-on behavior, identity linkage, and downstream cloud-control-plane exposure.

Current Maturity Level

High.

Maturity Rationale

·        The model identifies domain-controller compromise exposure as a staged identity and infrastructure control problem rather than a single exploit event.

·        The model separates suspicious domain-controller interaction, suspected Netlogon-adjacent activity, sensitive Active Directory modification, authentication expansion, endpoint follow-on behavior, downstream investigative leads, and confirmed compromise.

·        The model uses durable behavioral anchors that remain useful when exploit strings, packet content, source infrastructure, tool names, user-agent values, timing, post-compromise actions, or cloud targets change.

·        The model avoids single-signal attribution and requires supporting evidence before declaring exploitation, compromise, cloud compromise, SaaS compromise, credential theft, token theft, or actor attribution.

·        The model includes network, endpoint, SIEM, SIGMA, and cloud-native coverage across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

·        The model correctly treats YARA as conditional and artifact-dependent rather than forcing weak artifact-led coverage into a behavior-led report.

·        The model supports SOC operations through hunt-mode deployment, field validation, timing-window tuning, exception handling, false-positive review, query-performance testing, and triage readiness.

Intelligence Strengths

·        Strong behavior-led framing.

·        Strong domain-controller interaction model.

·        Strong Active Directory control and authentication-expansion model.

·        Strong separation of suspicious activity from confirmed compromise.

·        Strong non-attribution discipline.

·        Strong coverage across network, endpoint, Windows, Active Directory, authentication, SIEM, and cloud telemetry.

·        Strong variant resilience against changes in exploit mechanics, packet content, source infrastructure, tooling, timing, and downstream activity.

·        Strong support for SOC triage and incident scoping.

·        Strong cloud downstream exposure model across AWS, Azure, and GCP.

·        Strong support for future amendment if new CVEs, proof-of-concept behavior, actor adoption, cloud abuse, or post-exploitation behavior emerges.

Maturity Constraints

·        Full maturity depends on domain-controller inventory, approved administrative-source inventory, and source-to-domain-controller baselines.

·        Full maturity depends on reliable Windows Security, Directory Services, authentication, endpoint, NDR, SIEM, and cloud telemetry.

·        Full maturity depends on Kerberos, NTLM, explicit-credential, machine-account, service-account, and privileged-authentication visibility.

·        Full maturity depends on endpoint telemetry coverage for domain controllers, administrative hosts, jump hosts, source systems, and high-value internal systems.

·        Full maturity depends on cloud, SaaS, source-code, developer-platform, and CI/CD log availability.

·        Full maturity depends on source enrichment, account enrichment, asset inventory, privileged-account inventory, machine-account inventory, service-account inventory, cloud inventory, sensitive-asset inventory, and change-control integration.

·        Full maturity depends on local SIEM field mappings, parser reliability, timestamp alignment, query performance, exception handling, and SOC triage readiness.

·        Full maturity is reduced in environments with NAT, SASE routing, proxy infrastructure, shared jump hosts, third-party access paths, weak device attribution, incomplete endpoint coverage, cloud session reuse, token reuse, or weak cloud identity linkage.

Operational Maturity Requirements

·        Maintain current domain-controller inventory.

·        Maintain current replication partner, administrative source, monitoring system, backup system, vulnerability-management, endpoint-management, identity infrastructure, and privileged management inventory.

·        Maintain privileged-user, service-account, machine-account, domain-controller account, administrator, third-party, contractor, break-glass, dormant, stale, recently re-enabled, and low-frequency account inventories.

·        Maintain baselines for normal domain-controller service interaction, administrative source behavior, machine-account behavior, service-account behavior, privileged authentication, directory changes, and endpoint administration.

·        Maintain internal asset inventories for domain controllers, identity infrastructure, jump hosts, privileged management systems, backup systems, endpoint-management platforms, source-code systems, CI/CD systems, sensitive file shares, databases, and high-value applications.

·        Maintain cloud inventories for AWS accounts, Azure tenants and subscriptions, GCP organizations and projects, privileged roles, service principals, service accounts, managed identities, sensitive storage, secrets, keys, workloads, Kubernetes clusters, databases, and backup systems.

·        Maintain change-control, vendor-support, helpdesk, maintenance, security-testing, vulnerability-management, software-deployment, cloud-operations, developer-workflow, CI/CD-maintenance, and incident-response records for triage.

Detection Engineering Maturity Requirements

·        Validate all local field mappings before production alerting.

·        Validate event-action normalization across Windows, Active Directory, endpoint, NDR, proxy, DNS, cloud, SaaS, source-code, CI/CD, and SIEM telemetry.

·        Validate source-to-domain-controller sequence logic.

·        Validate Active Directory object-change correlation logic.

·        Validate authentication-expansion correlation logic.

·        Validate endpoint and internal destination linkage.

·        Validate cloud, SaaS, source-code, and CI/CD linkage.

·        Validate source-path handling where NAT, SASE, proxy, shared jump hosts, third-party access paths, identity federation, or cloud session reuse may transform attribution.

·        Validate timing windows for immediate, delayed, repeated, and low-and-slow activity.

·        Validate exception handling.

·        Validate baseline false-positive rates.

·        Validate query performance.

·        Validate SOC triage workflow.

·        Validate enrichment availability.

·        Validate incident-response evidence requirements.

·        Do not enable alert mode until these local validation requirements are complete.

Recommended Maturity Improvements

·        Improve domain-controller inventory and source-to-domain-controller baselining.

·        Improve Windows Security and Directory Services auditing for privileged authentication, machine-account behavior, sensitive object changes, Group Policy changes, trust changes, delegation changes, and replication-permission changes.

·        Improve endpoint coverage for domain controllers, administrative hosts, jump hosts, source systems, and high-value internal systems.

·        Improve internal network visibility for domain-controller service interaction, identity-service access, privileged resource access, administrative protocols, databases, file shares, jump hosts, and management systems.

·        Improve cloud audit coverage for AWS, Azure, and GCP.

·        Improve SaaS, source-code, developer-platform, and CI/CD logging for downstream investigation.

·        Improve enrichment for source reputation, ASN, geography, hosting providers, anonymization services, remote-access infrastructure, SASE egress, vendor access, first-seen source activity, account role, asset role, and service ownership.

·        Improve user, device, host, domain-controller, Active Directory object, cloud identity, and asset identifier consistency across telemetry platforms.

·        Improve change-control integration for domain-controller administration, Active Directory changes, authentication-policy changes, privileged access changes, endpoint-management activity, cloud operations, developer workflows, CI/CD maintenance, and incident response.

·        Improve SOC runbooks for suspicious domain-controller interaction, Active Directory change review, authentication-expansion validation, endpoint follow-on investigation, downstream cloud exposure, and confirmed compromise escalation.

Residual Intelligence Risk

Residual risk remains where attackers use valid credentials, valid tokens, reused cloud sessions, expected administrator pathways, approved remote-access paths, shared jump hosts, service accounts, machine accounts, or low-and-slow post-compromise behavior that blends with expected administrative activity.

Residual risk also remains where telemetry is incomplete, identity linkage is weak, source attribution is transformed, endpoint coverage is absent, Directory Services auditing is incomplete, cloud logs are incomplete, or SOC teams cannot access change-control and incident-response context.

The detection model reduces residual risk by requiring multiple linked behavioral stages, but it does not eliminate the need for local validation, incident-response review, and environment-specific tuning.

Final Intelligence Maturity Assessment

The Block 4 detection model is mature and operationally useful for identifying Netlogon-linked domain-controller compromise exposure when required telemetry is available and locally validated. It is strongest as a behavior-led detection and triage model and should not be interpreted as a universal exploit-confirmation or actor-attribution framework.

S31 — Telemetry Dependencies

Windows Netlogon remote code execution and domain-controller compromise exposure requires telemetry that can prove whether suspicious domain-controller interaction remained limited to exposure or attempted exploitation, or whether it affected Active Directory trust, machine-account state, privileged authentication, replication-related permissions, security controls, or downstream access. The central dependency is the ability to correlate Netlogon-adjacent activity, MS-NRPC/RPC/SMB service access, Windows Security events, Directory Services events, authentication logs, endpoint telemetry, network telemetry, asset context, and change-management evidence into a single identity-control-plane investigation model.

Domain-Controller Windows Security Telemetry

·        Domain-controller Windows Security logs must capture authentication events, privileged logons, account changes, machine-account activity, group membership changes, security-policy changes, and sensitive logon behavior.

·        Required fields include source host, source IP, target domain controller, account name, account domain, machine account, logon type, authentication package, event code, action, result, timestamp, and target object where available.

·        Windows Security telemetry is required to determine whether suspicious Netlogon-adjacent activity was followed by privileged authentication, machine-account changes, group changes, policy changes, or abnormal authentication expansion.

Directory Services and Active Directory Object-Change Telemetry

·        Directory Services telemetry must capture changes involving domain-controller accounts, machine accounts, privileged groups, domain trusts, delegation settings, replication permissions, Group Policy, and sensitive directory-service objects.

·        Required fields include object distinguished name, object class, attribute changed, previous value where available, new value where available, account performing the change, domain controller recording the event, timestamp, and change result.

·        Directory Services telemetry is required to distinguish attempted Netlogon abuse from actual identity-plane impact.

Netlogon, System, and Domain-Controller Service Telemetry

·        Netlogon operational, diagnostic, secure-channel, and domain-controller System telemetry should capture secure-channel failures, Netlogon service anomalies, authentication-service instability, unexpected service restarts, system faults, and domain-controller disruption.

·        Required context includes domain controller, source host, source account where available, error type, service state, timestamp, restart behavior, and related authentication or secure-channel context.

·        Netlogon and System telemetry are required to support triage of attempted exploitation, failed exploitation, exploit-adjacent instability, and post-compromise service disruption.

Network and Domain-Controller Service Telemetry

·        Network telemetry must capture source-to-domain-controller access for Netlogon, MS-NRPC, RPC endpoint mapper, SMB, Kerberos, LDAP, and other domain-controller service paths.

·        Required fields include source host, destination domain controller, source IP, destination IP, protocol, service classification, destination port, session timing, connection count, byte volume, directionality, source segment, and destination asset role.

·        Network telemetry is required to identify non-standard source paths, repeated domain-controller service access, multi-domain-controller probing, VPN ingress sources, branch network activity, workstation network activity, and newly observed internal source behavior.

Endpoint and EDR Telemetry

·        EDR telemetry should be available on domain controllers and suspected source systems wherever technically feasible.

·        Required endpoint telemetry includes process creation, parent-child process lineage, command-line execution, PowerShell activity, WMI and WinRM activity, service creation, scheduled task creation, file creation, DLL loading, registry modification, credential-access behavior, LSASS interaction, NTDS access, and defensive-tool interference.

·        Endpoint telemetry is required to validate whether suspicious domain-controller interaction was followed by execution, credential access, persistence, lateral-movement preparation, or security-control disruption.

Authentication and Identity Telemetry

·        Authentication telemetry should capture Kerberos activity, NTLM activity, service-ticket behavior, machine-account authentication, privileged logons, service-account use, and abnormal authentication expansion.

·        Required fields include account name, account type, source host, destination host, domain controller, authentication package, ticket or service name where available, logon type, result, timestamp, and user-to-host relationship.

·        Authentication telemetry is required to determine whether suspicious domain-controller interaction was followed by privileged account use, abnormal machine-account behavior, service-ticket anomalies, or lateral authentication expansion.

VPN, Remote-Access, and Source-Path Telemetry

·        VPN, remote-access, branch, and privileged-access telemetry should capture user, device, source IP, assigned internal address, session duration, ingress path, authentication outcome, geolocation context, and connection path for systems that later interact with domain controllers.

·        Source-path telemetry is required to determine whether suspicious domain-controller interaction originated from VPN ingress ranges, remote users, branch networks, unmanaged devices, privileged-access workstations, or approved administrative paths.

·        This telemetry should enrich source attribution, but it should not replace domain-controller, authentication, Directory Services, endpoint, or network telemetry.

Asset, Account, and Change-Control Telemetry

·        Required context includes domain-controller inventory, replication topology, Active Directory site topology, replication partner inventory, privileged account inventory, machine-account inventory, service-account inventory, administrative jump-host inventory, backup-system inventory, identity-management system inventory, and vulnerability-management system inventory.

·        Change-control records should include approved domain joins, trust repair, replication maintenance, machine-account resets, domain-controller maintenance, backup operations, patching, identity-management workflows, security testing, and incident-response activity.

·        Asset, account, and change-control context is required to separate suspicious Netlogon-adjacent activity from legitimate administration, maintenance, replication, monitoring, backup, and identity-infrastructure workflows.

Cloud, SaaS, Developer-Platform, and Backup Telemetry

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup telemetry should be used to scope downstream exposure after suspicious domain-controller or privileged-authentication activity.

·        Relevant telemetry includes cloud control-plane activity, SaaS administration, identity administration, backup-system access, source-code repository access, CI/CD workflow changes, access-key creation, API token activity, privileged role changes, secret access, data export, and recovery-system interaction.

·        Downstream telemetry should not be attributed to Netlogon compromise unless timing, identity, source host, authentication, endpoint, network, or incident-response evidence links it to the suspicious domain-controller activity.

S32 — Detection Limitations

Detection of Windows Netlogon remote code execution and domain-controller compromise exposure is limited by whether the organization can reconstruct the relationship between suspicious domain-controller service access, authentication behavior, Active Directory object changes, endpoint activity, and downstream access. Environments that rely only on patch state, scanner output, exposed Netlogon services, isolated Netlogon errors, or single RPC connections will not have enough evidence for high-confidence compromise determination.

Primary Limitations

·        Limited Netlogon diagnostic logging may reduce direct visibility into secure-channel behavior and force heavier reliance on Windows Security, Directory Services, network, endpoint, and change-management correlation.

·        Metadata-only network visibility may identify suspicious source-to-domain-controller access patterns but may not confirm protocol-level exploit behavior.

·        Missing Directory Services auditing may prevent reliable validation of machine-account changes, domain trust changes, privileged group changes, delegation changes, replication-permission changes, and Group Policy manipulation.

·        Missing EDR coverage on domain controllers may reduce visibility into process execution, credential access, persistence, file staging, defensive-tool tampering, and post-exploitation behavior.

·        Missing endpoint telemetry on suspected source hosts may prevent identification of discovery, exploit staging, credential-access preparation, remote administration tooling, or lateral-movement preparation.

·        Missing authentication telemetry may prevent defenders from identifying privileged authentication expansion, abnormal machine-account authentication, service-ticket anomalies, or rare user-to-host access.

·        Missing VPN, branch, remote-access, or privileged-access telemetry may reduce confidence when attributing suspicious domain-controller activity to a user, device, ingress path, or administrative route.

·        Poor asset inventory may make it difficult to distinguish domain controllers, replication partners, identity-management systems, administrative jump hosts, monitoring systems, backup systems, unmanaged devices, and ordinary workstations.

·        Missing change-control records may increase false positives around domain join activity, trust repair, machine-account reset workflows, replication administration, patching, backup operations, and domain-controller maintenance.

·        Poor timestamp normalization can break sequence logic between suspicious domain-controller service access, authentication events, Directory Services changes, endpoint activity, and downstream access.

Detection Boundary

·        Patch state is an exposure signal, not proof of active exploitation.

·        Vulnerability scan output is not proof of Netlogon exploitation.

·        Exposed Netlogon services are not proof of compromise by themselves.

·        Isolated Netlogon errors are not compromise indicators unless correlated with suspicious source context, repeated behavior, authentication anomalies, or downstream identity-plane activity.

·        A single RPC, SMB, or domain-controller service connection is not sufficient to infer exploitation.

·        Domain join activity, trust repair, machine-account reset activity, replication maintenance, backup activity, vulnerability scanning, or domain-controller troubleshooting should not be escalated as exploitation when it aligns with approved workflows and known administrative systems.

·        Privileged authentication is not proof of domain-controller compromise unless linked to suspicious domain-controller interaction, identity-plane change, endpoint evidence, or incident-response findings.

·        Cloud, SaaS, backup, developer-platform, source-code, or CI/CD anomalies should remain downstream investigative leads unless linked to suspicious domain-controller activity through timing, identity, source host, authentication, endpoint, or incident-response evidence.

·        Detection logic must not rely on prior alert state, another rule’s output, analyst judgment after alert generation, DRI, or TCR as an input.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, or withheld when required telemetry is unavailable, incomplete, delayed, or not normalized. Suspicious Netlogon-adjacent activity may be analytically important but unsuitable for high-confidence alerting if the organization cannot validate source role, destination domain controller, timing, authentication behavior, Active Directory object changes, endpoint activity, change context, and downstream access within bounded and locally validated correlation windows.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making domain-controller trust measurable, enforceable, and recoverable after suspicious Netlogon-adjacent activity. The objective is not only to patch Windows Server, but to prove that domain-controller service access, machine-account state, privileged authentication, Active Directory object integrity, and downstream identity-dependent access remain trustworthy.

Domain-Controller Exposure and Patch Governance

·        Maintain a complete inventory of writable domain controllers, read-only domain controllers, domain-controller IP ranges, Active Directory sites, replication partners, and domain-controller service exposure paths.

·        Validate Windows Server and domain-controller patch posture on a defined schedule and during active exploitation windows.

·        Prioritize remediation for domain controllers supporting privileged access, identity infrastructure, backup systems, cloud administration, SaaS administration, developer access, source-code access, CI/CD access, or regulated business operations.

·        Treat unknown domain-controller patch posture, unmanaged service exposure, stale domain-controller inventory, or incomplete replication topology as identity-control-plane risk.

Domain-Controller Service Access Control

·        Restrict Netlogon, MS-NRPC, RPC endpoint mapper, SMB, LDAP, Kerberos, and administrative domain-controller service access to approved systems and network paths.

·        Limit direct domain-controller service access from workstation networks, VPN ingress ranges, branch networks, unmanaged systems, non-administrative servers, and newly observed internal sources.

·        Baseline approved access from replication partners, administrative jump hosts, identity-management systems, monitoring systems, backup systems, vulnerability management platforms, and authorized maintenance systems.

·        Treat new or unexplained source-to-domain-controller access paths as trust-impacting events requiring validation.

Active Directory Change Governance

·        Require auditable workflows for machine-account password resets, domain join activity, trust repair, privileged group changes, domain trust changes, delegation changes, replication-permission changes, and Group Policy modification.

·        Monitor for domain-controller account changes, machine-account changes, privileged group membership changes, trust changes, and replication-permission changes outside approved maintenance windows.

·        Require change-management evidence before accepting sensitive Active Directory changes as legitimate.

·        Treat unexplained identity-plane changes near suspicious Netlogon-adjacent activity as high-priority escalation events.

Privileged Identity and Service-Account Hardening

·        Review privileged domain accounts, domain administrators, identity administrators, backup administrators, security administrators, service accounts, emergency-access accounts, stale accounts, dormant accounts, recently re-enabled accounts, and low-frequency high-privilege accounts.

·        Reduce standing privilege where possible and enforce least privilege for identity-management, backup, security, and administrative workflows.

·        Require stronger controls for accounts that can modify domain-controller accounts, domain trusts, privileged groups, replication permissions, delegation settings, Group Policy, or backup infrastructure.

·        Validate whether privileged authentication after suspicious domain-controller interaction is expected, approved, and tied to a known administrative workflow.

Domain-Controller EDR and Logging Hardening

·        Deploy EDR coverage on domain controllers wherever technically feasible.

·        Enable and validate Windows Security, Directory Services, System, Netlogon, authentication, and endpoint telemetry needed to support domain-controller trust investigations.

·        Preserve telemetry for enough time to reconstruct pre-exploitation activity, suspicious service interaction, authentication expansion, Active Directory changes, endpoint execution, and downstream access.

·        Treat missing domain-controller telemetry as a material detection and response limitation.

Segmentation and Source-Path Governance

·        Segment domain-controller service access from ordinary workstation networks, VPN ingress ranges, branch networks, and unmanaged systems.

·        Define approved administrative paths for domain-controller management, replication maintenance, backup operations, vulnerability scanning, identity-management workflows, and incident response.

·        Monitor for cross-site, cross-segment, or cross-domain authentication patterns that do not align with Active Directory topology or administrative practice.

·        Review legacy systems and third-party integrations that generate secure-channel noise and document any required exceptions.

Incident Response and Recovery Hardening

·        Create response procedures for suspected Netlogon-adjacent exploitation, suspicious domain-controller service access, machine-account manipulation, domain trust change, privileged authentication expansion, replication-like access, and security-control disruption.

·        Require rapid validation of domain-controller state, machine-account state, domain trusts, privileged group membership, replication permissions, delegation settings, Group Policy, and service-account activity.

·        Prepare decision paths for privileged credential reset, service-account rotation, domain-controller isolation, domain-controller rebuild, backup-trust validation, cloud and SaaS scoping, and enterprise identity restoration.

·        Treat suspected domain-controller trust compromise as an identity-control-plane incident, not a routine server alert.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat Active Directory and domain-controller trust as monitored control-plane infrastructure rather than an assumed condition. The architecture must connect domain-controller exposure, Netlogon-adjacent service activity, authentication telemetry, Directory Services changes, endpoint context, network activity, privileged identity context, downstream access, and recovery workflows into a single validation model.

Architecture Layer 1: Domain-Controller Inventory and Exposure Governance

Domain-controller inventory and exposure telemetry establishes what identity infrastructure exists and whether it is hardened. This layer captures writable domain controllers, read-only domain controllers, domain-controller IP ranges, Active Directory sites, replication partners, domain-controller service interfaces, patch posture, exposed service paths, segmentation posture, and compensating controls.

Architecture Layer 2: Domain-Controller Service Access Monitoring

Domain-controller service monitoring determines whether source systems are interacting with domain controllers through expected or suspicious paths. This layer captures Netlogon, MS-NRPC, RPC endpoint mapper, SMB, LDAP, Kerberos, authentication, and administrative service access by source host, source segment, destination domain controller, protocol, timing, frequency, and asset role.

Architecture Layer 3: Active Directory Object and Trust Validation

Active Directory object and trust validation determines whether suspicious domain-controller interaction affected identity-plane state. This layer captures machine-account changes, domain-controller account changes, privileged group changes, domain trust modifications, replication-permission changes, delegation changes, Group Policy changes, and sensitive directory-service object changes.

Architecture Layer 4: Privileged Authentication and Account Context

Privileged authentication and account context determines whether suspicious domain-controller activity was followed by high-risk identity use. This layer captures privileged logons, machine-account authentication, service-account use, Kerberos and NTLM anomalies, service-ticket behavior, low-frequency high-privilege account activity, stale or dormant account activity, and administrator workflow context.

Architecture Layer 5: Endpoint, Network, and Downstream Access Monitoring

Endpoint, network, and downstream access monitoring determines whether suspicious domain-controller activity expanded into operational control. This layer captures source-host execution, domain-controller endpoint behavior, credential access, LSASS or NTDS access, lateral movement, administrative protocol use, backup-system access, cloud or SaaS administration, developer-platform access, source-code access, CI/CD activity, database access, file-server access, and sensitive application access.

Architecture Layer 6: SOC Correlation and Identity-Trust Restoration Workflow

SOC correlation joins suspicious domain-controller service activity with authentication, Directory Services, endpoint, network, change-control, and downstream access evidence. The response workflow requires source-path validation, identity-plane validation, domain-controller integrity review, privileged-account scoping, machine-account review, trust review, replication-permission review, backup-trust validation, and identity-control-plane restoration.

Architecture Outcome

The architecture should enable the organization to answer five questions during an incident:

·        Did suspicious activity reach a domain-controller service path?

·        Did the activity align with an approved source, role, change window, or administrative workflow?

·        Did the activity affect machine-account state, domain-controller accounts, domain trusts, privileged groups, replication permissions, or other Active Directory objects?

·        Did the activity lead to privileged authentication, credential access, lateral movement, backup-system access, cloud or SaaS administration, source-code exposure, CI/CD exposure, or sensitive business-system access?

·        Can domain-controller trust and Active Directory integrity be restored with confidence before affected systems, accounts, or access paths return to normal operation?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Windows Server and domain-controller patch governance.

·        Complete domain-controller asset inventory.

·        Domain-controller service exposure reduction.

·        Network segmentation for domain-controller service paths.

·        Approved administrative source enforcement.

·        Privileged access workstation use for domain-controller administration.

·        Least-privilege domain administration.

·        Service-account governance.

·        Machine-account workflow governance.

·        Domain trust governance.

·        Replication-permission governance.

·        Group Policy change governance.

·        Backup-system access restrictions.

·        Strong authentication for privileged identity operations.

·        Change-control governance for domain-controller and Active Directory administration.

Detective Controls

·        Netlogon and MS-NRPC activity monitoring.

·        RPC endpoint mapper and SMB domain-controller service monitoring.

·        Source-to-domain-controller path deviation detection.

·        Multi-domain-controller service access detection.

·        Windows Security event monitoring.

·        Directory Services object-change monitoring.

·        Domain-controller System and Netlogon fault monitoring.

·        Privileged authentication expansion monitoring.

·        Machine-account change monitoring.

·        Domain trust change monitoring.

·        Privileged group change monitoring.

·        Replication-permission change monitoring.

·        Domain-controller EDR monitoring.

·        Source-host endpoint monitoring.

·        Lateral-movement and outbound communication correlation.

·        Cloud, SaaS, developer-platform, source-code, CI/CD, and backup access correlation after suspicious domain-controller activity.

Responsive Controls

·        Suspicious source isolation.

·        Domain-controller access containment.

·        Privileged credential reset decisioning.

·        Service-account review and rotation.

·        Machine-account validation.

·        Domain-controller account review.

·        Domain trust validation.

·        Replication-permission review.

·        Privileged group membership review.

·        Domain-controller forensic triage.

·        Endpoint triage for suspected source systems.

·        Backup-trust validation.

·        Cloud and SaaS administrative scoping.

·        Source-code and CI/CD exposure review.

·        Domain-controller rebuild planning where required.

·        Active Directory integrity restoration before return to normal operation.

Governance Controls

·        Approved domain-controller inventory.

·        Approved replication topology.

·        Approved administrative jump-host inventory.

·        Approved privileged account inventory.

·        Approved service-account inventory.

·        Approved machine-account management workflows.

·        Approved domain join workflows.

·        Approved trust repair workflows.

·        Approved replication administration workflows.

·        Approved backup administration workflows.

·        Approved vulnerability-management workflows.

·        Approved incident-response workflows.

·        Change-control records for domain-controller and Active Directory changes.

·        Executive reporting for high-risk identity-control-plane events.

·        Risk-register tracking for domain-controller trust compromise exposure.

Control Mapping Summary

The strongest control posture combines prevention of unauthorized domain-controller service access, detection of suspicious identity-plane change, and response workflows that restore Active Directory trust. Controls should be prioritized for domain controllers, privileged identity, machine-account workflows, replication permissions, domain trusts, backup systems, cloud and SaaS administration, source-code systems, CI/CD environments, and business-critical systems that depend on Active Directory.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

Windows Netlogon remote code execution and domain-controller compromise exposure is a well-defined behavior class, but organization-specific maturity depends on whether domain-controller service activity can be correlated with authentication events, Directory Services changes, endpoint behavior, network telemetry, asset context, and change-management evidence. Many environments can identify domain-controller exposure or patch state, but fewer can reconstruct whether suspicious Netlogon-adjacent activity affected machine-account state, domain-controller trust, privileged authentication, replication permissions, or downstream access.

Strengths

·        The behavior pattern is durable because it focuses on domain-controller trust impact rather than one CVE, exploit string, packet signature, proof-of-concept tool, source host, or event ID.

·        The core sequence is analytically clear: domain-controller service reachability, suspicious Netlogon-adjacent interaction, possible machine-account or trust manipulation, privileged authentication expansion, and downstream access.

·        Detection opportunities are strong where Windows Security logs, Directory Services events, Netlogon telemetry, authentication logs, EDR telemetry, NDR telemetry, asset inventory, and change-management records can be correlated.

·        Defensive controls can be mapped directly to patch governance, domain-controller service restriction, Active Directory change governance, privileged identity hardening, domain-controller logging, segmentation, and identity-trust restoration.

·        S17 TTP coverage can remain lean while still capturing the core operational chain.

Maturity Gaps

·        Netlogon operational, diagnostic, and secure-channel logging may not be enabled or retained with enough detail.

·        Directory Services auditing may not capture the object changes needed to validate machine-account, trust, privileged group, replication-permission, delegation, or Group Policy impact.

·        Domain controllers may lack EDR coverage or complete endpoint telemetry.

·        Network telemetry may identify source-to-domain-controller access but lack payload or protocol-level detail.

·        Source-host roles, administrative paths, VPN ranges, branch networks, replication partners, and approved maintenance systems may not be well documented.

·        Change-management records may not reliably explain domain join activity, trust repair, machine-account resets, replication administration, domain-controller maintenance, backup operations, or identity-management workflows.

·        Authentication baselines may not distinguish privileged account use, machine-account authentication, service-account behavior, and abnormal authentication expansion.

·        Downstream cloud, SaaS, backup, source-code, CI/CD, and developer-platform logs may not be linked to suspicious domain-controller activity with enough confidence.

·        Organizations may over-rely on patch state, scanner output, isolated Netlogon errors, or single-event alerts rather than validating the full identity-plane sequence.

Maturity Improvement Priorities

·        Normalize domain-controller Windows Security, System, Netlogon, Directory Services, authentication, EDR, NDR, and SIEM telemetry.

·        Improve domain-controller inventory, Active Directory site topology, replication partner inventory, and administrative source baselines.

·        Improve visibility into Netlogon-adjacent, MS-NRPC, RPC endpoint mapper, SMB, LDAP, Kerberos, and administrative service access to domain controllers.

·        Improve auditing for machine-account changes, domain-controller account changes, privileged group changes, domain trust changes, replication-permission changes, delegation changes, and Group Policy changes.

·        Improve privileged account, service-account, machine-account, dormant-account, recently re-enabled account, and low-frequency high-privilege account baselines.

·        Improve correlation between suspicious domain-controller activity and downstream endpoint, network, backup, cloud, SaaS, source-code, CI/CD, and sensitive application access.

·        Add domain-controller trust compromise validation steps to SOC and incident-response playbooks.

Maturity Outlook

Maturity can improve quickly if the organization prioritizes identity-control-plane reconstruction and source-to-domain-controller correlation. The highest-value improvements are domain-controller telemetry normalization, Directory Services auditing, privileged identity baselines, domain-controller EDR coverage, source-path governance, change-control validation, and downstream access correlation.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that attackers can exploit or abuse Netlogon-adjacent domain-controller paths without detection and reduce the response burden when domain-controller trust cannot be validated quickly. The objective is measurable Active Directory trust, not patching alone.

Priority 1: Establish Domain-Controller Trust Assurance as a Security Metric

·        Define measurable assurance metrics for domain-controller inventory, patch posture, Netlogon-adjacent service access, machine-account changes, domain trust changes, privileged group changes, replication permissions, privileged authentication, and downstream access.

·        Track trust-assurance completeness for domain controllers, privileged accounts, service accounts, machine accounts, backup administrators, identity administrators, security administrators, and high-value administrative paths.

·        Report unresolved domain-controller trust gaps as identity-control-plane risks.

·        Treat unexplained identity-plane changes near suspicious Netlogon-adjacent activity as executive-relevant control failures.

Priority 2: Harden Domain-Controller Service Exposure

·        Maintain a live inventory of writable domain controllers, read-only domain controllers, domain-controller IP ranges, Active Directory sites, replication partners, exposed service paths, Windows Server versions, patch posture, and compensating controls.

·        Restrict Netlogon, MS-NRPC, RPC endpoint mapper, SMB, LDAP, Kerberos, and administrative domain-controller service access to approved source systems and network paths.

·        Prioritize hardening for domain controllers supporting privileged identity, backup systems, cloud administration, SaaS administration, source-code systems, CI/CD environments, regulated data, or business-critical applications.

·        Reduce unmanaged, unknown, or broadly reachable domain-controller service exposure.

Priority 3: Strengthen Privileged Identity and Active Directory Change Governance

·        Reduce standing privilege for domain administrators, identity administrators, backup administrators, security administrators, service accounts, emergency-access accounts, dormant accounts, recently re-enabled accounts, and low-frequency high-privilege accounts.

·        Require change-control evidence for machine-account resets, domain trust changes, privileged group changes, replication-permission changes, delegation changes, and Group Policy changes.

·        Review administrative workflows for domain joins, trust repair, replication maintenance, backup operations, identity-management activity, vulnerability scanning, security testing, and incident response.

·        Require privileged-access governance for systems that can modify domain-controller accounts, domain trusts, replication permissions, or sensitive Active Directory objects.

Priority 4: Improve Domain-Controller Telemetry and Correlation

·        Improve telemetry that links Netlogon-adjacent activity, MS-NRPC activity, RPC endpoint mapper traffic, SMB domain-controller service access, Windows Security events, Directory Services changes, authentication logs, EDR telemetry, and network telemetry.

·        Baseline normal domain-controller service access by source host, source segment, asset role, Active Directory site, administrative workflow, and maintenance window.

·        Prioritize detection for non-standard source-to-domain-controller activity followed by machine-account changes, domain trust changes, privileged group changes, replication-like access, privileged authentication, endpoint activity, or security-control disruption.

·        Validate timestamp normalization, field mapping, lookup accuracy, and SIEM correlation quality before promoting hunt logic into alerting.

Priority 5: Improve Downstream Exposure Correlation

·        Correlate suspicious domain-controller activity with access to identity infrastructure, privileged management systems, jump hosts, backup systems, endpoint-management platforms, file servers, databases, cloud consoles, SaaS administration portals, developer platforms, source-code systems, CI/CD environments, and sensitive business applications.

·        Monitor privileged cloud and SaaS actions after suspicious domain-controller or identity-plane activity, including role changes, access-key creation, API token creation, application consent changes, repository access, CI/CD workflow changes, secret access, and data export.

·        Treat downstream cloud, SaaS, developer, source-code, CI/CD, and backup activity as investigative leads unless linked to suspicious domain-controller evidence.

·        Build incident-response workflows that scope identity-control-plane impact across internal and cloud-connected systems.

Priority 6: Strengthen SOC Response to Domain-Controller Trust Failure

·        Create or update playbooks for suspicious Netlogon-adjacent activity, machine-account manipulation, domain-controller account changes, domain trust modification, replication-permission changes, privileged authentication expansion, and domain-controller compromise.

·        Require responders to validate source role, destination domain controller, Netlogon-adjacent activity, Windows Security events, Directory Services changes, authentication expansion, endpoint activity, change-management context, and downstream access.

·        Require rapid source containment, privileged credential reset decisioning, service-account review, machine-account validation, trust review, replication-permission review, backup-trust validation, and downstream access scoping when suspicious identity-plane activity is confirmed.

·        Require Active Directory trust restoration before affected systems, accounts, access paths, or domain-controller workflows return to normal operation.

Strategic Outcome

The organization should be able to prove whether suspicious Netlogon-adjacent activity affected domain-controller trust, detect when identity-plane evidence does not reconcile, scope downstream access with confidence, and restore Active Directory trust before attackers convert domain-controller compromise into broader enterprise disruption.

S38 — Attack Economics & Organizational Impact Model

Windows Netlogon remote code execution and domain-controller compromise exposure changes the economics of intrusion by allowing adversaries to pursue control over the enterprise identity trust layer instead of defeating each downstream system individually. When suspicious Netlogon-adjacent activity can affect a domain controller, machine-account state, privileged authentication, replication permissions, or Active Directory integrity, the attacker can increase operational leverage while forcing defenders to validate whether the domain itself remained trustworthy.

Adversary Economic Advantage

·        Domain-controller compromise can reduce attacker friction because downstream systems may already trust Active Directory authentication, machine-account relationships, privileged groups, and domain-issued access.

·        Netlogon-adjacent abuse can create uncertainty around domain-controller trust, machine-account state, domain trusts, replication permissions, and privileged authentication.

·        Successful exploitation or strongly suspected trust manipulation can shift attacker effort from broad endpoint compromise to targeted abuse of the identity control plane.

·        Suspicious activity can blend with legitimate domain join activity, trust repair, replication maintenance, backup operations, vulnerability scanning, patching, identity-management workflows, or administrator troubleshooting.

·        A single affected domain-controller path can create disproportionate leverage when it enables privileged authentication, credential access, replication-like activity, backup-system access, cloud or SaaS administration, source-code access, CI/CD interaction, ransomware staging, or extortion.

·        The attacker benefits when defenders cannot quickly determine whether domain-controller state, machine-account relationships, privileged groups, trust relationships, or replication permissions remained intact.

Defender Cost Expansion

·        The organization must investigate both the suspicious Netlogon-adjacent activity and the integrity of the Active Directory control plane.

·        Response teams may need to reconstruct source-to-domain-controller service access, Windows Security events, Directory Services changes, authentication behavior, endpoint activity, network activity, and change-management evidence.

·        Privileged credential resets, service-account review, machine-account validation, domain trust review, replication-permission review, domain-controller forensic review, and backup-trust validation may be required even when ransomware or confirmed data theft is not proven.

·        Internal access scoping may be required across identity infrastructure, privileged management systems, jump hosts, endpoint-management systems, file servers, databases, backup systems, cloud consoles, SaaS administration portals, source-code systems, CI/CD systems, and sensitive business applications.

·        Response cost increases when Netlogon logging, Directory Services auditing, EDR coverage, network telemetry, asset inventory, change-control records, or authentication logs are incomplete.

·        High-value identity dependencies create disproportionate exposure because one suspicious domain-controller trust event can expand scoping requirements across the enterprise.

Organizational Impact Model

Identity-Control-Plane Impact

The organization must determine whether Active Directory trust, domain-controller integrity, machine-account state, privileged groups, domain trusts, replication permissions, and sensitive directory-service objects remained reliable.

Authentication and Authorization Impact

The organization must determine whether suspicious activity affected privileged authentication, machine-account authentication, service-account behavior, Kerberos or NTLM activity, service-ticket behavior, or downstream authorization decisions.

Operational Access Impact

The organization must determine whether suspicious domain-controller activity enabled access to identity infrastructure, jump hosts, privileged management systems, endpoint-management platforms, backup systems, file servers, databases, cloud consoles, SaaS administration portals, source-code systems, CI/CD systems, or sensitive business applications.

Recovery Impact

The organization must restore identity trust through domain-controller validation, Active Directory object review, privileged credential reset decisioning, service-account review, machine-account validation, domain trust review, replication-permission review, backup-trust validation, and downstream exposure assessment.

Governance Impact

Leadership may need to treat confirmed or strongly suspected domain-controller compromise as an executive incident because Active Directory governs access to internal systems, privileged resources, cloud and SaaS platforms, developer environments, backup infrastructure, and business-critical systems.

Economic Impact Summary

Windows Netlogon remote code execution and domain-controller compromise exposure is economically powerful for adversaries because it can convert domain-controller access into identity-control-plane leverage. The organization’s financial exposure grows when it cannot quickly prove whether domain-controller trust, machine-account state, privileged authentication, replication permissions, backup trust, downstream access, and Active Directory integrity remained intact.

S39 — Economic Impact & Organizational Exposure

Figure 7

Windows Netlogon remote code execution and domain-controller compromise exposure creates organizational exposure by increasing uncertainty around Active Directory trust, privileged identity, machine-account state, domain-controller integrity, downstream access, and recovery scope. Exposure rises when suspicious activity involves writable domain controllers, privileged accounts, domain-controller machine accounts, service accounts, replication permissions, backup systems, cloud or SaaS administration, source-code systems, CI/CD environments, or business-critical applications.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate is tied to whether the activity remains attempted exploitation or isolated suspicious Netlogon-adjacent behavior, becomes confirmed or strongly suspected domain-controller trust manipulation, or expands into privileged internal access, identity infrastructure exposure, backup-system access, cloud or SaaS administration, source-code or CI/CD exposure, ransomware staging, extortion, or broad Active Directory trust restoration.

Low Impact Scenario

Estimated $1M – $4M.

This scenario applies when suspicious Netlogon-adjacent activity is detected quickly, no unauthorized domain-controller account manipulation is confirmed, no machine-account password reset abuse is identified, no domain trust change occurs, no privileged group change is detected, no replication-permission abuse is observed, no credential theft is confirmed, no ransomware or extortion activity occurs, and telemetry is sufficient to validate the domain-controller activity path quickly.

Moderate Impact Scenario

Estimated $8M – $30M.

This scenario applies when confirmed or strongly suspected domain-controller trust manipulation, machine-account modification, suspicious privileged authentication, replication-like access, or identity-plane uncertainty requires the organization to treat the event as a domain-controller trust incident even without confirmed ransomware, confirmed data theft, or full enterprise compromise. Response may require privileged credential reset planning, domain-controller forensic review, Active Directory object validation, machine-account and service-account scoping, domain trust review, replication-permission review, SOC surge activity, change-management validation, backup-trust review, executive reporting, and downstream validation of identity, cloud, SaaS, developer-platform, source-code, CI/CD, backup, and sensitive business-system exposure.

High Impact Scenario

Estimated $35M – $150M+.

This scenario applies when Netlogon-linked domain-controller compromise becomes an enterprise-impact pathway involving broad Active Directory compromise, domain or forest recovery, privileged-account reset at scale, domain-controller rebuild, identity-service outage, credential theft, replication abuse, ransomware staging, backup-system access, cloud or SaaS administrative exposure, source-code or CI/CD exposure, data theft, extortion, or broad loss of confidence in enterprise identity controls. The upper range applies only when the organization must restore Active Directory trust, rebuild or recover domain-controller infrastructure, validate backup integrity, rotate high-risk credentials, scope downstream systems at enterprise scale, or recover business-critical systems affected through the compromised identity path.

Annualized Risk Exposure

Estimated $8M – $35M+ for materially exposed enterprise environments with domain-controller dependency, broad internal domain-controller service reachability, incomplete Netlogon or Directory Services telemetry, privileged-account exposure, weak change-management validation, or high downstream dependency on Active Directory. Exposure may exceed $50M – $150M+ where confirmed domain-controller compromise requires enterprise-scale Active Directory recovery, privileged credential reset, domain or forest restoration, ransomware or extortion response, backup-trust validation, cloud or SaaS administrative scoping, or business-critical system restoration.

Operational Dependency

Operational dependency is high where Active Directory and domain controllers support authentication, authorization, machine-account trust, privileged administration, identity-management workflows, backup operations, cloud or SaaS administration, source-code access, CI/CD activity, file services, databases, endpoint management, and business-critical applications. Dependency increases when domain-controller trust is required for recovery operations, privileged access, regulated systems, or operational continuity.

Control Trust

Control trust is reduced when the organization cannot prove that domain-controller state, machine-account relationships, privileged group memberships, domain trusts, replication permissions, delegation settings, Group Policy, authentication flows, and sensitive directory-service objects remained intact. Control trust is further reduced when Netlogon, Directory Services, Windows Security, authentication, endpoint, network, or change-control evidence is incomplete or inconsistent.

Visibility Confidence

Visibility confidence is highest when Windows Security logs, Directory Services events, Netlogon telemetry, System logs, authentication logs, EDR telemetry, NDR telemetry, asset inventory, change-management records, and SIEM correlation can be joined reliably. Visibility confidence is reduced where Netlogon diagnostic logging is unavailable, Active Directory auditing is incomplete, domain-controller EDR is missing, network telemetry is metadata-only, timestamps are inconsistent, or asset-role enrichment is weak.

Change-Control Confidence

Change-control confidence is high when domain join activity, trust repair, machine-account resets, replication administration, domain-controller maintenance, backup operations, patching, identity-management workflows, security testing, vulnerability management, and incident-response actions are documented and attributable. Confidence is reduced when change-control records are incomplete, delayed, inconsistent, or unavailable during suspicious domain-controller activity review.

Downstream Dependency

Downstream dependency is high when Active Directory trust provides access to identity infrastructure, privileged management systems, jump hosts, endpoint-management platforms, backup systems, file servers, databases, cloud consoles, SaaS administration portals, developer platforms, source-code repositories, CI/CD systems, and sensitive business applications. These dependencies increase the impact of even a single suspicious domain-controller trust event.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious domain-controller activity may have enabled access to regulated data, customer systems, privileged business applications, source-code repositories, CI/CD environments, backup infrastructure, cloud administration, SaaS administration, or identity control planes. Exposure also increases when incomplete telemetry prevents timely confirmation of whether sensitive systems were accessed, whether data was exposed, or whether downstream compromise occurred.

Residual Economic Risk

Residual economic risk remains after containment if the organization cannot prove that domain-controller trust was restored, privileged credentials were reset or validated, service accounts were reviewed, machine-account state was validated, domain trusts were verified, replication permissions were reviewed, backup trust was confirmed, downstream access was scoped, and Active Directory integrity was restored. Residual risk is highest where Netlogon evidence, Directory Services logs, authentication telemetry, endpoint telemetry, network telemetry, cloud logs, SaaS logs, backup logs, or change-control evidence are incomplete.

Proof-of-Concept Behavioral Coverage Assessment

This assessment is anchored to CVE-2026-41089, but the detection model is intentionally behavior-led so it can demonstrate reusable coverage across related Windows Netlogon and Active Directory domain-controller trust failures. The coverage model is designed to show how the same detection strategy can remain relevant when different exploit mechanisms produce the same operational outcomes: suspicious domain-controller service access, Netlogon-adjacent abuse, machine-account manipulation, domain-controller account impact, privileged authentication expansion, replication-like access, security-control disruption, or downstream identity-dependent access.

The model should not be read as universal exploit detection or universal zero-day prevention. It demonstrates coverage when a known CVE, new proof-of-concept, or future vulnerability produces observable domain-controller service anomalies, machine-account state changes, domain-controller account changes, privileged authentication expansion, replication-permission abuse, Active Directory object changes, credential access, lateral movement, or downstream business-system exposure.

CVE / Proof-of-Concept Behavioral Coverage Scope

This assessment is anchored to CVE-2026-41089, a Windows Netlogon remote code execution exposure affecting domain controllers. The same detection model also applies to related Netlogon and MS-NRPC trust failures where the exploit or abuse path affects domain-controller trust, machine-account state, domain-controller accounts, privileged authentication, replication permissions, or downstream access through Active Directory trust.

Detection Engineering Coverage Interpretation

Coverage is strongest when proof-of-concept or exploit activity results in observable Netlogon-adjacent anomalies, MS-NRPC/RPC/SMB domain-controller service activity, non-standard source-to-domain-controller access, machine-account changes, domain-controller account changes, domain trust changes, privileged group changes, replication-permission changes, privileged authentication expansion, credential-access behavior, lateral movement, or downstream access. Coverage is weaker when exploit activity produces no observable difference in Netlogon, Windows Security, Directory Services, authentication, endpoint, network, cloud, SaaS, backup, or SIEM telemetry.

Direct Coverage

Direct behavioral coverage applies to the following CVEs when exploitation or abuse produces observable domain-controller service anomalies, Netlogon-adjacent abuse, machine-account manipulation, domain-controller account manipulation, privileged authentication expansion, replication-like access, or Active Directory trust impact:

·        CVE-2026-41089 — Windows Netlogon remote code execution vulnerability affecting domain controllers. This is the primary report anchor and the clearest direct coverage case.

·        CVE-2020-1472 — Netlogon elevation-of-privilege vulnerability involving vulnerable Netlogon secure-channel behavior against a domain controller. This is directly covered when activity produces machine-account manipulation, domain-controller account spoofing, privileged authentication, credential access, or domain trust impact.

·        CVE-2025-33070 — Windows Netlogon elevation-of-privilege vulnerability. This is directly covered when exploitation produces unauthorized privilege escalation, domain-controller trust impact, privileged authentication expansion, or Active Directory control-plane changes.

Coverage With Adaptation

Coverage with adaptation applies to related Netlogon or domain-controller service vulnerabilities where the local incident shows service abuse, resource exhaustion, authentication disruption, domain-controller instability, or follow-on identity-plane activity that can be linked to Netlogon-adjacent behavior.

·        CVE-2025-49716 — Windows Netlogon RPC denial-of-service vulnerability involving uncontrolled resource consumption through Netlogon-based RPC calls. This is covered with adaptation for exploit-attempt, service-instability, authentication-disruption, and domain-controller availability triage, but it should not be counted as direct domain-controller trust compromise unless followed by identity-plane manipulation or downstream compromise behavior.

Limited / Non-Direct Coverage

Limited or non-direct coverage applies where a CVE affects adjacent Windows infrastructure but does not directly affect Netlogon, MS-NRPC, domain-controller trust, machine-account state, privileged authentication, or Active Directory integrity.

·        Windows DNS, SMB, LDAP, Kerberos, LSASS, RDP, or other Windows service vulnerabilities should not be counted as covered by this report unless the observed activity is linked to the Netlogon-to-domain-controller trust path defined in this report.

·        Availability-only activity should not be counted as direct identity-plane compromise unless it is paired with suspicious Netlogon-adjacent activity, authentication anomalies, Directory Services changes, endpoint evidence, or incident-response findings.

·        General Windows remote code execution or privilege escalation vulnerabilities should remain outside this report unless they materially support or follow from the Netlogon domain-controller compromise chain.

Direct Coverage Conditions

Direct coverage applies when proof-of-concept or exploit activity produces one or more of the following behaviors:

·        Abnormal Netlogon-adjacent, MS-NRPC, RPC, SMB, or domain-controller service interaction.

·        Source-to-domain-controller activity from a non-standard host, unmanaged system, workstation network, VPN ingress range, branch network, newly observed internal source, or system without an approved administrative role.

·        Machine-account password reset abuse or machine-account state change.

·        Domain-controller account modification or spoofing behavior.

·        Domain trust modification.

·        Privileged group change.

·        Replication-permission change or replication-like access.

·        Privileged authentication expansion after suspicious domain-controller interaction.

·        Directory Services changes involving sensitive Active Directory objects.

·        Credential-access behavior linked to suspicious domain-controller activity.

·        Security-control disruption near the domain-controller activity window.

·        Suspicious domain-controller activity followed by lateral movement, backup-system access, cloud or SaaS administration, source-code access, CI/CD interaction, ransomware staging, or extortion.

Coverage With Adaptation Conditions

Coverage with adaptation applies when activity uses a novel exploit mechanism, altered request pattern, changed timing, internal staging, compromised source host, availability disruption, authentication-service instability, low-noise domain-controller interaction, or an adjacent domain-controller service path but still creates Netlogon, authentication, Directory Services, endpoint, network, control-plane, or downstream anomalies. Adaptation may require local tuning for event IDs, Netlogon logging, Directory Services fields, Windows Security event mappings, EDR schemas, NDR protocol labels, timing windows, domain-controller inventory, source-role enrichment, change-control records, and exception lists.

Non-Coverage Conditions

Non-coverage applies when activity does not create observable domain-controller, authentication, identity-plane, endpoint, network, or downstream differences in available telemetry. This includes scenarios where:

·        The attacker uses valid credentials and approved administrative systems with no suspicious Netlogon-adjacent behavior.

·        The activity does not interact with Netlogon, MS-NRPC, RPC, SMB, or domain-controller service paths.

·        The activity affects only unrelated Windows services without domain-controller trust impact.

·        The activity remains limited to scanning, patch-state exposure, or vulnerability inventory without exploit-attempt behavior.

·        The activity affects only availability or service stability without authentication, identity-plane, or downstream access impact.

·        Required Windows Security, Directory Services, Netlogon, System, authentication, EDR, NDR, VPN, cloud, SaaS, backup, or SIEM telemetry is unavailable.

·        Source hosts, destination domain controllers, timestamps, accounts, machine accounts, object changes, or session context cannot be joined reliably.

·        Downstream cloud, SaaS, developer-platform, source-code, CI/CD, backup, or sensitive application activity cannot be linked to suspicious domain-controller behavior.

·        Activity is better explained by approved domain join, trust repair, replication maintenance, backup operations, patching, vulnerability management, identity-management workflows, security testing, or incident response.

Current Coverage Count

Current behavior-led coverage directly supports 3 CVEs where the documented behavior aligns with Windows Netlogon remote code execution, Netlogon secure-channel abuse, Netlogon privilege escalation, domain-controller trust manipulation, machine-account manipulation, or Active Directory control-plane compromise. The model also supports 1 additional Netlogon-related CVE with adaptation where the activity can be linked to Netlogon RPC abuse, domain-controller instability, authentication disruption, exploit-attempt triage, or follow-on identity-plane behavior. Non-Netlogon Windows vulnerabilities are not counted as covered unless incident evidence links them to the Netlogon-to-domain-controller trust path defined in this report.

Coverage Qualification

Coverage is strong for behaviorally visible Netlogon abuse and weaker for silent valid-administration abuse where all required domain-controller, authentication, Directory Services, endpoint, network, and change-control evidence appears normal. The report should not claim universal exploit detection, universal CVE coverage, or standalone attribution. Detection confidence depends on telemetry completeness, field mapping, local baselines, domain-controller inventory, source-role enrichment, Netlogon logging, Directory Services auditing, endpoint telemetry, network visibility, change-management records, false-positive testing, and SOC triage readiness.

Zero-Day Coverage Interpretation

The purpose of this S39 coverage model is to show that the detection strategy is not limited to the known exploit mechanics of CVE-2026-41089. Future zero-day or proof-of-concept activity affecting Windows Netlogon, MS-NRPC, or adjacent domain-controller trust paths should still be detectable when it produces the same operational behaviors: suspicious source-to-domain-controller service access, Netlogon-adjacent anomalies, machine-account manipulation, domain-controller account impact, privileged authentication expansion, replication-like access, Active Directory object changes, credential access, security-control disruption, or downstream access. The model should not be presented as universal zero-day prevention; it is behavior-led coverage for zero-day activity that becomes visible through the domain-controller trust chain.

Executive Exposure Statement

The organization’s economic exposure is highest when Windows Netlogon exploitation or suspected domain-controller trust manipulation creates uncertainty around whether Active Directory remained trustworthy. The strategic risk is not only code execution on a Windows Server; it is the possibility that attackers can compromise or cast doubt on the identity systems that authorize access across the enterprise.

S40 — References

Vendor / Platform Documentation

·        Microsoft Security Response Center — Security Update Guide — hxxps://msrc[.]microsoft[.]com/update-guide

·        Microsoft Security Response Center — CVE-2026-41089 Windows Netlogon Remote Code Execution Vulnerability — hxxps://msrc[.]microsoft[.]com/update-guide/vulnerability/CVE-2026-41089

·        Microsoft Security Response Center — Attacks Exploiting Netlogon Vulnerability CVE-2020-1472 — hxxps://www[.]microsoft[.]com/en-us/msrc/blog/2020/10/attacks-exploiting-netlogon-vulnerability-cve-2020-1472

·        Microsoft Support — KB5066014 Netlogon RPC Hardening CVE-2025-49716 — hxxps://support[.]microsoft[.]com/en-us/topic/kb5066014-netlogon-rpc-hardening-cve-2025-49716-38a0bc06-507c-47d4-be0f-ca1acab02c68

·        Microsoft Learn — Active Directory Domain Services Overview — hxxps://learn[.]microsoft[.]com/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview

·        Microsoft Learn — Netlogon Service Technical Reference — hxxps://learn[.]microsoft[.]com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831689(v=ws.11)

Threat Technique Framework

·        MITRE ATT&CK — Enterprise Matrix / Techniques Catalog — hxxps://attack[.]mitre[.]org/

Security Vendor Analysis

·        CISA — Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

·        NVD — Vulnerability Database / CVE Catalog — hxxps://nvd[.]nist[.]gov/vuln

·        CVE Program — CVE Records — hxxps://www[.]cve[.]org/CVERecord

Threat Tradecraft and Intrusion Patterns

·        Centre for Cybersecurity Belgium — Microsoft Patch Tuesday May 2026 Advisory — hxxps://ccb[.]belgium[.]be/advisories/warning-microsoft-patch-tuesday-may-2026-patches-118-vulnerabilities-16-critical-102

·        CISA — Microsoft Warns of Continued Exploitation of CVE-2020-1472 — hxxps://www[.]cisa[.]gov/news-events/alerts/2020/10/29/microsoft-warns-continued-exploitation-cve-2020-1472