Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1633: Analytic 1633

Detects exploitation attempts targeting defensive security software or OS services. Defender observation includes abnormal process behavior (e.g., AV or EDR crashing unexpectedly), unsigned/untrusted modules loaded into defensive processes, or privilege escalation from security agent services. Multi-event correlation ties exploitation attempts to subsequent evasive behavior like service termination or missing logs.

EnterpriseAN1633AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN1633 is a Windows detection analytic focused on signs that defensive security software or operating system services may be under attack. Its business value is not just catching a single exploit attempt; it helps identify situations where the tools relied on for visibility, containment, and audit evidence may be crashing, being tampered with, or losing logs. For leaders, this is material because compromise of security agents can weaken incident response confidence and delay business-impacting decisions.

Executive priority

Prioritize this analytic where Windows endpoint security agents, AV/EDR services, and OS services are critical to incident response and compliance evidence. Executives should ask whether the organization can detect abnormal behavior in its own defensive tooling, whether agent crashes are investigated as security events rather than only operational defects, and whether missing logs or terminated services trigger escalation. This supports resilience planning because loss of defensive visibility can undermine containment, forensic confidence, and audit readiness.

Technical view

For SOC, detection engineering, and IR teams, validate correlation around abnormal defensive-process behavior on Windows: unexpected AV/EDR process crashes, unsigned or untrusted modules loaded into defensive processes, privilege escalation from security agent services, service termination, and gaps in expected logging. Because no official detection logic is provided and no ATT&CK relationships are supplied, teams should implement this as a behavior-correlation use case rather than a single indicator rule. Tune by baselining legitimate security-agent updates, service restarts, driver/module loads, and maintenance windows.

Likely telemetry

  • Windows process creation and termination events for security tools and OS services
  • Service start, stop, crash, and recovery events
  • Module or DLL load telemetry, especially trust/signature status for modules loaded into defensive processes
  • Security agent health, tamper, crash, and policy-status telemetry
  • Privilege and token-change events involving security agent services

Detection direction

  • Correlate defensive-process crashes with subsequent evasive behavior such as service termination or missing logs, as described in the analytic.
  • Alert on unsigned or untrusted modules loaded into defensive security processes, while tuning for legitimate product updates and vendor-signed components.
  • Investigate privilege escalation paths originating from security agent services, especially when followed by process instability or disabled visibility.
  • Treat repeated agent failures, unexplained service restarts, and sudden telemetry loss as potential security events, not only endpoint operations issues.
  • Establish baselines for normal AV/EDR update behavior, service recovery patterns, and approved module loads to reduce false positives.

Mitigation priorities

  • Ensure Windows security agents and OS services generate centralized health, crash, service-control, and tamper telemetry.
  • Harden and monitor defensive software services with least privilege and controlled service-management permissions where supported by local architecture.
  • Maintain reliable log forwarding so missing logs or collection gaps can be detected independently of the endpoint agent.
  • Create IR playbooks for suspected compromise or failure of defensive tooling, including validation from alternate telemetry sources.
  • Review operational processes so planned maintenance, product updates, and agent restarts are distinguishable from suspicious disruption.
Analyst notes and limits

This object is a detection analytic, not a technique description. The supplied ATT&CK fields identify Windows as the platform and describe defender observations involving security software or OS services, but do not provide tactics, relationships, or executable detection logic. The strongest use is as a validation requirement for endpoint visibility integrity and security-agent health monitoring.

No official detection query, data source list, tactics, or relationship context was supplied. Local product behavior, logging architecture, and approved maintenance patterns are required to determine thresholds, exclusions, and severity. This summary does not assert active exploitation, attribution, or confirmed coverage.

Official MITRE ATT&CK definition

Analytic 1633

Detects exploitation attempts targeting defensive security software or OS services. Defender observation includes abnormal process behavior (e.g., AV or EDR crashing unexpectedly), unsigned/untrusted modules loaded into defensive processes, or privilege escalation from security agent services. Multi-event correlation ties exploitation attempts to subsequent evasive behavior like service termination or missing logs.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
d51d7dc2b23c937f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d51d7dc2b23c…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1633
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.