T0893: Data from Local System
Adversaries may target and collect data from local system sources, such as file systems, configuration files, or local databases. This can include sensitive data such as specifications, schematics, or diagrams of control system layouts, devices, and processes.
Adversaries may do this using Command-Line Interface or Scripting techniques to interact with the file system to gather information. Adversaries may also use Automated Collection on the local system.
Analyst context for executives and security teams
This technique matters because local ICS systems often hold the information an adversary needs to understand operations: engineering files, control layouts, schematics, configuration files, local databases, and process documentation. Even before disruption occurs, collection from workstations, HMIs, historians, control servers, application servers, jump hosts, switches, and firewalls can expose operational knowledge that increases risk to safety, resilience, intellectual property, and incident response decision-making.
Executive priority
Leaders should treat this as an operational information protection issue, not just endpoint monitoring. The priority is to know where sensitive ICS design and process data resides, who can access it, whether access is logged, and whether loss of that data would affect business continuity, regulatory evidence, or cyber-physical risk. Budget and control decisions should prioritize file permission hygiene, encryption of sensitive information, DLP where appropriate, and user training around attempts to obtain or manipulate access.
Technical view
SOC, detection engineering, and IR teams should validate visibility into local file access and collection behavior on the ICS assets identified in the ATT&CK relationships, especially engineering workstations, HMIs, data historians, control servers, application servers, and jump hosts. Because the ATT&CK object provides no official detection text, teams should use DET0749 as the linked detection strategy reference and tune locally for unusual access to engineering files, configuration stores, local databases, diagrams, schematics, and process telemetry repositories. Related techniques in the description include command-line interface, scripting, and automated collection, so validation should include whether those activity classes are logged and reviewable in ICS zones.
Likely telemetry
- File access, file read, file copy, and directory enumeration logs on ICS workstations and servers
- Endpoint process execution telemetry for command-line and scripting activity where safely collectable
- Authentication and authorization logs showing access to sensitive local directories, databases, and configuration files
- Database access logs for local historian or application data stores where available
- DLP alerts or audit events for attempted transfer of engineering plans, recipes, intellectual property, process telemetry, or similar operational information
Detection direction
- Confirm which ICS assets actually contain sensitive operational files and whether file access to those locations is logged.
- Prioritize monitoring of engineering workstations, HMIs, historians, control servers, application servers, and jump hosts because these are explicitly targeted assets for this technique.
- Tune for unusual bulk access, access outside normal engineering workflows, unexpected scripting or command-line interaction with sensitive directories, and access by accounts that do not normally handle control-system documentation.
- Use DLP detections cautiously in ICS environments: validate that monitored data categories map to real operational information and that controls do not disrupt legitimate engineering or operational workflows.
- Account for false positives from maintenance, backups, reporting, engineering changes, and historian exports; detection should rely on baselines and asset role context.
Mitigation priorities
- Inventory sensitive local ICS data stores, including configuration files, schematics, diagrams, engineering plans, local databases, recipes, intellectual property, and process telemetry repositories.
- Restrict file and directory permissions so access aligns with operational roles and privileged accounts are not broadly exposed.
- Encrypt sensitive information at rest where supported by the asset and operational constraints.
- Deploy or tune DLP capabilities at appropriate host, network, email, web, or physical media transfer points to identify attempted movement of operational information.
- Train users who access ICS environments to recognize social engineering or access manipulation attempts that could lead to unauthorized data collection.
Analyst notes and limits
The object is in the ICS ATT&CK domain and is linked to multiple ICS asset types, including workstations, HMIs, data historians, control servers, application servers, jump hosts, switches, and firewalls. ATT&CK also links software examples Duqu, Flame, and ACAD/Medre.A as using this behavior; this should be used as historical technique context, not as evidence of current activity in any environment.
MITRE provides no official detection text, no tactic value, and no platform value directly on the technique. Platform context comes only from related ICS assets and software relationships. Local architecture, asset criticality, logging capability, and operational workflow baselines are required before making coverage or exposure claims.
Data from Local System
Adversaries may target and collect data from local system sources, such as file systems, configuration files, or local databases. This can include sensitive data such as specifications, schematics, or diagrams of control system layouts, devices, and processes.
Adversaries may do this using Command-Line Interface or Scripting techniques to interact with the file system to gather information. Adversaries may also use Automated Collection on the local system.
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.
Groups, software, and campaigns
S0038: Duqu
S0143: Flame
S1000: ACAD/Medre.A
ACAD/Medre.A is a worm that steals operational information. The worm collects AutoCAD files with drawings. ACAD/Medre.A has the capability to be used for industrial espionage.[1]
All related ATT&CK context
Mitigation direction
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 | 20796c65f17a… |
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 T0893Open 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.