DET0187: Detect Disabled Windows Event Log
This detection strategy matters because it is tied to attempts to disable or modify Windows Event Log, a behavior that can remove the evidence SOC teams, i...
Analyst context for executives and security teams
This detection strategy matters because it is tied to attempts to disable or modify Windows Event Log, a behavior that can remove the evidence SOC teams, incident responders, auditors, and security tools rely on to understand what happened. For leaders, the issue is not just a missed alert; it is loss of investigative and compliance visibility during a potential incident.
Executive priority
Prioritize validation of Windows logging resilience where Windows systems are material to operations, privileged access, audit evidence, or incident response. The business question is whether teams would quickly know if event logging was impaired, and whether enough independent telemetry would remain to support containment, investigation, and reporting decisions.
Technical view
The supplied ATT&CK object has no official description or detection logic, but it detects T1685.001, Disable or Modify Windows Event Log, under defense-impairment for Windows. SOC and detection engineering teams should validate monitoring for changes that affect Windows Event Log availability or integrity, including service state, log configuration, audit policy-related changes, and gaps or unexpected drops in event volume. IR teams should treat suspected logging impairment as a signal that host evidence may be incomplete and should corroborate with other sources.
Likely telemetry
- Windows Event Log service state and configuration evidence
- Windows security, system, and application event logs
- Audit policy and log retention/configuration change records
- Endpoint detection and response host telemetry, where available
- Centralized log collection health, ingestion gaps, and source heartbeat data
Detection direction
- Validate that detections look for both explicit logging changes and indirect symptoms such as sudden event source silence or collection gaps.
- Tune for legitimate administrative maintenance, policy deployment, troubleshooting, or system recovery activity to reduce false positives.
- Correlate logging changes with privileged account activity, process execution context, and affected asset criticality.
- Do not rely only on the local Windows Event Log being intact; compare endpoint, SIEM ingestion, and management-plane health signals where available.
- Use the relationship to T1685.001 as the analytic anchor: the defensive goal is to detect impairment of evidence used for detections and audits.
Mitigation priorities
- Establish baseline Windows logging and audit policy configurations for important systems.
- Centralize log collection so local log tampering or outage is more visible.
- Restrict and monitor administrative privileges capable of changing logging services or audit configuration.
- Alert on log collection health failures and unexpected host-level logging changes.
- Include logging impairment checks in incident response triage and compliance evidence reviews.
Analyst notes and limits
This take is constrained by the ATT&CK record: the detection strategy has no official description, no official detection text, and no platforms listed on the object itself. The practical guidance is derived from its stated relationship to T1685.001, Disable or Modify Windows Event Log, which is a Windows defense-impairment technique.
Local environment evidence is required to determine which Windows systems, log sources, administrative workflows, and collection paths are in scope. This summary does not assert active exploitation, attribution, or existing detection coverage.
Detect Disabled Windows Event Log
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1685.001 | Disable or Modify Windows Event Log Sub-technique | This object detects Disable or Modify Windows Event Log. |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | c19731bf11fd… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0187Open source URL
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.