AN1890: Analytic 1890
Monitor for changes made to a large quantity of files for unexpected modifications in both user directories and directories used to store programs and OS components (e.g., C:\Windows\System32). Monitor for newly executed processes of binaries that could be involved in data destruction activity, such as SDelete. Monitor for unexpected deletion of files. Monitor executed commands and arguments for binaries that could be involved in data destruction activity, such as SDelete.
Analyst context for executives and security teams
Analytic 1890 is a detection analytic for spotting potential data destruction behavior: many file modifications, unexpected file deletion, and execution of utilities or commands associated with destructive deletion such as SDelete. For security leaders, the value is not just alerting on a tool name; it is confirming whether the organization can quickly see and investigate file-destruction indicators before they affect operational continuity, recovery options, or evidence preservation.
Executive priority
Prioritize this as a resilience and incident-response readiness question: can the SOC detect abnormal bulk file changes or deletions in important user, program, and operating system directories, and can IR teams rapidly determine scope? Because this object is in the ICS ATT&CK domain, leaders should also ask whether monitoring and response expectations are defined for environments where loss of files or system components could affect operations. The supplied ATT&CK fields do not specify platforms, tactics, relationships, or a formal detection logic, so local asset criticality and telemetry availability should drive prioritization.
Technical view
Validate collection and alerting for four evidence patterns directly reflected in the ATT&CK description: large-volume file modifications, unexpected changes in user and system/program directories, newly executed processes for binaries associated with data destruction such as SDelete, and command-line arguments for such binaries. Since no ATT&CK detection logic or platform list is provided, detection engineers should translate this into environment-specific baselines, thresholds, and allowlists rather than relying on static tool-name matching alone.
Likely telemetry
- File creation, modification, and deletion events from endpoints or monitored file systems
- Process execution events for newly launched binaries
- Command-line and process argument logging
- Directory-level monitoring for user directories and locations used for programs or operating system components, including paths such as C:\Windows\System32 when applicable
- Asset and directory criticality context to distinguish routine administrative activity from destructive patterns
Detection direction
- Baseline normal file modification and deletion volume by host, user, directory, and workload before setting high-confidence thresholds.
- Correlate bulk file changes or deletions with process execution and command-line evidence for utilities that can perform destructive deletion, including SDelete as named by ATT&CK.
- Tune for legitimate administrative, patching, backup, cleanup, and software deployment activity to reduce false positives.
- Avoid blind reliance on specific binary names; unexpected deletion behavior may matter even when the tool is renamed or a different utility is used.
- Confirm whether critical user, program, and operating system component directories are actually covered by telemetry in the relevant environments.
Mitigation priorities
- Ensure high-value systems and directories have sufficient file and process telemetry before depending on this analytic for coverage.
- Define response playbooks for suspected destructive file activity, including triage, containment decision points, preservation of evidence, and recovery coordination.
- Review access controls and administrative procedures around tools and permissions capable of large-scale file deletion.
- Maintain recovery readiness for critical files and systems, since detection of destructive activity may occur after modification or deletion has begun.
- Use the analytic to support compliance and audit evidence by documenting what directories, event sources, thresholds, and response procedures are in scope.
Analyst notes and limits
The official object provides a descriptive monitoring objective but no formal detection logic, platforms, tactics, or relationships. The most defensible implementation is behavior-based: combine file-change volume, deletion events, process starts, and command-line arguments, then tune against local administrative patterns and critical asset context.
This take is limited to the supplied MITRE fields and external reference for AN1890. It does not establish active exploitation, attribution, affected products, guaranteed detection, or specific platform coverage. Local endpoint, server, ICS, and file-system logging capabilities must be validated before using this as a coverage claim.
Analytic 1890
Monitor for changes made to a large quantity of files for unexpected modifications in both user directories and directories used to store programs and OS components (e.g., C:\Windows\System32). Monitor for newly executed processes of binaries that could be involved in data destruction activity, such as SDelete. Monitor for unexpected deletion of files. Monitor executed commands and arguments for binaries that could be involved in data destruction activity, such as SDelete.
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 | a605794a9d50… |
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 AN1890Open 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.