AN2030: Analytic 2030
A process with no prior history or outside of known whitelisted tools initiates file or registry modifications to configure exclusion rules for antivirus, backup, or file-handling systems. Or a file system enumeration for specific file names andcritical extensions like .dll, .exe, .sys, or specific directories such as 'Program Files' or security tool paths or system component discovery for the exclusion of the files or components.
Analyst context for executives and security teams
This analytic describes suspicious Windows activity where a process that is new, uncommon, or not on an approved tooling list changes file or registry settings to create exclusions for antivirus, backup, or file-handling systems, or enumerates sensitive file types and system/security directories that could be targeted for exclusion. For leaders, the practical issue is resilience: exclusions can create blind spots in prevention, recovery, and monitoring controls if they are not governed and auditable.
Executive priority
Prioritize this as a control-assurance question: who is allowed to change security, backup, and file-handling exclusions on Windows systems, how are those changes approved, and can the SOC prove they are monitored? This matters for business continuity because unauthorized exclusions may weaken security tooling and backup visibility. It also supports audit and incident response readiness by requiring evidence of authorized change processes and telemetry around registry, file, and process activity.
Technical view
Validate Windows telemetry that can show an uncommon or previously unseen process initiating registry or file modifications associated with exclusion configuration, as well as enumeration of critical extensions such as .dll, .exe, and .sys or directories such as Program Files, security tool paths, and system component locations. Because no official detection logic is supplied, teams should treat this as a behavior pattern requiring local baselining of approved administrative tools, security products, backup agents, deployment systems, and known maintenance workflows.
Likely telemetry
- Windows process creation events with command line, parent process, user, and host context
- Registry modification telemetry related to security, backup, or file-handling exclusion settings
- File modification telemetry for configuration files used by antivirus, backup, or file-handling systems
- File system enumeration activity involving critical extensions such as .dll, .exe, and .sys
- Directory access or enumeration telemetry for Program Files, security tool paths, and Windows system component locations
Detection direction
- Build baselines for authorized tools and service accounts that legitimately manage exclusions, then alert on new, rare, or non-whitelisted processes performing similar changes.
- Correlate process ancestry, user identity, host role, and change window context before escalating, because legitimate security, backup, and software-management activity may create false positives.
- Tune for changes to exclusion-related registry or file configuration locations and pair them with process rarity rather than relying on a single event type.
- Review whether telemetry covers both registry-based and file-based configuration changes; a blind spot in either can reduce confidence.
- Use enumeration of critical extensions or sensitive directories as supporting context, especially when followed by exclusion configuration changes.
Mitigation priorities
- Define and document who may create or modify antivirus, backup, and file-handling exclusions on Windows systems.
- Restrict exclusion management to approved administrative channels, managed tools, and authorized roles.
- Require change-control evidence for exclusion additions, especially on servers and critical endpoints.
- Regularly review active exclusions for business justification, owner, scope, and expiration where applicable.
- Ensure SOC and incident response teams have access to process, registry, file, and asset context needed to investigate exclusion changes.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Windows and does not specify tactics, related techniques, malware, groups, or campaigns. The strongest use of this object is as a validation checklist for control-change monitoring and local baselining of approved exclusion-management activity.
Official detection logic is not provided, and no relationship context is supplied. The analytic describes behavior but does not identify specific registry paths, products, or guaranteed indicators. Local environment knowledge is required to distinguish legitimate administration from suspicious activity.
Analytic 2030
A process with no prior history or outside of known whitelisted tools initiates file or registry modifications to configure exclusion rules for antivirus, backup, or file-handling systems. Or a file system enumeration for specific file names andcritical extensions like .dll, .exe, .sys, or specific directories such as 'Program Files' or security tool paths or system component discovery for the exclusion of the files or components.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 8318c1d30477… |
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 AN2030Open 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.