[EXP] Endpoint Defense Subversion and Security-Control Degradation

Report Type: Exploitation Threat Assessment
Threat Category: Endpoint Defense Subversion and Security-Control Degradation
Assessment Date: April 27, 2026
Primary Impact Domain: Endpoint Security-Control Integrity
Secondary Impact Domains: Detection and Response Reliability; Endpoint Telemetry Confidence; Credential Access Exposure; Lateral Movement Risk; Incident Containment and Recovery
Affected Asset Class: Enterprise Endpoints; Endpoint Protection and EDR Platforms; Antivirus and Security Intelligence Update Services; Endpoint Telemetry Pipelines; Device-Management and Policy Enforcement Systems; Privileged and Domain-Connected Systems
Threat Objective Classification: Defense Evasion, Endpoint-Control Degradation, Telemetry Impairment, Credential Access Enablement, Persistence Enablement, and Downstream Enterprise Compromise

BLUF

 Endpoint defense subversion and security-control degradation create material enterprise risk by weakening the endpoint controls organizations rely on to prevent, detect, investigate, and contain compromise. The risk is driven by adversary manipulation of endpoint protection, EDR visibility, antivirus posture, security intelligence updates, service state, exclusion policy, telemetry forwarding, remediation behavior, sensor health, or device-management enforcement after execution or privileged activity. This report is not focused on a single CVE, vendor product, or named exploit; it assesses endpoint-control degradation as an intrusion-enabling behavior that can reduce defensive reliability before credential access, persistence, discovery, outbound communication, or lateral movement occurs. Immediate executive action is required to validate endpoint-control integrity, confirm visibility into degradation pathways, and ensure response teams treat control weakening as a trust-impacting event.

Executive Risk Translation

Endpoint defense subversion shifts the business risk from isolated endpoint compromise to loss of confidence in the defensive layer itself. The primary concern is that attackers may weaken prevention, impair detection, reduce telemetry reliability, or degrade containment evidence before the organization can determine scope and impact. If endpoint-control integrity cannot be proven after suspicious privileged activity, response may expand into broader containment, credential review, endpoint rebuilds, and extended forensic validation. This creates financial, operational, and governance exposure beyond the originally affected endpoint.

S3 — Why This Matters Now

·        Endpoint controls are a primary dependency for intrusion detection, containment, and forensic scoping.

·        Adversaries benefit from weakening security controls after gaining execution or privileged context.

·        Endpoint tools may appear deployed while protection posture, update integrity, telemetry flow, service health, or sensor status has been degraded.

·        Control degradation can reduce visibility before credential access, persistence, discovery, outbound communication, or lateral movement occurs.

·        The threat model applies across endpoint protection, EDR, antivirus, update services, endpoint telemetry, and device-management enforcement.

·        Organizations that assume endpoint-control integrity without validating it are exposed to delayed detection, incomplete scoping, and expanded response cost.

S4 — Key Judgments

·        Endpoint defense subversion is a post-compromise control-integrity risk, not a single-vulnerability, single-product, or perimeter-defense issue.

·        The primary risk is loss of confidence in endpoint prevention, detection, telemetry, and containment evidence.

·        Suspicious privileged or administrative activity followed by measurable endpoint security-control degradation is the strongest enterprise risk signal.

·        Detection is difficult when the organization lacks visibility into endpoint activity, control-state changes, update integrity, service health, policy posture, or sensor status.

·        Generic update failures, isolated service restarts, standalone sensor silence, and routine configuration drift should not be treated as high-confidence malicious activity without suspicious context.

·        The highest-risk outcome occurs when endpoint-control degradation enables credential access, persistence, discovery, outbound communication, or lateral movement.

S5 — Executive Risk Summary

Business Risk

Endpoint defense subversion can undermine confidence in the organization’s ability to detect, investigate, and contain compromise. Risk increases when affected systems include privileged access workstations, servers, domain-connected assets, developer systems, cloud workloads, executive endpoints, or business-critical systems.

Technical Cause

The risk is driven by adversary manipulation of endpoint protection state, update behavior, service configuration, exclusions, telemetry forwarding, remediation behavior, policy posture, or sensor health after gaining execution, administrative context, or privileged access.

Threat Posture

The threat posture is elevated because control degradation supports intrusion progression by reducing prevention, impairing visibility, and creating conditions for credential access, persistence, discovery, outbound communication, and lateral movement.

Executive Decision Requirement

Executives must require measurable assurance that endpoint controls remain intact after suspicious privileged activity and that response teams can detect, contain, and validate endpoint-control degradation as a trust-impacting event.

S6 — Executive Cost Summary

Endpoint defense subversion and security-control degradation create financial exposure based on affected system criticality, detection speed, telemetry confidence, containment burden, credential exposure, and the degree to which control degradation enables follow-on compromise.

Low Impact Scenario

Rapid detection confirms attempted or limited endpoint-control degradation with no confirmed credential access, persistence, lateral movement, telemetry loss, or sensor-health degradation; estimated impact $500K – $2M.

Moderate Impact Scenario

Confirmed endpoint-control degradation affects a limited but meaningful set of systems, requiring endpoint isolation, telemetry validation, credential review, policy restoration, update-health verification, selective rebuilds, SOC surge activity, and executive incident coordination; estimated impact $3M – $12M.

High Impact Scenario

Endpoint-control degradation affects privileged, domain-connected, business-critical, developer, cloud workload, or high-value systems and is followed by credential access, persistence, lateral movement, or loss of telemetry confidence; estimated impact $15M – $75M+.

S6A — Key Cost Drivers

·        Scope and criticality of affected endpoints

·        Time to detection and containment

·        Confidence in endpoint telemetry during the compromise window

·        Ability to confirm whether protection posture changed

·        Credential exposure following control degradation

·        Persistence or lateral movement after endpoint weakening

·        Need for endpoint rebuilds, sensor redeployment, or policy restoration

·        Legal, regulatory, insurance, and board-level incident governance requirements

Most Likely Scenario Justification

Moderate scenario is most likely because endpoint-control degradation can create significant investigation, containment, and assurance cost even without confirmed enterprise-wide compromise. The estimate moves toward the lower end when telemetry confirms limited scope, rapid containment, no credential access, and intact sensor visibility. The estimate moves toward the upper end when affected systems are privileged, domain-connected, business-critical, or when incomplete telemetry forces broader validation of endpoint trust.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Endpoint Security-Control Degradation Following Suspicious Privileged Activity

Risk Description

Adversaries may degrade endpoint protection, EDR visibility, update integrity, service state, telemetry forwarding, exclusions, policy posture, remediation behavior, or sensor health after gaining execution or privileged access, reducing detection confidence and enabling follow-on compromise activity.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $5M – $15M+

S7 — Risk Drivers

·        Reliance on endpoint controls for intrusion detection, containment, and forensic scoping

·        Adversary abuse of legitimate administrative tools and privileged context

·        Weak visibility into endpoint-control degradation and defensive posture drift

·        Incomplete visibility into update integrity, service health, policy posture, and sensor status

·        Limited ability to distinguish approved administration from attacker-driven degradation

·        Security intelligence update suppression or update-source manipulation

·        Endpoint sensor-health degradation or telemetry forwarding reduction

·        Broad exclusions, weakened remediation settings, or unmanaged local policy changes

·        Follow-on credential access, persistence, discovery, outbound communication, or lateral movement after control degradation

·        Over-reliance on endpoint product presence rather than measurable endpoint-control integrity

S8 — Bottom Line for Executives

Endpoint defense subversion should be treated as a high-priority control-integrity risk because it can weaken the defensive layer during active compromise. The key executive concern is not whether endpoint tools are deployed, but whether those controls remain trustworthy after suspicious privileged activity. Response must focus on validating control integrity, restoring endpoint trust, and preventing degraded systems from becoming launch points for credential access, persistence, or lateral movement. The durable management requirement is measurable assurance across endpoint vendors, endpoint classes, management paths, and intrusion phases.

S9 — Board-Level Takeaway

Endpoint defense subversion turns the endpoint security-control layer into part of the attack surface. The board-level risk is loss of confidence in the controls used to detect, investigate, and contain compromise. This report is not about a single CVE; it is about adversary degradation of endpoint defenses as an intrusion-enabling behavior. Leadership should require measurable assurance that endpoint controls remain intact, degradation is detected quickly, and response teams can restore endpoint trust before attackers expand impact.

Figure 2

S10 — Threat Overview

Endpoint defense subversion and security-control degradation describe adversary behavior intended to weaken the endpoint security layer after execution, compromise, or privileged access. The behavior is most relevant when attackers manipulate endpoint protection, EDR visibility, antivirus posture, security intelligence updates, service state, exclusion policy, telemetry forwarding, remediation behavior, sensor health, or device-management enforcement to reduce prevention, detection, and response reliability.

·        This is not a single-CVE, single-vendor, or single-product threat model.

·        The core threat behavior is adversary degradation of endpoint controls after execution, administrative access, or privilege gain.

·        The primary risk is loss of confidence in the endpoint layer used for detection, containment, and forensic scoping.

·        Endpoint tools may appear deployed while protection posture, update integrity, telemetry flow, service health, policy enforcement, or sensor status has been weakened.

·        The behavior can allow attackers to operate with reduced visibility before credential access, persistence, discovery, outbound communication, or lateral movement.

·        Current public examples such as BlueHammer, RedSun, and UnDefend support the relevance of the behavior class but do not define the report scope.

S11 — Threat Classification and Type

Threat Type

Post-compromise defense evasion and security-control degradation

Threat Sub-Type

Endpoint protection subversion, endpoint telemetry impairment, security intelligence update disruption, endpoint service manipulation, exclusion abuse, sensor-health degradation, and endpoint policy weakening

Operational Classification

Intrusion-enabling endpoint control degradation

Primary Function

Reduce endpoint prevention, detection, telemetry reliability, update effectiveness, and containment confidence to increase adversary operational freedom after compromise.

S12 — Campaign or Activity Overview

This report assesses endpoint defense subversion as a behavior class rather than a single campaign. The activity pattern involves attackers weakening endpoint controls after obtaining execution, local administrative context, privileged access, remote administrative access, or hands-on-keyboard control.

·        The activity is best understood as a post-compromise enabler rather than an initial-access event by itself.

·        Adversaries may use legitimate administrative tools, endpoint-management paths, security-control configuration mechanisms, update mechanisms, service-control utilities, registry modification, or security product features to degrade endpoint defenses.

·        The behavior may be tactical, such as creating an exclusion, stopping a service, weakening protection, or suppressing telemetry before tool execution.

·        The behavior may also be strategic, such as suppressing updates, degrading telemetry forwarding, impairing sensor health, or creating policy drift that reduces visibility over time.

·        The activity becomes highest risk when endpoint-control degradation is followed by credential access, persistence, discovery, outbound communication, or lateral movement.

·        BlueHammer, RedSun, and UnDefend are treated as evidence anchors only and should not narrow the report into a single-CVE or Defender-only analysis.

S13 — Targets and Exposure Surface

The exposure surface includes endpoints, endpoint-management paths, and security-control dependencies that attackers can manipulate after obtaining execution or privileged context.

·        Windows workstations and servers with endpoint protection or EDR installed.

·        Privileged access workstations used for administrative functions.

·        Domain-connected systems that support credential access or lateral movement.

·        Developer endpoints with local privileges, sensitive tooling, repositories, secrets, or build-system access.

·        Executive endpoints and high-value user systems with access to sensitive communications or business data.

·        Cloud workload hosts, virtual desktops, and hybrid endpoints managed through endpoint security or device-management platforms.

·        Endpoint-management infrastructure, including MDM, EDR consoles, policy deployment systems, patch-management platforms, and administrative scripts.

·        Security-control configuration paths, including protection settings, exclusions, update sources, service configuration, registry-backed policy, telemetry forwarding, and sensor-health reporting.

·        Systems with broad local administrator access, weak tamper protection, incomplete logging, or limited visibility into control-state changes.

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

·        Managed service providers and enterprise IT operations

·        Organizations with large Windows endpoint fleets, privileged access workstations, domain-connected infrastructure, developer systems, cloud workload hosts, or regulated data environments

Countries Affected

·        Global

·        Exposure is not limited to a single country or region because endpoint protection, EDR, antivirus, device-management, and endpoint telemetry platforms are broadly deployed across enterprise environments.

·        Countries with large enterprise Windows deployments, regulated industries, government operations, remote workforce scale, or high-value technology environments may face elevated operational exposure.

·        Country-specific impact should be assessed by endpoint-control maturity, privileged access practices, telemetry quality, device-management governance, 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 endpoint protection behavior, control-state changes, update paths, service configuration, policy enforcement, and telemetry dependencies. The behavior can be performed with legitimate administrative tools, but effective use during intrusion activity requires timing, operational judgment, and awareness of endpoint-control dependencies.

Infrastructure Maturity

Variable

Endpoint defense subversion does not always require mature external infrastructure because the core behavior occurs locally through endpoint control manipulation. Infrastructure maturity increases when control degradation is paired with payload staging, credential access tooling, command-and-control preparation, remote access infrastructure, or lateral movement paths.

Operational Scale

Single-host to enterprise-scale

Operational scale ranges from localized control weakening on one host to broader enterprise impact when attackers repeat degradation across multiple systems, target privileged or domain-connected assets, or abuse endpoint-management pathways to affect endpoint groups.

Escalation Likelihood

High

Escalation likelihood is high when endpoint-control degradation is confirmed on privileged, domain-connected, business-critical, developer, cloud workload, or high-value systems. Escalation likelihood increases further when degradation is followed by credential access, persistence, discovery, outbound communication, or lateral movement.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        Endpoint controls are widely deployed and trusted for intrusion detection, containment, and forensic scoping.

·        Attackers benefit directly from weakening prevention, impairing telemetry, and reducing response confidence after compromise.

·        Legitimate administrative tools and endpoint-management paths can provide plausible cover for control degradation.

·        Weak command-line visibility, incomplete control-state telemetry, limited sensor-health monitoring, and poor device-management context increase attacker opportunity.

·        Broad local administrator rights and inconsistent endpoint hardening increase the likelihood of successful manipulation.

·        High-value systems create strong incentives because degraded endpoint controls can enable credential access, persistence, discovery, and lateral movement.

Most Likely Targets

·        Privileged access workstations.

·        Domain controllers and domain-connected administrative systems.

·        Windows servers and business-critical endpoints.

·        Developer systems with local privileges, sensitive tooling, repository access, or build-system access.

·        Executive endpoints and high-value user devices.

·        Cloud workload hosts and virtual desktop infrastructure.

·        Endpoints with incomplete telemetry, weak tamper protection, broad local administrator rights, or unmanaged local policy drift.

·        Endpoint-management and device-management workflows that can be abused to alter security posture at scale.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1: Execution or Valid Access

The adversary establishes local execution, remote access, or an authenticated operating position on the endpoint. This stage provides the foothold needed to inspect endpoint controls and prepare security-control degradation.

·        T1059 — Command and Scripting Interpreter

·        T1078 — Valid Accounts

Stage 2: Privilege Context

The adversary uses or obtains elevated privileges to modify endpoint security controls. This may involve local administrator access, SYSTEM-context execution, or privilege escalation that enables control manipulation.

·        T1068 — Exploitation for Privilege Escalation

Stage 3: Endpoint Security-Control Discovery

The adversary identifies security tooling, endpoint protection posture, service state, update behavior, exclusions, and other control conditions before attempting degradation.

·        T1518.001 — Security Software Discovery

Stage 4: Endpoint Defense Subversion

The adversary weakens endpoint protection, telemetry, policy posture, service state, update integrity, or related defensive controls to reduce prevention and detection reliability.

·        T1562.001 — Impair Defenses: Disable or Modify Tools

·        T1112 — Modify Registry

Stage 5: Post-Degradation Objective Activity

After endpoint controls are weakened, the adversary may pursue credential access, persistence, or staging activity while detection confidence is reduced.

·        T1003 — OS Credential Dumping

·        T1053.005 — Scheduled Task/Job: Scheduled Task

·        T1105 — Ingress Tool Transfer

Stage 6: Expansion Path

If not contained, the degraded endpoint may become a launch point for lateral movement or remote access into additional systems.

·        T1021 — Remote Services

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

Endpoint defense subversion begins after an adversary has obtained execution, privileged context, remote administrative access, or hands-on-keyboard control on an endpoint. The attacker’s objective is to reduce the reliability of the endpoint security layer before pursuing follow-on activity. The attack path is defined by access, privilege context, control discovery, control degradation, and post-degradation objectives.

Stage 1: Execution or Valid Access

The adversary establishes an operating position on the endpoint through local execution, authenticated access, remote administration, or a compromised user context. This stage provides the access needed to inspect host configuration and determine whether endpoint controls can be weakened.

Stage 2: Privilege Context

The adversary uses existing administrative access, attempts privilege escalation, abuses valid credentials, or transitions into SYSTEM, service, or elevated execution context. Elevated context increases the attacker’s ability to modify protection settings, service state, update behavior, exclusions, telemetry forwarding, or policy posture.

Stage 3: Endpoint Security-Control Discovery

The adversary identifies endpoint protection status, security software, service state, exclusions, update behavior, policy posture, telemetry forwarding, and sensor health. This discovery phase helps determine which controls can be degraded with lower operational noise.

Stage 4: Endpoint Defense Subversion

The adversary weakens endpoint controls to reduce prevention, detection, and response reliability. This may include reducing protection posture, adding broad exclusions, manipulating update behavior, modifying registry-backed security settings, stopping or impairing services, reducing telemetry forwarding, weakening remediation behavior, or creating policy drift from expected managed posture.

Stage 5: Post-Degradation Objective Activity

After endpoint controls are weakened, the adversary may pursue credential access, persistence, staging, discovery, outbound communication, or lateral movement while detection confidence is reduced. This is where endpoint-control degradation becomes an intrusion amplifier rather than a local configuration issue.

Stage 6: Expansion Path

If not contained, the degraded endpoint may become a launch point for broader compromise. The adversary may reuse credentials, access remote systems, stage tools, establish persistence, or move laterally while the organization must determine whether endpoint telemetry remained reliable during the compromise window.

S19 — Attack Chain Risk Amplification Summary

Endpoint defense subversion amplifies risk because it attacks the control layer used to detect, contain, and validate the intrusion. The chain becomes materially more dangerous when control degradation occurs before credential access, persistence, discovery, outbound communication, or lateral movement.

·        Execution or valid access gives the adversary an operating position on the endpoint.

·        Privilege context increases the attacker’s ability to modify protected settings, services, exclusions, updates, telemetry behavior, or policy posture.

·        Endpoint security-control discovery allows the adversary to identify which defenses can be weakened with lower operational noise.

·        Endpoint defense subversion reduces prevention, alert reliability, telemetry completeness, and containment confidence.

·        Credential access after control degradation increases the risk of broader identity compromise.

·        Persistence after control degradation increases the risk of re-entry after initial containment.

·        Discovery after control degradation increases the risk of informed lateral movement.

·        Outbound communication after control degradation increases the risk of payload staging, command-and-control preparation, or data movement.

·        Lateral movement after control degradation can transform a local endpoint event into enterprise-scale compromise.

·        Response burden increases because teams must investigate both attacker activity and whether endpoint controls remained trustworthy.

Figure 3

S20 — Tactics, Techniques, and Procedures

Execution and Access

Adversaries may use local execution, remote access, compromised credentials, administrative tools, or hands-on-keyboard activity to establish an operating position on the endpoint. This activity may resemble legitimate administration unless it is followed by abnormal privilege use, security-control discovery, or endpoint-control degradation.

Privilege Use and Elevation

Adversaries may rely on local administrator rights, valid accounts, privilege escalation, service execution, or SYSTEM-level execution to modify endpoint security controls. Privilege use becomes risk-relevant when it precedes changes to protection posture, update behavior, service state, policy enforcement, telemetry forwarding, or sensor health.

Security Tool and Control Discovery

Adversaries may inspect installed security tools, endpoint protection status, service names, update behavior, exclusion settings, policy configuration, and telemetry state. Discovery helps the attacker identify which controls can be weakened without immediately disrupting the host or triggering obvious containment actions.

Endpoint Protection Weakening

Adversaries may reduce endpoint protection features, weaken real-time protection, impair behavior monitoring, reduce cloud-delivered protection, alter sample submission behavior, modify remediation behavior, or otherwise reduce the likelihood that malicious activity will be blocked or detected.

Exclusion and Policy Abuse

Adversaries may create broad or suspicious exclusions for user-writable paths, temporary directories, staging locations, scripting paths, administrative shares, removable media, developer paths, or tool locations. They may also manipulate local policy, registry-backed configuration, or endpoint-management assumptions to create drift from expected managed posture.

Security Intelligence and Update Manipulation

Adversaries may suppress security intelligence updates, alter update sources, interfere with update behavior, remove definitions, or create stale protection conditions. This can reduce detection effectiveness while leaving the endpoint security product apparently present.

Service and Sensor Degradation

Adversaries may stop, disable, impair, or manipulate endpoint protection services, EDR services, sensor communication, telemetry forwarding, service recovery behavior, or agent health. This increases response uncertainty because degraded telemetry may reflect attacker activity rather than routine sensor failure.

Credential Access After Control Degradation

Adversaries may attempt credential dumping, LSASS access, registry hive access, credential enumeration, browser credential access, or credential-access tooling after weakening endpoint defenses. This is a high-risk follow-on behavior because endpoint-control degradation may reduce alerting and forensic completeness.

Persistence After Control Degradation

Adversaries may create scheduled tasks, services, autoruns, WMI persistence, startup artifacts, logon scripts, or user-profile persistence after reducing endpoint controls. Persistence created during a degraded control state may survive initial containment if endpoint integrity is not validated.

Expansion and Lateral Movement Preparation

Adversaries may use the degraded endpoint to stage tools, perform discovery, validate credentials, access administrative shares, use remote services, or prepare movement into additional systems. This expands the event from endpoint-control degradation into broader enterprise intrusion risk.

S20A — Adversary Tradecraft Summary

Endpoint defense subversion targets defensive trust rather than endpoint access alone. The adversary uses execution or privileged context to weaken the endpoint security layer before pursuing additional objectives. The tradecraft is effective because it can blend with legitimate administration, exploit visibility gaps, and force responders to validate both attacker behavior and the integrity of the controls used to investigate it.

·        The core tradecraft pattern is control weakening after execution or privileged access.

·        The behavior is not dependent on a single CVE, vendor product, exploit label, or malware family.

·        Legitimate administrative tools may be abused to reduce protection, alter policy, manipulate updates, impair services, or degrade telemetry.

·        The strongest operational risk occurs when endpoint-control degradation precedes credential access, persistence, discovery, outbound communication, or lateral movement.

·        Detection requires visibility into both attacker execution context and measurable endpoint-control state change.

·        Response requires treating degraded endpoint controls as a trust-impacting condition, not a routine configuration issue.

·        The behavior remains durable across endpoint products because the adversary objective is to reduce defensive reliability, regardless of the specific technology being targeted.

S21 — Detection Strategy Overview

Detection Philosophy

·        Detect endpoint security-control degradation as a chained post-compromise behavior pattern, not as a single product alert, exploit name, vulnerability label, vendor condition, or isolated configuration change.

·        The detection strategy focuses on observable attacker-driven degradation of endpoint protection after suspicious privilege transition, local administrative activity, or hands-on-keyboard execution.

·        BlueHammer, RedSun, and UnDefend are used as current evidence anchors only. They support the relevance of endpoint security-control degradation as a current behavior class but do not define the full report scope.

·        BlueHammer is treated as the CVE-anchored example of Microsoft Defender abuse. It is not treated as the report thesis, a standalone campaign, a Microsoft-only report driver, or an initial-access vulnerability.

·        RedSun and UnDefend are treated as reported supporting examples of Defender-oriented subversion and update disruption. They are not assigned CVE identifiers unless independently verified.

·        The durable detection objective is to identify endpoint security-control degradation across Defender, EDR, antivirus, endpoint telemetry, security intelligence updates, device-management policy, and endpoint protection posture.

·        The primary analytical unit is the behavior chain: suspicious privilege or administrative context, followed by endpoint security-control degradation, followed by optional credential access, persistence, discovery, or lateral movement preparation.

Detection Scope Boundary

·        This section addresses detection strategy for endpoint defense subversion after compromise.

·        This section does not address initial-access detection.

·        This section does not attempt direct BlueHammer exploit detection unless concrete exploit-specific telemetry exists.

·        This section does not treat Microsoft Defender as the only affected endpoint-control class.

·        This section does not treat RedSun or UnDefend as CVE-tracked vulnerabilities unless independently verified.

·        This section does not treat BlueHammer, RedSun, and UnDefend as a single confirmed campaign.

·        This section does not elevate isolated update failures, isolated service restarts, or generic configuration changes into deployable detections without suspicious context.

Primary Detection Anchors

·        Suspicious privilege transition followed by endpoint security-control degradation.

·        Local administrative activity followed by Defender, EDR, antivirus, update-service, device-management, or security telemetry modification.

·        Endpoint protection configuration tampering involving real-time protection, behavior monitoring, cloud-delivered protection, sample submission, tamper protection, remediation behavior, exclusions, update settings, telemetry forwarding, or sensor health.

·        Security intelligence update suppression after suspicious local administrative activity.

·        Endpoint protection service stop, service disablement, startup-type change, policy downgrade, update-source manipulation, or endpoint sensor degradation following suspicious process execution.

·        Broad or suspicious exclusion creation for user-writable paths, temporary directories, archive-extraction paths, staging directories, script paths, administrative shares, or attacker tooling locations.

·        Credential access, LSASS interaction, SAM access, credential enumeration, or persistence behavior after endpoint security-control degradation on the same host.

·        Security-control integrity drift from expected managed posture to reduced local protection posture.

Detection Prioritization Model

·        Highest priority detections identify a sequenced relationship between suspicious privilege or administrative activity and endpoint security-control degradation.

·        High priority detections include security intelligence or update suppression when correlated with suspicious local administrative activity, abnormal process ancestry, recently elevated account context, unauthorized management path usage, or local manipulation of update behavior.

·        Medium priority detections include protection-state degradation when tied to unusual administrative tooling, newly privileged accounts, non-standard execution paths, suspicious parent-child process relationships, or unmanaged local policy changes.

·        Conditional detections include credential access or persistence only when endpoint security-control degradation occurs first on the same host within a bounded time window.

·        Low priority monitoring includes uncorrelated endpoint protection drift, isolated update failure, expected service restart, or routine policy change. These conditions must not be deployed as standalone high-confidence detections.

·        Detection priority is based on behavior strength, chain specificity, telemetry reliability, deployability, and expected operational noise.

Correlation Strategy

·        Each deployable rule must independently correlate its own telemetry inputs.

·        Detection logic must not depend on the output, alert state, score, enrichment label, or conclusion of another rule.

·        Correlation must be based on direct observable evidence, including host identity, account identity, process identity, parent process, command line, affected setting, registry path, service action, protection-state transition, event time, and follow-on behavior.

·        Correlation windows must be explicit, bounded, and operationally deployable.

·        Same-host correlation is required for endpoint security-control degradation and follow-on credential access or persistence logic.

·        Same-account correlation should be used when available, but detection logic must account for SYSTEM-context execution, service execution, token elevation, token theft, and remote administrative execution where the initiating account may differ from the resulting security-control change.

·        Process-chain correlation should be prioritized where EDR, Sysmon, or equivalent telemetry supports parent process, grandparent process, signer, path, hash, and command-line fields.

·        Cross-platform enrichment may support triage, but it must not be required for detection unless the rule explicitly defines that dependency.

·        Suspicious context must be embedded in the detection logic rather than left for analysts to infer after alert generation.

Telemetry Prioritization

·        Endpoint process, command-line, parent-child process, and user-context telemetry has the highest priority because endpoint security-control degradation occurs locally after attacker execution.

·        Endpoint protection state telemetry has equal priority because the detection model depends on observing a transition from expected protected posture to reduced protection posture.

·        Device-management and endpoint-security policy telemetry is required to distinguish attacker-driven local degradation from approved centralized policy deployment, troubleshooting, migration, or recovery activity.

·        Windows Security logs, Defender operational logs, PowerShell logs, Sysmon or equivalent process telemetry, registry telemetry, service-control telemetry, endpoint protection state telemetry, and EDR device events are priority sources.

·        SIEM telemetry is useful when it preserves normalized process, command-line, account, host, registry, service, policy, protection-state, and timestamp fields.

·        Network telemetry is supporting context and must not be used as the primary rule basis for core endpoint security-control degradation detections.

·        Cloud telemetry is conditionally useful when it records endpoint-management policy changes, Defender for Endpoint device events, security-control configuration drift, remote administrative actions, device-risk state transitions, or centralized remediation events.

Detection Design Constraints

·        Do not attempt direct BlueHammer exploit detection unless concrete exploit-specific telemetry exists.

·        Do not deploy generic Defender tampering logic without suspicious context.

·        Do not deploy generic endpoint security-control tampering logic without suspicious context.

·        Do not deploy generic update failure as a standalone rule.

·        Do not deploy rules that alert on failed security updates unless the failure is paired with local manipulation, suspicious administrative context, unauthorized policy change, update-source manipulation, or abnormal execution context.

·        Do not deploy network-only rules for the core behavior.

·        Do not make Microsoft Defender the only relevant endpoint-control class.

·        Do not treat BlueHammer, RedSun, and UnDefend as a single confirmed campaign.

·        Do not classify BlueHammer as initial access.

·        Do not assign CVE identifiers to RedSun or UnDefend without independent verification.

·        Do not infer malicious activity from expected security engineering, help desk remediation, EDR migration, approved policy deployment, maintenance windows, break-glass recovery, or endpoint-management workflows.

·        Do not rely on exploit-name strings, proof-of-concept filenames, tool labels, or threat-name keywords as primary detection logic.

·        Do not use prior alert status or another rule’s output as detection input.

Baseline and Deployment Requirements

·        Establish approved administrative baselines for endpoint-security configuration changes.

·        Establish known-good security-control posture definitions by endpoint class, including workstation, server, domain controller, privileged access workstation, developer endpoint, cloud workload, and high-value asset groups.

·        Define expected protection posture for each endpoint class, including real-time protection, behavior monitoring, cloud-delivered protection, sample submission, tamper protection, remediation behavior, exclusion policy, update cadence, update source, service state, sensor health, and telemetry forwarding.

·        Identify authorized security-management sources, including Intune, Group Policy, SCCM, EDR consoles, patch-management platforms, security engineering scripts, help desk tooling, and break-glass administrative workflows.

·        Baseline expected administrators, service accounts, signed management binaries, policy deployment paths, maintenance windows, endpoint-management agents, and sanctioned security tooling workflows.

·        Validate command-line logging, PowerShell script block logging, registry auditing, service-control logging, Defender operational logging, endpoint protection state logging, and EDR process telemetry before deployment.

·        Normalize host identifiers, account identifiers, process identifiers, parent process fields, command-line fields, registry paths, service names, protection-state fields, policy identifiers, endpoint class, and event timestamps.

·        Define approved exception handling for legitimate troubleshooting, vendor support activity, failed updates, endpoint rebuilds, policy rollback, security product migration, and maintenance windows.

·        Confirm timestamp consistency across endpoint, SIEM, EDR, and device-management sources before enabling chained correlation logic.

Variant Resilience Requirements

·        Detection logic should account for PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled tasks, script hosts, endpoint-management tooling, remote administrative tooling, and renamed administrative binaries.

·        Detection logic should account for local administrator execution, token elevation, SYSTEM-context execution, service-context execution, remote administration, and abuse of legitimate management channels.

·        Detection logic should cover multiple degradation outcomes, including disabled protection, weakened cloud protection, added exclusions, impaired updates, stopped services, disabled telemetry, reduced remediation, sensor-health degradation, blocked security intelligence refresh, update-source manipulation, and tamper-protection weakening.

·        Detection logic must avoid single-artifact dependency on one process name, one registry value, one Defender setting, one service name, one exploit label, one command pattern, or one product-specific event.

·        Detection logic should preserve coverage when adversaries change tools but retain the same operational sequence of suspicious privilege activity, endpoint security-control degradation, and follow-on objective activity.

·        Detection logic should distinguish attacker-driven local degradation from centrally managed policy changes by validating execution context, parent process, signer, account, management source, maintenance window, affected host scope, and endpoint class.

Operational Detection Model

·        Deploy chained detections first, prioritizing endpoint security-control degradation after suspicious privilege transition.

·        Deploy update-suppression detections only when correlated with suspicious local administrative activity, abnormal execution context, unauthorized management path usage, local update manipulation, or abnormal account behavior.

·        Deploy credential-access follow-on detections only when endpoint security-control degradation precedes credential activity on the same host within a bounded window.

·        Use lower-severity monitoring for security-control integrity drift that lacks malicious context but still represents deviation from expected posture.

·        Route alerts to SOC workflows requiring process-tree reconstruction, endpoint protection-state validation, endpoint class validation, account review, recent administrative action review, update status review, management-platform validation, and containment assessment.

·        Triage should determine whether degradation was attacker-driven, administrator-approved, vendor-supported, policy-driven, recovery-driven, migration-related, or caused by expected maintenance.

Explicit Non-Deployment Guardrails

·        Do not deploy a rule based only on the presence of BlueHammer, RedSun, or UnDefend terminology.

·        Do not deploy a rule based only on a Defender, antivirus, EDR, or endpoint security update failure.

·        Do not deploy a rule based only on a Defender, antivirus, EDR, or endpoint protection service restart.

·        Do not deploy a rule based only on a configuration change by a known management platform during an approved change window.

·        Do not deploy a rule that treats generic endpoint security-control degradation as malicious without suspicious privilege, administrative, execution, policy, or follow-on context.

·        Do not deploy a rule that requires analysts to manually infer suspicious context after alert generation.

·        Do not deploy a rule that uses prior alert state, another detection’s output, or post-alert analyst judgment as an input.

·        Do not deploy a rule that cannot be implemented with available telemetry, bounded correlation, environment-specific baselines, known-good posture definitions, and operational allowlisting.

·        Do not deploy a rule that treats normal endpoint administration, security engineering, break-glass support, endpoint migration, endpoint recovery, or vendor support activity as malicious without suspicious execution context.

Detection Strategy Summary

·        Endpoint security-control degradation should be detected through chained behavioral correlation rather than isolated product alerts, vulnerability labels, vendor-specific indicators, or exploit-name references.

·        The strongest detection opportunities involve suspicious privilege or administrative context followed by measurable degradation of endpoint protection posture.

·        Generic update failures, isolated service restarts, and uncorrelated configuration changes should remain monitoring signals unless paired with suspicious local manipulation, abnormal administrative activity, or relevant follow-on behavior.

·        This strategy is durable beyond the Microsoft Defender examples because it applies across Defender, EDR, antivirus, endpoint telemetry, device-management, and endpoint security-control integrity monitoring.

S22 — Primary Detection Signals

Primary Detection Signals

·        Suspicious privilege transition followed by endpoint security-control degradation on the same host.

·        Local administrative activity followed by Defender, EDR, antivirus, endpoint protection, security telemetry, update-service, or device-management policy modification.

·        Endpoint protection configuration changes that reduce real-time protection, behavior monitoring, cloud-delivered protection, sample submission, tamper protection, remediation behavior, telemetry forwarding, update cadence, update source integrity, service state, or endpoint sensor health.

·        Broad or suspicious exclusions created for user-writable paths, temporary directories, archive-extraction paths, staging directories, scripting paths, administrative shares, removable media paths, developer tool paths, or known tool-staging locations.

·        Security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation after suspicious local administrative activity.

·        Endpoint protection service stop, disablement, startup-type change, restart suppression, policy downgrade, or sensor-health degradation following abnormal process execution.

·        Security-control integrity drift from expected managed posture to reduced local protection posture.

·        Credential access, LSASS interaction, SAM access, credential enumeration, or persistence behavior after endpoint security-control degradation on the same host within a bounded time window.

Supporting Detection Signals

·        Administrative tooling used to inspect privilege, group membership, security posture, service configuration, update status, or endpoint protection settings before endpoint security-control degradation.

·        PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote-administration tools, endpoint-management tooling, or renamed binaries used to modify endpoint protection posture.

·        Abnormal process ancestry involving browser, Office, archive utility, script host, remote access tool, VPN client, exploitation-adjacent process, user-facing application, or recently spawned administrative shell launching security-control modification activity.

·        Administrative execution from user-writable paths, temporary directories, download directories, archive-extraction paths, network shares, removable media, or recently written staging locations.

·        Registry modification affecting endpoint protection configuration, tamper protection, telemetry forwarding, update source, service state, policy enforcement, exclusion settings, or security intelligence behavior.

·        Service Control Manager activity showing service stop, disablement, startup-type modification, restart failure, repeated restart attempts, or service recovery modification affecting endpoint protection, EDR, antivirus, telemetry, or update components.

·        Device-management or policy telemetry showing deviation from centrally approved endpoint security posture.

·        Endpoint sensor health changes after suspicious administrative execution, including impaired telemetry flow, degraded agent state, disconnected sensor status, delayed check-in, reduced protection reporting, or failure to apply expected policy.

Exploit Attempt and Instability Signals

·        Local process crash, service crash, protection component fault, or endpoint security service instability immediately before privilege transition or endpoint security-control degradation.

·        Abnormal Defender, EDR, antivirus, or endpoint protection process behavior preceding a protection-state change.

·        Unexpected child-process creation from endpoint protection, update, service-hosting, or security-management components.

·        Suspicious privilege elevation indicators followed by local endpoint protection modification.

·        Security-control instability affecting a narrow set of hosts shortly before endpoint security-control degradation.

·        Repeated failed attempts to modify protection settings followed by successful degradation.

·        Protection component manipulation that does not map to approved patching, remediation, migration, policy rollback, recovery, or troubleshooting workflows.

Outbound Communication Signals

·        Outbound communication after endpoint security-control degradation to newly observed, low-reputation, rare, uncategorized, or host-role-inconsistent infrastructure.

·        Beacon-like or scripted outbound activity after protection-state reduction on the same host.

·        New outbound connections from processes launched from user-writable paths, temporary paths, archive-extraction directories, suspicious parent processes, or recently created persistence locations after endpoint protection degradation.

·        DNS lookups or web requests associated with payload staging, command-and-control preparation, tool retrieval, credential exfiltration, or lateral movement preparation after protection degradation.

·        Outbound communication from hosts that recently experienced endpoint sensor health degradation, telemetry suppression, endpoint protection policy drift, or security intelligence update suppression.

·        Network signals must remain supporting evidence unless they are tied to host-level endpoint security-control degradation and suspicious execution context.

Persistence and Post-Exploitation Signals (Conditional)

·        New scheduled task creation after endpoint security-control degradation.

·        New service creation, service modification, service recovery modification, or service binary path change after endpoint security-control degradation.

·        Registry autorun modification after endpoint security-control degradation.

·        WMI event subscription, script-based persistence, startup folder modification, logon script modification, or user-profile persistence after endpoint security-control degradation.

·        Credential access behavior after endpoint security-control degradation, including LSASS access, suspicious handle access, SAM or SECURITY hive access, credential enumeration, browser credential access, or use of credential-dumping tooling.

·        Discovery activity after endpoint security-control degradation, including local group enumeration, domain trust discovery, network share discovery, logged-on user discovery, session enumeration, endpoint protection discovery, or security tool discovery.

·        Defense evasion follow-on behavior after endpoint security-control degradation, including log clearing, telemetry suppression, event channel modification, script block logging reduction, service recovery manipulation, or security agent communication impairment.

Lateral Movement and Expansion Signals (Conditional)

·        Remote service creation, remote scheduled task creation, WMI remote execution, SMB-based execution, WinRM activity, PsExec-like behavior, or remote PowerShell after endpoint security-control degradation.

·        Authentication from a recently degraded host to multiple internal systems within a short time window.

·        Use of newly obtained, recently elevated, or unusual credentials from a host where endpoint protection posture was reduced.

·        Administrative share access, remote file copy, payload staging, or remote execution preparation after endpoint security-control degradation.

·        Lateral movement preparation involving domain enumeration, privileged group enumeration, remote host discovery, credential validation, or remote management discovery after endpoint security-control degradation.

·        Expansion signals must be treated as conditional follow-on evidence, not as substitutes for detecting the initial endpoint security-control degradation behavior.

Signal Usage Constraints

·        Do not use BlueHammer, RedSun, or UnDefend terminology as primary detection signals.

·        Do not treat generic Defender tampering as deployable without suspicious privilege, administrative, execution, policy, or follow-on context.

·        Do not treat generic endpoint security-control tampering as deployable without suspicious privilege, administrative, execution, policy, or follow-on context.

·        Do not treat generic update failure as deployable without evidence of local manipulation, suspicious administrative activity, unauthorized policy change, abnormal execution context, or update-source manipulation.

·        Do not treat isolated endpoint protection service restart as malicious without suspicious context.

·        Do not treat centrally approved policy deployment, endpoint migration, vendor support activity, break-glass recovery, recovery workflow, or maintenance-window activity as malicious without abnormal execution evidence.

·        Do not use network telemetry as the primary detection basis for the core behavior.

·        Do not rely on one product-specific field, one Defender setting, one registry value, one service name, one command pattern, one tool label, or one threat name as the full detection basis.

·        Do not use the output of another detection rule, prior alert state, post-alert analyst judgment, DRI, or TCR as an input signal.

·        Signals must be chained through direct observable telemetry, including host identity, account identity, process identity, parent process, command line, affected setting, service action, registry path, policy state, protection-state transition, timestamp, and follow-on behavior.

Detection Signal Summary

·        Primary signals emphasize endpoint security-control degradation after suspicious privilege, administrative, or execution context.

·        Supporting signals strengthen confidence through process ancestry, administrative tooling, registry modification, service-control activity, device-management drift, and endpoint sensor health changes.

·        Exploit attempt and instability signals remain supporting indicators unless chained to privilege transition, protection-state change, or suspicious local manipulation.

·        Conditional follow-on signals identify adversary objectives after security-control degradation, including credential access, persistence, discovery, defense evasion, and lateral movement preparation.

·        Network and outbound communication signals remain supporting context unless directly tied to host-level protection degradation and suspicious execution behavior.

·        The signal model remains durable beyond Microsoft Defender examples because it applies across Defender, EDR, antivirus, endpoint telemetry, device-management, and endpoint security-control integrity monitoring.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        Endpoint telemetry must capture process creation, process termination, parent-child process relationships, command-line arguments, process path, process signer, process hash, user context, elevation state, integrity level, host identity, and event timestamp.

·        EDR, Sysmon, Windows Security logs, or equivalent endpoint logging must support reconstruction of the process chain preceding endpoint security-control degradation.

·        Process telemetry must capture administrative tooling used for endpoint protection modification, including PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, endpoint-management tools, remote administration utilities, and script hosts.

·        Command-line visibility is required for high-confidence detection because endpoint security-control degradation often depends on specific configuration changes, service-control actions, registry modifications, update-source changes, or exclusion creation.

·        Parent and grandparent process visibility is required to distinguish expected administrative activity from suspicious execution launched by browsers, Office applications, archive utilities, script hosts, exploitation-adjacent processes, remote access tools, or user-facing applications.

·        Account context must include initiating user, effective user, logon session, local administrator status, domain administrator status where available, service account context, and SYSTEM-context execution where applicable.

·        Endpoint telemetry must preserve host identity consistently across EDR, SIEM, device-management, and Windows-native logs.

Endpoint Protection State Telemetry

·        Endpoint protection state telemetry must capture measurable transitions from expected protected posture to reduced protection posture.

·        Required state-change visibility includes real-time protection, behavior monitoring, cloud-delivered protection, sample submission, tamper protection, remediation behavior, exclusion policy, service state, update cadence, update source, security intelligence age, telemetry forwarding, and endpoint sensor health.

·        Defender, EDR, antivirus, and endpoint protection platforms must provide visibility into configuration changes, policy drift, service manipulation, update suppression, exclusion changes, protection disablement, and sensor degradation.

·        Protection-state telemetry must distinguish locally initiated endpoint security-control degradation from centrally managed policy changes.

·        Protection-state events must include affected setting, previous value where available, new value where available, initiating account where available, initiating process where available, management source where available, host identity, and timestamp.

·        Endpoint sensor health telemetry must capture agent disconnected status, impaired telemetry flow, delayed check-in, degraded protection reporting, policy application failure, and loss of expected endpoint-control visibility.

·        Without protection-state transition visibility, detection confidence is materially reduced because suspicious activity can be observed without confirming that endpoint protection posture changed.

Privilege and Account Context Telemetry

·        Windows Security logs, EDR identity context, identity provider logs, and privileged access management telemetry should capture suspicious privilege transition before endpoint security-control degradation.

·        Required account signals include new local administrator membership, privileged group membership changes, token elevation, logon type, remote logon source, service logon context, privileged session creation, and abnormal use of administrative credentials.

·        Telemetry should capture local account usage, domain account usage, service account usage, and SYSTEM-context execution.

·        Same-account correlation should be supported where possible, but telemetry must account for attacker workflows where initial user activity transitions into SYSTEM, service, scheduled task, or remote administrative contexts.

·        Identity telemetry must support evaluation of whether endpoint security-control degradation was performed by an expected administrator, service account, management platform, break-glass account, or anomalous user context.

·        Privilege telemetry must be normalized to the same host and time model used for process telemetry and endpoint protection state telemetry.

Registry and Configuration Telemetry

·        Registry telemetry must capture creation, modification, and deletion of keys and values associated with endpoint protection configuration, exclusion policy, telemetry forwarding, update settings, service configuration, tamper protection, and security intelligence behavior.

·        Registry event collection must preserve registry path, value name, previous value where available, new value where available, initiating process, initiating account, host identity, and timestamp.

·        Configuration telemetry must include policy changes made through local tools, Group Policy, Intune, SCCM, EDR console actions, endpoint-management agents, scripts, or direct registry manipulation.

·        Registry visibility is required for detecting adversaries who bypass user interfaces and modify endpoint protection posture through direct configuration changes.

·        Configuration telemetry must support differentiation between approved centralized policy deployment and local attacker-driven degradation.

·        Environments without registry or configuration telemetry should not deploy registry-dependent rules as high-confidence detections.

Service-Control and Sensor Health Telemetry

·        Service-control telemetry must capture service stop, service start, service disablement, startup-type modification, service recovery modification, service binary path modification, repeated restart failure, and restart suppression.

·        Required fields include service name, service display name, service action, previous state where available, new state where available, initiating process, initiating account, host identity, and timestamp.

·        Telemetry must cover Defender, EDR, antivirus, telemetry-forwarding, update, endpoint-management, and security sensor services.

·        Service Control Manager events, EDR service telemetry, Sysmon service events, and endpoint protection operational logs should be normalized into a common service-change model.

·        Sensor health telemetry must identify degraded agent state, disconnected agent state, communication impairment, delayed check-in, policy application failure, protection reporting gaps, or unexpected loss of telemetry.

·        Service-control and sensor health telemetry are required to distinguish actual endpoint security-control degradation from attempted but unsuccessful tampering.

Security Intelligence and Update Telemetry

·        Security intelligence and update telemetry must capture update cadence, update source, signature version, engine version, platform version, last successful update time, failed update attempts, update-policy changes, and security intelligence age.

·        Telemetry must identify local manipulation of update settings, update-source changes, policy downgrades, repeated update failure associated with local update-policy manipulation, update-source manipulation, or blocking of security intelligence refresh.

·        Update failure alone is not sufficient for high-confidence detection.

·        Update telemetry becomes detection-relevant when paired with suspicious local administrative activity, abnormal execution context, unauthorized policy change, update-source manipulation, or endpoint security-control degradation.

·        Required fields include update component, failure reason where available, update source, previous policy where available, new policy where available, initiating process where available, initiating account where available, host identity, and timestamp.

·        Environments must baseline normal update behavior by endpoint class, network segment, management platform, maintenance window, and product version to reduce false positives.

Device-Management and Policy Telemetry

·        Device-management telemetry is required to distinguish attacker-driven local degradation from approved centralized endpoint-security policy changes.

·        Required sources may include Intune, Group Policy, SCCM, EDR console actions, patch-management platforms, MDM platforms, security engineering automation, and help desk tooling.

·        Policy telemetry must capture policy assignment, policy removal, policy downgrade, exclusion deployment, security setting change, remediation action, endpoint migration, recovery workflow, and maintenance-window activity.

·        Required fields include management source, policy identifier, affected setting, previous value where available, new value where available, initiating administrator or service account, affected endpoint, endpoint class, deployment scope, and timestamp.

·        Policy telemetry must support validation of whether a local endpoint protection change aligns with centrally approved posture.

·        Without device-management context, detections may over-alert on legitimate policy deployment, endpoint migration, vendor support, break-glass recovery, or troubleshooting workflows.

Memory and Execution Telemetry

·        Memory and execution telemetry is conditionally required for detecting follow-on credential access after endpoint security-control degradation.

·        EDR or Sysmon-equivalent telemetry should capture suspicious process access to LSASS, credential store access, handle access patterns, memory reads, module loads, dump creation, and credential-dumping tool behavior.

·        Required fields include source process, target process, access rights where available, call stack where available, process signer, process path, process hash, initiating account, host identity, and timestamp.

·        Memory telemetry should not be treated as a substitute for endpoint protection state telemetry.

·        Credential access detections must be chained to prior endpoint security-control degradation on the same host within a bounded time window.

·        Environments without memory access telemetry should limit follow-on credential access detection to available artifacts such as dump file creation, suspicious process execution, SAM or SECURITY hive access, browser credential access, or known credential-access command patterns.

File and Persistence Telemetry

·        File telemetry must capture creation, modification, deletion, and execution from user-writable paths, temporary directories, download directories, archive-extraction paths, network shares, removable media, staging paths, and persistence locations.

·        Persistence telemetry must capture scheduled task creation, service creation, service binary modification, registry autorun modification, WMI event subscription, startup folder modification, logon script modification, and user-profile persistence.

·        Required fields include file path, file name, file hash, signer where available, creating process, modifying process, initiating account, host identity, and timestamp.

·        Persistence telemetry becomes high-value when observed after endpoint security-control degradation on the same host.

·        File and persistence telemetry should support differentiation between legitimate software deployment, endpoint-management activity, administrator maintenance, and attacker staging.

·        Environments without file and persistence telemetry should not deploy follow-on persistence rules as high-confidence detections.

Network and Outbound Communication Telemetry

·        Network telemetry is supporting telemetry for this report and must not be the primary basis for endpoint security-control degradation detection.

·        Required network telemetry includes DNS queries, outbound connections, destination domain, destination IP, URL where available, process-to-network mapping where available, host identity, account where available, reputation context, first-seen timing, and timestamp.

·        Network telemetry is most useful after endpoint security-control degradation when identifying payload retrieval, command-and-control preparation, credential exfiltration, lateral movement preparation, or newly observed infrastructure.

·        Process-to-network correlation materially improves confidence because it links outbound communication to suspicious execution context.

·        Network telemetry should be baselined by endpoint class, host role, user role, network segment, and expected application behavior.

·        Network signals must remain supporting evidence unless tied to host-level endpoint security-control degradation and suspicious execution behavior.

Web and Application Telemetry (Conditional Availability)

·        Web and application telemetry is conditionally useful when endpoint security-control degradation follows exploitation-adjacent execution, malicious document handling, browser-based activity, remote access tooling, or application-originated process chains.

·        Relevant telemetry includes browser downloads, web proxy events, secure web gateway logs, email security events, remote access logs, application crash events, and application-originated child-process activity.

·        Required fields include source user, source host, URL or file source where available, downloaded file name, file hash where available, parent application, child process, event time, and destination metadata.

·        Web and application telemetry should not be used as a substitute for endpoint telemetry or endpoint protection state telemetry.

·        These sources provide useful context for process ancestry and staging activity but do not independently prove endpoint security-control degradation.

·        Web and application telemetry should be used to strengthen triage and chain reconstruction when endpoint evidence shows subsequent protection-state reduction.

Telemetry Availability Requirements

·        Minimum viable telemetry requires process creation with command line, parent-child process relationships, account context, host identity, endpoint protection state-change visibility, service-control telemetry, registry or configuration telemetry, and event timestamps.

·        High-confidence deployment requires endpoint protection state telemetry, endpoint process telemetry, registry telemetry, service-control telemetry, device-management policy context, endpoint sensor health telemetry, and normalized SIEM correlation.

·        Conditional follow-on detections require credential access telemetry, file telemetry, persistence telemetry, and network telemetry tied to the same host and time window.

·        Correlation requires consistent host identity, account identity, timestamp normalization, endpoint class, management-source context, process context, affected setting, and protection-state transition across telemetry sources.

·        Detection logic must be degraded, scoped down, or withheld when required telemetry is unavailable, incomplete, delayed, or not normalized.

·        Telemetry validation must occur before deployment to confirm that required fields are present, field values are accurate, and event timing supports bounded sequence correlation.

Telemetry Limitations and Gaps

·        Missing command-line telemetry materially reduces the ability to distinguish benign administration from suspicious endpoint security-control degradation.

·        Missing endpoint protection state telemetry prevents confirmation that protection posture changed.

·        Missing registry telemetry limits visibility into direct configuration manipulation and exclusion abuse.

·        Missing service-control telemetry limits visibility into service stop, disablement, recovery modification, and startup-type manipulation.

·        Missing device-management telemetry increases false positives by making centrally approved policy changes harder to separate from local attacker activity.

·        Missing sensor health telemetry can hide successful endpoint security-control degradation or make telemetry loss appear as benign data absence.

·        Poor timestamp normalization can break chained detection logic and create false sequence assumptions.

·        Incomplete host identity normalization can prevent reliable same-host correlation.

·        Weak account context can obscure whether activity came from an expected administrator, anomalous user, service account, SYSTEM context, or compromised privileged identity.

·        Network-only visibility is insufficient for the core behavior and must not be used as a replacement for endpoint telemetry.

·        Detection coverage must be described as reduced when any required telemetry pillar is unavailable or unreliable.

Telemetry Requirements Summary

·        Endpoint process telemetry, endpoint protection state telemetry, registry and configuration telemetry, service-control telemetry, device-management policy telemetry, and sensor health telemetry form the core telemetry base for this behavior class.

·        Security intelligence and update telemetry are required for update-suppression detection but must be paired with suspicious local manipulation or administrative context.

·        Credential access, persistence, network, web, and application telemetry provide conditional follow-on context and must not replace direct observation of endpoint security-control degradation.

·        Reliable correlation depends on normalized host identity, account identity, endpoint class, management source, event time, process context, affected setting, and protection-state transition.

·        Environments with incomplete telemetry should reduce detection confidence, narrow deployment scope, or withhold affected detections rather than deploying generic low-confidence rules.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunity Overview

·        Endpoint security-control degradation creates strong detection opportunities when suspicious privilege, administrative, or execution context can be correlated with a measurable reduction in endpoint protection posture.

·        The strongest opportunities are behavior-chain detections that join precursor activity, protection-state degradation, and optional follow-on objective activity on the same host.

·        Detection opportunities are strongest when endpoint telemetry, protection-state telemetry, registry telemetry, service-control telemetry, device-management context, and endpoint sensor health telemetry are available and normalized.

·        Detection opportunities weaken materially when protection-state transitions cannot be directly observed.

·        Detection opportunities should remain vendor-neutral and durable across Defender, EDR, antivirus, endpoint telemetry, device-management, and endpoint security-control integrity monitoring.

·        BlueHammer, RedSun, and UnDefend remain evidence anchors only. They should not become detection keywords, campaign assumptions, or exploit-specific rule logic.

High-Value Core Detection Opportunities

·        Suspicious privilege transition followed by endpoint security-control degradation on the same host.

·        Local administrative activity followed by protection-state reduction, security-control policy downgrade, service disablement, update-source manipulation, or endpoint sensor health degradation.

·        Endpoint protection configuration tampering after suspicious process ancestry, including browser, Office, archive utility, script host, remote access tool, exploitation-adjacent process, or user-facing application spawning administrative tooling.

·        Broad or suspicious exclusion creation for user-writable paths, temporary directories, archive-extraction paths, staging directories, scripting paths, administrative shares, removable media paths, developer tool paths, or known tool-staging locations when paired with suspicious execution context or policy conflict.

·        Security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation after suspicious local administrative activity.

·        Endpoint protection service stop, startup-type modification, restart suppression, service recovery manipulation, or sensor health degradation after abnormal execution context.

·        Endpoint sensor health degradation followed by reduced telemetry flow, delayed check-in, disconnected agent state, impaired protection reporting, or failure to apply expected policy.

·        Security-control integrity drift from expected endpoint class posture to reduced protection posture when the drift is not explained by approved centralized policy, maintenance, migration, recovery, or vendor support activity.

Conditional Follow-On Detection Opportunities

·        Credential access, LSASS access, SAM or SECURITY hive access, browser credential access, or credential enumeration after endpoint security-control degradation on the same host within a bounded time window.

·        Persistence creation after endpoint security-control degradation, including scheduled tasks, service creation, autoruns, WMI persistence, startup folder modification, logon script modification, or user-profile persistence.

·        Discovery activity after endpoint security-control degradation, including local group enumeration, domain trust discovery, network share discovery, logged-on user discovery, session enumeration, endpoint protection discovery, or security tool discovery.

·        Defense evasion after endpoint security-control degradation, including log clearing, telemetry suppression, event channel modification, script block logging reduction, service recovery manipulation, or security agent communication impairment.

·        Lateral movement preparation after endpoint security-control degradation, including remote service creation, remote scheduled task creation, WinRM, WMI remote execution, PsExec-like behavior, administrative share access, remote PowerShell, or remote file staging.

·        Outbound communication after endpoint security-control degradation when newly observed, low-reputation, rare, uncategorized, or host-role-inconsistent destinations appear after protection-state reduction.

·        Network behavior after endpoint security-control degradation when process-to-network mapping ties outbound activity to suspicious execution context.

·        Web, email, browser, or application telemetry may support detection when it reconstructs the process chain that preceded endpoint security-control degradation.

·        Device-management and policy drift may support detection when local endpoint changes conflict with centrally approved posture.

·        Security intelligence age may support detection when staleness appears after local manipulation, unauthorized policy change, update-source manipulation, or blocking of security intelligence refresh.

·        Conditional opportunities are not sufficient by themselves. They require same-host correlation with endpoint security-control degradation and suspicious execution, administrative, policy, or follow-on context.

Detection Gaps

·        Missing command-line telemetry reduces confidence because many security-control degradation actions require command-line, script, registry, service-control, update-source, or exclusion details to separate malicious activity from administration.

·        Missing parent-child process visibility weakens the ability to identify suspicious execution origins and abnormal administrative chains.

·        Missing endpoint protection state telemetry prevents confirmation that endpoint security-control degradation occurred.

·        Missing registry telemetry limits visibility into direct configuration manipulation, exclusion abuse, update-source changes, and policy weakening.

·        Missing service-control telemetry limits visibility into service stop, startup-type modification, restart suppression, service recovery manipulation, and service binary path changes.

·        Missing device-management or policy telemetry increases false positives because approved centralized policy changes cannot be reliably separated from attacker-driven local degradation.

·        Missing endpoint sensor health telemetry may hide successful control degradation by making telemetry loss appear as ordinary data absence.

·        Missing privilege and account context weakens attribution of the degradation action to an expected administrator, anomalous user, service account, SYSTEM context, remote administrator, or compromised privileged identity.

·        Missing file and persistence telemetry limits detection of follow-on adversary objectives after protection-state reduction.

·        Missing memory and credential-access telemetry limits confidence in follow-on credential access detections.

·        Missing process-to-network mapping limits the usefulness of outbound communication as supporting evidence.

·        Poor timestamp normalization can break sequence logic and create false assumptions about whether privilege activity, protection degradation, and follow-on behavior were related.

·        Incomplete host identity normalization can prevent reliable same-host correlation across endpoint, EDR, SIEM, device-management, and Windows-native telemetry.

Rejected Detection Areas

·        Direct BlueHammer exploit detection is rejected unless concrete exploit-specific telemetry becomes available.

·        BlueHammer, RedSun, or UnDefend keyword matching is rejected as a primary detection method.

·        Generic Defender tampering without suspicious privilege, administrative, execution, policy, or follow-on context is rejected.

·        Generic endpoint security-control tampering without suspicious context is rejected.

·        Generic update failure without evidence of local manipulation, suspicious administrative activity, unauthorized policy change, abnormal execution context, or update-source manipulation is rejected.

·        Isolated security intelligence age or stale update status without suspicious local manipulation, unauthorized policy change, or update-source manipulation is rejected.

·        Isolated endpoint protection service restart without suspicious context is rejected.

·        Network-only detection for the core behavior is rejected.

·        Detection based only on newly observed outbound communication is rejected unless tied to host-level protection degradation and suspicious execution context.

·        Detection based only on endpoint sensor silence is rejected unless paired with observable degradation, suspicious execution context, or management-policy conflict.

·        Detection based only on a single product-specific field, one Defender setting, one registry value, one service name, one command pattern, one tool label, or one threat name is rejected.

·        Detection dependent on another rule’s output, prior alert state, analyst judgment after alert generation, DRI, or TCR is rejected.

Deployability Constraints

·        Deployable detections require direct observable telemetry, bounded correlation windows, reliable host identity, reliable timestamp normalization, and environment-specific baselines.

·        Deployable detections must distinguish attacker-driven local degradation from approved centralized policy deployment, endpoint migration, vendor support activity, break-glass recovery, maintenance windows, and troubleshooting workflows.

·        Deployable detections must include suspicious context within the rule logic rather than requiring analysts to infer maliciousness after alert generation.

·        Deployable detections must define the affected endpoint class, expected protection posture, authorized management sources, and known-good security-control configuration.

·        Deployable detections must account for SYSTEM-context execution, service-context execution, token elevation, token theft, remote administration, and endpoint-management abuse.

·        Deployable detections must avoid overfitting to Microsoft Defender and should remain applicable to broader endpoint protection and security-control integrity monitoring where telemetry supports the logic.

·        Deployable detections must be scoped down or withheld when the required telemetry from S23 is unavailable, incomplete, delayed, or not normalized.

·        Deployable detections must use DRI and TCR only as post-design scoring outputs, not as detection inputs or logic dependencies.

Variant and Evasion Considerations

·        Adversaries may use PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled tasks, script hosts, renamed binaries, remote administration tools, or endpoint-management tooling to degrade endpoint protection.

·        Adversaries may avoid obvious disablement and instead reduce protection through exclusions, update-source manipulation, policy weakening, telemetry suppression, remediation reduction, sensor communication impairment, or service recovery manipulation.

·        Adversaries may shift from user context to SYSTEM, service context, scheduled task context, or remote administrative context before degrading controls.

·        Adversaries may stage tooling in user-writable paths, temporary directories, download directories, network shares, removable media, archive-extraction paths, developer tool paths, or administrative shares.

·        Adversaries may perform credential access, persistence, discovery, defense evasion, or lateral movement only after protection posture is reduced.

·        Adversaries may attempt to blend with legitimate administrative tooling, endpoint-management activity, patching workflows, vendor support, or break-glass recovery.

·        Adversaries may degrade endpoint sensor health to reduce visibility before or after changing protection posture.

·        Detection logic should focus on the operational sequence and protection-state transition rather than a single tool, command, registry value, service name, product setting, or threat label.

Detection Opportunity Prioritization

·        Highest priority should be assigned to endpoint security-control degradation following suspicious privilege transition because it directly captures the core behavior chain.

·        High priority should be assigned to update suppression, update-source manipulation, or repeated update failure associated with local update-policy or update-source manipulation when chained to suspicious local administrative activity.

·        High priority should be assigned to protection-state degradation after abnormal process ancestry or unauthorized management path usage.

·        Medium priority should be assigned to broad exclusion creation when paired with suspicious execution context or policy conflict.

·        Medium priority should be assigned to sensor health degradation when paired with suspicious local activity, endpoint-management conflict, or follow-on objective behavior.

·        Conditional priority should be assigned to credential access, persistence, lateral movement, or outbound communication when these behaviors occur after endpoint security-control degradation on the same host within a bounded time window.

·        Low priority should be assigned to uncorrelated posture drift, isolated update failure, isolated security intelligence age, isolated service restart, and standalone network anomalies.

·        Low-priority signals should be used for enrichment, hunting, or posture review rather than high-confidence alerting unless chained to stronger evidence.

Detection Gap Impact

·        Telemetry gaps reduce deployability before they reduce analytical relevance. A behavior may be important but still unsuitable for high-confidence detection if required telemetry is missing.

·        Missing endpoint protection state telemetry is the highest-impact confirmation gap because it prevents verification that the core degradation event occurred.

·        Missing command-line and process-chain visibility is a high-impact context gap because it weakens separation between legitimate administration and suspicious control manipulation.

·        Missing registry and service-control telemetry is a high-impact visibility gap because it hides common paths used to modify endpoint protection posture.

·        Missing device-management context is a high-impact false-positive control gap because it prevents reliable separation of legitimate centralized policy changes from attacker-driven local degradation.

·        Missing timestamp normalization is a high-impact correlation gap because the detection model depends on ordered sequence correlation.

·        Missing memory, file, persistence, web, and network telemetry primarily affects follow-on objective detection rather than core degradation detection.

·        Detection coverage should be downgraded, narrowed, or withheld when high-impact telemetry gaps prevent reliable correlation.

S25 Rule Candidate Implications

·        Rule candidates should prioritize chained endpoint behavior over exploit-specific or vendor-keyword logic.

·        The strongest S25 candidate is endpoint security-control degradation following suspicious privilege transition.

·        A second strong S25 candidate is security intelligence update suppression, update-source manipulation, or repeated update failure associated with local update-policy or update-source manipulation correlated with suspicious local administrative activity.

·        A conditional third S25 candidate is credential access or persistence after endpoint security-control degradation, provided same-host correlation and bounded timing are available.

·        S25 rule writing must not begin until the full behavioral candidate sweep is completed.

·        The behavioral candidate sweep must enumerate materially observable behaviors, variants, evasion paths, telemetry limits, noise risks, deployability constraints, and rejection decisions before rule selection.

·        Candidate rules based only on generic tampering, generic update failure, isolated update staleness, network-only indicators, isolated service restarts, endpoint sensor silence, or BlueHammer, RedSun, and UnDefend terminology should be rejected.

·        Candidate rules must include their own correlation logic and must not depend on other rule outputs.

·        Candidate rules must include implementation requirements that define required telemetry, baselines, field mappings, allowed administrative sources, endpoint class scoping, and known-good posture assumptions.

Detection Opportunities and Gaps Summary

·        Endpoint security-control degradation provides strong detection opportunities when suspicious privilege, administrative, or execution context is chained to measurable protection-state reduction.

·        The highest-value opportunities involve same-host sequence correlation across process execution, privilege context, protection-state transition, registry or service manipulation, device-management context, and endpoint sensor health.

·        Conditional follow-on opportunities involving credential access, persistence, outbound communication, and lateral movement should remain secondary unless they occur after endpoint security-control degradation on the same host within a bounded time window.

·        The most important detection gaps are missing protection-state telemetry, missing command-line visibility, missing registry and service-control telemetry, missing device-management context, poor timestamp normalization, and incomplete host identity normalization.

·        Weak detection areas must remain rejected unless additional telemetry establishes suspicious context and confirms protection-state degradation.

·        S25 should proceed only with rule candidates that survive telemetry availability, noise, deployability, variant resilience, behavioral candidate sweep review, and non-circular scoring requirements.

S25 — Ultra-Tuned Detection Engineering Rules

Suricata

Detection Viability Assessment

·        No Suricata rule is included for this report.

Public Reporting Rationale

·        The core behavior evaluated in this report requires endpoint-level visibility into privilege context, endpoint protection-state changes, service-control activity, registry or configuration modification, update-source manipulation, and endpoint sensor health.

·        Suricata provides network-layer visibility and can support investigation of outbound activity, payload retrieval, command-and-control preparation, and post-compromise communication.

·        Suricata does not independently confirm endpoint security-control degradation.

·        A network-only signature would not provide sufficient confidence for the core behavior described in this report.

Detection Role

·        Suricata may be used as supporting enrichment when endpoint telemetry has already identified security-control degradation.

·        Relevant enrichment may include suspicious outbound communication, payload staging, unusual DNS activity, or command-and-control indicators.

·        Suricata should not be used as the primary detection source for endpoint defense subversion in this report.

Rule Count

·        Suricata S25 rule count: 0

SentinelOne

Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition

Rule Format

·        SentinelOne STAR custom detection logic using Deep Visibility telemetry.

Detection Objective

·        Detect suspicious privilege or administrative context followed by endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when suspicious privilege, administrative, or SYSTEM-context execution is followed by directly observed endpoint security-control degradation on the same host within 60 minutes.

·        Suspicious privilege or administrative activity includes elevated shell execution, local administrator activity, SYSTEM-context execution from abnormal ancestry, remote administrative execution, administrative utilities launched from suspicious paths, or user-facing applications spawning administrative tooling.

·        Endpoint security-control degradation includes real-time protection reduction, behavior monitoring reduction, cloud-delivered protection reduction, sample submission reduction, tamper-protection weakening, broad exclusion creation, endpoint protection service manipulation, endpoint sensor health degradation, telemetry forwarding reduction, or unmanaged policy downgrade.

·        Suppress or lower severity when activity maps to approved endpoint-management tooling, authorized security engineering activity, vendor support, maintenance windows, endpoint migration, or break-glass recovery.

·        Do not deploy this rule if endpoint protection-state transition visibility is unavailable.

Engineering Implementation Instructions

·        Map SentinelOne Deep Visibility fields for process name, process path, command line, parent process, parent command line, user, elevation context, integrity level where available, signer, hash, endpoint name, endpoint identifier, Storyline identifier, and timestamp.

·        Map SentinelOne or integrated endpoint telemetry for agent state, policy state, protection configuration, service state, sensor health, endpoint security-control posture, and endpoint protection changes.

·        Define organization-specific allowlists for authorized administrators, approved service accounts, sanctioned management tooling, EDR console activity, endpoint-management agents, maintenance windows, approved security engineering scripts, vendor support tooling, and break-glass workflows.

·        Define suspicious execution paths, including user profile paths, temporary directories, download directories, archive-extraction directories, administrative shares, removable media, public directories, and non-standard tooling paths.

·        Validate whether SentinelOne telemetry directly exposes the affected protection setting, previous value, new value, management source, initiating process, and initiating account.

·        Require direct endpoint security-control degradation evidence before enabling production alerting.

·        Treat the code as a deployment template and validate syntax, supported fields, event categories, and same-endpoint sequence correlation in the target SentinelOne tenant.

DRI

·        9.1

DRI Justification

·        The rule is strongly anchored to the core behavior chain of suspicious privilege or administrative context followed by measurable endpoint security-control degradation.

·        The rule resists simple tool changes because it does not depend on BlueHammer, RedSun, UnDefend, one process name, one command, one service, one registry value, or one Defender-only setting.

·        The rule covers multiple execution variants, including elevated shells, SYSTEM-context execution, remote administration, script hosts, renamed binaries, administrative utilities, endpoint-management abuse, and suspicious parent-child process chains.

·        The rule has low artifact dependence because it focuses on behavioral sequence and protection-state transition rather than tool signatures.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        8.4

Operational TCR Justification

·        SentinelOne commonly provides strong endpoint process, command-line, user, parent-child process, Storyline, and agent-state telemetry.

·        Operational confidence depends on whether the deployment exposes endpoint protection-state changes, policy changes, service changes, and sensor-health transitions in fields that can be reliably queried and correlated.

·        Device-management and maintenance-window context may require local environment allowlisting or external enrichment to reduce false positives.

·        The rule remains deployable in mature SentinelOne environments with strong endpoint telemetry, protection-state visibility, and known-good management baselines.

Full-Telemetry TCR

·        9.2

Full-Telemetry TCR Justification

·        With complete endpoint execution telemetry, endpoint protection-state telemetry, agent-health telemetry, service-control telemetry, policy telemetry, and approved management context, SentinelOne can directly support same-host sequence correlation for this behavior.

·        Full telemetry allows the rule to distinguish attacker-driven degradation from centrally approved security administration, endpoint recovery, endpoint migration, and policy deployment.

Rule Code

// SentinelOne Deep Visibility / STAR correlation template
// Rule 1: Endpoint Security-Control Degradation Following Suspicious Privilege Transition
// Deployment requirement: Validate field names, event categories, and sequence correlation support in the customer SentinelOne tenant.
// Correlation requirement: Same endpoint, preferably same Storyline or same account where available, within 60 minutes.
// Required sequence:
//   Event A: suspicious privilege or administrative execution
//   Event B: directly observed endpoint security-control degradation
// Alert only when Event A precedes Event B on the same endpoint.

SEQUENCE SAME_ENDPOINT WITHIN 60m
(
  EVENT_A:
  (
    (
      SrcProcName In AnyCase (
        "powershell.exe",
        "pwsh.exe",
        "cmd.exe",
        "wmic.exe",
        "reg.exe",
        "sc.exe",
        "schtasks.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe",
        "rundll32.exe"
      )
      OR TgtProcName In AnyCase (
        "powershell.exe",
        "pwsh.exe",
        "cmd.exe",
        "wmic.exe",
        "reg.exe",
        "sc.exe",
        "schtasks.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe",
        "rundll32.exe"
      )
    )
    AND
    (
      SrcProcParentName In AnyCase (
        "winword.exe",
        "excel.exe",
        "powerpnt.exe",
        "outlook.exe",
        "chrome.exe",
        "msedge.exe",
        "firefox.exe",
        "7z.exe",
        "winrar.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe"
      )
      OR SrcProcImagePath Contains AnyCase (
        "\\Users\\",
        "\\AppData\\",
        "\\Temp\\",
        "\\Downloads\\",
        "\\ProgramData\\",
        "\\Windows\\Temp\\",
        "\\Public\\",
        "\\ADMIN$\\",
        "\\C$\\"
      )
      OR TgtProcImagePath Contains AnyCase (
        "\\Users\\",
        "\\AppData\\",
        "\\Temp\\",
        "\\Downloads\\",
        "\\ProgramData\\",
        "\\Windows\\Temp\\",
        "\\Public\\",
        "\\ADMIN$\\",
        "\\C$\\"
      )
    )
  )

  FOLLOWED BY

  EVENT_B:
  (
    (
      SrcProcCmdLine Contains AnyCase (
        "Add-MpPreference",
        "Set-MpPreference",
        "DisableRealtimeMonitoring",
        "DisableBehaviorMonitoring",
        "DisableIOAVProtection",
        "DisableBlockAtFirstSeen",
        "SubmitSamplesConsent",
        "ExclusionPath",
        "ExclusionProcess",
        "ExclusionExtension",
        "SignatureFallbackOrder",
        "Stop-Service",
        "Set-Service",
        "sc stop",
        "sc config",
        "reg add",
        "reg delete"
      )
      OR TgtProcCmdLine Contains AnyCase (
        "Add-MpPreference",
        "Set-MpPreference",
        "DisableRealtimeMonitoring",
        "DisableBehaviorMonitoring",
        "DisableIOAVProtection",
        "DisableBlockAtFirstSeen",
        "SubmitSamplesConsent",
        "ExclusionPath",
        "ExclusionProcess",
        "ExclusionExtension",
        "SignatureFallbackOrder",
        "Stop-Service",
        "Set-Service",
        "sc stop",
        "sc config",
        "reg add",
        "reg delete"
      )
      OR SrcProcCmdLine Contains AnyCase (
        "WinDefend",
        "Sense",
        "WdNisSvc",
        "SecurityHealthService",
        "Windows Defender",
        "Microsoft Defender",
        "DisableAntiSpyware",
        "DisableAntiVirus",
        "TamperProtection"
      )
      OR TgtProcCmdLine Contains AnyCase (
        "WinDefend",
        "Sense",
        "WdNisSvc",
        "SecurityHealthService",
        "Windows Defender",
        "Microsoft Defender",
        "DisableAntiSpyware",
        "DisableAntiVirus",
        "TamperProtection"
      )
    )
    AND
    (
      EndpointProtectionStateChanged = true
      OR AgentHealthStateChanged = true
      OR PolicyStateChanged = true
      OR SecurityControlSettingChanged = true
      OR EndpointSecurityServiceStateChanged = true
    )
  )
)

Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity

Rule Format

·        SentinelOne STAR custom detection logic using Deep Visibility telemetry with Windows security-control and update telemetry enrichment where available.

Detection Objective

·        Detect suspicious local administrative activity followed by security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation.

Detection Logic

·        Trigger when suspicious local administrative activity is followed by update-related endpoint security-control degradation on the same host within 120 minutes.

·        Suspicious local administrative activity includes elevated PowerShell, CMD, WMI, registry utility, service-control utility, scheduled task utility, script host execution, administrative tooling launched from suspicious parent process ancestry, or administrative execution from suspicious paths.

·        Update-related degradation includes update-source manipulation, update-policy downgrade, security intelligence refresh blocking, security intelligence age increase after local manipulation, repeated update failure associated with local update-policy or update-source manipulation, or service or policy changes affecting endpoint security updates.

·        Do not alert on update failure alone.

·        Do not alert on expected patching, approved security engineering, endpoint migration, vendor support, maintenance-window activity, or known management-platform policy changes.

·        Do not deploy this rule unless update-related telemetry can be tied to host, initiating process, initiating account, and timestamp.

Engineering Implementation Instructions

·        Map SentinelOne Deep Visibility fields for initiating process, command line, parent process, parent command line, user, path, signer, hash, endpoint identifier, Storyline identifier, and timestamp.

·        Integrate Windows Defender, endpoint protection, operating system, or management-platform telemetry that exposes update source, update policy, signature version, engine version, platform version, last successful update time, failure reason, and security intelligence age.

·        Define approved update sources, expected update cadence, approved endpoint-management platforms, expected service accounts, authorized administrators, patching systems, and maintenance windows.

·        Baseline update behavior by endpoint class, including workstation, server, domain controller, privileged access workstation, developer endpoint, cloud workload, and high-value asset.

·        Require evidence of local update-policy manipulation, update-source manipulation, or security intelligence refresh blocking before treating update failure as detection-relevant.

·        Do not deploy this rule in environments where update telemetry cannot be tied to initiating process, account, host, and timestamp with sufficient reliability.

·        Treat the code as a deployment template and validate syntax, supported fields, event categories, update telemetry enrichment, and same-endpoint sequence correlation in the target SentinelOne tenant.

DRI

·        8.4

DRI Justification

·        The rule is behaviorally strong because it focuses on update suppression tied to suspicious local administrative context rather than generic update failure.

·        The rule adds distinct coverage for a degradation path that may leave protection enabled while reducing security intelligence freshness.

·        The rule is more fragile than Rule 1 because update behavior has greater benign operational overlap and requires precise distinction between update failure and update manipulation.

·        The rule resists basic evasion by covering update-source manipulation, update-policy downgrade, security intelligence refresh blocking, and related service or policy changes.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.6

Operational TCR Justification

·        SentinelOne endpoint execution telemetry is typically strong, but update-source, security intelligence, update-policy, and security intelligence age fields may require enrichment from Windows, Defender, endpoint protection, or management-platform telemetry.

·        Operational confidence depends on whether the environment can reliably connect update degradation to initiating process, account, host, and local manipulation.

·        False-positive control depends on accurate baselines for patching systems, update cadence, approved maintenance windows, and security platform management activity.

Full-Telemetry TCR

·        8.7

Full-Telemetry TCR Justification

·        With complete endpoint process telemetry, update telemetry, policy telemetry, and management-source context, the rule can reliably separate attacker-driven update suppression from routine update failure.

·        Full telemetry supports bounded same-host correlation between suspicious local administrative activity and update-related endpoint protection degradation.

Rule Code

// SentinelOne Deep Visibility / STAR correlation template
// Rule 2: Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity
// Deployment requirement: Requires update-policy, update-source, security intelligence, or Defender telemetry enrichment.
// Guardrail: Update failure alone must not alert.
// Correlation requirement: Same endpoint, preferably same Storyline or same account where available, within 120 minutes.
// Required sequence:
//   Event A: suspicious local administrative execution
//   Event B: update-policy manipulation, update-source manipulation, security intelligence refresh blocking, or update failure tied to local manipulation
// Alert only when Event A precedes Event B on the same endpoint.

SEQUENCE SAME_ENDPOINT WITHIN 120m
(
  EVENT_A:
  (
    (
      SrcProcName In AnyCase (
        "powershell.exe",
        "pwsh.exe",
        "cmd.exe",
        "wmic.exe",
        "reg.exe",
        "sc.exe",
        "schtasks.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe"
      )
      OR TgtProcName In AnyCase (
        "powershell.exe",
        "pwsh.exe",
        "cmd.exe",
        "wmic.exe",
        "reg.exe",
        "sc.exe",
        "schtasks.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe"
      )
    )
    AND
    (
      SrcProcParentName In AnyCase (
        "winword.exe",
        "excel.exe",
        "powerpnt.exe",
        "outlook.exe",
        "chrome.exe",
        "msedge.exe",
        "firefox.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe"
      )
      OR SrcProcImagePath Contains AnyCase (
        "\\Users\\",
        "\\AppData\\",
        "\\Temp\\",
        "\\Downloads\\",
        "\\ProgramData\\",
        "\\Windows\\Temp\\",
        "\\Public\\",
        "\\ADMIN$\\",
        "\\C$\\"
      )
      OR TgtProcImagePath Contains AnyCase (
        "\\Users\\",
        "\\AppData\\",
        "\\Temp\\",
        "\\Downloads\\",
        "\\ProgramData\\",
        "\\Windows\\Temp\\",
        "\\Public\\",
        "\\ADMIN$\\",
        "\\C$\\"
      )
    )
  )

  FOLLOWED BY

  EVENT_B:
  (
    (
      SrcProcCmdLine Contains AnyCase (
        "Set-MpPreference",
        "SignatureFallbackOrder",
        "SignatureDefinitionUpdateFileSharesSources",
        "DefinitionUpdatesChannel",
        "EngineUpdatesChannel",
        "PlatformUpdatesChannel",
        "UpdateSource",
        "DisableUpdate",
        "MpCmdRun.exe",
        "RemoveDefinitions",
        "SignatureUpdate",
        "Windows Defender\\Signature Updates",
        "reg add",
        "reg delete"
      )
      OR TgtProcCmdLine Contains AnyCase (
        "Set-MpPreference",
        "SignatureFallbackOrder",
        "SignatureDefinitionUpdateFileSharesSources",
        "DefinitionUpdatesChannel",
        "EngineUpdatesChannel",
        "PlatformUpdatesChannel",
        "UpdateSource",
        "DisableUpdate",
        "MpCmdRun.exe",
        "RemoveDefinitions",
        "SignatureUpdate",
        "Windows Defender\\Signature Updates",
        "reg add",
        "reg delete"
      )
    )
    AND
    (
      UpdatePolicyChanged = true
      OR UpdateSourceChanged = true
      OR SecurityIntelligenceRefreshBlocked = true
      OR SecurityIntelligenceAgeIncreasedAfterLocalManipulation = true
      OR (
        RepeatedUpdateFailure = true
        AND LocalUpdatePolicyOrSourceManipulationObserved = true
      )
    )
  )
)

Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation

Rule Format

·        SentinelOne STAR custom detection logic using Deep Visibility telemetry.

Detection Objective

·        Detect credential access or persistence activity that occurs after endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when directly observed endpoint security-control degradation is followed by credential access or persistence behavior on the same host within 240 minutes.

·        Endpoint security-control degradation includes protection reduction, broad exclusion creation, endpoint protection service manipulation, endpoint sensor health degradation, telemetry forwarding reduction, security intelligence update suppression, update-source manipulation, or policy downgrade not aligned with approved management activity.

·        Credential access behavior includes LSASS access, suspicious process handle access, dump file creation, SAM or SECURITY hive access, browser credential access, credential enumeration, or credential-access behavior that does not rely solely on tool name.

·        Persistence behavior includes scheduled task creation, service creation, service binary path modification, registry autorun modification, WMI persistence, startup folder modification, logon script modification, or user-profile persistence.

·        Suppress or lower severity when follow-on behavior maps to approved software deployment, endpoint-management activity, administrator maintenance, vendor support, endpoint recovery, backup tooling, or known security tooling.

·        Do not deploy this rule as a generic credential-access or persistence detector. Prior endpoint security-control degradation is required.

Engineering Implementation Instructions

·        Map SentinelOne telemetry for endpoint security-control degradation, process access, target process, source process, command line, file creation, registry modification, service creation, scheduled task creation, user context, host identity, Storyline identifier, and timestamp.

·        Confirm that SentinelOne captures LSASS access, suspicious handle access, dump creation, registry hive access, service creation, scheduled task creation, persistence-relevant file changes, and persistence-relevant registry changes in the target environment.

·        Define expected administrative credential tooling, authorized security tools, backup agents, EDR components, software deployment tools, endpoint-management agents, and legitimate persistence mechanisms used by the organization.

·        Tune timing windows by endpoint class and operational pattern. Shorter windows may reduce noise for workstations. Longer windows may be needed for servers or delayed adversary activity.

·        Do not deploy this rule if endpoint security-control degradation cannot be directly observed before the credential access or persistence behavior.

·        Treat the code as a deployment template and validate syntax, supported fields, event categories, degradation telemetry, and same-endpoint sequence correlation in the target SentinelOne tenant.

DRI

·        8.2

DRI Justification

·        The rule adds meaningful post-degradation objective coverage by identifying credential access or persistence after endpoint protection has been weakened.

·        The rule is behaviorally anchored because credential access or persistence must follow measurable endpoint security-control degradation on the same host.

·        The rule is weaker than Rule 1 because it depends on a longer behavior chain and may miss delayed follow-on activity outside the correlation window.

·        The rule resists tool substitution by covering multiple credential access and persistence patterns rather than one tool label or one command.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        8.0

Operational TCR Justification

·        SentinelOne commonly provides strong visibility into process behavior, file activity, service creation, registry modification, and suspicious credential-access activity.

·        Operational confidence depends on the completeness of endpoint protection-state telemetry and the quality of same-host bounded-time correlation.

·        False-positive control depends on accurate allowlisting for security tools, software deployment systems, backup agents, administrator maintenance, endpoint-management workflows, and recovery activity.

Full-Telemetry TCR

·        8.8

Full-Telemetry TCR Justification

·        With complete endpoint degradation telemetry, process access telemetry, file telemetry, registry telemetry, service telemetry, scheduled task telemetry, and persistence telemetry, the rule provides strong post-degradation objective coverage.

·        Full telemetry enables reliable separation of attacker objective activity from legitimate administrative, security, deployment, backup, and recovery workflows.

Rule Code

// SentinelOne Deep Visibility / STAR correlation template
// Rule 3: Credential Access or Persistence After Endpoint Security-Control Degradation
// Deployment requirement: Endpoint security-control degradation must be directly observable before this logic is enabled as an alert.
// Guardrail: Do not deploy as a generic credential-access or persistence rule.
// Correlation requirement: Same endpoint, preferably same Storyline or same account where available, within 240 minutes.
// Required sequence:
//   Event A: directly observed endpoint security-control degradation
//   Event B: credential access or persistence behavior
// Alert only when Event A precedes Event B on the same endpoint.

SEQUENCE SAME_ENDPOINT WITHIN 240m
(
  EVENT_A:
  (
    EndpointProtectionStateChanged = true
    OR AgentHealthStateChanged = true
    OR PolicyStateChanged = true
    OR SecurityControlSettingChanged = true
    OR EndpointSecurityServiceStateChanged = true
    OR SecurityIntelligenceRefreshBlocked = true
    OR UpdateSourceChanged = true
    OR TelemetryForwardingReduced = true
    OR BroadOrSuspiciousExclusionCreated = true
  )

  FOLLOWED BY

  EVENT_B:
  (
    (
      TgtProcName In AnyCase (
        "lsass.exe"
      )
      OR SrcProcCmdLine Contains AnyCase (
        "comsvcs.dll",
        "MiniDump",
        "procdump",
        "rundll32",
        "lsass",
        "reg save",
        "\\SAM",
        "\\SECURITY",
        "cmdkey",
        "vaultcmd",
        "sekurlsa",
        "logonpasswords"
      )
      OR TgtProcCmdLine Contains AnyCase (
        "comsvcs.dll",
        "MiniDump",
        "procdump",
        "rundll32",
        "lsass",
        "reg save",
        "\\SAM",
        "\\SECURITY",
        "cmdkey",
        "vaultcmd",
        "sekurlsa",
        "logonpasswords"
      )
    )
    OR
    (
      SrcProcCmdLine Contains AnyCase (
        "schtasks /create",
        "New-ScheduledTask",
        "sc create",
        "New-Service",
        "sc config",
        "reg add",
        "CurrentVersion\\Run",
        "__EventFilter",
        "CommandLineEventConsumer",
        "ActiveScriptEventConsumer",
        "Startup",
        "Logon Script"
      )
      OR TgtProcCmdLine Contains AnyCase (
        "schtasks /create",
        "New-ScheduledTask",
        "sc create",
        "New-Service",
        "sc config",
        "reg add",
        "CurrentVersion\\Run",
        "__EventFilter",
        "CommandLineEventConsumer",
        "ActiveScriptEventConsumer",
        "Startup",
        "Logon Script"
      )
    )
  )
)

SentinelOne Rule Count

·        SentinelOne S25 rule count: 3

Splunk

Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition

Rule Format

·        Splunk SPL correlation search.

Detection Objective

·        Detect suspicious privilege or administrative execution followed by directly observed endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when suspicious administrative execution is followed by directly observed endpoint security-control degradation on the same host within 60 minutes.

·        Suspicious administrative execution includes elevated PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tooling, or administrative binaries launched from suspicious parent processes or suspicious paths.

·        Endpoint security-control degradation must be directly observable through protection-state change, policy-state change, endpoint security service-state change, sensor-health change, security-control setting change, or equivalent endpoint protection telemetry.

·        Command-line indicators may support the degradation event but must not substitute for direct protection-state or security-control state evidence.

·        Suppress or lower severity when the activity maps to approved endpoint-management tooling, authorized security engineering activity, vendor support, maintenance windows, endpoint migration, or break-glass recovery.

·        Do not deploy this rule if endpoint protection-state transition visibility is unavailable.

Engineering Implementation Instructions

·        Normalize process telemetry into fields for host, user, process name, process path, command line, parent process, parent command line, process hash, signer, process GUID where available, and timestamp.

·        Normalize endpoint security-control degradation telemetry into fields for host, affected setting, previous value, new value, management source, initiating process where available, initiating account where available, event type, and timestamp.

·        Required data sources may include Windows Security logs, Sysmon, EDR telemetry, Defender operational logs, endpoint protection platform logs, registry telemetry, service-control telemetry, and endpoint sensor health telemetry.

·        Create and maintain Splunk lookups for authorized administrators, approved service accounts, endpoint-management platforms, approved maintenance windows, known security engineering scripts, vendor support tooling, endpoint migration activity, and break-glass workflows.

·        Validate same-host correlation using normalized host identifiers across endpoint, Windows, EDR, Defender, and device-management sources.

·        Validate timestamp normalization before enabling the correlation window.

·        Do not deploy this rule as a single-event keyword search. It must require same-host sequence correlation between suspicious administrative activity and directly observed endpoint security-control degradation.

DRI

·        8.9

DRI Justification

·        The rule is strongly anchored to the core behavior chain of suspicious administrative or privilege context followed by measurable endpoint security-control degradation.

·        The rule resists simple tool changes because it does not depend on BlueHammer, RedSun, UnDefend, one process name, one command, one service, one registry value, or one Defender-only setting.

·        The rule covers multiple execution variants, including elevated shells, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration, renamed binaries, and suspicious parent-child process chains.

·        The rule has low artifact dependence because it focuses on behavior sequence and protection-state transition rather than tool signatures.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.6

Operational TCR Justification

·        Splunk can support strong correlation when endpoint, Windows, Defender, EDR, registry, service-control, device-management, and endpoint protection telemetry are onboarded and normalized.

·        Operational confidence depends heavily on data onboarding quality, sourcetype consistency, field extraction quality, timestamp normalization, host normalization, and lookup maintenance.

·        Device-management and approved maintenance context are often environment-specific and must be implemented through local lookups or enrichment.

·        The rule remains deployable in mature Splunk environments with complete endpoint telemetry and reliable field normalization.

Full-Telemetry TCR

·        9.1

Full-Telemetry TCR Justification

·        With complete endpoint execution telemetry, endpoint protection-state telemetry, registry telemetry, service-control telemetry, device-management context, sensor health telemetry, and normalized timestamps, Splunk can support high-confidence same-host sequence correlation.

·        Full telemetry allows the rule to separate attacker-driven local degradation from approved security administration, endpoint recovery, endpoint migration, and policy deployment.

Rule Code

| multisearch
    [
      search index=<endpoint_index> (
        process_name IN ("powershell.exe","pwsh.exe","cmd.exe","wmic.exe","reg.exe","sc.exe","schtasks.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
        OR process IN ("powershell.exe","pwsh.exe","cmd.exe","wmic.exe","reg.exe","sc.exe","schtasks.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
      )
      (
        parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","chrome.exe","msedge.exe","firefox.exe","7z.exe","winrar.exe","wscript.exe","cscript.exe","mshta.exe")
        OR process_path="*\\Users\\*"
        OR process_path="*\\AppData\\*"
        OR process_path="*\\Temp\\*"
        OR process_path="*\\Downloads\\*"
        OR process_path="*\\ProgramData\\*"
        OR process_path="*\\Windows\\Temp\\*"
        OR process_path="*\\Public\\*"
        OR process_path="*\\ADMIN$\\*"
        OR process_path="*\\C$\\*"
        OR command_line="*runas*"
        OR command_line="*net localgroup administrators*"
        OR command_line="*whoami /priv*"
      )
      | eval event_role="suspicious_admin_execution"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name process_path command_line parent_process_name parent_process
    ]
    [
      search index=<endpoint_or_defender_index> (
        EndpointProtectionStateChanged=true
        OR AgentHealthStateChanged=true
        OR PolicyStateChanged=true
        OR SecurityControlSettingChanged=true
        OR EndpointSecurityServiceStateChanged=true
        OR affected_setting IN ("RealtimeProtection","BehaviorMonitoring","CloudProtection","SampleSubmission","TamperProtection","ExclusionPolicy","TelemetryForwarding","SensorHealth","PolicyState")
        OR service_name IN ("WinDefend","Sense","WdNisSvc","SecurityHealthService")
      )
      | eval direct_degradation_observed=if(
          EndpointProtectionStateChanged=true
          OR AgentHealthStateChanged=true
          OR PolicyStateChanged=true
          OR SecurityControlSettingChanged=true
          OR EndpointSecurityServiceStateChanged=true
          OR isnotnull(affected_setting)
          OR isnotnull(service_name),
          1, 0
        )
      | where direct_degradation_observed=1
      | eval event_role="endpoint_security_control_degradation"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name process_path command_line parent_process_name parent_process affected_setting previous_value new_value service_name management_source direct_degradation_observed
    ]
| stats
    min(eval(if(event_role="suspicious_admin_execution", event_time, null()))) as first_admin_time
    min(eval(if(event_role="endpoint_security_control_degradation", event_time, null()))) as first_degradation_time
    values(event_role) as event_roles
    values(entity_user) as users
    values(process_name) as process_names
    values(parent_process_name) as parent_process_names
    values(command_line) as command_lines
    values(affected_setting) as affected_settings
    values(service_name) as services
    values(management_source) as management_sources
    max(direct_degradation_observed) as direct_degradation_observed
  by entity_host
| where mvfind(event_roles,"suspicious_admin_execution")>=0
    AND mvfind(event_roles,"endpoint_security_control_degradation")>=0
    AND direct_degradation_observed=1
    AND first_admin_time <= first_degradation_time
    AND first_degradation_time - first_admin_time <= 3600
| lookup approved_endpoint_management_sources management_source as management_sources OUTPUT management_source as approved_management_source
| lookup approved_security_admins user as users OUTPUT user as approved_admin
| lookup approved_maintenance_windows entity_host OUTPUT maintenance_window_active
| where isnull(approved_management_source)
    AND isnull(approved_admin)
    AND coalesce(maintenance_window_active,"false")!="true"
| eval rule_name="Endpoint Security-Control Degradation Following Suspicious Privilege Transition"
| eval severity="high"
| eval description="Suspicious administrative execution was followed by directly observed endpoint security-control degradation on the same host within 60 minutes."
| table rule_name severity entity_host users first_admin_time first_degradation_time process_names parent_process_names command_lines affected_settings services description

Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity

Rule Format

·        Splunk SPL correlation search.

Detection Objective

·        Detect suspicious local administrative activity followed by security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation.

Detection Logic

·        Trigger when suspicious local administrative activity is followed by update-related endpoint security-control degradation on the same host within 120 minutes.

·        Suspicious local administrative activity includes elevated PowerShell, CMD, WMI, registry utility, service-control utility, scheduled task utility, script host execution, administrative tooling launched from suspicious parent process ancestry, or administrative execution from suspicious paths.

·        Update-related degradation requires update-source manipulation, update-policy manipulation, security intelligence refresh blocking, security intelligence age increase after local manipulation, or repeated update failure paired with local update-policy or update-source manipulation.

·        Update failure alone must not alert.

·        Do not alert on expected patching, approved security engineering, endpoint migration, vendor support, maintenance-window activity, or known management-platform policy changes.

·        Do not deploy this rule unless update-related telemetry can be tied to host, initiating process, initiating account, and timestamp.

Engineering Implementation Instructions

·        Normalize endpoint process telemetry into fields for host, user, process name, process path, command line, parent process, parent command line, and timestamp.

·        Normalize security intelligence and update telemetry into fields for host, update source, update policy, update component, signature version, engine version, platform version, last successful update time, update failure reason, security intelligence age, initiating process where available, initiating account where available, and timestamp.

·        Required data sources may include Defender operational logs, endpoint protection logs, Windows event logs, EDR telemetry, registry telemetry, service-control telemetry, and device-management or patch-management logs.

·        Create and maintain lookups for approved update sources, expected update cadence, endpoint classes, approved patching systems, authorized administrators, service accounts, maintenance windows, and device-management platforms.

·        Require evidence of update-source manipulation, update-policy manipulation, or security intelligence refresh blocking before treating update failure as detection-relevant.

·        Validate that update telemetry and suspicious administrative telemetry can be correlated to the same normalized host identity.

·        Do not deploy the rule as update-failure-only logic.

DRI

·        8.3

DRI Justification

·        The rule is behaviorally meaningful because it focuses on update suppression tied to suspicious local administrative context rather than generic update failure.

·        The rule adds distinct coverage for a degradation path that may leave endpoint protection nominally enabled while reducing security intelligence freshness.

·        The rule is weaker than Rule 1 because update behavior has greater benign operational overlap and requires precise separation between routine update failure and local manipulation.

·        The rule covers multiple update degradation variants, including update-source manipulation, update-policy downgrade, security intelligence refresh blocking, and repeated update failure associated with local manipulation.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.1

Operational TCR Justification

·        Splunk can correlate update degradation with local administrative activity when process telemetry, Defender or endpoint protection logs, registry telemetry, and update telemetry are onboarded and normalized.

·        Operational confidence depends on whether update-source, update-policy, security intelligence age, update failure reason, initiating process, account, and timestamp fields are reliably extracted.

·        False-positive control depends on accurate baselines for patching systems, maintenance windows, endpoint class, update cadence, approved update sources, and management-platform activity.

·        The rule is deployable in mature Splunk environments but should be withheld or scoped down where update telemetry is incomplete or not tied to local manipulation.

Full-Telemetry TCR

·        8.8

Full-Telemetry TCR Justification

·        With complete endpoint process telemetry, update telemetry, registry telemetry, service-control telemetry, policy telemetry, management-source context, and normalized host identity, Splunk can reliably separate attacker-driven update suppression from routine update failure.

·        Full telemetry supports same-host bounded correlation between suspicious local administrative activity and update-related endpoint protection degradation.

Rule Code

| multisearch
    [
      search index=<endpoint_index> (
        process_name IN ("powershell.exe","pwsh.exe","cmd.exe","wmic.exe","reg.exe","sc.exe","schtasks.exe","wscript.exe","cscript.exe","mshta.exe")
        OR process IN ("powershell.exe","pwsh.exe","cmd.exe","wmic.exe","reg.exe","sc.exe","schtasks.exe","wscript.exe","cscript.exe","mshta.exe")
      )
      (
        parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","chrome.exe","msedge.exe","firefox.exe","wscript.exe","cscript.exe","mshta.exe")
        OR process_path="*\\Users\\*"
        OR process_path="*\\AppData\\*"
        OR process_path="*\\Temp\\*"
        OR process_path="*\\Downloads\\*"
        OR process_path="*\\ProgramData\\*"
        OR process_path="*\\Windows\\Temp\\*"
        OR process_path="*\\Public\\*"
        OR process_path="*\\ADMIN$\\*"
        OR process_path="*\\C$\\*"
      )
      | eval event_role="suspicious_local_admin_execution"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name process_path command_line parent_process_name parent_process
    ]
    [
      search index=<endpoint_or_defender_index> (
        command_line="*Set-MpPreference*"
        OR command_line="*SignatureFallbackOrder*"
        OR command_line="*SignatureDefinitionUpdateFileSharesSources*"
        OR command_line="*DefinitionUpdatesChannel*"
        OR command_line="*EngineUpdatesChannel*"
        OR command_line="*PlatformUpdatesChannel*"
        OR command_line="*UpdateSource*"
        OR command_line="*DisableUpdate*"
        OR command_line="*MpCmdRun.exe*"
        OR command_line="*RemoveDefinitions*"
        OR command_line="*Windows Defender\\Signature Updates*"
        OR registry_path="*Windows Defender\\Signature Updates*"
        OR UpdatePolicyChanged=true
        OR UpdateSourceChanged=true
        OR SecurityIntelligenceRefreshBlocked=true
        OR SecurityIntelligenceAgeIncreasedAfterLocalManipulation=true
        OR LocalUpdatePolicyOrSourceManipulationObserved=true
      )
      | eval update_manipulation_observed=if(
          UpdatePolicyChanged=true
          OR UpdateSourceChanged=true
          OR SecurityIntelligenceRefreshBlocked=true
          OR SecurityIntelligenceAgeIncreasedAfterLocalManipulation=true
          OR LocalUpdatePolicyOrSourceManipulationObserved=true
          OR like(command_line,"%SignatureFallbackOrder%")
          OR like(command_line,"%SignatureDefinitionUpdateFileSharesSources%")
          OR like(command_line,"%DefinitionUpdatesChannel%")
          OR like(command_line,"%EngineUpdatesChannel%")
          OR like(command_line,"%PlatformUpdatesChannel%")
          OR like(command_line,"%UpdateSource%")
          OR like(registry_path,"%Windows Defender\\Signature Updates%"),
          1, 0
        )
      | where update_manipulation_observed=1
      | eval event_role="update_policy_or_source_manipulation"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name process_path command_line parent_process_name registry_path update_source update_policy update_component failure_reason update_manipulation_observed
    ]
    [
      search index=<endpoint_or_defender_index> (
        RepeatedUpdateFailure=true
        OR event_type="update_failure"
        OR signature_update_status="failed"
        OR update_status="failed"
      )
      | eval event_role="repeated_update_failure"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role update_component failure_reason update_source update_policy signature_version engine_version platform_version
    ]
| stats
    min(eval(if(event_role="suspicious_local_admin_execution", event_time, null()))) as first_admin_time
    min(eval(if(event_role="update_policy_or_source_manipulation", event_time, null()))) as first_update_manipulation_time
    min(eval(if(event_role="repeated_update_failure", event_time, null()))) as first_update_failure_time
    values(event_role) as event_roles
    values(entity_user) as users
    values(process_name) as process_names
    values(parent_process_name) as parent_process_names
    values(command_line) as command_lines
    values(registry_path) as registry_paths
    values(update_source) as update_sources
    values(update_policy) as update_policies
    values(update_component) as update_components
    values(failure_reason) as failure_reasons
    max(update_manipulation_observed) as update_manipulation_observed
  by entity_host
| where mvfind(event_roles,"suspicious_local_admin_execution")>=0
    AND mvfind(event_roles,"update_policy_or_source_manipulation")>=0
    AND update_manipulation_observed=1
    AND first_admin_time <= first_update_manipulation_time
    AND first_update_manipulation_time - first_admin_time <= 7200
| where isnull(first_update_failure_time)
    OR (
      first_update_manipulation_time <= first_update_failure_time
      AND first_update_failure_time - first_update_manipulation_time <= 7200
    )
| lookup approved_update_sources update_source as update_sources OUTPUT update_source as approved_update_source
| lookup approved_patch_management_sources entity_host OUTPUT patch_management_approved
| lookup approved_maintenance_windows entity_host OUTPUT maintenance_window_active
| where isnull(approved_update_source)
    AND coalesce(patch_management_approved,"false")!="true"
    AND coalesce(maintenance_window_active,"false")!="true"
| eval rule_name="Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity"
| eval severity="high"
| eval description="Suspicious local administrative execution was followed by update-policy or update-source manipulation on the same host. Update failure alone is not sufficient for this alert."
| table rule_name severity entity_host users first_admin_time first_update_manipulation_time first_update_failure_time process_names parent_process_names command_lines registry_paths update_sources update_policies update_components failure_reasons description

Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation

Rule Format

·        Splunk SPL correlation search.

Detection Objective

·        Detect credential access or persistence activity that occurs after directly observed endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when directly observed endpoint security-control degradation is followed by credential access or persistence behavior on the same host within 240 minutes.

·        Endpoint security-control degradation includes protection reduction, broad exclusion creation, endpoint protection service manipulation, endpoint sensor health degradation, telemetry forwarding reduction, security intelligence update suppression, update-source manipulation, or unmanaged policy downgrade.

·        Credential access behavior includes LSASS access, suspicious process handle access, dump file creation, SAM or SECURITY hive access, browser credential access, credential enumeration, or credential-access behavior that does not rely solely on tool name.

·        Persistence behavior includes scheduled task creation, service creation, service binary path modification, registry autorun modification, WMI persistence, startup folder modification, logon script modification, or user-profile persistence.

·        Suppress or lower severity when follow-on behavior maps to approved software deployment, endpoint-management activity, administrator maintenance, vendor support, endpoint recovery, backup tooling, or known security tooling.

·        Do not deploy this rule as a generic credential-access or persistence detector. Prior directly observed endpoint security-control degradation is required.

Engineering Implementation Instructions

·        Normalize endpoint security-control degradation telemetry into fields for host, affected setting, service action, policy state, sensor health state, update source, initiating process, initiating account, and timestamp.

·        Normalize credential access telemetry into fields for source process, target process, access rights where available, command line, file path, registry path, process hash, signer, account, host, and timestamp.

·        Normalize persistence telemetry into fields for scheduled task name, service name, service binary path, registry autorun path, WMI event subscription, startup path, creating process, modifying process, user, host, and timestamp.

·        Required data sources may include EDR telemetry, Sysmon, Windows Security logs, Defender or endpoint protection telemetry, registry telemetry, service-control telemetry, scheduled task logs, WMI activity logs, and file telemetry.

·        Create and maintain lookups for approved security tools, backup agents, software deployment platforms, endpoint-management activity, known administrative scripts, approved persistence mechanisms, maintenance windows, and recovery workflows.

·        Validate same-host bounded-time correlation before enabling production alerting.

·        Do not deploy the rule if endpoint security-control degradation cannot be directly observed before the credential access or persistence behavior.

DRI

·        7.9

DRI Justification

·        The rule adds meaningful post-degradation objective coverage by identifying credential access or persistence after endpoint protection has been weakened.

·        The rule is behaviorally anchored because credential access or persistence must follow measurable endpoint security-control degradation on the same host.

·        The rule is weaker than Rule 1 because it depends on a longer behavior chain and more complex multi-source correlation.

·        The rule resists tool substitution by covering multiple credential access and persistence patterns rather than one tool label, one command, or one file name.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.0

Operational TCR Justification

·        Splunk can support this rule when endpoint degradation telemetry, credential access telemetry, file telemetry, registry telemetry, service telemetry, and persistence telemetry are onboarded and normalized.

·        Operational confidence varies significantly by data source coverage, field extraction quality, endpoint product integration, and timestamp normalization.

·        False-positive control depends on accurate allowlisting for security tools, backup agents, endpoint-management workflows, software deployment systems, administrator maintenance, and recovery activity.

·        This rule should be withheld or scoped down in environments where endpoint degradation, credential-access, or persistence telemetry is incomplete.

Full-Telemetry TCR

·        8.5

Full-Telemetry TCR Justification

·        With complete endpoint degradation telemetry, credential access telemetry, file telemetry, registry telemetry, service-control telemetry, scheduled task telemetry, WMI telemetry, and normalized host identity, Splunk can support reliable post-degradation objective detection.

·        Full telemetry enables reliable separation of attacker objective activity from legitimate administrative, security, backup, deployment, and recovery workflows.

Rule Code

| multisearch
    [
      search index=<endpoint_or_defender_index> (
        EndpointProtectionStateChanged=true
        OR AgentHealthStateChanged=true
        OR PolicyStateChanged=true
        OR SecurityControlSettingChanged=true
        OR EndpointSecurityServiceStateChanged=true
        OR SecurityIntelligenceRefreshBlocked=true
        OR UpdateSourceChanged=true
        OR TelemetryForwardingReduced=true
        OR BroadOrSuspiciousExclusionCreated=true
        OR affected_setting IN ("RealtimeProtection","BehaviorMonitoring","CloudProtection","SampleSubmission","TamperProtection","ExclusionPolicy","TelemetryForwarding","SensorHealth","PolicyState")
        OR service_name IN ("WinDefend","Sense","WdNisSvc","SecurityHealthService")
      )
      | eval direct_degradation_observed=if(
          EndpointProtectionStateChanged=true
          OR AgentHealthStateChanged=true
          OR PolicyStateChanged=true
          OR SecurityControlSettingChanged=true
          OR EndpointSecurityServiceStateChanged=true
          OR SecurityIntelligenceRefreshBlocked=true
          OR UpdateSourceChanged=true
          OR TelemetryForwardingReduced=true
          OR BroadOrSuspiciousExclusionCreated=true
          OR isnotnull(affected_setting)
          OR isnotnull(service_name),
          1, 0
        )
      | where direct_degradation_observed=1
      | eval event_role="endpoint_security_control_degradation"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name command_line affected_setting service_name previous_value new_value management_source direct_degradation_observed
    ]
    [
      search index=<endpoint_index> (
        target_process_name="lsass.exe"
        OR process_name="procdump.exe"
        OR command_line="*comsvcs.dll*"
        OR command_line="*MiniDump*"
        OR command_line="*procdump*"
        OR command_line="*rundll32*lsass*"
        OR command_line="*reg save*\\SAM*"
        OR command_line="*reg save*\\SECURITY*"
        OR command_line="*cmdkey*"
        OR command_line="*vaultcmd*"
        OR command_line="*sekurlsa*"
        OR command_line="*logonpasswords*"
        OR file_path="*\\Windows\\Temp\\*.dmp"
        OR file_path="*\\Users\\*\\AppData\\Local\\Temp\\*.dmp"
      )
      | eval event_role="credential_access_behavior"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name command_line target_process_name access_rights file_path registry_path
    ]
    [
      search index=<endpoint_index> (
        command_line="*schtasks /create*"
        OR command_line="*New-ScheduledTask*"
        OR command_line="*sc create*"
        OR command_line="*New-Service*"
        OR command_line="*sc config*"
        OR command_line="*reg add*CurrentVersion\\Run*"
        OR command_line="*__EventFilter*"
        OR command_line="*CommandLineEventConsumer*"
        OR command_line="*ActiveScriptEventConsumer*"
        OR command_line="*Startup*"
        OR command_line="*Logon Script*"
        OR registry_path="*CurrentVersion\\Run*"
        OR service_action IN ("created","modified","binary_path_changed")
        OR scheduled_task_action IN ("created","modified")
        OR wmi_persistence_created=true
      )
      | eval event_role="persistence_behavior"
      | eval entity_host=coalesce(dest, host, ComputerName, device_name)
      | eval entity_user=coalesce(user, Account_Name, src_user)
      | eval event_time=_time
      | table entity_host entity_user event_time event_role process_name command_line registry_path service_name service_action scheduled_task_name scheduled_task_action wmi_persistence_created
    ]
| stats
    min(eval(if(event_role="endpoint_security_control_degradation", event_time, null()))) as first_degradation_time
    min(eval(if(event_role="credential_access_behavior", event_time, null()))) as first_credential_time
    min(eval(if(event_role="persistence_behavior", event_time, null()))) as first_persistence_time
    values(event_role) as event_roles
    values(entity_user) as users
    values(process_name) as process_names
    values(command_line) as command_lines
    values(affected_setting) as affected_settings
    values(service_name) as services
    values(target_process_name) as target_processes
    values(access_rights) as access_rights
    values(file_path) as file_paths
    values(registry_path) as registry_paths
    values(scheduled_task_name) as scheduled_tasks
    max(direct_degradation_observed) as direct_degradation_observed
  by entity_host
| where mvfind(event_roles,"endpoint_security_control_degradation")>=0
    AND direct_degradation_observed=1
    AND (
      mvfind(event_roles,"credential_access_behavior")>=0
      OR mvfind(event_roles,"persistence_behavior")>=0
    )
| eval first_followon_time=case(
    isnotnull(first_credential_time) AND isnotnull(first_persistence_time) AND first_credential_time <= first_persistence_time, first_credential_time,
    isnotnull(first_credential_time) AND isnotnull(first_persistence_time) AND first_persistence_time < first_credential_time, first_persistence_time,
    isnotnull(first_credential_time), first_credential_time,
    isnotnull(first_persistence_time), first_persistence_time
  )
| where first_degradation_time <= first_followon_time
    AND first_followon_time - first_degradation_time <= 14400
| lookup approved_security_tools process_name as process_names OUTPUT process_name as approved_security_tool
| lookup approved_backup_agents process_name as process_names OUTPUT process_name as approved_backup_agent
| lookup approved_software_deployment entity_host OUTPUT software_deployment_active
| lookup approved_maintenance_windows entity_host OUTPUT maintenance_window_active
| where isnull(approved_security_tool)
    AND isnull(approved_backup_agent)
    AND coalesce(software_deployment_active,"false")!="true"
    AND coalesce(maintenance_window_active,"false")!="true"
| eval rule_name="Credential Access or Persistence After Endpoint Security-Control Degradation"
| eval severity="high"
| eval description="Directly observed endpoint security-control degradation was followed by credential access or persistence behavior on the same host within 240 minutes."
| table rule_name severity entity_host users first_degradation_time first_followon_time event_roles process_names command_lines affected_settings services target_processes access_rights file_paths registry_paths scheduled_tasks description

Splunk Rule Count

·        Splunk S25 rule count: 3

Elastic

·        Elastic produces viable S25 detection rules for this report when endpoint, Windows, Defender, EDR, registry, service-control, update, and device-management telemetry are normalized into Elastic Common Schema or equivalent mapped fields.

·        Elastic is suitable for behavior-chain detection when EQL sequence logic, Elastic Defend telemetry, process ancestry, protection-state telemetry, registry telemetry, service-control telemetry, and same-host correlation are available.

·        Three Elastic rules survive for this report.

·        The surviving rules focus on endpoint security-control degradation following suspicious privilege transition, update suppression following suspicious administrative activity, and credential access or persistence after endpoint security-control degradation.

·        The rule code below is provided as Elastic EQL detection-rule templates. Index patterns, ECS field mappings, Elastic Defend fields, Windows integration fields, endpoint integration fields, exception lists, and correlation windows must be validated in the customer Elastic environment before production deployment.

Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition

Rule Format

·        Elastic EQL detection rule.

Detection Objective

·        Detect suspicious privilege or administrative execution followed by directly observed endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when suspicious administrative execution is followed by directly observed endpoint security-control degradation on the same host within 60 minutes.

·        Suspicious administrative execution includes elevated PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tooling, or administrative binaries launched from suspicious parent processes or suspicious paths.

·        Endpoint security-control degradation must be directly observable through protection-state change, policy-state change, endpoint security service-state change, sensor-health change, security-control setting change, Defender operational event, registry-backed security setting change, service-control event, or equivalent endpoint protection telemetry.

·        Command-line indicators may support the degradation event but must not substitute for direct protection-state or security-control state evidence.

·        Suppress or lower severity when the activity maps to approved endpoint-management tooling, authorized security engineering activity, vendor support, maintenance windows, endpoint migration, or break-glass recovery.

·        Do not deploy this rule if endpoint protection-state transition visibility or equivalent endpoint security-control state telemetry is unavailable.

Engineering Implementation Instructions

·        Map Elastic or ECS fields for host identity, user identity, process name, process executable, process command line, parent process name, parent command line, process hash, code signature, event timestamp, event category, and event dataset.

·        Map endpoint security-control degradation telemetry into fields for affected setting, previous value, new value, management source, initiating process where available, initiating account where available, service name, registry path, policy state, sensor health state, and timestamp.

·        Required data sources may include Elastic Defend, Windows event logs, Sysmon, Defender operational logs, endpoint protection platform logs, registry telemetry, service-control telemetry, endpoint sensor health telemetry, and device-management telemetry.

·        Create and maintain Elastic exception lists for approved administrators, approved service accounts, endpoint-management platforms, approved maintenance windows, known security engineering scripts, vendor support tooling, endpoint migration workflows, and break-glass recovery activity.

·        Validate same-host correlation using normalized host identifiers across Elastic Defend, Windows, Defender, EDR, and device-management sources.

·        Validate timestamp normalization before enabling the sequence window.

·        Do not deploy this rule as a single-event keyword rule. It must require same-host sequence correlation between suspicious administrative execution and directly observed endpoint security-control degradation.

DRI

·        8.8

DRI Justification

·        The rule is strongly anchored to the core behavior chain of suspicious administrative or privilege context followed by measurable endpoint security-control degradation.

·        The rule resists simple tool changes because it does not depend on BlueHammer, RedSun, UnDefend, one process name, one command, one service, one registry value, or one Defender-only setting.

·        The rule covers multiple execution variants, including elevated shells, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration, renamed binaries, and suspicious parent-child process chains.

·        The rule has low artifact dependence because it focuses on behavior sequence and protection-state transition rather than tool signatures.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.7

Operational TCR Justification

·        Elastic can support strong endpoint correlation when Elastic Defend, Windows, Defender, registry, service-control, endpoint protection, and device-management telemetry are onboarded and mapped consistently.

·        Operational confidence depends on ECS mapping quality, endpoint integration depth, field extraction consistency, timestamp normalization, host normalization, and exception-list maintenance.

·        Protection-state and policy-state telemetry may require product-specific integration fields beyond standard process or registry events.

·        The rule remains deployable in mature Elastic environments with complete endpoint telemetry, protection-state visibility, and known-good management baselines.

Full-Telemetry TCR

·        9.0

Full-Telemetry TCR Justification

·        With complete endpoint execution telemetry, endpoint protection-state telemetry, registry telemetry, service-control telemetry, device-management context, sensor health telemetry, and normalized timestamps, Elastic can support high-confidence same-host sequence correlation.

·        Full telemetry allows the rule to distinguish attacker-driven local degradation from approved security administration, endpoint recovery, endpoint migration, and policy deployment.

Rule Code

/* Elastic EQL detection-rule template
   Rule 1: Endpoint Security-Control Degradation Following Suspicious Privilege Transition
   Deployment requirement: Validate index patterns, ECS field names, integration-specific fields, and sequence support.
   Correlation requirement: Same host within 60 minutes.
   Required sequence:
     Event A: suspicious privilege or administrative execution
     Event B: directly observed endpoint security-control degradation
   Alert only when Event A precedes Event B on the same host.
   Guardrail: Command-line tampering indicators alone are not sufficient unless paired with direct protection-state, policy-state, service-state, registry-backed security setting, or sensor-health evidence.
*/

sequence by host.id with maxspan=60m
  [process where event.type in ("start", "process_started") and
process.name in~ (
      "powershell.exe", "pwsh.exe", "cmd.exe", "wmic.exe", "reg.exe",
      "sc.exe", "schtasks.exe", "wscript.exe", "cscript.exe",
      "mshta.exe", "rundll32.exe"
    ) and
    (
process.parent.name in~ (
        "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
        "chrome.exe", "msedge.exe", "firefox.exe", "7z.exe", "winrar.exe",
        "wscript.exe", "cscript.exe", "mshta.exe"
      )
      or process.executable like~ (
        "*\\Users\\*", "*\\AppData\\*", "*\\Temp\\*", "*\\Downloads\\*",
        "*\\ProgramData\\*", "*\\Windows\\Temp\\*", "*\\Public\\*",
        "*\\ADMIN$\\*", "*\\C$\\*"
      )
      or process.command_line like~ (
        "*runas*", "*net localgroup administrators*", "*whoami /priv*"
      )
    )
  ]
  [any where
    (
      event.category in ("configuration", "registry", "service", "host")
      or event.dataset in (
        "windows.defender_operational",
        "elastic_defend",
        "endpoint",
        "windows.sysmon_operational"
      )
    ) and
    (
      EndpointProtectionStateChanged == true
      or AgentHealthStateChanged == true
      or PolicyStateChanged == true
      or SecurityControlSettingChanged == true
      or EndpointSecurityServiceStateChanged == true
      or endpoint.security.protection_state_changed == true
      or endpoint.security.agent_health_changed == true
      or endpoint.security.policy_state_changed == true
      or endpoint.security.setting_changed == true
      or endpoint.security.service_state_changed == true
      or endpoint.security.telemetry_forwarding_reduced == true
      or endpoint.security.broad_or_suspicious_exclusion_created == true
      or winlog.event_data.ServiceName in ("WinDefend", "Sense", "WdNisSvc", "SecurityHealthService")
      or service.name in ("WinDefend", "Sense", "WdNisSvc", "SecurityHealthService")
      or registry.path like~ (
        "*\\Microsoft\\Windows Defender\\*",
        "*\\Policies\\Microsoft\\Windows Defender\\*",
        "*\\Microsoft\\Windows Advanced Threat Protection\\*"
      )
      or endpoint.security.affected_setting in (
        "RealtimeProtection", "BehaviorMonitoring", "CloudProtection",
        "SampleSubmission", "TamperProtection", "ExclusionPolicy",
        "TelemetryForwarding", "SensorHealth", "PolicyState", "ServiceState"
      )
    )
  ]

Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity

Rule Format

·        Elastic EQL detection rule.

Detection Objective

·        Detect suspicious local administrative activity followed by security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation.

Detection Logic

·        Trigger when suspicious local administrative activity is followed by update-related endpoint security-control degradation on the same host within 120 minutes.

·        Suspicious local administrative activity includes elevated PowerShell, CMD, WMI, registry utility, service-control utility, scheduled task utility, script host execution, administrative tooling launched from suspicious parent process ancestry, or administrative execution from suspicious paths.

·        Update-related degradation requires update-source manipulation, update-policy manipulation, security intelligence refresh blocking, security intelligence age increase after local manipulation, or repeated update failure paired with local update-policy or update-source manipulation.

·        Update failure alone must not alert.

·        Update staleness alone must not alert.

·        Do not alert on expected patching, approved security engineering, endpoint migration, vendor support, maintenance-window activity, or known management-platform policy changes.

·        Do not deploy this rule unless update-related telemetry can be tied to host, initiating process, initiating account, and timestamp.

Engineering Implementation Instructions

·        Map Elastic or ECS fields for host identity, user identity, process name, process executable, command line, parent process, parent command line, registry path, update source, update policy, update component, signature version, engine version, platform version, update failure reason, security intelligence age, and timestamp.

·        Required data sources may include Elastic Defend, Defender operational logs, endpoint protection platform logs, Windows event logs, registry telemetry, service-control telemetry, and device-management or patch-management telemetry.

·        Create and maintain Elastic exception lists for approved update sources, expected update cadence, endpoint classes, approved patching systems, authorized administrators, service accounts, maintenance windows, and device-management platforms.

·        Require evidence of update-source manipulation, update-policy manipulation, local policy manipulation, or security intelligence refresh blocking before treating update failure as detection-relevant.

·        Validate that update telemetry and suspicious administrative telemetry can be correlated to the same normalized host identity.

·        Do not deploy the rule as update-failure-only or update-staleness-only logic.

DRI

·        8.1

DRI Justification

·        The rule is behaviorally meaningful because it focuses on update suppression tied to suspicious local administrative context rather than generic update failure.

·        The rule adds distinct coverage for a degradation path that may leave endpoint protection nominally enabled while reducing security intelligence freshness.

·        The rule is weaker than Rule 1 because update behavior has greater benign operational overlap and requires precise separation between routine update failure and local manipulation.

·        The rule covers multiple update degradation variants, including update-source manipulation, update-policy downgrade, security intelligence refresh blocking, and repeated update failure associated with local manipulation.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        6.9

Operational TCR Justification

·        Elastic can correlate update degradation with local administrative activity when process telemetry, Defender or endpoint protection logs, registry telemetry, and update telemetry are onboarded and mapped consistently.

·        Operational confidence depends on whether update-source, update-policy, security intelligence age, update failure reason, initiating process, account, and timestamp fields are available and reliably extracted.

·        Update-related telemetry may be inconsistently mapped across mixed endpoint products unless the environment has mature Defender, Windows, endpoint protection, or management-platform integrations.

·        The rule is deployable in mature Elastic environments but should be withheld or scoped down where update telemetry is incomplete or not tied to local manipulation.

Full-Telemetry TCR

·        8.5

Full-Telemetry TCR Justification

·        With complete endpoint process telemetry, update telemetry, registry telemetry, service-control telemetry, policy telemetry, management-source context, and normalized host identity, Elastic can reliably separate attacker-driven update suppression from routine update failure.

·        Full telemetry supports same-host bounded correlation between suspicious local administrative activity and update-related endpoint protection degradation.

Rule Code

/* Elastic EQL detection-rule template
   Rule 2: Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity
   Deployment requirement: Requires update-policy, update-source, security intelligence, Defender, registry, or endpoint protection telemetry enrichment.
   Guardrail: Update failure alone must not alert. Update staleness alone must not alert.
   Correlation requirement: Same host within 120 minutes.
   Required sequence:
     Event A: suspicious local administrative execution
     Event B: update-policy manipulation, update-source manipulation, security intelligence refresh blocking, or update failure tied to local manipulation
   Alert only when Event A precedes Event B on the same host.
*/

sequence by host.id with maxspan=120m
  [process where event.type in ("start", "process_started") and
process.name in~ (
      "powershell.exe", "pwsh.exe", "cmd.exe", "wmic.exe", "reg.exe",
      "sc.exe", "schtasks.exe", "wscript.exe", "cscript.exe", "mshta.exe"
    ) and
    (
process.parent.name in~ (
        "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
        "chrome.exe", "msedge.exe", "firefox.exe", "wscript.exe",
        "cscript.exe", "mshta.exe"
      )
      or process.executable like~ (
        "*\\Users\\*", "*\\AppData\\*", "*\\Temp\\*", "*\\Downloads\\*",
        "*\\ProgramData\\*", "*\\Windows\\Temp\\*", "*\\Public\\*",
        "*\\ADMIN$\\*", "*\\C$\\*"
      )
    )
  ]
  [any where
    (
      process.command_line like~ (
        "*Set-MpPreference*", "*SignatureFallbackOrder*",
        "*SignatureDefinitionUpdateFileSharesSources*",
        "*DefinitionUpdatesChannel*", "*EngineUpdatesChannel*",
        "*PlatformUpdatesChannel*", "*UpdateSource*", "*DisableUpdate*",
        "*MpCmdRun.exe*", "*RemoveDefinitions*",
        "*Windows Defender\\Signature Updates*"
      )
      or registry.path like~ "*Windows Defender\\Signature Updates*"
      or registry.path like~ "*\\Policies\\Microsoft\\Windows Defender\\Signature Updates*"
      or UpdatePolicyChanged == true
      or UpdateSourceChanged == true
      or SecurityIntelligenceRefreshBlocked == true
      or SecurityIntelligenceAgeIncreasedAfterLocalManipulation == true
      or LocalUpdatePolicyOrSourceManipulationObserved == true
      or endpoint.security.update_policy_changed == true
      or endpoint.security.update_source_changed == true
      or endpoint.security.security_intelligence_refresh_blocked == true
      or endpoint.security.local_update_manipulation_observed == true
    ) and not
    (
      (
        event.action == "update_failure"
        or endpoint.security.update_status == "failed"
        or winlog.event_data.UpdateStatus == "failed"
      )
      and not (
        UpdatePolicyChanged == true
        or UpdateSourceChanged == true
        or SecurityIntelligenceRefreshBlocked == true
        or LocalUpdatePolicyOrSourceManipulationObserved == true
        or endpoint.security.update_policy_changed == true
        or endpoint.security.update_source_changed == true
        or endpoint.security.security_intelligence_refresh_blocked == true
        or endpoint.security.local_update_manipulation_observed == true
        or process.command_line like~ (
          "*SignatureFallbackOrder*",
          "*SignatureDefinitionUpdateFileSharesSources*",
          "*DefinitionUpdatesChannel*",
          "*EngineUpdatesChannel*",
          "*PlatformUpdatesChannel*",
          "*UpdateSource*"
        )
        or registry.path like~ "*Windows Defender\\Signature Updates*"
      )
    )
  ]

Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation

Rule Format

·        Elastic EQL detection rule.

Detection Objective

·        Detect credential access or persistence activity that occurs after directly observed endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when directly observed endpoint security-control degradation is followed by credential access or persistence behavior on the same host within 240 minutes.

·        Endpoint security-control degradation includes protection reduction, broad exclusion creation, endpoint protection service manipulation, endpoint sensor health degradation, telemetry forwarding reduction, security intelligence update suppression, update-source manipulation, or unmanaged policy downgrade.

·        Credential access behavior includes LSASS access, suspicious process handle access, dump file creation, SAM or SECURITY hive access, browser credential access, credential enumeration, or credential-access behavior that does not rely solely on tool name.

·        Persistence behavior includes scheduled task creation, service creation, service binary path modification, registry autorun modification, WMI persistence, startup folder modification, logon script modification, or user-profile persistence.

·        Suppress or lower severity when follow-on behavior maps to approved software deployment, endpoint-management activity, administrator maintenance, vendor support, endpoint recovery, backup tooling, or known security tooling.

·        Do not deploy this rule as a generic credential-access or persistence detector. Prior directly observed endpoint security-control degradation is required.

Engineering Implementation Instructions

·        Map endpoint security-control degradation telemetry into fields for host identity, affected setting, service action, policy state, sensor health state, update source, initiating process, initiating account, and timestamp.

·        Map credential access telemetry into fields for source process, target process, access rights where available, command line, file path, registry path, process hash, signer, account, host, and timestamp.

·        Map persistence telemetry into fields for scheduled task name, service name, service binary path, registry autorun path, WMI event subscription, startup path, creating process, modifying process, user, host, and timestamp.

·        Required data sources may include Elastic Defend, Sysmon, Windows Security logs, Defender or endpoint protection telemetry, registry telemetry, service-control telemetry, scheduled task logs, WMI activity logs, and file telemetry.

·        Create and maintain Elastic exception lists for approved security tools, backup agents, software deployment platforms, endpoint-management activity, known administrative scripts, approved persistence mechanisms, maintenance windows, and recovery workflows.

·        Validate same-host bounded-time correlation before enabling production alerting.

·        Do not deploy the rule if endpoint security-control degradation cannot be directly observed before the credential access or persistence behavior.

DRI

·        7.8

DRI Justification

·        The rule adds meaningful post-degradation objective coverage by identifying credential access or persistence after endpoint protection has been weakened.

·        The rule is behaviorally anchored because credential access or persistence must follow measurable endpoint security-control degradation on the same host.

·        The rule is weaker than Rule 1 because it depends on a longer behavior chain and more complex multi-event correlation.

·        The rule resists tool substitution by covering multiple credential access and persistence patterns rather than one tool label, one command, or one file name.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.0

Operational TCR Justification

·        Elastic can support this rule when endpoint degradation telemetry, credential access telemetry, file telemetry, registry telemetry, service telemetry, scheduled task telemetry, and persistence telemetry are onboarded and mapped consistently.

·        Operational confidence varies by endpoint integration quality, ECS mapping consistency, field extraction quality, and timestamp normalization.

·        False-positive control depends on accurate exception lists for security tools, backup agents, endpoint-management workflows, software deployment systems, administrator maintenance, and recovery activity.

·        This rule should be withheld or scoped down in environments where endpoint degradation, credential-access, or persistence telemetry is incomplete.

Full-Telemetry TCR

·        8.4

Full-Telemetry TCR Justification

·        With complete endpoint degradation telemetry, credential access telemetry, file telemetry, registry telemetry, service-control telemetry, scheduled task telemetry, WMI telemetry, and normalized host identity, Elastic can support reliable post-degradation objective detection.

·        Full telemetry enables reliable separation of attacker objective activity from legitimate administrative, security, backup, deployment, and recovery workflows.

Rule Code

/* Elastic EQL detection-rule template
   Rule 3: Credential Access or Persistence After Endpoint Security-Control Degradation
   Deployment requirement: Endpoint security-control degradation must be directly observable before this logic is enabled as an alert.
   Guardrail: Do not deploy as a generic credential-access or persistence rule.
   Correlation requirement: Same host within 240 minutes.
   Required sequence:
     Event A: directly observed endpoint security-control degradation
     Event B: credential access or persistence behavior
   Alert only when Event A precedes Event B on the same host.
*/

sequence by host.id with maxspan=240m
  [any where
    (
      EndpointProtectionStateChanged == true
      or AgentHealthStateChanged == true
      or PolicyStateChanged == true
      or SecurityControlSettingChanged == true
      or EndpointSecurityServiceStateChanged == true
      or SecurityIntelligenceRefreshBlocked == true
      or UpdateSourceChanged == true
      or TelemetryForwardingReduced == true
      or BroadOrSuspiciousExclusionCreated == true
      or endpoint.security.protection_state_changed == true
      or endpoint.security.agent_health_changed == true
      or endpoint.security.policy_state_changed == true
      or endpoint.security.setting_changed == true
      or endpoint.security.service_state_changed == true
      or endpoint.security.security_intelligence_refresh_blocked == true
      or endpoint.security.update_source_changed == true
      or endpoint.security.telemetry_forwarding_reduced == true
      or endpoint.security.broad_or_suspicious_exclusion_created == true
      or endpoint.security.affected_setting in (
        "RealtimeProtection", "BehaviorMonitoring", "CloudProtection",
        "SampleSubmission", "TamperProtection", "ExclusionPolicy",
        "TelemetryForwarding", "SensorHealth", "PolicyState", "ServiceState"
      )
      or registry.path like~ (
        "*\\Microsoft\\Windows Defender\\*",
        "*\\Policies\\Microsoft\\Windows Defender\\*",
        "*\\Microsoft\\Windows Advanced Threat Protection\\*"
      )
    )
  ]
  [any where
    (
      (
        event.category == "process" and
        (
process.name in~ ("procdump.exe", "rundll32.exe", "reg.exe", "cmd.exe", "powershell.exe", "pwsh.exe")
          or process.command_line like~ (
            "*comsvcs.dll*", "*MiniDump*", "*procdump*", "*rundll32*lsass*",
            "*reg save*\\SAM*", "*reg save*\\SECURITY*", "*cmdkey*",
            "*vaultcmd*", "*sekurlsa*", "*logonpasswords*"
          )
          or process.Ext.target.name == "lsass.exe"
          or process.Ext.api.name in ("OpenProcess", "ReadProcessMemory")
        )
      )
      or
      (
        event.category in ("process", "registry", "file", "configuration", "service")
        and
        (
          process.command_line like~ (
            "*schtasks /create*", "*New-ScheduledTask*", "*sc create*",
            "*New-Service*", "*sc config*", "*reg add*CurrentVersion\\Run*",
            "*__EventFilter*", "*CommandLineEventConsumer*",
            "*ActiveScriptEventConsumer*", "*Startup*", "*Logon Script*"
          )
          or registry.path like~ "*CurrentVersion\\Run*"
          or service.action in ("created", "modified", "binary_path_changed")
          or scheduled_task.action in ("created", "modified")
          or wmi.persistence.created == true
        )
      )
    )
  ]

Elastic Rule Count

·        Elastic S25 rule count: 3

QRadar

Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition

Rule Format

·        QRadar CRE correlation rule supported by AQL search logic and custom event properties.

Detection Objective

·        Detect suspicious privilege or administrative execution followed by directly observed endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger when suspicious administrative execution is followed by directly observed endpoint security-control degradation on the same host within 60 minutes.

·        Suspicious administrative execution includes elevated PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tooling, or administrative binaries launched from suspicious parent processes or suspicious paths.

·        Endpoint security-control degradation must be directly observable through protection-state change, policy-state change, endpoint security service-state change, sensor-health change, security-control setting change, Defender operational event, registry-backed security setting change, service-control event, or equivalent endpoint protection telemetry.

·        Command-line indicators may support the degradation event but must not substitute for direct protection-state or security-control state evidence.

·        Suppress or lower severity when the activity maps to approved endpoint-management tooling, authorized security engineering activity, vendor support, maintenance windows, endpoint migration, or break-glass recovery.

·        Do not deploy this rule if endpoint protection-state transition visibility or equivalent endpoint security-control state telemetry is unavailable.

Engineering Implementation Instructions

·        Normalize QRadar custom properties for host identity, user identity, process name, process path, command line, parent process name, parent command line, process hash where available, process signer where available, event timestamp, event category, and log source type.

·        Normalize endpoint security-control degradation properties for affected setting, previous value, new value, management source, initiating process where available, initiating account where available, service name, registry path, policy state, sensor health state, and timestamp.

·        Required log sources may include Windows Security logs, Sysmon, Defender operational logs, EDR events, endpoint protection platform logs, registry telemetry, service-control telemetry, endpoint sensor health telemetry, and device-management telemetry.

·        Create and maintain QRadar reference sets for approved administrators, approved service accounts, endpoint-management platforms, approved maintenance windows, known security engineering scripts, vendor support tooling, endpoint migration workflows, and break-glass recovery activity.

·        Validate same-host correlation using normalized destination host, device hostname, asset hostname, or endpoint identifier across all required log sources.

·        Validate timestamp normalization and event ordering before enabling the correlation window.

·        Do not deploy this rule as a single-event keyword rule. It must require same-host sequence correlation between suspicious administrative execution and directly observed endpoint security-control degradation.

·        Use QRadar building blocks for suspicious administrative execution and directly observed endpoint security-control degradation only if the final CRE rule evaluates both building blocks within the same bounded same-host sequence.

DRI

·        8.5

DRI Justification

·        The rule is anchored to the core behavior chain of suspicious administrative or privilege context followed by measurable endpoint security-control degradation.

·        The rule resists simple tool changes because it does not depend on BlueHammer, RedSun, UnDefend, one process name, one command, one service, one registry value, or one Defender-only setting.

·        The rule covers multiple execution variants, including elevated shells, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration, renamed binaries, and suspicious parent-child process chains.

·        The rule has moderate artifact dependence because QRadar relies on source parsing and custom properties, but the logic remains behavior-chain based rather than signature based.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        6.8

Operational TCR Justification

·        QRadar can support the detection when endpoint, Windows, Defender, registry, service-control, endpoint protection, and device-management telemetry are parsed into reliable DSM fields and custom properties.

·        Operational confidence depends on DSM coverage, custom property extraction quality, event source consistency, timestamp normalization, host normalization, and reference set maintenance.

·        Protection-state and policy-state telemetry may require endpoint product-specific parsing or custom DSM work.

·        The rule is deployable in mature QRadar environments but should be scoped down or withheld where endpoint protection-state telemetry is unavailable or poorly normalized.

Full-Telemetry TCR

·        8.4

Full-Telemetry TCR Justification

·        With complete endpoint execution telemetry, endpoint protection-state telemetry, registry telemetry, service-control telemetry, device-management context, sensor health telemetry, and normalized custom properties, QRadar can support reliable same-host sequence correlation.

·        Full telemetry allows the rule to distinguish attacker-driven local degradation from approved security administration, endpoint recovery, endpoint migration, and policy deployment.

Rule Code

-- QRadar AQL / CRE correlation template
-- Rule 1: Endpoint Security-Control Degradation Following Suspicious Privilege Transition
-- Deployment requirement: Validate log sources, DSM mappings, custom properties, reference sets, building blocks, and CRE sequence support.
-- Correlation requirement: Same normalized host within 60 minutes.
-- Required sequence:
--   Event A: suspicious privilege or administrative execution
--   Event B: directly observed endpoint security-control degradation
-- Alert only when Event A precedes Event B on the same normalized host.
-- Guardrail: Command-line tampering indicators alone are not sufficient unless paired with direct protection-state, policy-state, service-state, registry-backed security setting, or sensor-health evidence.

SELECT
  a."Normalized Host ID" AS normalized_host_id,
  a.destinationip AS destination_ip,
  a."Hostname" AS host_name,
  a."Username" AS user_name,
  MIN(a.starttime) AS first_admin_time,
  MIN(b.starttime) AS first_degradation_time,
  COLLECT(a."Process Name") AS admin_processes,
  COLLECT(a."Command Line") AS admin_command_lines,
  COLLECT(a."Parent Process Name") AS parent_processes,
  COLLECT(b."Affected Setting") AS affected_settings,
  COLLECT(b."Service Name") AS affected_services,
  COLLECT(b."Registry Path") AS affected_registry_paths,
  COLLECT(b."Management Source") AS management_sources
FROM events a
JOIN events b
  ON a."Normalized Host ID" = b."Normalized Host ID"
WHERE
  a.starttime <= b.starttime
  AND b.starttime - a.starttime <= 3600000
  AND (
    LOWER(a."Process Name") IN (
      'powershell.exe','pwsh.exe','cmd.exe','wmic.exe','reg.exe',
      'sc.exe','schtasks.exe','wscript.exe','cscript.exe',
      'mshta.exe','rundll32.exe'
    )
    OR LOWER(a."Command Line") LIKE '%whoami /priv%'
    OR LOWER(a."Command Line") LIKE '%net localgroup administrators%'
    OR LOWER(a."Command Line") LIKE '%runas%'
  )
  AND (
    LOWER(a."Parent Process Name") IN (
      'winword.exe','excel.exe','powerpnt.exe','outlook.exe',
      'chrome.exe','msedge.exe','firefox.exe','7z.exe','winrar.exe',
      'wscript.exe','cscript.exe','mshta.exe'
    )
    OR LOWER(a."Process Path") LIKE '%\\users\\%'
    OR LOWER(a."Process Path") LIKE '%\\appdata\\%'
    OR LOWER(a."Process Path") LIKE '%\\temp\\%'
    OR LOWER(a."Process Path") LIKE '%\\downloads\\%'
    OR LOWER(a."Process Path") LIKE '%\\programdata\\%'
    OR LOWER(a."Process Path") LIKE '%\\windows\\temp\\%'
    OR LOWER(a."Process Path") LIKE '%\\public\\%'
    OR LOWER(a."Process Path") LIKE '%\\admin$\\%'
    OR LOWER(a."Process Path") LIKE '%\\c$\\%'
  )
  AND (
    b."Endpoint Protection State Changed" = 'true'
    OR b."Agent Health State Changed" = 'true'
    OR b."Policy State Changed" = 'true'
    OR b."Security Control Setting Changed" = 'true'
    OR b."Endpoint Security Service State Changed" = 'true'
    OR b."Sensor Health State Changed" = 'true'
    OR b."Telemetry Forwarding Reduced" = 'true'
    OR b."Broad Or Suspicious Exclusion Created" = 'true'
    OR b."Affected Setting" IN (
      'RealtimeProtection','BehaviorMonitoring','CloudProtection',
      'SampleSubmission','TamperProtection','ExclusionPolicy',
      'TelemetryForwarding','SensorHealth','PolicyState','ServiceState'
    )
    OR b."Service Name" IN (
      'WinDefend','Sense','WdNisSvc','SecurityHealthService'
    )
    OR LOWER(b."Registry Path") LIKE '%\\microsoft\\windows defender\\%'
    OR LOWER(b."Registry Path") LIKE '%\\policies\\microsoft\\windows defender\\%'
    OR LOWER(b."Registry Path") LIKE '%\\microsoft\\windows advanced threat protection\\%'
  )
  AND NOT REFERENCESETCONTAINS('Approved Security Admins', a."Username")
  AND NOT REFERENCESETCONTAINS('Approved Endpoint Management Sources', b."Management Source")
  AND NOT REFERENCESETCONTAINS('Approved Maintenance Window Hosts', a."Normalized Host ID")
GROUP BY
  a."Normalized Host ID",
  a.destinationip,
  a."Hostname",
  a."Username"
LAST 60 MINUTES

Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity

Rule Format

·        QRadar CRE correlation rule supported by AQL search logic and custom event properties.

Detection Objective

·        Detect suspicious local administrative activity followed by security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation.

Detection Logic

·        Trigger when suspicious local administrative activity is followed by update-related endpoint security-control degradation on the same host within 120 minutes.

·        Suspicious local administrative activity includes elevated PowerShell, CMD, WMI, registry utility, service-control utility, scheduled task utility, script host execution, administrative tooling launched from suspicious parent process ancestry, or administrative execution from suspicious paths.

·        Update-related degradation requires update-source manipulation, update-policy manipulation, local policy manipulation, security intelligence refresh blocking, security intelligence age increase after local manipulation, or repeated update failure paired with local update-policy or update-source manipulation.

·        Update failure alone must not alert.

·        Update staleness alone must not alert.

·        Do not alert on expected patching, approved security engineering, endpoint migration, vendor support, maintenance-window activity, or known management-platform policy changes.

·        Do not deploy this rule unless update-related telemetry can be tied to host, initiating process, initiating account, and timestamp.

Engineering Implementation Instructions

·        Normalize QRadar custom properties for host identity, user identity, process name, process path, command line, parent process name, parent command line, registry path, update source, update policy, update component, signature version, engine version, platform version, update failure reason, security intelligence age, and timestamp.

·        Required log sources may include Defender operational logs, endpoint protection logs, Windows event logs, EDR telemetry, registry telemetry, service-control telemetry, and device-management or patch-management logs.

·        Create and maintain QRadar reference sets for approved update sources, expected patching systems, endpoint classes, authorized administrators, approved service accounts, maintenance windows, and device-management platforms.

·        Require evidence of update-source manipulation, update-policy manipulation, local policy manipulation, or security intelligence refresh blocking before treating update failure as detection-relevant.

·        Validate that update telemetry and suspicious administrative telemetry can be correlated to the same normalized host identity.

·        Do not deploy the rule as update-failure-only or update-staleness-only logic.

·        Use QRadar building blocks for suspicious local administrative execution and update manipulation only if the final CRE rule evaluates both building blocks within the same bounded same-host sequence.

DRI

·        7.8

DRI Justification

·        The rule is behaviorally meaningful because it focuses on update suppression tied to suspicious local administrative context rather than generic update failure.

·        The rule adds distinct coverage for a degradation path that may leave endpoint protection nominally enabled while reducing security intelligence freshness.

·        The rule is weaker than Rule 1 because update behavior has greater benign operational overlap and requires precise separation between routine update failure and local manipulation.

·        The rule covers multiple update degradation variants, including update-source manipulation, update-policy downgrade, security intelligence refresh blocking, and repeated update failure associated with local manipulation.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        6.3

Operational TCR Justification

·        QRadar can correlate update degradation with local administrative activity when process telemetry, Defender or endpoint protection logs, registry telemetry, and update telemetry are parsed into reliable custom properties.

·        Operational confidence depends on whether update-source, update-policy, security intelligence age, update failure reason, initiating process, account, and timestamp fields are reliably extracted.

·        Update-related telemetry may be inconsistently parsed across endpoint products without custom DSM work.

·        The rule is deployable in mature QRadar environments but should be withheld or scoped down where update telemetry is incomplete or not tied to local manipulation.

Full-Telemetry TCR

·        8.0

Full-Telemetry TCR Justification

·        With complete endpoint process telemetry, update telemetry, registry telemetry, service-control telemetry, policy telemetry, management-source context, and normalized host identity, QRadar can separate attacker-driven update suppression from routine update failure.

·        Full telemetry supports same-host bounded correlation between suspicious local administrative activity and update-related endpoint protection degradation.

Rule Code

-- QRadar AQL / CRE correlation template
-- Rule 2: Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity
-- Deployment requirement: Validate log sources, DSM mappings, custom properties, reference sets, building blocks, and CRE sequence support.
-- Guardrail: Update failure alone must not alert. Update staleness alone must not alert.
-- Correlation requirement: Same normalized host within 120 minutes.
-- Required sequence:
--   Event A: suspicious local administrative execution
--   Event B: update-policy manipulation, update-source manipulation, security intelligence refresh blocking, or update failure tied to local manipulation
-- Alert only when Event A precedes Event B on the same normalized host.

SELECT
  a."Normalized Host ID" AS normalized_host_id,
  a.destinationip AS destination_ip,
  a."Hostname" AS host_name,
  a."Username" AS user_name,
  MIN(a.starttime) AS first_admin_time,
  MIN(b.starttime) AS first_update_manipulation_time,
  MIN(c.starttime) AS first_update_failure_time,
  COLLECT(a."Process Name") AS admin_processes,
  COLLECT(a."Command Line") AS admin_command_lines,
  COLLECT(a."Parent Process Name") AS parent_processes,
  COLLECT(b."Registry Path") AS update_registry_paths,
  COLLECT(b."Update Source") AS update_sources,
  COLLECT(b."Update Policy") AS update_policies,
  COLLECT(c."Update Failure Reason") AS update_failure_reasons
FROM events a
JOIN events b
  ON a."Normalized Host ID" = b."Normalized Host ID"
LEFT JOIN events c
  ON b."Normalized Host ID" = c."Normalized Host ID"
WHERE
  a.starttime <= b.starttime
  AND b.starttime - a.starttime <= 7200000
  AND (
    c.starttime IS NULL
    OR (
      b.starttime <= c.starttime
      AND c.starttime - b.starttime <= 7200000
    )
  )
  AND (
    LOWER(a."Process Name") IN (
      'powershell.exe','pwsh.exe','cmd.exe','wmic.exe','reg.exe',
      'sc.exe','schtasks.exe','wscript.exe','cscript.exe','mshta.exe'
    )
  )
  AND (
    LOWER(a."Parent Process Name") IN (
      'winword.exe','excel.exe','powerpnt.exe','outlook.exe',
      'chrome.exe','msedge.exe','firefox.exe','wscript.exe',
      'cscript.exe','mshta.exe'
    )
    OR LOWER(a."Process Path") LIKE '%\\users\\%'
    OR LOWER(a."Process Path") LIKE '%\\appdata\\%'
    OR LOWER(a."Process Path") LIKE '%\\temp\\%'
    OR LOWER(a."Process Path") LIKE '%\\downloads\\%'
    OR LOWER(a."Process Path") LIKE '%\\programdata\\%'
    OR LOWER(a."Process Path") LIKE '%\\windows\\temp\\%'
    OR LOWER(a."Process Path") LIKE '%\\public\\%'
    OR LOWER(a."Process Path") LIKE '%\\admin$\\%'
    OR LOWER(a."Process Path") LIKE '%\\c$\\%'
  )
  AND (
    LOWER(b."Command Line") LIKE '%set-mppreference%'
    OR LOWER(b."Command Line") LIKE '%signaturefallbackorder%'
    OR LOWER(b."Command Line") LIKE '%signaturedefinitionupdatefilesharessources%'
    OR LOWER(b."Command Line") LIKE '%definitionupdateschannel%'
    OR LOWER(b."Command Line") LIKE '%engineupdateschannel%'
    OR LOWER(b."Command Line") LIKE '%platformupdateschannel%'
    OR LOWER(b."Command Line") LIKE '%updatesource%'
    OR LOWER(b."Command Line") LIKE '%disableupdate%'
    OR LOWER(b."Command Line") LIKE '%mpcmdrun.exe%'
    OR LOWER(b."Command Line") LIKE '%removedefinitions%'
    OR LOWER(b."Registry Path") LIKE '%windows defender\\signature updates%'
    OR LOWER(b."Registry Path") LIKE '%policies\\microsoft\\windows defender\\signature updates%'
    OR b."Update Policy Changed" = 'true'
    OR b."Update Source Changed" = 'true'
    OR b."Security Intelligence Refresh Blocked" = 'true'
    OR b."Security Intelligence Age Increased After Local Manipulation" = 'true'
    OR b."Local Update Policy Or Source Manipulation Observed" = 'true'
  )
  AND (
    c.starttime IS NULL
    OR (
      c."Repeated Update Failure" = 'true'
      AND (
        b."Update Policy Changed" = 'true'
        OR b."Update Source Changed" = 'true'
        OR b."Security Intelligence Refresh Blocked" = 'true'
        OR b."Local Update Policy Or Source Manipulation Observed" = 'true'
        OR LOWER(b."Command Line") LIKE '%signaturefallbackorder%'
        OR LOWER(b."Command Line") LIKE '%signaturedefinitionupdatefilesharessources%'
        OR LOWER(b."Command Line") LIKE '%definitionupdateschannel%'
        OR LOWER(b."Command Line") LIKE '%engineupdateschannel%'
        OR LOWER(b."Command Line") LIKE '%platformupdateschannel%'
        OR LOWER(b."Command Line") LIKE '%updatesource%'
        OR LOWER(b."Registry Path") LIKE '%windows defender\\signature updates%'
        OR LOWER(b."Registry Path") LIKE '%policies\\microsoft\\windows defender\\signature updates%'
      )
    )
  )
  AND NOT REFERENCESETCONTAINS('Approved Security Admins', a."Username")
  AND NOT REFERENCESETCONTAINS('Approved Update Sources', b."Update Source")
  AND NOT REFERENCESETCONTAINS('Approved Patch Management Hosts', a."Normalized Host ID")
  AND NOT REFERENCESETCONTAINS('Approved Maintenance Window Hosts', a."Normalized Host ID")
GROUP BY
  a."Normalized Host ID",
  a.destinationip,
  a."Hostname",
  a."Username"
LAST 120 MINUTES

QRadar Rule Count

·        QRadar S25 rule count: 2

Sigma

Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition

Rule Format

·        Sigma correlation-package template.

Detection Objective

·        Detect suspicious privilege or administrative execution followed by directly observed endpoint security-control degradation on the same host within a bounded time window.

Detection Logic

·        Trigger only when Event A and Event B are both observed on the same host within 60 minutes.

·        Event A is suspicious administrative execution involving elevated PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tooling, or administrative binaries launched from suspicious parent processes or suspicious paths.

·        Event B is directly observed endpoint security-control degradation through protection-state change, policy-state change, endpoint security service-state change, sensor-health change, security-control setting change, Defender operational event, registry-backed security setting change, service-control event, or equivalent endpoint protection telemetry.

·        Event A alone must not be deployed as an alert.

·        Event B alone must not be deployed as an alert unless the backend implements separate local policy for endpoint protection integrity monitoring.

·        Command-line indicators may support the degradation event but must not substitute for direct protection-state or security-control state evidence.

·        Suppress or lower severity when the activity maps to approved endpoint-management tooling, authorized security engineering activity, vendor support, maintenance windows, endpoint migration, or break-glass recovery.

·        Do not deploy this rule if the backend cannot support same-host event sequencing or if endpoint protection-state transition visibility is unavailable.

Engineering Implementation Instructions

·        Map Sigma fields to backend-specific fields for host identity, user identity, process name, process path, command line, parent process name, parent command line, registry path, service name, event timestamp, and log source.

·        Map endpoint security-control degradation fields for affected setting, previous value, new value, management source, initiating process where available, initiating account where available, service state, registry path, policy state, sensor health state, and timestamp.

·        Required telemetry may include Windows Security logs, Sysmon, Defender operational logs, EDR events, endpoint protection platform logs, registry telemetry, service-control telemetry, endpoint sensor health telemetry, and device-management telemetry.

·        Validate that the target backend supports Sigma correlation rules or equivalent same-host sequence logic before deployment.

·        Define backend-specific allowlists or filters for approved administrators, approved service accounts, endpoint-management platforms, maintenance windows, security engineering scripts, vendor support tooling, endpoint migration workflows, and break-glass recovery activity.

·        Do not deploy Event A or Event B as standalone alerting logic from this package.

·        If the backend cannot preserve sequence logic, use this content only as a hunting template or convert it into backend-native correlation logic.

DRI

·        8.2

DRI Justification

·        The rule is anchored to the core behavior chain of suspicious administrative or privilege context followed by measurable endpoint security-control degradation.

·        The rule resists simple tool changes because it does not depend on BlueHammer, RedSun, UnDefend, one process name, one command, one service, one registry value, or one Defender-only setting.

·        The rule covers multiple execution variants, including elevated shells, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration, renamed binaries, and suspicious parent-child process chains.

·        The rule has moderate portability constraints because Sigma backends vary in sequence-correlation support, but the detection logic remains behavior-chain based rather than signature based.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        6.5

Operational TCR Justification

·        Operational confidence depends on whether the backend receiving Sigma content has endpoint process telemetry, protection-state telemetry, registry telemetry, service-control telemetry, device-management context, and normalized host identity.

·        Sigma field portability varies across backends, especially for endpoint protection state, policy state, sensor health, and management-source fields.

·        Correlation support is backend-dependent and must be validated before the rule is treated as deployable.

·        The rule should be scoped down, converted to backend-native logic, or withheld where same-host sequencing and direct protection-state evidence are unavailable.

Full-Telemetry TCR

·        8.1

Full-Telemetry TCR Justification

·        With complete endpoint execution telemetry, endpoint protection-state telemetry, registry telemetry, service-control telemetry, device-management context, sensor health telemetry, and backend-supported sequence correlation, this Sigma logic can support reliable same-host behavioral detection.

·        Full telemetry allows the detection to separate attacker-driven local degradation from approved security administration, endpoint recovery, endpoint migration, and policy deployment.

Rule Code

title: Endpoint Security-Control Degradation Following Suspicious Privilege Transition
id: sig-endpoint-defense-subversion-001
status: experimental
description: >
  Sigma correlation-package template for detecting suspicious administrative execution
  followed by directly observed endpoint security-control degradation on the same host
  within 60 minutes. Event A and Event B must be correlated by the backend. Neither
  event should be deployed as standalone alerting logic from this package.
author: CyberDax
date: 2026-04-27
references:
  - Endpoint defense subversion and security-control degradation behavior class
tags:
  - attack.defense_evasion
  - attack.privilege_escalation
  - attack.t1562
  - attack.t1059
  - attack.t1112

correlation_package:
  correlation_type: temporal_sequence
  group_by:
    - Computer
  timeframe: 60m
  sequence:
    - event_a_suspicious_administrative_execution
    - event_b_direct_endpoint_security_control_degradation
  alert_condition: event_a_suspicious_administrative_execution followed_by event_b_direct_endpoint_security_control_degradation
  deployment_guardrails:
    - Event A alone must not alert.
    - Event B alone must not alert from this package unless separately deployed as endpoint protection integrity monitoring.
    - Command-line tampering indicators alone are not sufficient.
    - Direct protection-state, policy-state, service-state, registry-backed security setting, or sensor-health evidence is required.
    - Backend conversion must preserve same-host temporal sequence.

event_rules:
  - name: event_a_suspicious_administrative_execution
    logsource:
      product: windows
      category: process_creation
    detection:
      suspicious_admin_process:
        Image|endswith:
          - '\powershell.exe'
          - '\pwsh.exe'
          - '\cmd.exe'
          - '\wmic.exe'
          - '\reg.exe'
          - '\sc.exe'
          - '\schtasks.exe'
          - '\wscript.exe'
          - '\cscript.exe'
          - '\mshta.exe'
          - '\rundll32.exe'
      suspicious_parent:
        ParentImage|endswith:
          - '\winword.exe'
          - '\excel.exe'
          - '\powerpnt.exe'
          - '\outlook.exe'
          - '\chrome.exe'
          - '\msedge.exe'
          - '\firefox.exe'
          - '\7z.exe'
          - '\winrar.exe'
          - '\wscript.exe'
          - '\cscript.exe'
          - '\mshta.exe'
      suspicious_path:
        Image|contains:
          - '\Users\'
          - '\AppData\'
          - '\Temp\'
          - '\Downloads\'
          - '\ProgramData\'
          - '\Windows\Temp\'
          - '\Public\'
          - '\ADMIN$\'
          - '\C$\'
      privilege_context:
        CommandLine|contains:
          - 'runas'
          - 'net localgroup administrators'
          - 'whoami /priv'
      condition: suspicious_admin_process and (suspicious_parent or suspicious_path or privilege_context)
    fields:
      - Computer
      - User
      - Image
      - ParentImage
      - CommandLine
      - IntegrityLevel
      - Hashes

  - name: event_b_direct_endpoint_security_control_degradation
    logsource:
      product: windows
      category: registry_set
    detection:
      defender_registry_paths:
        TargetObject|contains:
          - '\Microsoft\Windows Defender\'
          - '\Policies\Microsoft\Windows Defender\'
          - '\Microsoft\Windows Advanced Threat Protection\'
      degradation_keywords:
        TargetObject|contains:
          - 'Real-Time Protection'
          - 'DisableRealtimeMonitoring'
          - 'DisableBehaviorMonitoring'
          - 'DisableIOAVProtection'
          - 'DisableBlockAtFirstSeen'
          - 'SubmitSamplesConsent'
          - 'Exclusions'
          - 'ExclusionPath'
          - 'ExclusionProcess'
          - 'ExclusionExtension'
          - 'SignatureFallbackOrder'
          - 'TamperProtection'
      condition: defender_registry_paths and degradation_keywords
    fields:
      - Computer
      - User
      - Image
      - TargetObject
      - Details

  - name: event_b_direct_endpoint_security_service_degradation
    logsource:
      product: windows
      service: system
    detection:
      security_services:
        ServiceName:
          - 'WinDefend'
          - 'Sense'
          - 'WdNisSvc'
          - 'SecurityHealthService'
      service_degradation:
        EventID:
          - 7036
          - 7040
          - 7045
      condition: security_services and service_degradation
    fields:
      - Computer
      - User
      - ServiceName
      - EventID
      - Message

falsepositives:
  - Approved endpoint-management tooling
  - Authorized security engineering activity
  - Vendor support activity
  - Endpoint migration
  - Maintenance-window activity
  - Break-glass recovery

level: high

notes:
  - This is a Sigma correlation-package template, not a standalone single-event rule.
  - Backends that do not support Sigma correlation packages must convert this into backend-native correlation logic.
  - Event A must precede Event B on the same host within 60 minutes.
  - Direct endpoint security-control degradation evidence is required.
  - Command-line indicators alone are not sufficient.

Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity

Rule Format

·        Sigma correlation-package template.

Detection Objective

·        Detect suspicious local administrative activity followed by security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation.

Detection Logic

·        Trigger only when Event A and Event B are both observed on the same host within 120 minutes.

·        Event A is suspicious local administrative execution involving elevated PowerShell, CMD, WMI, registry utility, service-control utility, scheduled task utility, script host execution, administrative tooling launched from suspicious parent process ancestry, or administrative execution from suspicious paths.

·        Event B is direct evidence of update-source manipulation, update-policy manipulation, local policy manipulation, or security intelligence refresh blocking.

·        Repeated update failure is detection-relevant only when paired with Event B manipulation evidence.

·        Event A alone must not be deployed as an alert.

·        Event B alone must not be deployed as an alert from this package unless the backend implements separate endpoint update-integrity monitoring.

·        Update failure alone must not alert.

·        Update staleness alone must not alert.

·        Do not alert on expected patching, approved security engineering, endpoint migration, vendor support, maintenance-window activity, or known management-platform policy changes.

·        Do not deploy this rule unless the backend can correlate suspicious local administrative activity with update manipulation on the same host.

Engineering Implementation Instructions

·        Map Sigma fields to backend-specific fields for host identity, user identity, process name, process path, command line, parent process name, parent command line, registry path, update source, update policy, update component, update status, update failure reason, security intelligence age, and timestamp.

·        Required telemetry may include Defender operational logs, endpoint protection logs, Windows event logs, EDR telemetry, registry telemetry, service-control telemetry, and device-management or patch-management telemetry.

·        Validate that the backend can distinguish update-source manipulation, update-policy manipulation, local policy manipulation, and security intelligence refresh blocking from ordinary update failure.

·        Define backend-specific allowlists or filters for approved update sources, expected patching systems, endpoint classes, authorized administrators, service accounts, maintenance windows, and device-management platforms.

·        Do not deploy the rule as update-failure-only or update-staleness-only logic.

·        If the backend cannot preserve sequence logic or direct update-manipulation evidence, use this content only as a hunting template or convert it into backend-native correlation logic.

DRI

·        7.6

DRI Justification

·        The rule is behaviorally meaningful because it focuses on update suppression tied to suspicious local administrative context rather than generic update failure.

·        The rule adds distinct coverage for a degradation path that may leave endpoint protection nominally enabled while reducing security intelligence freshness.

·        The rule is weaker than Rule 1 because update behavior has greater benign operational overlap and requires precise separation between routine update failure and local manipulation.

·        The rule covers multiple update degradation variants, including update-source manipulation, update-policy downgrade, security intelligence refresh blocking, and repeated update failure associated with local manipulation.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        6.1

Operational TCR Justification

·        Operational confidence depends on whether the backend receiving Sigma content has process telemetry, update-source telemetry, update-policy telemetry, registry telemetry, management context, and normalized host identity.

·        Update-related telemetry and protection-state fields may be inconsistently mapped across products and backends.

·        Sigma portability is limited for this behavior because the rule requires same-host sequence correlation and reliable update-manipulation evidence.

·        The rule should be scoped down, converted to backend-native logic, or withheld where update telemetry is incomplete or not tied to local manipulation.

Full-Telemetry TCR

·        7.8

Full-Telemetry TCR Justification

·        With complete endpoint process telemetry, update telemetry, registry telemetry, service-control telemetry, policy telemetry, management-source context, normalized host identity, and backend-supported sequence correlation, this Sigma logic can support reliable update-suppression detection.

·        Full telemetry allows the detection to separate attacker-driven update suppression from routine update failure, stale update status, approved patching, and endpoint-management activity.

Rule Code

title: Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity
id: sig-endpoint-defense-subversion-002
status: experimental
description: >
  Sigma correlation-package template for detecting suspicious local administrative execution
  followed by update-policy manipulation, update-source manipulation, local policy manipulation,
  or security intelligence refresh blocking on the same host within 120 minutes. Event A and
  Event B must be correlated by the backend. Update failure alone and update staleness alone
  must not alert.
author: CyberDax
date: 2026-04-27
references:
  - Endpoint defense subversion and security-control degradation behavior class
tags:
  - attack.defense_evasion
  - attack.t1562
  - attack.t1112
  - attack.t1059

correlation_package:
  correlation_type: temporal_sequence
  group_by:
    - Computer
  timeframe: 120m
  sequence:
    - event_a_suspicious_local_administrative_execution
    - event_b_direct_update_manipulation
  alert_condition: event_a_suspicious_local_administrative_execution followed_by event_b_direct_update_manipulation
  deployment_guardrails:
    - Event A alone must not alert.
    - Event B alone must not alert from this package unless separately deployed as endpoint update-integrity monitoring.
    - Update failure alone must not alert.
    - Update staleness alone must not alert.
    - Repeated update failure is relevant only when paired with direct update-policy, update-source, local policy, or security intelligence refresh-blocking evidence.
    - Backend conversion must preserve same-host temporal sequence.

event_rules:
  - name: event_a_suspicious_local_administrative_execution
    logsource:
      product: windows
      category: process_creation
    detection:
      admin_process:
        Image|endswith:
          - '\powershell.exe'
          - '\pwsh.exe'
          - '\cmd.exe'
          - '\wmic.exe'
          - '\reg.exe'
          - '\sc.exe'
          - '\schtasks.exe'
          - '\wscript.exe'
          - '\cscript.exe'
          - '\mshta.exe'
      suspicious_parent:
        ParentImage|endswith:
          - '\winword.exe'
          - '\excel.exe'
          - '\powerpnt.exe'
          - '\outlook.exe'
          - '\chrome.exe'
          - '\msedge.exe'
          - '\firefox.exe'
          - '\wscript.exe'
          - '\cscript.exe'
          - '\mshta.exe'
      suspicious_path:
        Image|contains:
          - '\Users\'
          - '\AppData\'
          - '\Temp\'
          - '\Downloads\'
          - '\ProgramData\'
          - '\Windows\Temp\'
          - '\Public\'
          - '\ADMIN$\'
          - '\C$\'
      condition: admin_process and (suspicious_parent or suspicious_path)
    fields:
      - Computer
      - User
      - Image
      - ParentImage
      - CommandLine

  - name: event_b_direct_update_manipulation
    logsource:
      product: windows
      category: registry_set
    detection:
      defender_signature_update_registry:
        TargetObject|contains:
          - '\Windows Defender\Signature Updates'
          - '\Policies\Microsoft\Windows Defender\Signature Updates'
      update_manipulation_keywords:
        TargetObject|contains:
          - 'SignatureFallbackOrder'
          - 'SignatureDefinitionUpdateFileSharesSources'
          - 'DefinitionUpdatesChannel'
          - 'EngineUpdatesChannel'
          - 'PlatformUpdatesChannel'
          - 'UpdateSource'
      condition: defender_signature_update_registry and update_manipulation_keywords
    fields:
      - Computer
      - User
      - Image
      - TargetObject
      - Details

  - name: event_b_direct_update_manipulation_command
    logsource:
      product: windows
      category: process_creation
    detection:
      update_manipulation_command:
        CommandLine|contains:
          - 'Set-MpPreference'
          - 'SignatureFallbackOrder'
          - 'SignatureDefinitionUpdateFileSharesSources'
          - 'DefinitionUpdatesChannel'
          - 'EngineUpdatesChannel'
          - 'PlatformUpdatesChannel'
          - 'UpdateSource'
          - 'DisableUpdate'
          - 'MpCmdRun.exe'
          - 'RemoveDefinitions'
      condition: update_manipulation_command
    fields:
      - Computer
      - User
      - Image
      - ParentImage
      - CommandLine

falsepositives:
  - Approved patching systems
  - Approved update sources
  - Endpoint-management activity
  - Authorized security engineering activity
  - Maintenance-window activity
  - Vendor support activity

level: high

notes:
  - This is a Sigma correlation-package template, not a standalone single-event rule.
  - Backends that do not support Sigma correlation packages must convert this into backend-native correlation logic.
  - Event A must precede Event B on the same host within 120 minutes.
  - Direct update-policy manipulation, update-source manipulation, local policy manipulation, or security intelligence refresh-blocking evidence is required.
  - Update failure alone must not alert.
  - Update staleness alone must not alert.

Sigma Rule Count

·        Sigma S25 rule count: 2

YARA

Detection Viability Assessment

·        No YARA rule is included for this report.

Public Reporting Rationale

·        The core behavior evaluated in this report requires endpoint-level visibility into privilege context, endpoint protection-state changes, service-control activity, registry or configuration modification, update-source manipulation, endpoint sensor health, and same-host behavioral sequencing.

·        YARA is designed for file, memory, and artifact pattern matching. It does not independently observe endpoint security-control degradation as a chained behavior.

·        A YARA rule for this report would risk overfitting to malware strings, proof-of-concept artifacts, tool names, exploit labels, or vendor-specific indicators rather than detecting the broader endpoint defense subversion behavior class.

·        Because this report is focused on durable post-compromise security-control degradation, a file or memory signature would not provide sufficient confidence for the core behavior described in this report.

Detection Role

·        YARA may support malware triage, suspicious file classification, memory scanning, or artifact enrichment when endpoint telemetry has already identified security-control degradation.

·        Relevant enrichment may include suspicious tooling, payloads, loaders, scripts, or memory artifacts discovered after endpoint protection posture has been reduced.

·        YARA should not be used as the primary detection source for endpoint defense subversion in this report.

·        YARA should not be used to detect BlueHammer, RedSun, or UnDefend by keyword, label, proof-of-concept string, or assumed artifact unless a validated artifact-specific detection requirement exists outside this report.

Rule Count

·        YARA S25 rule count: 0

AWS

Detection Viability Assessment

·        No AWS-native detection rule is included for this report.

·        AWS-native telemetry may identify management-plane activity, automation execution, remote command activity, instance configuration changes, or suspicious administrative use, but AWS telemetry alone does not reliably confirm endpoint security-control degradation.

·        The core behavior evaluated in this report requires endpoint-level confirmation of protection-state change, service-control activity, registry or configuration modification, update-source manipulation, endpoint sensor health degradation, and same-host behavioral sequencing.

·        AWS telemetry may support detection and investigation when management-plane activity can be correlated with endpoint-level evidence confirming security-control degradation.

Public Reporting Rationale

·        AWS CloudTrail, Systems Manager, EC2, VPC, Route 53 Resolver, GuardDuty, and related telemetry can support investigation of suspicious administrative activity or post-compromise activity affecting cloud-hosted workloads.

·        AWS-native management-plane telemetry can show that commands, automation, or configuration changes occurred, but it does not independently prove that endpoint protection posture was degraded.

·        A cloud-only rule would risk inferring endpoint defense subversion from administrative activity without confirming the endpoint outcome.

·        Because this report focuses on endpoint defense subversion and security-control degradation, AWS-based detection requires endpoint telemetry or workload-level telemetry capable of confirming the security-control state change.

Cloud-Management Detection Context

·        AWS management-plane command or automation activity may be relevant when it targets AWS-managed compute and is followed by endpoint-confirmed security-control degradation.

·        Relevant AWS activity may include Systems Manager Run Command, Systems Manager Automation, Session Manager activity, EC2 user-data modification, instance profile abuse, or other authorized management-plane actions used to execute commands on workloads.

·        This detection context is conditional because AWS telemetry must be paired with endpoint evidence showing protection-state reduction, endpoint security service manipulation, update-source manipulation, telemetry reduction, or endpoint sensor health degradation.

·        Useful correlation points include the initiating AWS principal, management-plane action, target instance or workload, command or automation content where available, endpoint execution evidence, and endpoint protection-state outcome.

Detection Role

·        AWS telemetry may support investigation of how an attacker used cloud management capabilities to reach or modify workloads.

·        AWS telemetry may provide useful context for initiating identity, source IP, management action, target workload, session activity, command execution, and automation history.

·        AWS should not be used as the primary detection source for endpoint defense subversion unless endpoint outcome telemetry is integrated and confirms the security-control degradation.

·        AWS-native findings, network telemetry, or management-plane events should remain supporting evidence unless they are tied to directly observed endpoint security-control degradation.

Rule Count

·        AWS-native detection rule count: 0

Azure

Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition

Rule Format

·        Microsoft Sentinel KQL / Microsoft Defender XDR Advanced Hunting correlation template.

Detection Objective

·        Detect suspicious privilege or administrative execution followed by directly observed endpoint security-control degradation on the same device within a bounded time window.

Detection Logic

·        Trigger when suspicious administrative, elevated, remote management, or SYSTEM-context execution is followed by directly observed endpoint security-control degradation on the same device within 60 minutes.

·        Suspicious administrative execution includes elevated PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote management tooling, Azure Arc command execution, Intune script execution, or administrative binaries launched from suspicious parent processes or suspicious paths.

·        Endpoint security-control degradation must be directly observable through Defender protection-state change, Defender configuration change, endpoint security service-state change, sensor-health change, policy-state change, registry-backed security setting change, service-control event, or equivalent endpoint protection telemetry.

·        Azure Activity, Intune, Entra ID, or Azure Arc events may establish administrative context, but they must not substitute for endpoint outcome confirmation.

·        Microsoft Defender command-line indicators may support the degradation event but must not substitute for direct protection-state, service-state, policy-state, registry-backed setting, or sensor-health evidence.

·        Suppress or lower severity when the activity maps to approved Intune policy deployment, approved Defender configuration management, security engineering activity, vendor support, maintenance windows, endpoint migration, or break-glass recovery.

·        Do not deploy this rule if endpoint protection-state transition visibility or equivalent endpoint security-control state telemetry is unavailable.

Engineering Implementation Instructions

·        Map device identity across Microsoft Defender XDR, Microsoft Sentinel, Intune, Entra ID, Azure Arc, Windows Security logs, Defender operational logs, and endpoint telemetry.

·        Required fields include device identifier, device name, initiating account, account SID or object ID where available, process name, process command line, parent process, parent command line, process path, signer, hash, timestamp, action type, affected setting, previous value where available, new value where available, service name, policy source, management source, and sensor-health state.

·        Required telemetry may include Microsoft Defender for Endpoint DeviceProcessEvents, DeviceRegistryEvents, DeviceEvents, Defender operational events, Intune policy events, Windows Security logs, Azure Arc activity, and Sentinel-normalized endpoint telemetry.

·        Create and maintain watchlists for approved administrators, approved service accounts, Intune administrators, approved management platforms, approved maintenance windows, known security engineering scripts, vendor support tooling, endpoint migration workflows, and break-glass recovery accounts.

·        Validate that same-device correlation works across Defender device identifiers, Sentinel host fields, Intune device identifiers, Azure Arc resource identifiers, and Entra ID identity fields.

·        Validate timestamp normalization before enabling the sequence window.

·        Do not deploy this rule as a single-event Defender tampering rule, Azure control-plane rule, or Intune activity rule. It must require same-device sequence correlation between suspicious administrative execution and directly observed endpoint security-control degradation.

DRI

·        8.6

DRI Justification

·        The rule is anchored to the core behavior chain of suspicious administrative or privilege context followed by measurable endpoint security-control degradation.

·        The rule resists simple tool changes because it does not depend on BlueHammer, RedSun, UnDefend, one process name, one command, one registry value, one service, or one Defender-only setting.

·        The rule covers multiple execution variants, including elevated shells, SYSTEM-context execution, remote management, Intune or Azure Arc execution paths, registry utilities, service-control utilities, scheduled task utilities, script hosts, and suspicious parent-child process chains.

·        The rule has low artifact dependence because it focuses on behavior sequence and protection-state transition rather than exploit names, threat labels, or tool signatures.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.5

Operational TCR Justification

·        Azure can support this rule when Defender for Endpoint, Defender XDR, Intune, Entra ID, Windows endpoint telemetry, and Sentinel connectors are available and normalized.

·        Operational confidence depends on Defender licensing, connector coverage, retention, device identifier consistency, Intune policy visibility, field completeness, and timestamp normalization.

·        Protection-state and policy-state telemetry may require Defender, Intune, Windows, or endpoint-management enrichment beyond process telemetry.

·        The rule is deployable in mature Microsoft security environments but should be scoped down or withheld where endpoint protection-state telemetry is unavailable.

Full-Telemetry TCR

·        8.9

Full-Telemetry TCR Justification

·        With complete Defender for Endpoint, Defender XDR, Intune, Entra ID, Windows endpoint, registry, service-control, policy, and sensor-health telemetry, Azure can support high-confidence same-device sequence correlation.

·        Full telemetry allows the rule to distinguish attacker-driven local degradation from approved Intune policy deployment, Defender administration, endpoint recovery, endpoint migration, and security engineering workflows.

Rule Code

// Microsoft Sentinel / Microsoft Defender XDR Advanced Hunting correlation template
// Rule 1: Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition
// Deployment requirement: Validate table availability, connector coverage, field mappings, watchlists, and device identity normalization.
// Correlation requirement: Same device within 60 minutes.
// Required sequence:
//   Event A: suspicious privilege, administrative, remote management, or SYSTEM-context execution
//   Event B: directly observed endpoint security-control degradation
// Alert only when Event A precedes Event B on the same device.
// Guardrail: Cloud, identity, Intune, or Azure Arc administrative activity alone is not sufficient.
// Guardrail: Command-line tampering indicators alone are not sufficient without direct protection-state, policy-state, service-state, registry-backed setting, or sensor-health evidence.

let TimeWindow = 60m;
let ApprovedAdmins = (_GetWatchlist('ApprovedSecurityAdmins') | project SearchKey);
let ApprovedMaintenanceHosts = (_GetWatchlist('ApprovedMaintenanceWindowHosts') | project SearchKey);
let SuspiciousLocalExecution =
DeviceProcessEvents
| where
    (
        FileName in~ (
            "powershell.exe", "pwsh.exe", "cmd.exe", "wmic.exe", "reg.exe",
            "sc.exe", "schtasks.exe", "wscript.exe", "cscript.exe",
            "mshta.exe", "rundll32.exe"
        )
    )
    and
    (
        InitiatingProcessFileName in~ (
            "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
            "chrome.exe", "msedge.exe", "firefox.exe", "7z.exe", "winrar.exe",
            "wscript.exe", "cscript.exe", "mshta.exe"
        )
        or FolderPath has_any (
            "\\Users\\", "\\AppData\\", "\\Temp\\", "\\Downloads\\",
            "\\ProgramData\\", "\\Windows\\Temp\\", "\\Public\\", "\\ADMIN$\\", "\\C$\\"
        )
        or ProcessCommandLine has_any (
            "runas", "net localgroup administrators", "whoami /priv"
        )
    )
| extend EventA_Time = Timestamp,
         AdminSource = "LocalEndpoint"
| project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName,
          EventA_Time, AdminSource, FileName, FolderPath, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine;
let SuspiciousManagementExecution =
union isfuzzy=true
(
    AuditLogs
    | where OperationName has_any (
        "Run script",
        "Update device configuration",
        "Assign device configuration",
        "Device management script"
    )
    | extend DeviceId = tostring(TargetResources[0].id),
             DeviceName = tostring(TargetResources[0].displayName),
             AccountName = tostring(InitiatedBy.user.userPrincipalName),
             EventA_Time = TimeGenerated,
             AdminSource = "IntuneOrEntra",
             FileName = "",
             FolderPath = "",
             ProcessCommandLine = "",
             InitiatingProcessFileName = "",
             InitiatingProcessCommandLine = ""
    | project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName = "", EventA_Time,
              AdminSource, FileName, FolderPath, ProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    AzureActivity
    | where OperationNameValue has_any (
        "Microsoft.HybridCompute/machines/runCommand/action",
        "Microsoft.Compute/virtualMachines/runCommand/action"
    )
    | extend DeviceId = tostring(ResourceId),
             DeviceName = tostring(Resource),
             AccountName = tostring(Caller),
             EventA_Time = TimeGenerated,
             AdminSource = "AzureManagementPlane",
             FileName = "",
             FolderPath = "",
             ProcessCommandLine = "",
             InitiatingProcessFileName = "",
             InitiatingProcessCommandLine = ""
    | project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName = "", EventA_Time,
              AdminSource, FileName, FolderPath, ProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine
);
let SuspiciousAdminExecution =
SuspiciousLocalExecution
| union isfuzzy=true SuspiciousManagementExecution;
let DirectSecurityControlDegradation =
(
    DeviceEvents
    | where ActionType has_any (
        "AntivirusConfigurationChanged",
        "TamperProtectionDisabled",
        "DefenderConfigurationChanged",
        "SensorHealthStateChanged",
        "SecurityControlStateChanged",
        "EndpointProtectionStateChanged",
        "PolicyStateChanged"
    )
    | extend EventB_Time = Timestamp,
             DegradationEvidence = ActionType,
             DirectDegradationObserved = true,
             RegistryKey = "",
             RegistryValueName = "",
             RegistryValueData = ""
    | project DeviceId, DeviceName, EventB_Time, DegradationEvidence,
              DirectDegradationObserved, AccountName, InitiatingProcessAccountName,
              AdditionalFields, RegistryKey, RegistryValueName, RegistryValueData
)
| union
(
    DeviceRegistryEvents
    | where RegistryKey has_any (
        @"\Microsoft\Windows Defender",
        @"\Policies\Microsoft\Windows Defender",
        @"\Microsoft\Windows Advanced Threat Protection"
    )
    | where RegistryValueName has_any (
        "DisableRealtimeMonitoring",
        "DisableBehaviorMonitoring",
        "DisableIOAVProtection",
        "DisableBlockAtFirstSeen",
        "SubmitSamplesConsent",
        "Exclusions",
        "ExclusionPath",
        "ExclusionProcess",
        "ExclusionExtension",
        "TamperProtection",
        "SignatureFallbackOrder"
    )
    | extend EventB_Time = Timestamp,
             DegradationEvidence = strcat("RegistrySettingChanged:", RegistryKey, "\\", RegistryValueName),
             DirectDegradationObserved = true,
             AdditionalFields = ""
    | project DeviceId, DeviceName, EventB_Time, DegradationEvidence,
              DirectDegradationObserved, AccountName, InitiatingProcessAccountName,
              AdditionalFields, RegistryKey, RegistryValueName, RegistryValueData
)
| union
(
    DeviceEvents
    | where ActionType has_any (
        "ServiceStopped",
        "ServiceDisabled",
        "ServiceConfigurationChanged",
        "ServiceStartTypeChanged"
    )
    | where AdditionalFields has_any ("WinDefend", "Sense", "WdNisSvc", "SecurityHealthService")
    | extend EventB_Time = Timestamp,
             DegradationEvidence = strcat("SecurityServiceStateChanged:", ActionType),
             DirectDegradationObserved = true,
             RegistryKey = "",
             RegistryValueName = "",
             RegistryValueData = ""
    | project DeviceId, DeviceName, EventB_Time, DegradationEvidence,
              DirectDegradationObserved, AccountName, InitiatingProcessAccountName,
              AdditionalFields, RegistryKey, RegistryValueName, RegistryValueData
);
SuspiciousAdminExecution
| join kind=inner DirectSecurityControlDegradation on DeviceId
| where DirectDegradationObserved == true
| where EventA_Time <= EventB_Time and EventB_Time - EventA_Time <= TimeWindow
| where AccountName !in (ApprovedAdmins)
| where DeviceName !in (ApprovedMaintenanceHosts)
| extend RuleName = "Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition"
| extend Severity = "High"
| project RuleName, Severity, DeviceName, DeviceId, AccountName, AdminSource,
          EventA_Time, EventB_Time, FileName, FolderPath, ProcessCommandLine,
          InitiatingProcessFileName, DegradationEvidence

Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local or Management-Plane Administrative Activity

Rule Format

·        Microsoft Sentinel KQL / Microsoft Defender XDR Advanced Hunting correlation template.

Detection Objective

·        Detect suspicious local or management-plane administrative activity followed by security intelligence update suppression, update-source manipulation, update-policy downgrade, or repeated update failure associated with local update-policy or update-source manipulation.

Detection Logic

·        Trigger when suspicious local or management-plane administrative activity is followed by update-related endpoint security-control degradation on the same device within 120 minutes.

·        Suspicious administrative activity includes elevated PowerShell, CMD, WMI, registry utility, service-control utility, scheduled task utility, Intune script execution, Azure Arc command execution, Defender management activity, or administrative tooling launched from suspicious parent process ancestry or suspicious paths.

·        Update-related degradation requires update-source manipulation, update-policy manipulation, local policy manipulation, security intelligence refresh blocking, Defender signature update control manipulation, or repeated update failure paired with local update-policy or update-source manipulation.

·        Azure Activity, Intune, Entra ID, or Azure Arc administrative activity may establish administrative context, but it must not substitute for endpoint update-manipulation evidence.

·        Update failure alone must not alert.

·        Update staleness alone must not alert.

·        Do not alert on expected patching, approved Defender update channel management, approved Intune policy deployment, endpoint migration, vendor support, maintenance-window activity, or known management-platform policy changes.

·        Do not deploy this rule unless update-related telemetry can be tied to device, initiating process or management action, initiating account, and timestamp.

Engineering Implementation Instructions

·        Map Microsoft Defender, Sentinel, Intune, Entra ID, Azure Arc, Windows, and endpoint telemetry into consistent device and account identifiers.

·        Required fields include device identifier, device name, initiating user, initiating process, management source, policy source, update source, update policy, signature version, engine version, platform version, update failure reason, security intelligence age, registry path, timestamp, and action type.

·        Required telemetry may include DeviceProcessEvents, DeviceRegistryEvents, DeviceEvents, Defender operational logs, Intune policy records, Azure Activity, Azure Arc activity, Windows event logs, and Sentinel-normalized endpoint telemetry.

·        Create and maintain watchlists for approved update sources, expected update cadence, endpoint classes, approved patching systems, authorized administrators, Intune administrators, service accounts, maintenance windows, and device-management platforms.

·        Require evidence of update-source manipulation, update-policy manipulation, local policy manipulation, or security intelligence refresh blocking before treating update failure as detection-relevant.

·        Validate that update telemetry and suspicious administrative telemetry can be correlated to the same normalized device identity.

·        Do not deploy the rule as update-failure-only or update-staleness-only logic.

DRI

·        8.0

DRI Justification

·        The rule is behaviorally meaningful because it focuses on update suppression tied to suspicious local or management-plane administrative context rather than generic update failure.

·        The rule adds distinct coverage for a degradation path that may leave endpoint protection nominally enabled while reducing security intelligence freshness.

·        The rule is weaker than Rule 1 because update behavior has greater benign operational overlap and requires precise separation between routine update failure and local or policy manipulation.

·        The rule covers multiple update degradation variants, including update-source manipulation, update-policy downgrade, local policy manipulation, Defender signature update disruption, and security intelligence refresh blocking.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.1

Operational TCR Justification

·        Azure can support this rule when Defender for Endpoint, Defender operational telemetry, Intune policy telemetry, Windows registry telemetry, Sentinel connectors, and device-management context are available.

·        Operational confidence depends on whether update-source, update-policy, security intelligence age, update failure reason, initiating process, initiating account, management action, and timestamp fields are reliably available.

·        Update-related telemetry may vary by license, connector, endpoint configuration, and data retention.

·        The rule is deployable in mature Microsoft security environments but should be withheld or scoped down where update telemetry is incomplete or not tied to local or management-plane manipulation.

Full-Telemetry TCR

·        8.5

Full-Telemetry TCR Justification

·        With complete Defender endpoint, Defender operational, Intune, Windows registry, service-control, policy, management-source, and normalized device identity telemetry, Azure can reliably separate attacker-driven update suppression from routine update failure.

·        Full telemetry supports same-device bounded correlation between suspicious local or management-plane administrative activity and update-related endpoint protection degradation.

Rule Code

// Microsoft Sentinel / Microsoft Defender XDR Advanced Hunting correlation template
// Rule 2: Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local or Management-Plane Administrative Activity
// Deployment requirement: Validate Defender, Intune, Azure Activity, Azure Arc, Windows, and endpoint telemetry availability.
// Guardrail: Update failure alone must not alert. Update staleness alone must not alert.
// Guardrail: Cloud, identity, Intune, or Azure Arc administrative activity alone is not sufficient.
// Correlation requirement: Same device within 120 minutes.
// Required sequence:
//   Event A: suspicious local or management-plane administrative activity
//   Event B: update-policy manipulation, update-source manipulation, local policy manipulation, or security intelligence refresh blocking
// Alert only when Event A precedes Event B on the same device.

let TimeWindow = 120m;
let ApprovedAdmins = (_GetWatchlist('ApprovedSecurityAdmins') | project SearchKey);
let ApprovedPatchMgmtHosts = (_GetWatchlist('ApprovedPatchManagementHosts') | project SearchKey);
let ApprovedMaintenanceHosts = (_GetWatchlist('ApprovedMaintenanceWindowHosts') | project SearchKey);
let SuspiciousLocalAdmin =
DeviceProcessEvents
| where
    (
        FileName in~ (
            "powershell.exe", "pwsh.exe", "cmd.exe", "wmic.exe", "reg.exe",
            "sc.exe", "schtasks.exe", "wscript.exe", "cscript.exe", "mshta.exe"
        )
    )
    and
    (
        InitiatingProcessFileName in~ (
            "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
            "chrome.exe", "msedge.exe", "firefox.exe", "wscript.exe", "cscript.exe", "mshta.exe"
        )
        or FolderPath has_any (
            "\\Users\\", "\\AppData\\", "\\Temp\\", "\\Downloads\\",
            "\\ProgramData\\", "\\Windows\\Temp\\", "\\Public\\", "\\ADMIN$\\", "\\C$\\"
        )
    )
| extend EventA_Time = Timestamp,
         AdminSource = "LocalEndpoint"
| project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName,
          EventA_Time, AdminSource, FileName, FolderPath, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine;
let SuspiciousManagementPlane =
union isfuzzy=true
(
    AuditLogs
    | where OperationName has_any (
        "Run script",
        "Update device configuration",
        "Assign device configuration",
        "Device management script"
    )
    | extend DeviceId = tostring(TargetResources[0].id),
             DeviceName = tostring(TargetResources[0].displayName),
             AccountName = tostring(InitiatedBy.user.userPrincipalName),
             EventA_Time = TimeGenerated,
             AdminSource = "IntuneOrEntra",
             FileName = "",
             FolderPath = "",
             ProcessCommandLine = "",
             InitiatingProcessFileName = "",
             InitiatingProcessCommandLine = ""
    | project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName = "",
              EventA_Time, AdminSource, FileName, FolderPath, ProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    AzureActivity
    | where OperationNameValue has_any (
        "Microsoft.HybridCompute/machines/runCommand/action",
        "Microsoft.Compute/virtualMachines/runCommand/action"
    )
    | extend DeviceId = tostring(ResourceId),
             DeviceName = tostring(Resource),
             AccountName = tostring(Caller),
             EventA_Time = TimeGenerated,
             AdminSource = "AzureManagementPlane",
             FileName = "",
             FolderPath = "",
             ProcessCommandLine = "",
             InitiatingProcessFileName = "",
             InitiatingProcessCommandLine = ""
    | project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName = "",
              EventA_Time, AdminSource, FileName, FolderPath, ProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine
);
let SuspiciousAdminActivity =
SuspiciousLocalAdmin
| union isfuzzy=true SuspiciousManagementPlane;
let DirectUpdateManipulation =
(
    DeviceRegistryEvents
    | where RegistryKey has_any (
        @"\Windows Defender\Signature Updates",
        @"\Policies\Microsoft\Windows Defender\Signature Updates"
    )
    | where RegistryValueName has_any (
        "SignatureFallbackOrder",
        "SignatureDefinitionUpdateFileSharesSources",
        "DefinitionUpdatesChannel",
        "EngineUpdatesChannel",
        "PlatformUpdatesChannel",
        "UpdateSource"
    )
    | extend EventB_Time = Timestamp,
             UpdateManipulationEvidence = strcat("RegistryUpdateSettingChanged:", RegistryKey, "\\", RegistryValueName),
             DirectUpdateManipulationObserved = true,
             FileName = "",
             ProcessCommandLine = "",
             AdditionalFields = ""
    | project DeviceId, DeviceName, EventB_Time, AccountName, InitiatingProcessAccountName,
              UpdateManipulationEvidence, DirectUpdateManipulationObserved,
              RegistryKey, RegistryValueName, RegistryValueData,
              FileName, ProcessCommandLine, AdditionalFields
)
| union
(
    DeviceProcessEvents
    | where ProcessCommandLine has_any (
        "Set-MpPreference",
        "SignatureFallbackOrder",
        "SignatureDefinitionUpdateFileSharesSources",
        "DefinitionUpdatesChannel",
        "EngineUpdatesChannel",
        "PlatformUpdatesChannel",
        "UpdateSource",
        "DisableUpdate",
        "MpCmdRun.exe",
        "RemoveDefinitions"
    )
    | extend EventB_Time = Timestamp,
             UpdateManipulationEvidence = strcat("CommandUpdateManipulation:", ProcessCommandLine),
             DirectUpdateManipulationObserved = true,
             RegistryKey = "",
             RegistryValueName = "",
             RegistryValueData = "",
             AdditionalFields = ""
    | project DeviceId, DeviceName, EventB_Time, AccountName, InitiatingProcessAccountName,
              UpdateManipulationEvidence, DirectUpdateManipulationObserved,
              RegistryKey, RegistryValueName, RegistryValueData,
              FileName, ProcessCommandLine, AdditionalFields
)
| union
(
    DeviceEvents
    | where ActionType has_any (
        "SecurityIntelligenceRefreshBlocked",
        "UpdateSourceChanged",
        "UpdatePolicyChanged",
        "AntivirusSignatureUpdateSourceChanged",
        "AntivirusConfigurationChanged"
    )
    | extend EventB_Time = Timestamp,
             UpdateManipulationEvidence = ActionType,
             DirectUpdateManipulationObserved = true,
             RegistryKey = "",
             RegistryValueName = "",
             RegistryValueData = "",
             FileName = "",
             ProcessCommandLine = ""
    | project DeviceId, DeviceName, EventB_Time, AccountName, InitiatingProcessAccountName,
              UpdateManipulationEvidence, DirectUpdateManipulationObserved,
              RegistryKey, RegistryValueName, RegistryValueData,
              FileName, ProcessCommandLine, AdditionalFields
);
SuspiciousAdminActivity
| join kind=inner DirectUpdateManipulation on DeviceId
| where DirectUpdateManipulationObserved == true
| where EventA_Time <= EventB_Time and EventB_Time - EventA_Time <= TimeWindow
| where AccountName !in (ApprovedAdmins)
| where DeviceName !in (ApprovedPatchMgmtHosts)
| where DeviceName !in (ApprovedMaintenanceHosts)
| extend RuleName = "Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local or Management-Plane Administrative Activity"
| extend Severity = "High"
| project RuleName, Severity, DeviceName, DeviceId, AccountName, AdminSource,
          EventA_Time, EventB_Time, UpdateManipulationEvidence,
          FileName, ProcessCommandLine, RegistryKey, RegistryValueName, RegistryValueData

Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation

Rule Format

·        Microsoft Sentinel KQL / Microsoft Defender XDR Advanced Hunting correlation template.

Detection Objective

·        Detect credential access or persistence activity that occurs after directly observed endpoint security-control degradation on the same device within a bounded time window.

Detection Logic

·        Trigger when directly observed endpoint security-control degradation is followed by credential access or persistence behavior on the same device within 240 minutes.

·        Endpoint security-control degradation includes protection reduction, broad exclusion creation, endpoint protection service manipulation, endpoint sensor health degradation, telemetry forwarding reduction, security intelligence update suppression, update-source manipulation, or unmanaged policy downgrade.

·        Credential access behavior includes LSASS access, suspicious process handle access, dump file creation, SAM or SECURITY hive access, browser credential access, credential enumeration, or credential-access behavior that does not rely solely on tool name.

·        Persistence behavior includes scheduled task creation, service creation, service binary path modification, registry autorun modification, WMI persistence, startup folder modification, logon script modification, or user-profile persistence.

·        Azure Activity, Intune, Entra ID, or Azure Arc events may support context, but endpoint degradation must be directly observed before follow-on credential access or persistence can alert.

·        Suppress or lower severity when follow-on behavior maps to approved software deployment, endpoint-management activity, administrator maintenance, vendor support, endpoint recovery, backup tooling, or known security tooling.

·        Do not deploy this rule as a generic credential-access or persistence detector. Prior directly observed endpoint security-control degradation is required.

Engineering Implementation Instructions

·        Map Microsoft Defender XDR, Sentinel, Windows, Intune, and endpoint telemetry into consistent device identifiers and account identifiers.

·        Required fields include device identifier, device name, account, initiating process, source process, target process, access rights where available, command line, file path, registry path, service action, scheduled task action, timestamp, affected security-control setting, and management source.

·        Required telemetry may include DeviceEvents, DeviceProcessEvents, DeviceRegistryEvents, DeviceFileEvents, Defender operational logs, Windows Security logs, Sysmon, Intune policy telemetry, and Sentinel-normalized endpoint telemetry.

·        Create and maintain watchlists for approved security tools, backup agents, software deployment platforms, endpoint-management activity, known administrative scripts, approved persistence mechanisms, maintenance windows, and recovery workflows.

·        Validate same-device bounded-time correlation before enabling production alerting.

·        Do not deploy the rule if endpoint security-control degradation cannot be directly observed before the credential access or persistence behavior.

DRI

·        7.8

DRI Justification

·        The rule adds meaningful post-degradation objective coverage by identifying credential access or persistence after endpoint protection has been weakened.

·        The rule is behaviorally anchored because credential access or persistence must follow measurable endpoint security-control degradation on the same device.

·        The rule is weaker than Rule 1 because it depends on a longer behavior chain and more complex multi-event correlation.

·        The rule resists tool substitution by covering multiple credential access and persistence patterns rather than one tool label, one command, or one file name.

·        The rule is independent and does not depend on another detection output.

Operational TCR

·        7.0

Operational TCR Justification

·        Azure can support this rule when Defender for Endpoint, Defender XDR, Windows endpoint telemetry, file telemetry, registry telemetry, service telemetry, and persistence telemetry are available and normalized.

·        Operational confidence varies by Defender configuration, licensing, endpoint integration quality, field extraction quality, and timestamp normalization.

·        False-positive control depends on accurate watchlists for security tools, backup agents, endpoint-management workflows, software deployment systems, administrator maintenance, and recovery activity.

·        This rule should be withheld or scoped down in environments where endpoint degradation, credential-access, or persistence telemetry is incomplete.

Full-Telemetry TCR

·        8.3

Full-Telemetry TCR Justification

·        With complete endpoint degradation telemetry, credential access telemetry, file telemetry, registry telemetry, service-control telemetry, scheduled task telemetry, WMI telemetry, policy telemetry, and normalized device identity, Azure can support reliable post-degradation objective detection.

·        Full telemetry enables reliable separation of attacker objective activity from legitimate administrative, security, backup, deployment, and recovery workflows.

Rule Code

// Microsoft Sentinel / Microsoft Defender XDR Advanced Hunting correlation template
// Rule 3: Credential Access or Persistence After Endpoint Security-Control Degradation
// Deployment requirement: Endpoint security-control degradation must be directly observable before this logic is enabled as an alert.
// Guardrail: Do not deploy as a generic credential-access or persistence rule.
// Guardrail: Cloud, identity, Intune, or Azure Arc administrative activity alone is not sufficient.
// Correlation requirement: Same device within 240 minutes.
// Required sequence:
//   Event A: directly observed endpoint security-control degradation
//   Event B: credential access or persistence behavior
// Alert only when Event A precedes Event B on the same device.

let TimeWindow = 240m;
let ApprovedSecurityTools = (_GetWatchlist('ApprovedSecurityTools') | project SearchKey);
let ApprovedBackupAgents = (_GetWatchlist('ApprovedBackupAgents') | project SearchKey);
let ApprovedSoftwareDeploymentHosts = (_GetWatchlist('ApprovedSoftwareDeploymentHosts') | project SearchKey);
let ApprovedMaintenanceHosts = (_GetWatchlist('ApprovedMaintenanceWindowHosts') | project SearchKey);
let DirectSecurityControlDegradation =
(
    DeviceEvents
    | where ActionType has_any (
        "AntivirusConfigurationChanged",
        "TamperProtectionDisabled",
        "DefenderConfigurationChanged",
        "SensorHealthStateChanged",
        "SecurityControlStateChanged",
        "EndpointProtectionStateChanged",
        "PolicyStateChanged",
        "SecurityIntelligenceRefreshBlocked",
        "UpdateSourceChanged"
    )
    | extend EventA_Time = Timestamp,
             DegradationEvidence = ActionType,
             DirectDegradationObserved = true,
             RegistryKey = "",
             RegistryValueName = "",
             RegistryValueData = ""
    | project DeviceId, DeviceName, EventA_Time, AccountName, InitiatingProcessAccountName,
              DegradationEvidence, DirectDegradationObserved, AdditionalFields,
              RegistryKey, RegistryValueName, RegistryValueData
)
| union
(
    DeviceRegistryEvents
    | where RegistryKey has_any (
        @"\Microsoft\Windows Defender",
        @"\Policies\Microsoft\Windows Defender",
        @"\Microsoft\Windows Advanced Threat Protection"
    )
    | extend EventA_Time = Timestamp,
             DegradationEvidence = strcat("RegistrySecurityControlChange:", RegistryKey, "\\", RegistryValueName),
             DirectDegradationObserved = true,
             AdditionalFields = ""
    | project DeviceId, DeviceName, EventA_Time, AccountName, InitiatingProcessAccountName,
              DegradationEvidence, DirectDegradationObserved, AdditionalFields,
              RegistryKey, RegistryValueName, RegistryValueData
);
let CredentialAccess =
DeviceProcessEvents
| where
    (
        FileName in~ ("procdump.exe", "rundll32.exe", "reg.exe", "cmd.exe", "powershell.exe", "pwsh.exe")
        or ProcessCommandLine has_any (
            "comsvcs.dll", "MiniDump", "procdump", "rundll32", "lsass",
            "reg save", "\\SAM", "\\SECURITY", "cmdkey", "vaultcmd", "sekurlsa", "logonpasswords"
        )
    )
| extend EventB_Time = Timestamp,
         FollowOnType = "CredentialAccess",
         RegistryKey = "",
         RegistryValueName = "",
         RegistryValueData = ""
| project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName,
          EventB_Time, FollowOnType, FileName, FolderPath, ProcessCommandLine,
          InitiatingProcessFileName, RegistryKey, RegistryValueName, RegistryValueData;
let Persistence =
(
    DeviceProcessEvents
    | where
        (
            ProcessCommandLine has_any (
                "schtasks /create", "New-ScheduledTask", "sc create", "New-Service",
                "sc config", "reg add", "CurrentVersion\\Run", "__EventFilter",
                "CommandLineEventConsumer", "ActiveScriptEventConsumer", "Startup", "Logon Script"
            )
        )
    | extend EventB_Time = Timestamp,
             FollowOnType = "Persistence",
             RegistryKey = "",
             RegistryValueName = "",
             RegistryValueData = ""
    | project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName,
              EventB_Time, FollowOnType, FileName, FolderPath, ProcessCommandLine,
              InitiatingProcessFileName, RegistryKey, RegistryValueName, RegistryValueData
)
| union
(
    DeviceRegistryEvents
    | where RegistryKey has_any (@"\CurrentVersion\Run", @"\CurrentVersion\RunOnce")
    | extend EventB_Time = Timestamp,
             FollowOnType = "Persistence",
             FileName = "",
             FolderPath = "",
             ProcessCommandLine = "",
             InitiatingProcessFileName = ""
    | project DeviceId, DeviceName, AccountName, InitiatingProcessAccountName,
              EventB_Time, FollowOnType, FileName, FolderPath, ProcessCommandLine,
              InitiatingProcessFileName, RegistryKey, RegistryValueName, RegistryValueData
);
let FollowOnBehavior =
CredentialAccess
| union isfuzzy=true Persistence;
DirectSecurityControlDegradation
| join kind=inner FollowOnBehavior on DeviceId
| where DirectDegradationObserved == true
| where EventA_Time <= EventB_Time and EventB_Time - EventA_Time <= TimeWindow
| where DeviceName !in (ApprovedSoftwareDeploymentHosts)
| where DeviceName !in (ApprovedMaintenanceHosts)
| where FileName !in (ApprovedSecurityTools)
| where FileName !in (ApprovedBackupAgents)
| extend RuleName = "Credential Access or Persistence After Endpoint Security-Control Degradation"
| extend Severity = "High"
| project RuleName, Severity, DeviceName, DeviceId, AccountName, InitiatingProcessAccountName,
          EventA_Time, EventB_Time, DegradationEvidence, FollowOnType,
          FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName,
          RegistryKey, RegistryValueName, RegistryValueData

Azure Rule Count

·        Azure S25 conditional rule count: 3

GCP

Detection Viability Assessment

·        No standard GCP S25 rule is included for this report.

·        GCP-native telemetry may identify management-plane activity, workload administration, OS configuration changes, instance metadata changes, service account activity, or suspicious administrative use, but GCP telemetry alone does not reliably confirm endpoint security-control degradation.

·        The core behavior evaluated in this report requires endpoint-level confirmation of protection-state change, service-control activity, registry or configuration modification, update-source manipulation, endpoint sensor health degradation, and same-host behavioral sequencing.

·        GCP may support a conditional cloud-native detection opportunity when management-plane activity can be correlated with endpoint-level evidence confirming security-control degradation.

Public Reporting Rationale

·        GCP Cloud Audit Logs, OS Config telemetry, Compute Engine activity, IAM activity, VPC Flow Logs, Cloud DNS logs, Security Command Center findings, and related telemetry can support investigation of suspicious administrative or post-compromise activity affecting cloud-hosted workloads.

·        GCP-native management-plane telemetry can show that administrative actions, OS configuration changes, metadata changes, service account activity, or remote workload-management actions occurred, but it does not independently prove that endpoint protection posture was degraded.

·        A cloud-only rule would risk inferring endpoint defense subversion from administrative or workload-management activity without confirming the endpoint outcome.

·        Because this report focuses on endpoint defense subversion and security-control degradation, GCP detections require endpoint telemetry or workload-level telemetry capable of confirming the security-control state change.

Cloud-Native Detection Opportunity

·        GCP management-plane or workload-management activity may be relevant when it targets GCP-hosted workloads and is followed by endpoint-confirmed security-control degradation.

·        Relevant GCP activity may include OS Config changes, instance metadata or startup-script modification, Compute Engine administrative actions, service account abuse, remote command workflows, or other authorized management-plane actions used to execute commands or alter workload state.

·        This opportunity is conditional because GCP telemetry must be paired with endpoint evidence showing protection-state reduction, endpoint security service manipulation, update-source manipulation, telemetry reduction, or endpoint sensor health degradation.

·        The detection must correlate the initiating GCP principal, management-plane action, target instance or workload, command or configuration content where available, endpoint execution evidence, and endpoint protection-state outcome.

Detection Role

·        GCP telemetry may support investigation of how an attacker used cloud management capabilities to reach or modify workloads.

·        GCP telemetry may provide useful context for initiating identity, source IP, management action, target workload, instance metadata activity, service account activity, remote configuration changes, and workload administration history.

·        GCP should not be used as the primary detection source for endpoint defense subversion unless endpoint outcome telemetry is integrated and confirms the security-control degradation.

·        GCP-native findings, cloud audit telemetry, network telemetry, or management-plane events should remain supporting evidence unless they are tied to directly observed endpoint security-control degradation.

·         

Rule Count

·        GCP S25 standard rule count: 0

·        GCP conditional detection opportunity: included as supporting cloud-management context only

S26 — Threat-to-Rule Traceability Matrix

Traceability Purpose

·        This section maps the endpoint defense subversion behaviors addressed in this report to the detection rules and supporting telemetry roles defined in the rule set.

·        The traceability model is behavior-based rather than vendor-based. Rules are mapped to observable adversary activity, not to exploit names, campaign labels, product names, or isolated configuration changes.

·        BlueHammer, RedSun, and UnDefend remain evidence anchors only. They are not used as detection keywords, campaign assumptions, or rule logic.

·        The primary traceability chain is suspicious privilege or administrative context, followed by measurable endpoint security-control degradation, followed by optional credential access, persistence, outbound communication, or cloud-management context.

Core Behavior 1 — Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition

Threat Behavior

·        An adversary gains or uses elevated, administrative, SYSTEM, service, remote management, or management-plane execution context and then reduces endpoint protection posture.

·        The degradation may affect real-time protection, behavior monitoring, cloud-delivered protection, sample submission, tamper protection, endpoint security service state, endpoint policy state, sensor health, telemetry forwarding, update behavior, or security-control configuration.

·        This behavior is the primary detection anchor because it captures defensive-control degradation after suspicious control over the endpoint.

Mapped Detection Rules

·        SentinelOne Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Splunk Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Elastic Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        QRadar Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Sigma Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Azure Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition.

Traceability Rationale

·        These rules map directly to the report’s central behavior chain: suspicious privilege or administrative context followed by measurable endpoint security-control degradation.

·        Each rule requires suspicious execution, administrative, or management context before the degradation event is treated as detection-relevant.

·        Each rule requires direct endpoint security-control degradation evidence rather than relying on product-name matching, update failure alone, network activity alone, cloud activity alone, or analyst inference after alert generation.

·        Azure is included only where endpoint outcome telemetry confirms the security-control degradation. Azure control-plane, identity, Intune, or Azure Arc telemetry alone is not sufficient.

Coverage Outcome

·        This behavior has the strongest coverage across endpoint-native telemetry, SIEM correlation, portable correlation templates, and Microsoft security telemetry.

·        Suricata, YARA, AWS, and GCP do not provide primary rule coverage for this behavior because they do not independently confirm endpoint protection-state degradation.

·        AWS and GCP may provide supporting management-plane context when correlated with endpoint-confirmed degradation.

Core Behavior 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Administrative Activity

Threat Behavior

·        An adversary uses suspicious local administrative activity or management-plane execution to impair endpoint security updates or manipulate security intelligence behavior.

·        The degradation may include update-source manipulation, update-policy downgrade, security intelligence refresh blocking, security intelligence age increase after local manipulation, or repeated update failure tied to local update-policy or update-source manipulation.

·        Update failure alone is not sufficient. The behavior becomes detection-relevant only when paired with suspicious administrative context or direct update-manipulation evidence.

Mapped Detection Rules

·        SentinelOne Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity.

·        Splunk Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity.

·        Elastic Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity.

·        QRadar Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity.

·        Sigma Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local Administrative Activity.

·        Azure Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local or Management-Plane Administrative Activity.

Traceability Rationale

·        These rules map to the degradation path where endpoint protection may remain nominally enabled but becomes less effective because security intelligence, update source, update policy, or refresh behavior is impaired.

·        The rules require suspicious administrative context and direct update-manipulation evidence.

·        The rules exclude update-failure-only and update-staleness-only logic because those conditions can occur during benign operational failures, maintenance windows, connectivity issues, or approved update management.

·        Azure Rule 2 extends this behavior to local or management-plane administrative activity only when endpoint update-manipulation evidence is available.

Coverage Outcome

·        This behavior has strong coverage in platforms that can correlate process execution, registry or policy telemetry, endpoint protection telemetry, and update-state telemetry.

·        QRadar and Sigma provide narrower coverage because successful deployment depends on backend correlation, field mapping, and reliable update-manipulation telemetry.

·        AWS and GCP remain supporting context only unless endpoint telemetry confirms that cloud-management activity produced endpoint update or protection degradation.

Core Behavior 3 — Credential Access After Endpoint Security-Control Degradation

Threat Behavior

·        An adversary reduces endpoint protection posture and then attempts credential access from the same host.

·        Relevant activity may include LSASS access, suspicious process handle access, dump creation, SAM or SECURITY hive access, credential enumeration, browser credential access, or credential-access tooling.

·        The detection value comes from ordered sequence: endpoint security-control degradation first, credential access behavior second.

Mapped Detection Rules

·        SentinelOne Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Splunk Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Elastic Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Azure Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

Traceability Rationale

·        These rules map to adversary objective behavior that becomes more significant after endpoint protection posture has been weakened.

·        The rules are not generic credential-access detections.

·        Prior directly observed endpoint security-control degradation is required before credential access behavior satisfies the intended detection chain.

·        The rule logic preserves the same-host or same-device relationship between degradation and follow-on credential activity.

Coverage Outcome

·        This behavior has strong coverage where endpoint telemetry includes protection-state changes, process access, credential-access artifacts, registry events, file events, and same-host correlation.

·        QRadar and Sigma do not include this as primary rule coverage because the longer multi-source sequence is less consistently deployable across those platforms.

·        Suricata, YARA, AWS, and GCP may support triage or enrichment but do not provide primary detection coverage for this behavior.

Core Behavior 4 — Persistence After Endpoint Security-Control Degradation

Threat Behavior

·        An adversary reduces endpoint protection posture and then establishes or modifies persistence on the same host.

·        Relevant persistence may include scheduled task creation, service creation, service binary path modification, registry autorun modification, WMI persistence, startup folder modification, logon script modification, or user-profile persistence.

·        The detection anchor is not persistence alone. The detection anchor is persistence after measurable endpoint security-control degradation.

Mapped Detection Rules

·        SentinelOne Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Splunk Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Elastic Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Azure Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

Traceability Rationale

·        These rules map to adversary attempts to preserve access after reducing defensive visibility or protection.

·        The rules avoid generic persistence alerting by requiring prior endpoint security-control degradation.

·        The detection chain prioritizes behavioral sequence over single persistence artifacts, tool labels, isolated registry changes, or isolated service changes.

·        The rules are strongest where file, registry, service-control, scheduled task, WMI, and endpoint protection-state telemetry are available.

Coverage Outcome

·        This behavior is covered by platforms with strong endpoint execution, file, registry, service, and persistence telemetry.

·        QRadar and Sigma are excluded from primary follow-on persistence coverage because consistently reliable long-chain correlation is harder to guarantee across those platforms.

·        YARA may enrich suspicious file or memory artifacts associated with persistence but does not observe the behavioral chain.

Core Behavior 5 — Endpoint Sensor Health Degradation or Telemetry Reduction

Threat Behavior

·        An adversary impairs endpoint visibility by degrading sensor health, reducing telemetry forwarding, disrupting agent communication, or causing endpoint protection reporting gaps.

·        This behavior may occur before, during, or after protection-state reduction.

·        Sensor degradation is most useful when correlated with suspicious execution, policy conflict, protection-state change, or follow-on objective activity.

Mapped Detection Rules

·        SentinelOne Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        SentinelOne Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Splunk Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Splunk Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        Elastic Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Elastic Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

·        QRadar Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Sigma Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege Transition.

·        Azure Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition.

·        Azure Rule 3 — Credential Access or Persistence After Endpoint Security-Control Degradation.

Traceability Rationale

·        Sensor health degradation is treated as endpoint security-control degradation when it is directly observable.

·        The rules avoid alerting on sensor silence alone.

·        The behavior must be tied to suspicious administrative context, direct degradation evidence, or follow-on objective activity.

·        This reduces the risk of treating normal agent outages, maintenance, migration, or troubleshooting as attacker-driven degradation without supporting context.

Coverage Outcome

·        Coverage is strongest in platforms that expose endpoint sensor state, endpoint protection state, service status, telemetry forwarding state, and agent health events.

·        Network, cloud, and artifact-only tools may indicate visibility gaps but cannot independently confirm endpoint sensor degradation as attacker-driven.

Core Behavior 6 — Cloud-Management Activity Associated With Endpoint Security-Control Degradation

Threat Behavior

·        An adversary uses cloud management capabilities to reach or modify a workload, and endpoint telemetry later confirms security-control degradation on that workload.

·        Relevant management activity may include remote command execution, automation execution, device-management scripts, instance metadata changes, startup-script changes, service account abuse, or cloud-hosted workload administration.

·        Cloud activity alone is not sufficient. Endpoint outcome confirmation is required.

Mapped Detection Rules and Supporting Context

·        Azure Rule 1 — Endpoint Security-Control Degradation Following Suspicious Privilege or Administrative Transition.

·        Azure Rule 2 — Security Intelligence Update Suppression or Update-Source Manipulation After Suspicious Local or Management-Plane Administrative Activity.

·        AWS — Supporting cloud-management detection context only.

·        GCP — Supporting cloud-management detection context only.

Traceability Rationale

·        Azure can provide conditional rule coverage when Defender for Endpoint, Microsoft Defender XDR, Intune, Entra ID, Azure Arc, Sentinel, and Windows endpoint telemetry are integrated and normalized.

·        AWS and GCP can support investigative context but do not independently confirm endpoint security-control degradation.

·        Cloud telemetry should be used to identify initiating principal, management action, target workload, command or configuration content where available, and timing relative to endpoint-confirmed degradation.

·        The report avoids cloud-control-plane-only inference because cloud telemetry alone cannot prove that endpoint protection posture was reduced.

Coverage Outcome

·        Azure provides conditional detection coverage because Microsoft endpoint and management telemetry can support same-device correlation when integrated.

·        AWS and GCP provide supporting context only.

·        No AWS-native or GCP-native primary detection rule is included for endpoint defense subversion without endpoint outcome telemetry.

Core Behavior 7 — Outbound Communication After Endpoint Security-Control Degradation

Threat Behavior

·        An adversary reduces endpoint protection posture and then initiates outbound communication for payload retrieval, command-and-control preparation, credential exfiltration, or lateral movement preparation.

·        Outbound behavior may include newly observed destinations, rare domains, suspicious DNS activity, low-reputation infrastructure, scripted web requests, or process-linked network connections after protection degradation.

Mapped Detection and Supporting Context

·        Suricata — Supporting network enrichment only.

·        Splunk Rule 3 — May support post-degradation investigation when network telemetry is correlated into the SIEM.

·        Elastic Rule 3 — May support post-degradation investigation when process-to-network telemetry is available.

·        Azure Rule 3 — May support post-degradation investigation when Defender or Sentinel telemetry links follow-on activity to the degraded device.

Traceability Rationale

·        Network telemetry is useful for triage and scope development but does not directly prove endpoint security-control degradation.

·        Suricata is not included as a primary rule platform for this behavior because the report’s central detection requirement is endpoint outcome confirmation.

·        Network evidence should be treated as supporting context after endpoint degradation is observed.

Coverage Outcome

·        Outbound communication has enrichment value but is not a primary detection anchor for this report.

·        Process-to-network mapping strengthens investigation quality where available.

·        Network-only detection remains insufficient for the core behavior.

Core Behavior 8 — Suspicious File, Memory, or Artifact Discovery After Endpoint Security-Control Degradation

Threat Behavior

·        An adversary may stage tools, payloads, scripts, loaders, credential-access utilities, persistence files, or memory-resident artifacts after weakening endpoint protection.

·        These artifacts may be useful for triage, malware classification, or post-detection investigation.

·        Artifact matching alone does not establish endpoint defense subversion.

Mapped Detection and Supporting Context

·        YARA — Supporting artifact enrichment only.

·        SentinelOne Rule 3 — May identify suspicious file, credential-access, or persistence behavior after degradation.

·        Splunk Rule 3 — May identify suspicious file, registry, credential-access, or persistence artifacts after degradation.

·        Elastic Rule 3 — May identify suspicious file, registry, credential-access, or persistence artifacts after degradation.

·        Azure Rule 3 — May identify suspicious file, registry, credential-access, or persistence artifacts after degradation.

Traceability Rationale

·        YARA may support malware triage, suspicious file classification, memory scanning, or artifact enrichment.

·        YARA is not used as a primary rule for endpoint defense subversion because it does not independently observe privilege context, protection-state transitions, service-control changes, registry or policy manipulation, update-source manipulation, or same-host behavioral sequencing.

·        Artifact evidence becomes more useful after endpoint telemetry confirms degradation.

Coverage Outcome

·        Artifact coverage is supportive rather than primary.

·        YARA should not be used to detect BlueHammer, RedSun, or UnDefend by keyword, label, proof-of-concept string, or assumed artifact.

·        Endpoint telemetry remains required to establish the behavior chain.

Platform Traceability Summary

Suricata

·        Primary detection coverage is not included.

·        Suricata supports network enrichment after endpoint-confirmed degradation.

·        Suricata may help investigate outbound activity, payload staging, unusual DNS activity, or command-and-control indicators.

·        Suricata does not independently confirm endpoint security-control degradation.

SentinelOne

·        SentinelOne provides primary coverage for endpoint degradation after suspicious privilege transition.

·        SentinelOne provides primary coverage for update suppression after suspicious local administrative activity.

·        SentinelOne provides primary coverage for credential access or persistence after endpoint degradation.

·        SentinelOne offers strong endpoint-native traceability across the primary behavior chain and follow-on objective activity when protection-state telemetry is available.

Splunk

·        Splunk provides primary coverage for endpoint degradation after suspicious privilege transition.

·        Splunk provides primary coverage for update suppression after suspicious local administrative activity.

·        Splunk provides primary coverage for credential access or persistence after endpoint degradation.

·        Splunk provides strong SIEM correlation coverage when endpoint, registry, service, update, and device-management telemetry are normalized.

Elastic

·        Elastic provides primary coverage for endpoint degradation after suspicious privilege transition.

·        Elastic provides primary coverage for update suppression after suspicious local administrative activity.

·        Elastic provides primary coverage for credential access or persistence after endpoint degradation.

·        Elastic provides strong sequence coverage when Elastic Defend, ECS mappings, endpoint, registry, service, update, and policy telemetry are available.

QRadar

·        QRadar provides primary coverage for endpoint degradation after suspicious privilege transition.

·        QRadar provides primary coverage for update suppression after suspicious local administrative activity.

·        Primary follow-on credential access or persistence coverage is not included for QRadar.

·        QRadar provides focused coverage for the strongest behavior chains where parsing, custom properties, reference sets, and same-host correlation are reliable.

Sigma

·        Sigma provides portable correlation-package coverage for endpoint degradation after suspicious privilege transition.

·        Sigma provides portable correlation-package coverage for update suppression after suspicious local administrative activity.

·        Primary follow-on credential access or persistence coverage is not included for Sigma.

·        Sigma coverage depends on backend support for same-host temporal correlation, field mapping, and direct endpoint degradation evidence.

YARA

·        Primary detection coverage is not included.

·        YARA supports file, memory, and artifact enrichment after endpoint-confirmed degradation.

·        YARA may assist with malware triage, suspicious file classification, memory scanning, or payload review.

·        YARA does not independently confirm endpoint security-control degradation.

AWS

·        Primary detection coverage is not included.

·        AWS supports cloud-management context when AWS activity targets a workload later confirmed by endpoint telemetry to have degraded security controls.

·        AWS may help identify initiating principal, source IP, management action, target workload, session activity, command execution, and automation history.

·        AWS does not independently confirm endpoint security-control degradation.

Azure

·        Azure provides conditional primary coverage for endpoint degradation after suspicious privilege or administrative transition.

·        Azure provides conditional primary coverage for update suppression after suspicious local or management-plane administrative activity.

·        Azure provides conditional primary coverage for credential access or persistence after endpoint degradation.

·        Azure coverage depends on integration and normalization across Defender for Endpoint, Defender XDR, Sentinel, Intune, Entra ID, Azure Arc, Windows, and endpoint telemetry.

GCP

·        Primary detection coverage is not included.

·        GCP supports cloud-management context when GCP activity targets a workload later confirmed by endpoint telemetry to have degraded security controls.

·        GCP may help identify initiating principal, management action, target workload, instance metadata activity, service account activity, remote configuration changes, and workload administration history.

·        GCP does not independently confirm endpoint security-control degradation.

Traceability Constraints

·        No detection rule should depend on the output of another rule.

·        No detection rule should depend on BlueHammer, RedSun, or UnDefend terminology.

·        No detection rule should infer endpoint security-control degradation from cloud activity, network activity, artifact matching, update failure, service restart, or sensor silence alone.

·        No detection rule should treat endpoint security-control degradation as malicious without suspicious privilege, administrative, execution, policy, or follow-on context.

·        No detection rule should use post-alert analyst judgment as part of detection logic.

·        Each deployable rule must include observable telemetry inputs, same-host or same-device correlation, bounded timing, environment-specific baselines, and allowlisting logic.

Traceability Summary

·        The strongest rule coverage maps to endpoint security-control degradation after suspicious privilege or administrative activity.

·        Update suppression is covered where update-source or update-policy manipulation can be correlated with suspicious local or management-plane activity.

·        Credential access and persistence are covered only when they occur after directly observed endpoint security-control degradation.

·        Suricata, YARA, AWS, and GCP provide supporting investigative context rather than primary endpoint defense subversion detection.

·        Azure provides conditional coverage because Microsoft endpoint, identity, device-management, and Defender telemetry can support same-device behavior-chain correlation when integrated.

·        The rule set remains durable beyond the Microsoft Defender examples because the traceability model is built around endpoint security-control degradation behavior rather than exploit names, vendor labels, or campaign assumptions.

S27 — Behavior & Log Artifacts

Behavior Artifact Overview

·        Endpoint defense subversion produces observable artifacts when suspicious administrative activity, endpoint security-control changes, update manipulation, service-control activity, registry modification, sensor-health degradation, credential access, or persistence activity can be correlated on the same host.

·        The most important artifacts are ordered evidence points showing that suspicious execution or administrative control was followed by measurable endpoint protection degradation.

·        BlueHammer, RedSun, and UnDefend remain contextual evidence anchors only. Artifact collection should not depend on those names appearing in logs, filenames, detections, threat labels, or intelligence reporting.

·        Artifact review should prioritize host identity, account identity, process identity, command line, parent process, affected security setting, protection-state transition, service action, registry path, update behavior, endpoint class, management source, and event timing.

Primary Behavior Artifacts

·        Suspicious administrative process execution involving PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tooling, endpoint-management tooling, or renamed administrative binaries.

·        Abnormal parent-child process relationships where user-facing applications, browsers, Office processes, archive utilities, script hosts, remote access tools, or exploitation-adjacent processes launch administrative tooling.

·        Administrative execution from user-writable paths, temporary directories, download directories, archive-extraction paths, public directories, administrative shares, removable media, staging directories, or non-standard tooling paths.

·        Privilege or administrative context changes, including local administrator use, privileged group activity, SYSTEM-context execution, service-context execution, remote administrative execution, token elevation, or suspicious use of privileged accounts.

·        Endpoint protection-state changes affecting real-time protection, behavior monitoring, cloud-delivered protection, sample submission, tamper protection, remediation behavior, telemetry forwarding, sensor health, or endpoint security-control posture.

·        Security-control configuration changes involving protection policy, exclusion policy, update source, update cadence, service state, telemetry state, device-management posture, or endpoint security baseline drift.

·        Security intelligence or update manipulation involving update-source changes, update-policy changes, security intelligence refresh blocking, abnormal security intelligence age, or repeated update failure tied to local manipulation.

·        Follow-on credential access, persistence, discovery, lateral movement preparation, or outbound communication after endpoint security-control degradation.

Process Execution Artifacts

·        Process name.

·        Process path.

·        Process command line.

·        Parent process name.

·        Parent process command line.

·        Grandparent process where available.

·        Process hash.

·        Process signer.

·        Process integrity level where available.

·        Process elevation context.

·        Process creation time.

·        Process termination time where available.

·        Process GUID or equivalent execution identifier where available.

·        Storyline, process tree, or entity graph identifier where available.

·        User account associated with process execution.

·        Effective user context where available.

·        Host identifier and endpoint class.

Privilege and Account Artifacts

·        Local administrator activity.

·        Privileged group membership changes.

·        Privileged logon sessions.

·        Remote administrative logons.

·        Service account execution.

·        SYSTEM-context execution.

·        Scheduled task context.

·        Service-context execution.

·        Token elevation indicators.

·        Unusual administrator use from unexpected host, user, time, or source.

·        Break-glass account use.

·        Endpoint-management account use.

·        Account-to-host mismatch or anomalous administrative scope.

·        Initiating account for endpoint security-control changes where available.

·        Effective account for resulting service, policy, update, or protection-state changes.

Endpoint Protection-State Artifacts

·        Protection enabled or disabled state.

·        Real-time protection status.

·        Behavior monitoring status.

·        Cloud-delivered protection status.

·        Sample submission status.

·        Tamper protection status.

·        Remediation behavior status.

·        Endpoint protection policy state.

·        Endpoint sensor health state.

·        Endpoint agent connected or disconnected state.

·        Telemetry forwarding status.

·        Protection reporting state.

·        Last policy check-in time.

·        Last successful management check-in time.

·        Endpoint protection service state.

·        Previous value and new value for affected settings where available.

·        Management source for the change where available.

·        Initiating process and initiating account for the change where available.

Registry and Configuration Artifacts

·        Registry key path.

·        Registry value name.

·        Previous registry value where available.

·        New registry value.

·        Registry action type.

·        Initiating process.

·        Initiating account.

·        Host identity.

·        Timestamp.

·        Endpoint protection configuration path.

·        Exclusion policy path.

·        Update configuration path.

·        Service configuration path.

·        Policy enforcement path.

·        Tamper protection or security-control posture path.

·        Device-management policy identifier where available.

·        Local policy conflict with centrally approved posture where available.

Service-Control Artifacts

·        Service name.

·        Service display name.

·        Service action.

·        Previous service state where available.

·        New service state.

·        Startup type change.

·        Service stop event.

·        Service disablement event.

·        Service restart failure.

·        Service recovery configuration change.

·        Service binary path modification.

·        Initiating process.

·        Initiating account.

·        Host identity.

·        Timestamp.

·        Endpoint protection service affected.

·        EDR or sensor service affected.

·        Security telemetry or update service affected.

Security Intelligence and Update Artifacts

·        Update source.

·        Update policy.

·        Update channel.

·        Signature version.

·        Engine version.

·        Platform version.

·        Last successful update time.

·        Security intelligence age.

·        Update failure reason where available.

·        Repeated update failure.

·        Update-source manipulation.

·        Update-policy manipulation.

·        Security intelligence refresh blocking.

·        Local update-policy or update-source manipulation evidence.

·        Initiating process where available.

·        Initiating account where available.

·        Management source where available.

·        Endpoint class and expected update cadence.

Sensor Health and Telemetry Artifacts

·        Agent health state.

·        Sensor connected or disconnected state.

·        Delayed endpoint check-in.

·        Telemetry forwarding reduction.

·        Policy application failure.

·        Protection reporting gap.

·        Endpoint communication impairment.

·        Endpoint sensor restart or crash where available.

·        Endpoint sensor service state.

·        Management console visibility state.

·        EDR or endpoint telemetry gap beginning after suspicious execution.

·        Endpoint class and expected sensor health baseline.

·        Last known healthy state.

·        First observed degraded state.

Credential Access Artifacts

·        LSASS access.

·        Suspicious process handle access.

·        Memory read behavior where available.

·        Dump file creation.

·        SAM hive access.

·        SECURITY hive access.

·        Browser credential access.

·        Credential enumeration.

·        Credential tooling command-line indicators.

·        Source process.

·        Target process.

·        Access rights where available.

·        File path for dump or credential artifact.

·        Registry path for hive access.

·        User account.

·        Host identity.

·        Timestamp.

·        Prior endpoint security-control degradation on the same host.

Persistence Artifacts

·        Scheduled task creation.

·        Scheduled task modification.

·        Service creation.

·        Service binary path modification.

·        Service recovery modification.

·        Registry autorun creation or modification.

·        Startup folder modification.

·        WMI event subscription.

·        Script-based persistence.

·        Logon script modification.

·        User-profile persistence.

·        Creating process.

·        Modifying process.

·        Associated account.

·        Persistence path.

·        File hash where available.

·        File signer where available.

·        Timestamp.

·        Prior endpoint security-control degradation on the same host.

Network and Outbound Communication Artifacts

·        Destination domain.

·        Destination IP address.

·        Destination URL where available.

·        DNS query.

·        Connection timestamp.

·        Source process where available.

·        Source user where available.

·        Source host.

·        Destination reputation context where available.

·        First-seen destination timing.

·        Rare or host-role-inconsistent destination.

·        Scripted outbound request.

·        Payload retrieval indicator.

·        Command-and-control preparation indicator.

·        Outbound communication after endpoint security-control degradation.

·        Network evidence must remain supporting context unless tied to host-level endpoint degradation.

Cloud and Management-Plane Artifacts

·        Cloud principal.

·        Source IP address.

·        Management-plane action.

·        Target workload or instance.

·        Remote command execution event.

·        Automation execution event.

·        Device-management script execution.

·        Instance metadata modification.

·        Startup-script modification.

·        Service account activity.

·        Session activity.

·        Command content where available.

·        Policy assignment or policy change.

·        Target endpoint identity.

·        Correlated endpoint execution event.

·        Correlated endpoint protection-state outcome.

·        Cloud telemetry must not be treated as proof of endpoint security-control degradation without endpoint confirmation.

Artifact Collection Priorities

·        Collect process tree and command-line history surrounding the first suspicious administrative execution.

·        Collect endpoint protection-state changes before and after the suspicious activity.

·        Collect registry, service-control, update, policy, and sensor-health events associated with the affected endpoint.

·        Collect account and privilege context for the initiating user, effective user, service context, and management source.

·        Collect endpoint-management and policy telemetry to determine whether the change was approved, centrally managed, maintenance-related, migration-related, or locally initiated.

·        Collect follow-on credential access, persistence, discovery, outbound communication, and lateral movement evidence after the degradation event.

·        Preserve timestamp ordering across all telemetry sources before drawing conclusions about sequence.

Artifact Usage Constraints

·        Do not treat BlueHammer, RedSun, or UnDefend terminology as required artifacts.

·        Do not treat update failure alone as evidence of endpoint defense subversion.

·        Do not treat service restart alone as evidence of endpoint defense subversion.

·        Do not treat network activity alone as evidence of endpoint defense subversion.

·        Do not treat sensor silence alone as evidence of endpoint defense subversion.

·        Do not treat cloud activity alone as evidence of endpoint defense subversion.

·        Do not treat file or memory artifact matching alone as evidence of endpoint defense subversion.

·        Artifacts must be evaluated in sequence and tied to host, account, process, affected setting, and event timing.

Behavior and Log Artifact Summary

·        The strongest artifacts are those that show suspicious administrative execution followed by direct endpoint security-control degradation.

·        Update-related artifacts become high-value only when tied to local manipulation, suspicious administrative context, or endpoint-confirmed degradation.

·        Credential access, persistence, network, cloud, and artifact evidence are strongest when observed after endpoint protection posture has been reduced.

·        The artifact model remains durable because it focuses on behavior, telemetry, and sequence rather than vendor labels, exploit names, or campaign assumptions.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

SOC Implementation Objective

·        The SOC objective is to detect endpoint defense subversion through chained behavioral evidence rather than isolated endpoint product events.

·        Analysts should validate whether suspicious privilege, administrative, local execution, or management-plane activity preceded endpoint security-control degradation.

·        Alert handling should focus on confirming the endpoint outcome, determining whether the change was authorized, identifying follow-on adversary objectives, and restoring endpoint protection posture.

·        The SOC workflow should treat endpoint protection degradation as a high-priority investigation point when it occurs after suspicious execution or administrative activity.

Initial Alert Review

·        Confirm the alerting platform and rule name.

·        Confirm the affected host or device.

·        Confirm the endpoint class, such as workstation, server, domain controller, privileged access workstation, developer endpoint, cloud workload, or high-value asset.

·        Confirm the initiating account.

·        Confirm the effective account where available.

·        Confirm whether the activity occurred under user, administrator, service, SYSTEM, remote management, or management-plane context.

·        Confirm the first suspicious execution event.

·        Confirm the endpoint security-control degradation event.

·        Confirm the event ordering and bounded time window.

·        Confirm whether the endpoint protection-state change is directly observable.

·        Confirm whether the alert depends on a valid behavior chain rather than a single suspicious artifact.

Endpoint Protection-State Validation

·        Determine which security control changed.

·        Determine the previous value where available.

·        Determine the new value.

·        Determine whether protection was reduced, disabled, weakened, bypassed, excluded, downgraded, or made less observable.

·        Determine whether the endpoint sensor health changed.

·        Determine whether telemetry forwarding was reduced.

·        Determine whether the endpoint protection service was stopped, disabled, or modified.

·        Determine whether update source, update policy, or security intelligence behavior changed.

·        Determine whether the change matches approved centralized policy.

·        Determine whether the change conflicts with expected endpoint class posture.

Administrative Context Review

·        Determine whether the initiating account was expected to perform endpoint-security configuration changes.

·        Determine whether the activity came from an approved endpoint-management platform.

·        Determine whether the activity occurred during an approved maintenance window.

·        Determine whether the action aligns with security engineering, help desk, vendor support, migration, recovery, or break-glass activity.

·        Determine whether a user-facing application spawned administrative tooling.

·        Determine whether the process executed from a suspicious path.

·        Determine whether the account recently changed privilege context.

·        Determine whether remote administrative tooling, cloud-management tooling, or device-management automation was involved.

·        Determine whether a service account or SYSTEM context was used in a way consistent with approved management workflows.

Process Tree Reconstruction

·        Reconstruct the process tree beginning with the earliest suspicious parent process.

·        Identify process name, process path, command line, parent process, parent command line, signer, hash, account, and timestamp.

·        Identify whether administrative utilities were launched from suspicious ancestry or suspicious paths.

·        Identify whether the process chain includes PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tooling, or renamed binaries.

·        Identify whether the process chain was linked to exploitation-adjacent activity, document handling, browser activity, archive extraction, remote access tooling, or user-facing application execution.

·        Identify whether follow-on process activity indicates credential access, persistence, discovery, lateral movement preparation, or outbound communication.

Update Suppression Triage

·        Do not triage update failure alone as confirmed endpoint defense subversion.

·        Determine whether update-source manipulation occurred.

·        Determine whether update-policy manipulation occurred.

·        Determine whether security intelligence refresh was blocked.

·        Determine whether security intelligence age increased after suspicious local manipulation.

·        Determine whether repeated update failure followed update-policy or update-source manipulation.

·        Determine whether approved patch management, maintenance, update-channel change, endpoint migration, or vendor support activity explains the behavior.

·        Determine whether the same host shows suspicious administrative execution before the update manipulation.

·        Determine whether the same host later shows credential access, persistence, sensor degradation, or outbound activity.

Credential Access and Persistence Triage

·        Treat credential access and persistence as higher priority when they occur after endpoint security-control degradation.

·        Determine whether LSASS access, dump creation, SAM or SECURITY hive access, browser credential access, credential enumeration, or credential tooling occurred.

·        Determine whether scheduled task creation, service creation, service modification, registry autorun modification, WMI persistence, startup folder modification, logon script modification, or user-profile persistence occurred.

·        Determine whether the follow-on activity occurred on the same host after the degradation event.

·        Determine whether the activity aligns with approved security tooling, backup tooling, software deployment, administrator maintenance, recovery workflow, or endpoint-management activity.

·        Do not treat generic credential access or persistence as part of this behavior chain unless endpoint security-control degradation occurred first.

Cloud-Management Triage

·        Treat AWS and GCP telemetry as supporting management-plane context unless endpoint telemetry confirms protection degradation.

·        Treat Azure management-plane, identity, Intune, and Azure Arc telemetry as supporting context unless endpoint outcome telemetry confirms protection degradation.

·        Determine whether a cloud principal performed remote command execution, automation, device-management scripting, metadata modification, startup-script modification, or workload administration.

·        Determine whether the target workload later produced endpoint-confirmed protection-state degradation.

·        Determine whether the command, script, automation, or configuration content is available.

·        Determine whether the management-plane activity was approved, scheduled, scoped, and consistent with expected administrative behavior.

·        Do not infer endpoint defense subversion from cloud activity alone.

Network and Artifact Triage

·        Treat network telemetry as supporting context unless tied to endpoint-confirmed degradation.

·        Determine whether outbound communication occurred after endpoint protection posture was reduced.

·        Identify rare, newly observed, low-reputation, or host-role-inconsistent destinations.

·        Determine whether process-to-network mapping links outbound communication to suspicious execution.

·        Treat YARA, file, and memory findings as artifact enrichment unless endpoint telemetry confirms the behavior chain.

·        Determine whether suspicious files, payloads, scripts, loaders, credential tools, or persistence artifacts appeared after the degradation event.

·        Do not infer endpoint defense subversion from artifact matching alone.

Containment Guidance

·        Preserve evidence before remediation where operationally feasible.

·        Isolate the host if endpoint protection degradation is confirmed and suspicious follow-on activity is present.

·        Restore endpoint protection settings to expected managed posture.

·        Re-enable disabled services, telemetry forwarding, sensor communication, and update behavior.

·        Remove unauthorized exclusions, policy downgrades, and update-source modifications.

·        Validate that tamper protection, behavior monitoring, cloud-delivered protection, sample submission, remediation behavior, and update cadence are restored.

·        Rotate or invalidate credentials if credential access occurred after degradation.

·        Review lateral movement from the affected host.

·        Review administrative account usage and service account exposure.

·        Confirm the endpoint has resumed normal telemetry and management check-in behavior.

·        Conduct targeted hunts for the same behavior chain across similar endpoint classes.

Escalation Criteria

·        Escalate immediately when endpoint security-control degradation follows suspicious privilege transition on a high-value asset.

·        Escalate immediately when credential access follows endpoint protection degradation.

·        Escalate immediately when persistence follows endpoint protection degradation.

·        Escalate immediately when multiple hosts show similar degradation patterns.

·        Escalate immediately when cloud-management activity is tied to endpoint-confirmed degradation on a production workload.

·        Escalate immediately when endpoint sensor health or telemetry forwarding is degraded after suspicious activity.

·        Escalate when approved management sources cannot explain the protection-state change.

·        Escalate when the initiating account is privileged, newly elevated, anomalous, or associated with multiple affected hosts.

False Positive Management

·        Maintain approved administrator lists.

·        Maintain approved endpoint-management platform lists.

·        Maintain approved service account lists.

·        Maintain approved maintenance windows.

·        Maintain approved security engineering scripts.

·        Maintain approved vendor support workflows.

·        Maintain endpoint migration and recovery workflow documentation.

·        Maintain approved patch-management and update-source baselines.

·        Maintain endpoint class posture baselines.

·        Maintain known-good service state, update cadence, sensor health, and policy-state baselines.

·        Tune detections by endpoint class, business function, management source, and approved operational workflow.

·        Do not suppress broadly based only on administrator status. Administrator activity should still be validated against context, timing, host scope, and expected workflow.

Post-Incident Detection Improvement

·        Identify telemetry gaps encountered during investigation.

·        Identify missing command-line, process-chain, registry, service-control, update, sensor-health, or device-management fields.

·        Identify correlation failures caused by host identity mismatch, timestamp inconsistency, or incomplete account context.

·        Update allowlists only when the activity is confirmed benign and expected.

·        Add new approved workflows to baselines when operationally justified.

·        Add new suspicious paths, parent processes, or management paths when they reflect attacker behavior.

·        Expand endpoint protection-state visibility where degradation could not be confirmed.

·        Validate that rules remain behavior-based and do not drift into single-artifact matching.

SOC Implementation Summary

·        SOC implementation should prioritize sequence validation, endpoint outcome confirmation, and authorized-management review.

·        The highest-priority incidents are those where suspicious administrative activity is followed by measurable endpoint security-control degradation and then credential access, persistence, or lateral movement preparation.

·        Cloud, network, and artifact telemetry should strengthen investigation but should not replace endpoint outcome evidence.

·        Containment should focus on restoring protection posture, preserving evidence, identifying follow-on objectives, and preventing repeated degradation across similar hosts.

S29 — Detection Coverage Summary

Coverage Summary Overview

·        Detection coverage is strongest for endpoint security-control degradation when endpoint execution telemetry, protection-state telemetry, registry or configuration telemetry, service-control telemetry, update telemetry, device-management context, and same-host correlation are available.

·        The highest-value coverage comes from rules that detect suspicious privilege or administrative activity followed by direct endpoint protection degradation.

·        Coverage is moderate for update suppression because update behavior has greater benign operational overlap and requires reliable separation between routine update failure and local manipulation.

·        Coverage is conditional for credential access and persistence because these behaviors must occur after endpoint security-control degradation to support the report’s detection thesis.

·        Coverage is supporting rather than primary for network, cloud, file, memory, and artifact telemetry unless correlated with endpoint-confirmed degradation.

Strongest Coverage Areas

·        Suspicious privilege transition followed by endpoint security-control degradation.

·        Local administrative activity followed by protection-state reduction.

·        Security-control configuration tampering with suspicious execution context.

·        Endpoint protection service stop, disablement, startup-type modification, or service-state change after suspicious execution.

·        Endpoint sensor health degradation or telemetry forwarding reduction after suspicious administrative activity.

·        Security intelligence update-source or update-policy manipulation after suspicious local administrative activity.

·        Credential access after endpoint security-control degradation.

·        Persistence after endpoint security-control degradation.

·        Microsoft security telemetry correlation when endpoint, identity, device-management, Defender, and Windows telemetry are integrated.

Moderate Coverage Areas

·        Update suppression where update telemetry is incomplete, inconsistently mapped, or not tied to initiating process and account.

·        Broad exclusion creation where approved security administration and attacker activity overlap.

·        Sensor health degradation where agent outages, migration, recovery, or maintenance may create benign explanations.

·        Management-plane activity where endpoint outcome telemetry confirms degradation but identity or device mapping requires normalization.

·        SIEM correlation where source coverage is strong but field extraction, timestamp normalization, or host identity mapping varies.

·        Portable Sigma correlation where backend support for temporal sequence logic and endpoint-state fields varies.

·        QRadar correlation where custom properties, parsing, and reference sets are required for reliable deployment.

Limited or Supporting Coverage Areas

·        Network-only detection.

·        Cloud-control-plane-only detection.

·        File or memory artifact matching without endpoint outcome confirmation.

·        YARA-based artifact enrichment without endpoint behavior correlation.

·        Generic update failure.

·        Isolated service restart.

·        Sensor silence without suspicious context.

·        Standalone outbound communication.

·        Standalone credential access or persistence without prior endpoint security-control degradation.

·        Exploit-name, campaign-name, or vendor-label matching.

Platform Coverage Summary

Suricata

·        Suricata provides supporting network visibility only.

·        Suricata can support investigation of outbound activity, payload retrieval, unusual DNS activity, and command-and-control preparation after endpoint-confirmed degradation.

·        Suricata does not provide primary coverage for endpoint defense subversion because it does not independently observe endpoint protection-state changes.

SentinelOne

·        SentinelOne provides strong endpoint-native coverage for suspicious privilege activity followed by endpoint security-control degradation.

·        SentinelOne provides strong coverage for update manipulation when update telemetry or enrichment is available.

·        SentinelOne provides strong follow-on coverage for credential access or persistence after endpoint degradation.

·        Coverage depends on endpoint protection-state visibility, Deep Visibility field availability, agent-health telemetry, and environment-specific allowlists.

Splunk

·        Splunk provides strong correlation coverage when endpoint, Windows, Defender, EDR, registry, service-control, update, and device-management telemetry are onboarded and normalized.

·        Splunk is well suited for same-host sequence detection across multiple telemetry sources.

·        Coverage depends on source consistency, field extraction quality, timestamp normalization, host normalization, and lookup maintenance.

Elastic

·        Elastic provides strong EQL sequence coverage when Elastic Defend, Windows, Defender, registry, service-control, update, endpoint protection, and policy telemetry are mapped consistently.

·        Elastic supports behavior-chain detection through same-host sequence logic.

·        Coverage depends on ECS mapping quality, index availability, Elastic Defend visibility, endpoint integration depth, and exception-list quality.

QRadar

·        QRadar provides focused coverage for endpoint degradation after suspicious administrative activity and update manipulation after suspicious local administrative activity.

·        QRadar does not include primary follow-on credential access or persistence coverage for this report.

·        Coverage depends on parsing, custom properties, reference sets, normalized host identity, and sequence implementation.

Sigma

·        Sigma provides portable correlation-package coverage for the two strongest behavior chains.

·        Sigma does not include primary follow-on credential access or persistence coverage for this report.

·        Coverage depends on backend translation, field mapping, temporal sequence support, endpoint-state visibility, and backend-specific exception handling.

YARA

·        YARA provides supporting artifact enrichment only.

·        YARA may support malware triage, memory scanning, suspicious file classification, and payload review.

·        YARA does not provide primary coverage for endpoint defense subversion because it does not observe privilege context, protection-state changes, service-control activity, registry or policy manipulation, update-source manipulation, or same-host sequence behavior.

AWS

·        AWS provides supporting cloud-management context only.

·        AWS may help identify management-plane activity, Systems Manager activity, automation execution, Session Manager activity, EC2 user-data modification, instance profile abuse, and workload administration.

·        AWS does not independently confirm endpoint security-control degradation.

·        Coverage requires endpoint telemetry to confirm the security-control outcome.

Azure

·        Azure provides conditional primary coverage when Microsoft Defender for Endpoint, Defender XDR, Sentinel, Intune, Entra ID, Azure Arc, Windows, and endpoint telemetry are integrated and normalized.

·        Azure can support endpoint degradation, update manipulation, and credential access or persistence after endpoint degradation.

·        Azure control-plane, identity, Intune, or Azure Arc activity alone is not sufficient without endpoint outcome confirmation.

GCP

·        GCP provides supporting cloud-management context only.

·        GCP may help identify Cloud Audit activity, OS Config activity, Compute Engine administrative actions, instance metadata changes, service account activity, and workload administration.

·        GCP does not independently confirm endpoint security-control degradation.

·        Coverage requires endpoint telemetry to confirm the security-control outcome.

Coverage Gaps

·        Missing endpoint protection-state telemetry prevents confirmation that the core degradation behavior occurred.

·        Missing command-line telemetry weakens the ability to distinguish suspicious administrative activity from legitimate administration.

·        Missing parent-child process telemetry weakens process-chain reconstruction.

·        Missing registry telemetry limits visibility into direct configuration manipulation, exclusion changes, and update-source modification.

·        Missing service-control telemetry limits visibility into service stop, disablement, startup-type change, and recovery manipulation.

·        Missing update telemetry limits detection of security intelligence suppression and update-source manipulation.

·        Missing device-management telemetry increases false positives by obscuring approved policy deployment, migration, troubleshooting, and recovery workflows.

·        Missing sensor health telemetry can hide endpoint visibility reduction.

·        Missing timestamp normalization can break ordered sequence detection.

·        Missing host identity normalization can prevent same-host correlation.

·        Missing account context can obscure whether the activity came from an expected administrator, service account, compromised identity, or SYSTEM context.

Coverage Improvement Priorities

·        Improve endpoint protection-state telemetry.

·        Improve command-line and process-chain visibility.

·        Improve registry and configuration-change visibility.

·        Improve service-control and sensor-health visibility.

·        Improve update-source, update-policy, and security intelligence telemetry.

·        Improve device-management and policy-change context.

·        Improve host identity normalization across endpoint, SIEM, EDR, cloud, and device-management sources.

·        Improve account identity normalization across local, domain, service, privileged, and cloud identities.

·        Improve timestamp consistency across telemetry sources.

·        Improve baselines for endpoint class, expected security posture, approved administrators, management platforms, update sources, maintenance windows, and recovery workflows.

Coverage Summary

·        Primary detection coverage is strongest where endpoint telemetry can show both suspicious execution context and direct security-control degradation.

·        Update suppression coverage is strong only when update manipulation can be distinguished from routine operational failure.

·        Credential access and persistence coverage is strongest when those behaviors occur after endpoint protection posture has been reduced.

·        Suricata, YARA, AWS, and GCP support investigation but do not independently confirm endpoint defense subversion.

·        The coverage model is durable because it is based on endpoint behavior chains rather than vendor-specific labels, exploit names, or campaign assumptions.

S30 — Intelligence Maturity Assessment

Assessment Overview

·        Intelligence maturity for this behavior class depends on an organization’s ability to connect endpoint execution, privilege context, protection-state change, update behavior, device-management activity, sensor health, and follow-on adversary objectives into a coherent behavior chain.

·        Mature detection programs should be able to distinguish attacker-driven endpoint security-control degradation from approved administration, endpoint migration, recovery workflows, vendor support, patch management, and maintenance activity.

·        Maturity is not determined by the presence of one endpoint product or SIEM. Maturity is determined by telemetry completeness, normalization quality, baseline quality, correlation reliability, triage repeatability, and continuous improvement.

·        The behavior class is durable because endpoint defense subversion can occur across different endpoint products, management platforms, and cloud-hosted workloads.

Current Maturity Posture

·        The current detection model is behaviorally mature because it focuses on ordered security-control degradation rather than exploit-name or vendor-label matching.

·        The rule set provides strong coverage for the highest-value behavior chain: suspicious administrative activity followed by direct endpoint security-control degradation.

·        The rule set provides meaningful coverage for update suppression when update-source or update-policy manipulation can be tied to suspicious administrative activity.

·        The rule set provides conditional coverage for credential access and persistence when those behaviors occur after endpoint degradation.

·        Cloud, network, and artifact telemetry are correctly treated as supporting context unless endpoint outcome telemetry confirms degradation.

·        The primary maturity dependency is telemetry quality rather than analytical relevance.

Maturity Strengths

·        Detection logic is anchored to observable behavior chains.

·        Rules avoid reliance on BlueHammer, RedSun, UnDefend, campaign assumptions, exploit names, or vendor-only labels.

·        Rules avoid update-failure-only, network-only, cloud-only, artifact-only, and sensor-silence-only logic.

·        Endpoint-native and SIEM-based platforms provide strong coverage where telemetry is available.

·        Azure provides conditional coverage where Microsoft endpoint, identity, device-management, and Defender telemetry are integrated.

·        Suricata, YARA, AWS, and GCP are correctly positioned as supporting context rather than primary endpoint degradation detections.

·        The detection model supports public durability beyond the current evidence anchors.

Maturity Constraints

·        Detection maturity is reduced when endpoint protection-state changes cannot be directly observed.

·        Detection maturity is reduced when command-line and process-chain telemetry are unavailable.

·        Detection maturity is reduced when registry, service-control, update, or sensor-health telemetry is incomplete.

·        Detection maturity is reduced when device-management context is unavailable because approved policy activity cannot be reliably separated from local manipulation.

·        Detection maturity is reduced when cloud, endpoint, SIEM, and device-management identities cannot be normalized to the same host or workload.

·        Detection maturity is reduced when timestamp inconsistency prevents reliable sequence correlation.

·        Detection maturity is reduced when false-positive controls rely on broad administrator allowlists rather than workflow-specific baselines.

·        Detection maturity is reduced when follow-on credential access or persistence telemetry is incomplete.

Foundational Maturity Level

·        A foundational program can collect basic endpoint process telemetry and some endpoint protection events.

·        A foundational program may identify obvious endpoint protection tampering but will struggle to distinguish attacker-driven degradation from legitimate administration.

·        A foundational program may lack reliable command-line logging, parent-child process visibility, protection-state transition detail, update telemetry, registry telemetry, service-control telemetry, and device-management context.

·        A foundational program should use this report’s logic primarily for hunting, triage enrichment, and telemetry gap identification.

·        A foundational program should avoid deploying high-confidence chained detections until minimum endpoint state, process, registry, service, and timestamp requirements are met.

Intermediate Maturity Level

·        An intermediate program can collect endpoint process telemetry, command-line data, parent-child process relationships, endpoint protection-state changes, registry changes, service-control events, and basic update telemetry.

·        An intermediate program can correlate suspicious administrative activity with endpoint security-control degradation on the same host.

·        An intermediate program can define endpoint class baselines and known-good security posture for major endpoint groups.

·        An intermediate program can distinguish many approved endpoint-management workflows from suspicious local manipulation.

·        An intermediate program can deploy primary degradation and update-manipulation detections but may need tighter scoping for follow-on credential access and persistence rules.

·        An intermediate program should prioritize improved device-management context, sensor-health visibility, timestamp normalization, and account normalization.

Advanced Maturity Level

·        An advanced program can correlate endpoint execution, privilege context, protection-state changes, registry events, service-control activity, update telemetry, device-management policy, sensor health, credential access, persistence, network activity, and cloud-management context.

·        An advanced program can validate same-host or same-device sequence logic across endpoint, SIEM, EDR, identity, cloud, and device-management telemetry.

·        An advanced program maintains baselines for endpoint class, security posture, authorized administrators, approved service accounts, approved management platforms, update sources, maintenance windows, vendor support workflows, endpoint migration, and recovery activity.

·        An advanced program can deploy the strongest behavior-chain detections with reliable false-positive control.

·        An advanced program can hunt for variants involving renamed binaries, endpoint-management abuse, SYSTEM-context execution, service-context execution, update-source manipulation, sensor-health degradation, and follow-on credential access or persistence.

·        An advanced program can use cloud, network, file, and memory telemetry as enrichment without confusing those sources for primary endpoint outcome evidence.

Optimized Maturity Level

·        An optimized program continuously validates endpoint security-control posture against expected managed baselines.

·        An optimized program detects unauthorized drift from expected protection posture quickly and correlates drift with process, account, policy, and management-source context.

·        An optimized program can identify attacker-driven degradation across endpoint-native telemetry, SIEM, identity telemetry, device-management systems, cloud-management platforms, and workload telemetry.

·        An optimized program can rapidly distinguish approved administrative workflows from malicious or anomalous local manipulation.

·        An optimized program continuously tests detection logic against alternate execution methods, renamed binaries, management-plane abuse, update suppression, sensor degradation, and post-degradation objectives.

·        An optimized program feeds incident findings back into telemetry requirements, baselines, allowlists, response playbooks, and detection content.

Maturity Improvement Priorities

·        Establish known-good endpoint protection posture by endpoint class.

·        Validate endpoint protection-state transition logging.

·        Enable reliable command-line and parent-child process telemetry.

·        Improve registry, service-control, update, and sensor-health telemetry.

·        Normalize host identity across endpoint, SIEM, EDR, cloud, and device-management telemetry.

·        Normalize account identity across local, domain, service, privileged, and cloud identities.

·        Integrate device-management and policy telemetry into detection and triage workflows.

·        Define approved security administration, patching, migration, vendor support, recovery, and break-glass workflows.

·        Tune detections by endpoint class and management source rather than relying on broad exclusions.

·        Improve follow-on credential access and persistence visibility.

·        Ensure cloud-management telemetry is correlated with endpoint outcome telemetry before being used in endpoint defense subversion investigations.

·        Conduct recurring hunts for endpoint security-control degradation after suspicious administrative activity.

Maturity Assessment Summary

·        The detection approach is analytically mature because it focuses on endpoint defense subversion as a behavior chain rather than a vendor-specific exploit condition.

·        Operational maturity depends on whether the environment can directly observe endpoint protection-state changes and correlate them with suspicious execution, account context, policy context, and follow-on activity.

·        Organizations with incomplete endpoint protection-state, process-chain, registry, service-control, update, sensor-health, or device-management telemetry should treat coverage as reduced.

·        The highest improvement value comes from closing telemetry gaps that prevent direct confirmation of endpoint security-control degradation.

·        Mature programs should prioritize behavior-chain correlation, endpoint outcome confirmation, and validated administrative baselines over single-event tampering alerts or exploit-name matching.

S31 — Telemetry Dependencies

Endpoint defense subversion and security-control degradation require telemetry that can prove whether endpoint controls remained intact after suspicious execution, administrative activity, or privilege use. The central dependency is the ability to connect attacker operating context with endpoint-control state changes on the same host.

Endpoint Execution Telemetry

·        Process creation, command-line arguments, parent-child process relationships, process path, signer, hash, user context, elevation state, host identity, and timestamp.

·        Visibility into PowerShell, CMD, WMI, registry utilities, service-control utilities, scheduled task utilities, script hosts, remote administration tools, and endpoint-management tooling.

·        Parent and grandparent process visibility to distinguish legitimate administration from suspicious execution launched by user-facing applications, script hosts, archive tools, remote access tools, or unusual paths.

Endpoint Protection State Telemetry

·        Real-time protection state, behavior monitoring state, cloud-delivered protection state, sample submission behavior, remediation behavior, exclusion policy, tamper-protection status, service state, update cadence, update source, telemetry forwarding, and sensor health.

·        Previous value, new value, affected setting, initiating process, initiating account, management source, host identity, endpoint class, and timestamp where available.

·        Direct evidence of protection-state transition is required for high-confidence control-degradation detection.

Service-Control and Sensor-Health Telemetry

·        Service stop, service disablement, startup-type modification, service recovery modification, restart suppression, service binary path modification, and repeated service failure.

·        Endpoint agent state, sensor connectivity, telemetry forwarding state, delayed check-in, degraded protection reporting, failed policy application, and agent-health transitions.

·        Sensor-health evidence is required to distinguish attacker-driven visibility degradation from routine endpoint noise or benign service interruption.

Registry and Configuration Telemetry

·        Creation, modification, and deletion of registry keys and values tied to endpoint protection, update behavior, exclusions, telemetry forwarding, service configuration, tamper protection, and security policy.

·        Configuration changes made through local tools, scripts, endpoint-management agents, Group Policy, MDM, EDR consoles, patching platforms, or direct registry modification.

·        Registry and configuration telemetry are critical where adversaries bypass user interfaces and modify control posture directly.

Security Intelligence and Update Telemetry

·        Security intelligence version, engine version, platform version, update cadence, update source, update policy, last successful update time, failed update attempts, failure reason, and security intelligence age.

·        Update telemetry must identify update-source manipulation, update-policy downgrade, security intelligence refresh blocking, repeated update failure tied to local manipulation, or unauthorized update-path changes.

·        Update failure alone is not sufficient; it becomes detection-relevant only when paired with suspicious local activity or evidence of update manipulation.

Device-Management and Policy Telemetry

·        Policy assignment, policy removal, policy downgrade, exclusion deployment, endpoint security setting changes, remediation actions, recovery workflows, endpoint migration activity, and maintenance-window activity.

·        Management source, policy identifier, affected endpoint, endpoint class, deployment scope, initiating administrator or service account, previous value, new value, and timestamp.

·        Device-management context is required to separate approved centralized policy activity from attacker-driven local degradation.

Credential Access, Persistence, and Follow-On Telemetry

·        LSASS access, suspicious process access, dump creation, SAM or SECURITY hive access, credential enumeration, browser credential access, scheduled task creation, service creation, autorun modification, WMI persistence, startup-folder changes, and logon script changes.

·        These sources support post-degradation objective detection and must be correlated to prior endpoint-control degradation on the same host.

·        Follow-on telemetry is not a substitute for direct endpoint-control state visibility.

Network and Outbound Communication Telemetry

·        DNS queries, outbound connections, destination domains, destination IPs, URLs where available, process-to-network mapping, reputation context, first-seen timing, host identity, and timestamp.

·        Network telemetry supports investigation of payload staging, command-and-control preparation, tool retrieval, credential movement, and lateral movement preparation after control degradation.

·        Network telemetry must remain supporting evidence unless tied to host-level endpoint-control degradation and suspicious execution context.

S32 — Detection Limitations

Detection of endpoint defense subversion is limited by whether the organization can observe both attacker context and endpoint-control state changes. Environments that rely only on endpoint product presence, generic health status, or isolated update failure will not have enough evidence for high-confidence detection.

Primary Limitations

·        Missing command-line telemetry reduces the ability to distinguish attacker-driven control manipulation from routine administration.

·        Missing parent-child process visibility weakens the ability to identify suspicious execution origins.

·        Missing endpoint protection state telemetry prevents confirmation that endpoint-control degradation occurred.

·        Missing registry and configuration telemetry limits visibility into direct protection changes, exclusion abuse, update manipulation, and policy weakening.

·        Missing service-control telemetry limits visibility into service stop, disablement, startup-type changes, recovery modification, and service impairment.

·        Missing device-management context increases false positives because approved policy changes cannot be separated from attacker-driven local manipulation.

·        Missing sensor-health telemetry can make attacker-driven visibility loss appear as routine telemetry absence.

·        Poor timestamp normalization can break sequence logic between privilege activity, control degradation, and follow-on behavior.

·        Incomplete host identity normalization can prevent reliable same-host correlation across EDR, SIEM, Windows-native logs, endpoint protection telemetry, and device-management sources.

·        Network-only visibility is insufficient for the core behavior and must not replace endpoint telemetry.

Detection Boundary

·        Generic update failure is not sufficient as a standalone malicious signal.

·        Isolated service restart is not sufficient as a standalone malicious signal.

·        Standalone endpoint sensor silence is not sufficient without suspicious context or management-policy conflict.

·        Product-name keywords, exploit labels, or public example names must not be used as primary detection logic.

·        Detection logic must not rely on prior alert state, another rule’s output, analyst judgment after alert generation, DRI, or TCR as an input.

·        High-confidence detection requires direct observable telemetry, bounded sequence correlation, and environment-specific baselines.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, or withheld when required telemetry is unavailable, incomplete, delayed, or not normalized. A behavior may be analytically important but unsuitable for high-confidence alerting if the organization cannot prove endpoint-control state change and suspicious context within a bounded time window.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making endpoint-control integrity measurable, resistant to unauthorized local manipulation, and recoverable after suspicious privileged activity. The objective is not merely to deploy endpoint tools, but to prove those controls remain intact during intrusion activity.

Endpoint-Control Integrity Monitoring

·        Monitor endpoint protection state, update health, service state, exclusion policy, telemetry forwarding, remediation behavior, policy posture, and sensor health as security-control integrity signals.

·        Alert when endpoint controls drift from known-good posture after suspicious execution, administrative activity, or privilege use.

·        Apply stricter control-integrity monitoring to privileged access workstations, domain-connected systems, developer endpoints, cloud workloads, and business-critical systems.

Tamper Resistance and Administrative Control

·        Enforce tamper protection, privileged access controls, and centralized policy management for endpoint security settings.

·        Restrict standing local administrator rights and require strong justification for endpoint administrative access.

·        Use privileged access workstations, just-in-time access, strong authentication, and session monitoring for endpoint administration.

·        Prevent unmanaged local changes to endpoint protection settings where centralized policy enforcement is available.

Endpoint Policy and Configuration Governance

·        Define known-good endpoint security posture by endpoint class, including workstation, server, domain controller, privileged access workstation, developer endpoint, cloud workload, and high-value asset.

·        Maintain approved baselines for exclusions, update sources, security intelligence cadence, service state, telemetry forwarding, and sensor health.

·        Review broad exclusions, unmanaged local policy changes, and exception paths for abuse potential.

·        Validate that policy rollback, recovery activity, endpoint migration, and vendor support workflows are logged and attributable.

Update and Security Intelligence Hardening

·        Enforce approved update sources and monitor for update-source changes, update-policy downgrades, security intelligence refresh blocking, and repeated update failure tied to local manipulation.

·        Baseline normal update behavior by endpoint class, network segment, management platform, and maintenance window.

·        Treat security intelligence staleness as a control-health risk when paired with suspicious local activity or policy manipulation.

Sensor Health and Telemetry Resilience

·        Monitor endpoint sensor check-in cadence, agent health, telemetry forwarding, policy application, and protection reporting.

·        Alert on sensor-health degradation when paired with suspicious administrative activity, endpoint-management conflict, or follow-on objective behavior.

·        Ensure telemetry continues to flow during containment, isolation, recovery, and endpoint rebuild workflows.

SOC and Incident Response Hardening

·        Treat confirmed endpoint-control degradation as a trust-impacting event.

·        Require containment review, endpoint integrity validation, credential-risk assessment, and follow-on activity review for degraded endpoints.

·        Add playbook steps for validating protection state, update health, exclusions, service state, sensor health, policy source, and management-platform activity.

·        Require responders to determine whether credential access, persistence, discovery, outbound communication, or lateral movement occurred after control degradation.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat endpoint-control integrity as a monitored security layer rather than an assumed condition. The architecture must connect endpoint activity, endpoint-control state, device-management context, identity context, and response workflows into a single validation model.

Architecture Layer 1: Endpoint Execution Visibility

Endpoint execution telemetry provides visibility into the activity that precedes control degradation. This layer captures process creation, command line, parent-child relationships, user context, elevation state, path, signer, hash, host identity, and timestamp.

Architecture Layer 2: Endpoint-Control State Monitoring

Endpoint-control state monitoring proves whether protection posture changed. This layer captures protection state, exclusions, update behavior, service state, telemetry forwarding, remediation settings, policy posture, sensor health, and endpoint security-control drift.

Architecture Layer 3: Device-Management and Policy Validation

Device-management telemetry separates approved centralized administration from attacker-driven local manipulation. This layer validates policy source, policy identifier, deployment scope, maintenance window, administrator or service account, and endpoint class.

Architecture Layer 4: Identity and Privilege Context

Identity and privilege telemetry identifies whether control changes occurred under expected administrative context, compromised user context, service context, SYSTEM context, or remote administrative execution. This layer includes privileged group changes, logon type, remote source, token elevation, administrative session activity, and service account usage.

Architecture Layer 5: Follow-On Objective Monitoring

Follow-on telemetry determines whether control degradation enabled additional adversary activity. This layer monitors credential access, persistence, discovery, outbound communication, staging, remote access, and lateral movement after endpoint-control degradation.

Architecture Layer 6: SOC Correlation and Response Workflow

SOC correlation joins suspicious execution or privilege context with endpoint-control degradation and follow-on activity on the same host. Response workflow requires endpoint integrity validation, credential-risk review, management-platform validation, containment decisioning, and recovery confirmation.

Architecture Outcome

The architecture should enable the organization to answer four questions during an incident:

·        Did suspicious execution or privileged activity occur?

·        Did endpoint-control posture change after that activity?

·        Was the change authorized by a trusted management source?

·        Did credential access, persistence, discovery, outbound communication, or lateral movement occur after degradation?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Tamper protection for endpoint security settings

·        Centralized endpoint security policy enforcement

·        Least-privilege administration

·        Just-in-time privileged access

·        Privileged access workstations

·        Application control for administrative tooling

·        Approved update-source enforcement

·        Controlled exclusion management

·        Endpoint-management change governance

·        Strong authentication for administrative access

Detective Controls

·        Process and command-line monitoring

·        Parent-child process correlation

·        Endpoint protection state monitoring

·        Registry and configuration change monitoring

·        Service-control monitoring

·        Security intelligence update telemetry

·        Sensor-health monitoring

·        Device-management policy telemetry

·        Privileged account and remote administration monitoring

·        Same-host sequence correlation for suspicious activity followed by control degradation

Responsive Controls

·        Endpoint isolation

·        Endpoint integrity validation

·        Credential-risk review and credential rotation

·        Policy restoration

·        Security intelligence update validation

·        Sensor redeployment or repair

·        Endpoint rebuild

·        Forensic acquisition

·        Management-platform validation

·        Incident playbooks for endpoint-control degradation

Governance Controls

·        Known-good endpoint posture definitions by endpoint class

·        Approved administrator and service account baselines

·        Approved endpoint-management source inventory

·        Maintenance-window governance

·        Exclusion review and exception governance

·        Policy rollback and recovery documentation

·        Vendor support workflow logging

·        Executive reporting for high-value endpoint-control degradation

·        Risk-register tracking for endpoint-control integrity

Control Mapping Summary

The strongest control posture combines prevention of unauthorized local modification, detection of endpoint-control degradation, and response workflows that restore endpoint trust. Controls should be prioritized for privileged access workstations, domain-connected systems, developer endpoints, business-critical servers, cloud workload hosts, and other high-value systems.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

Endpoint defense subversion is a well-defined behavior class, but organization-specific maturity depends on whether endpoint-control state changes are visible, normalized, and correlated with suspicious execution or privilege context. Many environments have strong process visibility but weaker protection-state, update-health, device-management, and sensor-health correlation.

Strengths

·        The behavior pattern is durable across endpoint products and does not depend on a single public example.

·        The core sequence is analytically clear: execution or privilege context, control discovery, endpoint-control degradation, and follow-on objective activity.

·        Detection opportunities are strong where endpoint execution telemetry and endpoint protection state telemetry are available.

·        Defensive controls can be mapped directly to endpoint hardening, policy governance, telemetry validation, and incident response workflows.

Maturity Gaps

·        Endpoint-control state telemetry is often inconsistent across products and environments.

·        Device-management context may not be available in the same system as endpoint execution telemetry.

·        Security intelligence update telemetry may be incomplete or difficult to tie to initiating process and account context.

·        Sensor-health degradation may be treated as operational noise rather than a security-control integrity signal.

·        Baselines for authorized administrators, management sources, exclusions, update sources, and endpoint classes may be incomplete.

·        Organizations may over-rely on endpoint product presence rather than validating control integrity during incidents.

Maturity Improvement Priorities

·        Normalize endpoint-control state telemetry across EDR, endpoint protection, SIEM, and device-management platforms.

·        Define known-good endpoint security posture by endpoint class.

·        Implement same-host correlation between suspicious privilege activity and endpoint-control degradation.

·        Improve visibility into update-source manipulation, update-policy changes, exclusion abuse, service-control activity, and sensor-health degradation.

·        Add endpoint-control integrity validation to incident response playbooks.

·        Track endpoint-control degradation as a risk-register condition for high-value systems.

Maturity Outlook

Maturity can improve quickly if the organization prioritizes a small number of high-impact telemetry and control improvements. The highest-value improvements are command-line visibility, endpoint protection state monitoring, device-management context, service-control telemetry, update telemetry, and sensor-health monitoring.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that endpoint controls can be degraded silently and reduce the response burden when degradation occurs. The objective is measurable endpoint-control integrity across endpoint classes, not tool deployment alone.

Priority 1: Establish Endpoint-Control Integrity as a Security Metric

·        Define endpoint-control integrity metrics for protection state, update health, service state, exclusion policy, telemetry forwarding, policy posture, remediation behavior, and sensor health.

·        Report endpoint-control integrity for privileged access workstations, domain-connected systems, servers, developer endpoints, executive endpoints, cloud workload hosts, and high-value assets.

·        Treat unexplained degradation on high-value systems as an executive-relevant control failure.

Priority 2: Reduce Local Administrative Exposure

·        Reduce standing local administrator rights.

·        Enforce privileged access workflows for endpoint administration.

·        Require stronger governance for endpoint-management tools, scripts, service accounts, and remote administration.

·        Monitor administrative actions that modify endpoint protection posture.

Priority 3: Harden Endpoint Policy and Update Paths

·        Enforce approved security intelligence update sources.

·        Monitor update-source changes and update-policy downgrades.

·        Review endpoint exclusions and exception workflows.

·        Validate endpoint security policy inheritance and rollback behavior.

·        Prevent unmanaged local policy drift where centralized enforcement is available.

Priority 4: Improve Sensor-Health and Telemetry Assurance

·        Monitor agent health, telemetry forwarding, delayed check-in, policy application, and endpoint reporting completeness.

·        Treat unexplained sensor degradation as security-relevant when paired with suspicious activity.

·        Validate telemetry continuity during containment, isolation, and recovery operations.

Priority 5: Strengthen SOC Response to Control Degradation

·        Create or update playbooks for endpoint-control degradation.

·        Require same-host review of suspicious privileged activity, protection-state change, credential access, persistence, discovery, outbound communication, and lateral movement.

·        Add endpoint integrity validation before returning systems to service.

·        Require credential-risk review when endpoint-control degradation occurs on privileged or domain-connected systems.

Priority 6: Prioritize High-Value Endpoint Classes

·        Apply stronger monitoring and stricter policy enforcement to privileged access workstations, domain controllers, administrative servers, developer systems, executive endpoints, cloud workload hosts, and business-critical systems.

·        Ensure high-value endpoints have complete telemetry, controlled administration, strong tamper protection, and validated response workflows.

Strategic Outcome

The organization should be able to prove that endpoint controls remain intact during suspicious privileged activity, detect when those controls are degraded, and restore endpoint trust before attackers convert local control weakening into broader enterprise compromise.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Endpoint defense subversion changes the economics of intrusion by allowing adversaries to reduce defensive reliability before pursuing higher-value objectives. Instead of defeating every control directly, the attacker attempts to weaken the endpoint layer that supports prevention, alerting, investigation, and containment. This lowers attacker friction while increasing organizational uncertainty, response cost, and validation burden.

Adversary Economic Advantage

·        Endpoint-control degradation can reduce the cost of operating on a compromised host by lowering prevention and detection pressure.

·        Weakening endpoint controls before credential access, persistence, discovery, outbound communication, or lateral movement increases the attacker’s probability of successful follow-on activity.

·        Abuse of legitimate administrative tools and endpoint-management pathways allows attackers to blend malicious activity with normal operations.

·        Security intelligence update suppression, exclusion abuse, service manipulation, and sensor degradation can extend attacker dwell time without requiring highly customized malware.

·        Successful degradation shifts the attacker’s burden from stealth alone to control manipulation, forcing defenders to prove whether security evidence remained reliable.

Defender Cost Expansion

·        The organization must investigate both the attacker’s activity and the integrity of the defensive controls used to observe that activity.

·        Response teams may need to validate endpoint protection state, update health, service status, exclusion policy, telemetry forwarding, sensor health, and management-platform activity.

·        Credential review, endpoint isolation, forensic collection, policy restoration, sensor redeployment, and selective rebuilds may be required even when enterprise-wide compromise is not confirmed.

·        Response cost increases when telemetry gaps prevent rapid determination of whether endpoint controls were degraded before follow-on attacker behavior.

·        High-value endpoints create disproportionate exposure because degraded controls on privileged, domain-connected, developer, cloud workload, or business-critical systems can expand containment requirements quickly.

Organizational Impact Model

Initial Compromise Impact

The organization must determine how the adversary obtained execution, privileged context, or administrative access.

Control Integrity Impact

The organization must determine whether endpoint protection, telemetry, updates, services, policy posture, and sensor health remained reliable.

Follow-On Compromise Impact

The organization must determine whether degraded controls enabled credential access, persistence, discovery, outbound communication, or lateral movement.

Recovery Impact

The organization must restore endpoint trust through policy validation, sensor repair, credential review, endpoint rebuilds, or management-platform verification.

Governance Impact

Leadership may need to treat confirmed endpoint-control degradation on high-value systems as an executive incident because containment evidence may be incomplete or unreliable.

Economic Impact Summary

Endpoint defense subversion is economically powerful for adversaries because it can lower detection pressure while increasing defender validation cost. The organization’s financial exposure grows when it cannot quickly prove what was blocked, what was logged, what was hidden, and whether endpoint controls remained trustworthy during the compromise window.

S39 — Economic Impact & Organizational Exposure

Endpoint defense subversion creates organizational exposure by increasing uncertainty around endpoint trust, containment scope, and response completeness. Exposure rises when endpoint-control degradation affects high-value systems or when the organization cannot quickly prove that endpoint protection, update health, service state, telemetry forwarding, policy posture, and sensor health remained reliable.

Financial Exposure

·        Direct response costs include SOC surge activity, endpoint isolation, forensic acquisition, endpoint rebuilds, sensor repair, policy restoration, and management-platform validation.

·        Identity-related costs include credential review, privileged credential rotation, account-risk analysis, and privileged access workflow validation.

·        Operational costs include system downtime, containment disruption, delayed recovery, endpoint re-enrollment, and reduced productivity for affected teams.

·        Governance costs include legal review, executive reporting, cyber insurance coordination, audit response, and board-level incident oversight.

·        Long-tail costs include increased monitoring, tool redeployment, endpoint hardening, policy cleanup, exception review, and security program remediation.

Organizational Exposure Factors

·        Broad local administrator rights increase the likelihood that endpoint controls can be modified after compromise.

·        Weak endpoint-control state telemetry increases uncertainty around whether degradation occurred.

·        Incomplete device-management context makes it harder to distinguish authorized policy changes from attacker-driven manipulation.

·        Weak sensor-health monitoring can allow visibility degradation to be misread as ordinary endpoint noise.

·        Poor command-line and process-context visibility reduces confidence in attacker sequencing and root-cause determination.

·        High-value endpoint exposure increases the likelihood of credential compromise, lateral movement, and broader containment requirements.

·        Over-reliance on endpoint product deployment rather than measurable endpoint-control integrity increases response uncertainty.

Operational Exposure

Organizations should treat confirmed endpoint-control degradation as a trust-impacting event. Affected endpoints may need isolation, integrity validation, policy restoration, credential-risk review, and verification that no follow-on activity occurred during the degraded-control window. When high-value systems are involved, endpoint-control degradation should trigger executive visibility because the affected defensive layer is central to containment and forensic confidence.

Residual Exposure

Residual exposure remains after containment if the organization cannot prove that endpoint controls were restored, telemetry remained complete, credentials were not accessed, persistence was not established, and lateral movement did not occur. Residual exposure is highest where endpoint protection state telemetry, update telemetry, service-control data, device-management context, and sensor-health reporting are incomplete or poorly normalized.

Executive Exposure Statement

The organization’s economic exposure is highest when endpoint-control degradation creates uncertainty around what happened, what was logged, what was blocked, and what can be trusted. The strategic risk is not only the compromised endpoint; it is the possibility that the endpoint defense layer failed silently during the period when the organization most needed reliable detection and containment evidence.

S40 — References

Vendor / Platform Documentation

·        Microsoft Learn — Microsoft Defender for Endpoint tamper protection — hxxps://learn[.]microsoft[.]com/en-us/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection

·        Microsoft Learn — Microsoft Defender Antivirus security intelligence and product updates — hxxps://learn[.]microsoft[.]com/en-us/defender-endpoint/microsoft-defender-antivirus-updates

·        Microsoft Learn — Microsoft Defender for Endpoint device health and sensor health reporting — hxxps://learn[.]microsoft[.]com/en-us/defender-endpoint/device-health-sensor-health-os

·        Microsoft Learn — Microsoft Intune endpoint security policies — hxxps://learn[.]microsoft[.]com/en-us/intune/intune-service/protect/endpoint-security-policy

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 — CVE-2026-33825 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-33825

·        The Hacker News — Microsoft Defender zero-day exploitation reporting — hxxps://thehackernews[.]com/2026/04/three-microsoft-defender-zero-days.html

Threat Tradecraft and Intrusion Patterns

·        Cloud Security Alliance — Defender triple zero-day research note: BlueHammer, RedSun, and UnDefend — hxxps://labs[.]cloudsecurityalliance[.]org/research/csa-research-note-defender-triple-zero-day-bluehammer-redsun/

·        BleepingComputer — Recently leaked Windows zero-days exploited in attacks — hxxps://www[.]bleepingcomputer[.]com/news/security/recently-leaked-windows-zero-days-now-exploited-in-attacks/