T0893 Data from Local System: Detecting Collection of OT Files and Configurations

Data from Local System (T0893) is an adversary reading files, configuration and local databases on OT hosts and devices to learn how your process is built and controlled. Engineering workstations, HMIs, SCADA servers and historians hold exactly what an attacker needs to plan a disruptive attack: project files, controller programs, network drawings, tag lists and alarm settings. MITRE ATT&CK for ICS lists T0893 under the Collection tactic (TA0100) for Embedded, Linux, Network Devices and Windows platforms. This guide is for OT security engineers and OT SOC analysts. It covers what is worth stealing in an OT environment, what ATT&CK's procedure examples show, how ATT&CK v20 suggests detecting bulk reads, and which controls reduce the exposure. For the wider matrix see the MITRE ATT&CK for ICS Guide.

Key takeaways

• Collection usually comes before impact. Drawings, project files and configuration tell an adversary which devices to target and what commands they accept.
• The real cases are espionage malware. ATT&CK's procedure examples for T0893 are Duqu, Flame and ACAD/Medre.A, all of which gathered documents and drawings from infected Windows hosts.
• File-read telemetry has to be switched on. ATT&CK's Windows analytic relies on Security Event ID 4663 with Object Access auditing and SACLs on the monitored paths; Sysmon does not log generic file reads.
• Context beats volume. ATT&CK's OT analytics tell you not to alert on read volume alone, but on bulk reads by an account or process outside the approved engineering, backup or application baseline.
• Least privilege on files is the main prevention. ATT&CK's mitigations are file and directory permissions, encryption of sensitive information, data loss prevention and user training on what may be stored locally.

What T0893 covers in OT

ATT&CK for ICS describes T0893 as adversaries collecting data from local system sources such as file systems, configuration files or local databases, including specifications, schematics or diagrams of control system layouts, devices and processes. The Enterprise equivalent is T1005 Data from Local System; the ICS entry exists because the files on OT hosts carry process knowledge rather than business data. Related collection techniques are T0802 Automated Collection and T0811 Data from Information Repositories, and the stolen material often feeds T0882 Theft of Operational Information.

The procedure examples and what they teach

• ACAD/Medre.A (S1000): ESET's analysis describes an AutoLISP worm that copied itself into folders of opened AutoCAD drawings and emailed the drawings out in encrypted archives through accounts on public mail services. ESET reported tens of thousands of drawings leaking, mainly from users in Peru, and noted that outbound SMTP on port 25 was allowed from the infected machines. The lesson: design files on engineering hosts are a target in themselves, and unrestricted outbound mail is an exfiltration path.
• Duqu (S0038): ATT&CK records Duqu downloading modules named infostealer 1, infostealer 2 and reconnaissance, and staging collected data by copying, compressing and XOR-encrypting it. The lesson: staging and compression after bulk reads is a detectable pattern.
• Flame (S0143): ATT&CK describes Flame, used since at least 2010 largely against Middle East targets, collecting AutoCAD designs, Visio diagrams and other documents with operational information from local systems.

None of these is an OT-specific disruptive tool. They are reminders that ordinary espionage malware on a Windows engineering host can take the most sensitive OT knowledge with no OT protocol involved.

Detection: what ATT&CK v20 suggests

ATT&CK v20's detection strategy for T0893 has four platform analytics. The common thread is an OT operational fidelity gate: do not alert on novelty or read volume alone, and suppress normal SCADA, HMI and historian polling, commissioning, asset inventory, backup, diagnostics and approved engineering activity.

The work is mostly in scoping. Decide which directories hold project files, tag databases and drawings on each host, put SACLs on those paths only, and record which accounts and executables normally read them. Auditing every file on an HMI produces noise and can affect performance, so test the audit policy on a non-production host first. See the OT Network Security Monitoring Guide for the network side.

Prevention: ATT&CK mitigations in practice

• M0922 Restrict File and Directory Permissions: limit read access to project, configuration and drawing folders to the engineering and service accounts that need it. HMI operator accounts rarely need to read controller project files.
• M0941 Encrypt Sensitive Information: encrypt information that is sensitive to the operation and architecture of the process, so a copied file is less useful and access is limited to those who need to know.
• M0803 Data Loss Prevention: restrict access to sensitive data and detect sensitive data held unencrypted. In OT this is usually simpler egress control at the conduit rather than a full DLP suite on every host.
• M0917 User Training: publish a policy on what information may be stored on local systems, so drawings and full project archives are not left on HMIs and laptops by habit.

Two controls from the procedure examples add to these. Block direct outbound mail and internet access from OT hosts, which would have stopped ACAD/Medre.A's exfiltration route, and keep authoritative project archives in one controlled repository rather than copies spread across every engineering laptop. See the Engineering Workstation Security Guide and the Data Loss Prevention (DLP) Guide.

Where identity fits

File permissions are only as good as the accounts behind them. Shared engineering logins and generic service accounts on historians and SCADA servers make the "approved account" baseline meaningless, because every reader looks the same. Use named accounts for engineers, separate service accounts per application with read access only to their own paths, and time-bound access for vendors and integrators. See the OT and ICS Identity and Access Guide.

How to implement

1. Inventory sensitive local data. With control engineers, list the paths on each engineering workstation, HMI, SCADA server and historian that hold project files, tag databases, drawings and configuration.
2. Tighten permissions. Remove broad read groups from those paths, test that HMI and historian applications still run, and keep the previous ACLs recorded so they can be restored.
3. Turn on targeted auditing. Enable Object Access auditing with SACLs on the listed paths only, and Linux audit rules for equivalent paths, on a pilot host first.
4. Baseline readers. Collect two to four weeks of events (our recommendation) to learn which accounts and processes read the files and when backups run.
5. Deploy alerts. Alert on bulk reads by unapproved accounts or processes, especially when followed by archive creation or transfer outside the ICS zone.
6. Close egress. Block direct internet and mail from OT zones at the conduit and route approved transfers through a controlled exchange point.

Decision guidance

• Small sites: permissions on a short list of folders, no direct internet or mail from OT, and an offline central project archive cover most of the risk without new tools.
• Large sites: add SIEM-based 4663 and auditd analytics, flow monitoring at conduits and protocol-aware monitoring for configuration reads from field devices. See the OT Security Operations Centre Guide.
• Legacy hosts that cannot be audited: rely on network egress monitoring and strict permissions, and move sensitive files off the host where operations allow.

Responding to suspected collection

Collection does not change the process, so there is time to investigate without disturbing operations. Preserve the audit logs, file access history and any archives found on the host, then identify what was read and whether it left the zone. Assume anything taken gives the adversary knowledge of the process and controllers, review which follow-on techniques that knowledge enables, and raise monitoring on the controllers described in the stolen files. Investigate the account and host involved as likely compromised. See the OT Incident Response Guide.

Detection and measurement

• Path coverage: percentage of OT hosts with sensitive data paths documented and audited.
• Permission hygiene: number of accounts with read access to project and configuration folders, tracked against the approved list.
• Stray copies: count of project archives or drawings found outside the controlled repository during periodic sweeps.
• Egress exposure: number of OT hosts able to reach the internet or external mail directly.
• Alert outcomes: bulk-read alerts investigated, and the share traced to approved work.

Framework mapping

Common failure patterns

• Everyone can read the project folder: default groups on engineering shares give every account access to controller logic.
• Auditing not enabled: teams assume their EDR or Sysmon records file reads, then find no evidence after an incident.
• Auditing everything: SACLs on whole drives create noise and load that leads to the policy being switched off.
• Drawings scattered everywhere: copies on HMIs, laptops and file shares mean no single place to protect or monitor.
• Open outbound mail or internet from OT: the exfiltration route ACAD/Medre.A relied on.

Practitioner checklist

• List sensitive data paths on every engineering workstation, HMI, SCADA server and historian.
• Restrict read access on those paths to named engineering and application accounts.
• Enable Object Access auditing with SACLs on those paths only, and equivalent Linux audit rules.
• Baseline normal readers and backup windows before alerting.
• Alert on bulk reads followed by archive creation or transfer outside the ICS zone.
• Monitor ICS protocol sessions for configuration reads from unfamiliar sources.
• Block direct internet and mail access from OT zones.
• Keep project archives in one controlled repository and sweep for stray copies.

Standards and references

• MITRE ATT&CK for ICS: Data from Local System (T0893)
• MITRE ATT&CK: ACAD/Medre.A (S1000)
• MITRE ATT&CK: Duqu (S0038)
• MITRE ATT&CK: Flame (S0143)
• ESET: ACAD/Medre.A whitepaper
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Engineering Workstation Security Guide · HMI and SCADA Server Hardening Guide · OT Network Security Monitoring Guide · OT and ICS Identity and Access Guide