MITRE ATT&CK® Technique

T1685.001: Disable or Modify Windows Event Log

Adversaries may disable or modify the Windows Event Log to limit data that can be leveraged for detections and audits. Windows Event Log records user and system activity such as login attempts and process creation.[1] This data is used by security tools and analysts to generate detections.

The EventLog service maintains event logs from various system components and applications. By default, the service automatically starts when a system powers on. An audit policy, maintained by the Local Security Policy (secpol.msc), defines which system events the EventLog service logs. Security audit policy settings can be changed by running secpol.msc, then navigating to `Security Settings\Local Policies\Audit Policy` for basic audit policy settings or `Security Settings\Advanced Audit Policy Configuration` for advanced audit policy settings.[2][3] `auditpol.exe` may also be used to set audit policies.[4]

Adversaries may target system-wide logging or just that of a particular application. For example, the Windows EventLog service may be disabled using the `Set-Service -Name EventLog -Status Stopped` or `sc config eventlog start=disabled` commands (followed by manually stopping the service using `Stop-Service -Name EventLog`). Additionally, the service may be disabled by modifying the "Start" value in `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog` then restarting the system for the change to take effect.[5][6]

There are several ways to disable the EventLog service via registry key modification. Without Administrator privileges, adversaries may modify the "Start" value in the key `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Security`, then reboot the system to disable the Security EventLog.[7] With Administrator privilege, adversaries may modify the same values in `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-System` and `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-Application` to disable the entire EventLog.

Additionally, adversaries may use `auditpol` and its sub-commands in a command prompt to disable auditing or clear the audit policy. To enable or disable a specified setting or audit category, adversaries may use the `/success` or `/failure` parameters. For example, `auditpol /set /category:"Account Logon" /success:disable /failure:disable` turns off auditing for the Account Logon category.[8] To clear the audit policy, adversaries may run the following lines: `auditpol /clear /y` or `auditpol /remove /allusers`.[9]

EnterpriseT1685.001Sub-techniqueObject v1.0 Modified May 12, 2026, 15:12 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

This technique matters because Windows Event Log is often the evidence trail used to prove what happened during an incident. If an adversary disables the EventLog service, changes audit policy, or modifies related registry settings, security teams may lose visibility into logons, process activity, and other audit evidence needed for detection, investigation, and compliance reporting.

Executive priority

Treat this as a resilience and audit-readiness issue, not just a Windows hardening item. Leaders should ask whether critical Windows systems can continue sending useful security evidence if local logging is impaired, whether audit policy changes are reviewed, and whether privileged access is tight enough to prevent unauthorized tampering. ATT&CK relationships also associate this behavior with major campaigns, including SolarWinds Compromise, HomeLand Justice, and the 2016 Ukraine Electric Power Attack, making it relevant to incident decision-making and, in some environments, cyber-physical risk planning.

Technical view

For Windows endpoints and servers, validate coverage for the defense-impairment behavior described by T1685.001: attempts to stop or disable the Windows EventLog service, registry modifications affecting EventLog and WMI Autologger EventLog channels, and audit policy changes that reduce or clear logging. Because the official ATT&CK object does not provide detection text, use the related DET0187 strategy, 'Detect Disabled Windows Event Log,' as a coverage mapping target and test against approved administrative workflows to separate malicious tampering from legitimate maintenance or Group Policy changes.

Likely telemetry

Windows service configuration and service state changes for the EventLog service
Registry modification telemetry for EventLog service and WMI Autologger EventLog keys
Process execution telemetry for Windows administrative utilities that manage services, audit policy, PowerShell, and event log functions
Audit policy change records from Local Security Policy, Advanced Audit Policy Configuration, or auditpol activity
Windows Security, System, and Application log availability, gaps, truncation, or sudden cessation of events

Detection direction

Alert on unauthorized changes that stop, disable, or reconfigure the EventLog service, especially outside approved change windows.
Monitor for registry changes to EventLog-related service and Autologger paths identified in the ATT&CK description.
Detect audit policy reduction, clearing, or removal, and compare against expected baselines managed through policy.
Tune for legitimate administrator activity, security baseline deployment, troubleshooting, and Group Policy changes to reduce false positives.
Correlate host-side events with central log ingestion health; a host that stops producing expected logs can be as important as an explicit disable event.

Mitigation priorities

Prioritize User Account Management: enforce least privilege so only authorized administrators can change audit policy, service settings, or sensitive logging configuration.
Restrict Registry Permissions on EventLog and related Autologger keys to reduce unauthorized modification risk.
Restrict File and Directory Permissions where logging components, configurations, or supporting files could be tampered with.
Maintain and review audit baselines so reductions in logging are detectable as configuration drift, not treated as normal variation.
Ensure incident response playbooks include checks for logging impairment before relying on Windows event evidence as complete.

Analyst notes and limits

The object is a Windows sub-technique under Disable or Modify Tools and is mapped to defense-impairment. The relationship to Wevtutil and the revoked predecessor T1562.002 provides historical/contextual continuity, but the supplied official detection field is empty, so detections should be validated locally rather than assumed.

This take is based only on the supplied ATT&CK fields, external references, and relationships. It does not establish current exploitation, customer exposure, or guaranteed detection coverage. Local privileges, Group Policy design, log forwarding architecture, and endpoint telemetry determine practical coverage.

Official MITRE ATT&CK definition

Disable or Modify Windows Event Log

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.

ATT&CK relationship table

Related techniques

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.

Filter related techniques 2 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1685	Disable or Modify Tools	This object subtechnique of Disable or Modify Tools.
Enterprise	T1562.002	Disable Windows Event Logging Sub-technique	Disable Windows Event Logging revoked by this object.

Associated objects

Groups, software, and campaigns

G0059: Magic Hound

Magic Hound is an Iranian-sponsored threat group that conducts long term, resource-intensive cyber espionage operations, likely on behalf of the Islamic Revolutionary Guard Corps. They have targeted European, U.S., and Middle Eastern government and military personnel, academics, journalists, and organizations such as the World Health Organization (WHO), via complex social engineering campaigns since at least 2014.[1][2][3][4][5]

G0027: Threat Group-3390

Threat Group-3390 is a Chinese threat group that has extensively used strategic Web compromises to target victims.[1] The group has been active since at least 2010 and has targeted organizations in the aerospace, government, defense, technology, energy, manufacturing and gambling/betting sectors.[2][3][4]

S0645: Wevtutil

Wevtutil is a Windows command-line utility that enables administrators to retrieve information about event logs and publishers.[1]

Windows

C0025: 2016 Ukraine Electric Power Attack

2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]

C0024: SolarWinds Compromise

The SolarWinds Compromise was a sophisticated supply chain cyber operation conducted by APT29 that was discovered in mid-December 2020. APT29 used customized malware to inject malicious code into the SolarWinds Orion software build process that was later distributed through a normal software update; they also used password spraying, token theft, API abuse, spear phishing, and other supply chain attacks to compromise user accounts and leverage their associated access. Victims of this campaign included government, consulting, technology, telecom, and other organizations in North America, Europe, Asia, and the Middle East. This activity has been labled the StellarParticle campaign in industry reporting.[1] Industry reporting also initially referred to the actors involved in this campaign as UNC2452, NOBELIUM, Dark Halo, and SolarStorm.[2][3][4][5][1][6][7][8]

In April 2021, the US and UK governments attributed the SolarWinds Compromise to Russia's Foreign Intelligence Service (SVR); public statements included citations to APT29, Cozy Bear, and The Dukes.[9][10][11] The US government assessed that of the approximately 18,000 affected public and private sector customers of Solar Winds’ Orion product, a much smaller number were compromised by follow-on APT29 activity on their systems.[12]

C0038: HomeLand Justice

HomeLand Justice was a disruptive cyber campaign conducted by Iranian state-affiliated actors against Albanian government networks in July and September 2022. The activity combined ransomware, wiper malware, and data leak operations. Initial access for HomeLand Justice was established as early as May 2021, and threat actors moved laterally, exfiltrated sensitive information, and maintained persistence for approximately 14 months prior to the destructive phase of the operation. Responsibility was claimed by the "HomeLand Justice" front, which framed the campaign as retaliation against the Mujahedeen-e Khalq (MEK), an Iranian opposition group with a presence in Albania. Multiple Iran-nexus groups are assessed to have participated in the campaign, including HEXANE who probed victim infrastructure.[1][2][3] A second wave of attacks was launched in September 2022 using similar tactics following public attribution of the previous activity to Iran and the severing of diplomatic ties between Iran and Albania.[3]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1018: User Account Management Enterprise mitigates · Mitigation M1047: Audit Enterprise subtechnique of · Technique T1685: Disable or Modify Tools Enterprise mitigates · Mitigation M1024: Restrict Registry Permissions Enterprise detects · Detection Strategy DET0187: Detect Disabled Windows Event Log Enterprise uses · Campaign C0025: 2016 Ukraine Electric Power Attack Enterprise uses · Tool S0645: Wevtutil Enterprise uses · Group G0059: Magic Hound Enterprise uses · Campaign C0024: SolarWinds Compromise Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Group G0027: Threat Group-3390 Enterprise uses · Campaign C0038: HomeLand Justice Enterprise revoked by · Technique T1562.002: Disable Windows Event Logging Enterprise

Mitigations

Mitigation direction

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

M1024: Restrict Registry Permissions

Restricting registry permissions involves configuring access control settings for sensitive registry keys and hives to ensure that only authorized users or processes can make modifications. By limiting access, organizations can prevent unauthorized changes that adversaries might use for persistence, privilege escalation, or defense evasion. This mitigation can be implemented through the following measures:

Review and Adjust Permissions on Critical Keys

- Regularly review permissions on keys such as `Run`, `RunOnce`, and `Services` to ensure only authorized users have write access. - Use tools like `icacls` or `PowerShell` to automate permission adjustments.

Enable Registry Auditing

- Enable auditing on sensitive keys to log access attempts. - Use Event Viewer or SIEM solutions to analyze logs and detect suspicious activity. - Example Audit Policy: `auditpol /set /subcategory:"Registry" /success:enable /failure:enable`

Protect Credential-Related Hives

- Limit access to hives like `SAM`,`SECURITY`, and `SYSTEM` to prevent credential dumping or other unauthorized access. - Use LSA Protection to add an additional security layer for credential storage.

Restrict Registry Editor Usage

- Use Group Policy to restrict access to regedit.exe for non-administrative users. - Block execution of registry editing tools on endpoints where they are unnecessary.

Deploy Baseline Configuration Tools

- Use tools like Microsoft Security Compliance Toolkit or CIS Benchmarks to apply and maintain secure registry configurations.

*Tools for Implementation*

Registry Permission Tools:

- Registry Editor (regedit): Built-in tool to manage registry permissions. - PowerShell: Automate permissions and manage keys. `Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "KeyName" -Value "Value"` - icacls: Command-line tool to modify ACLs.

Monitoring Tools:

- Sysmon: Monitor and log registry events. - Event Viewer: View registry access logs.

Policy Management Tools:

- Group Policy Management Console (GPMC): Enforce registry permissions via GPOs. - Microsoft Endpoint Manager: Deploy configuration baselines for registry permissions.

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

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: Apr 14, 2026, 22:54 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: acb131106b84a867...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`acb131106b84…`

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.

Open mirrored raw JSON Open MITRE-hosted copy

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]
EventLog_Core_Technologies

Core Technologies. (2021, May 24). Essential Windows Services: EventLog / Windows Event Log. Retrieved September 14, 2021.
Open source URL
[2]
Microsoft Audit Policy

Microsoft. (n.d.). Retrieved April 15, 2026.
Open source URL
[3]
Microsoft Adv Security Settings

Microsoft. (n.d.). Retrieved April 15, 2026.
Open source URL
[4]
Microsoft auditpol

Microsoft. (n.d.). Retrieved April 15, 2026.
Open source URL
[5]
Disable_Win_Event_Logging

dmcxblue. (n.d.). Disable Windows Event Logging. Retrieved September 10, 2021.
Open source URL
[6]
disable_win_evt_logging

Heiligenstein, L. (n.d.). REP-25: Disable Windows Event Logging. Retrieved April 7, 2022.
Open source URL
[7]
winser19_file_overwrite_bug_twitter

Naceri, A. (2021, November 7). Windows Server 2019 file overwrite bug. Retrieved April 7, 2022.
Open source URL
[8]
auditpol.exe_STRONTIC

STRONTIC. (n.d.). auditpol.exe. Retrieved September 9, 2021.
Open source URL
[9]
T1562.002_redcanaryco

redcanaryco. (2021, September 3). T1562.002 - Disable Windows Event Logging. Retrieved September 13, 2021.
Open source URL
[10]
mitre-attack T1685.001
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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use