M0947: Audit
Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses. Perform periodic integrity checks of the device to validate the correctness of the firmware, software, programs, and configurations. Integrity checks, which typically include cryptographic hashes or digital signatures, should be compared to those obtained at known valid states, especially after events like device reboots, program downloads, or program restarts.
Analyst context for executives and security teams
Audit is a foundational ICS mitigation: routinely check systems, permissions, software, configurations, firmware, programs, and device integrity against known-good states. Its business value is reducing uncertainty about whether control-system assets have drifted, been misconfigured, or been changed in ways that could affect safe and reliable operations.
Executive priority
Prioritize this as an assurance and resilience control for ICS environments. It supports compliance mappings listed by ATT&CK, including IEC 62443 SR/CR 3.4 and NIST SP 800-53 SI-7, and helps leaders ask whether critical controllers, engineering workstations, project files, firmware, and permissions can be independently verified after reboots, program downloads, program restarts, or maintenance activity.
Technical view
For SOC, IR, and engineering teams, validate that audit processes cover the change paths reflected in the mitigated techniques: controller tasking changes, parameter changes, program download variants, program modification, firmware modification, project file infection, valid-account abuse, transient assets, supply-chain compromise, and access to information repositories. The core defensive requirement is a trustworthy known-good baseline and repeatable comparison using integrity checks such as cryptographic hashes or digital signatures where available.
Likely telemetry
- Asset, software, firmware, program, and configuration inventory records
- Known-good firmware, software, controller program, project file, and configuration baselines
- Cryptographic hash or digital signature verification results
- Permission and account review outputs, including default or unnecessary access findings
- Audit or scan findings for insecure software and insecure configurations
Detection direction
- ATT&CK provides no official detection text for this mitigation, so coverage must be validated locally rather than assumed.
- Confirm audits are not limited to IT hosts; include ICS-relevant firmware, controller logic, tasking, parameters, project files, and configuration states where the environment supports it.
- Tune review workflows to distinguish authorized engineering or maintenance changes from unexpected drift, especially after reboots, downloads, restarts, and project-file updates.
- Validate that known-good baselines are protected from unauthorized modification; otherwise integrity comparison can produce false assurance.
- Look for blind spots around transient assets, vendor-supplied software or firmware, default/valid accounts, and repositories containing control-system specifications or diagrams.
Mitigation priorities
- Establish and protect known-good baselines for critical ICS firmware, software, programs, configurations, permissions, and project files.
- Schedule periodic audits and scans for insecure software, insecure configurations, and excessive permissions.
- Perform integrity checks after device reboots, program downloads, program restarts, and other engineering change events.
- Include controller logic, tasking, parameters, and firmware in change review where technically feasible.
- Use audit findings to drive remediation priorities, compliance evidence, and incident-response scoping.
Analyst notes and limits
This mitigation is broad but especially material in ICS because many related techniques involve unauthorized or unsafe changes to controller programs, parameters, firmware, project files, accounts, or repositories. The decision value is whether the organization can prove what changed, when it changed, and whether the current state still matches an approved baseline.
Platforms, tactics, and official detection guidance are not specified in the supplied ATT&CK object. Implementation details, available telemetry, and integrity-check mechanisms depend on the local ICS architecture, device capabilities, engineering tools, and operational constraints.
Audit
Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses. Perform periodic integrity checks of the device to validate the correctness of the firmware, software, programs, and configurations. Integrity checks, which typically include cryptographic hashes or digital signatures, should be compared to those obtained at known valid states, especially after events like device reboots, program downloads, or program restarts.
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.
Techniques used
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0862 | Supply Chain Compromise | Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses. Perform periodic integrity checks of the device to validate the correctness of the firmware, software, programs, and configurations. Integrity checks, which typically include cryptographic hashes or digital signatures, should be compared to those obtained at known valid states, especially after events like device reboots, program downloads, or program restarts. |
| ICS | T0843 | Program Download | Provide the ability to verify the integrity of programs downloaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically secure and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.CitationIEC February 2019 |
| ICS | T0843.001 | Download All Sub-technique | Provide the ability to verify the integrity of programs downloaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically secure and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.CitationIEC February 2019 |
| ICS | T0811 | Data from Information Repositories | Consider periodic reviews of accounts and privileges for critical and sensitive repositories. |
| ICS | T0889 | Modify Program | Provide the ability to verify the integrity of control logic or programs loaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically strong and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used. CitationIEC February 2019 |
| ICS | T0864 | Transient Cyber Asset | Integrity checking of transient assets can include performing the validation of the booted operating system and programs using TPM-based technologies, such as Secure Boot and Trusted Boot. CitationEmerson Exchange It can also include verifying filesystem changes, such as programs and configuration files stored on the system, executing processes, libraries, accounts, and open ports. CitationNational Security Agency February 2016 |
| ICS | T0836 | Modify Parameter | Provide the ability to verify the integrity and authenticity of changes to parameter values. |
| ICS | T0851 | Rootkit | Audit the integrity of PLC system and application code functionality, such as the manipulation of standard function blocks (e.g., Organizational Blocks) that manage the execution of application logic programs. CitationIEC February 2019 |
| ICS | T0821 | Modify Controller Tasking | Provide the ability to verify the integrity of controller tasking. While techniques like CRCs and checksums are commonly used, they are not cryptographically secure and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used. CitationIEC February 2019 |
| ICS | T1693 | Modify Firmware | Perform integrity checks of firmware before uploading it on a device. Utilize cryptographic hashes to verify the firmware has not been tampered with by comparing it to a trusted hash of the firmware. This could be from trusted data sources (e.g., vendor site) or through a third-party verification service. |
| ICS | T1693.001 | System Firmware Sub-technique | Perform integrity checks of firmware before uploading it on a device. Utilize cryptographic hashes to verify the firmware has not been tampered with by comparing it to a trusted hash of the firmware. This could be from trusted data sources (e.g., vendor site) or through a third-party verification service. |
| ICS | T0843.003 | Program Append Sub-technique | Provide the ability to verify the integrity of programs downloaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically secure and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.CitationIEC February 2019 |
| ICS | T0830 | Adversary-in-the-Middle | Limit access to network infrastructure and resources that can be used to reshape traffic or otherwise produce AiTM conditions. |
| ICS | T1693.002 | Module Firmware Sub-technique | Perform integrity checks of firmware before uploading it on a device. Utilize cryptographic hashes to verify the firmware has not been tampered with by comparing it to a trusted hash of the firmware. This could be from trusted data sources (e.g., vendor site) or through a third-party verification service. |
| ICS | T0874 | Hooking | Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses. Perform periodic integrity checks of the device to validate the correctness of the firmware, software, programs, and configurations. Integrity checks, which typically include cryptographic hashes or digital signatures, should be compared to those obtained at known valid states, especially after events like device reboots, program downloads, or program restarts. |
| ICS | T0859 | Valid Accounts | Routinely audit source code, application configuration files, open repositories, and public cloud storage for insecure use and storage of credentials. |
| ICS | T0843.002 | Online Edit Sub-technique | Provide the ability to verify the integrity of programs downloaded on a controller. While techniques like CRCs and checksums are commonly used, they are not cryptographically secure and can be vulnerable to collisions. Preferably cryptographic hash functions (e.g., SHA-2, SHA-3) should be used.CitationIEC February 2019 |
| ICS | T0873.001 | Siemens Project File Format Sub-technique | Review the integrity of project files to verify they have not been modified by adversary behavior. Verify a cryptographic hash for the file with a known trusted version, or look for other indicators of modification (e.g., timestamps). |
| ICS | T0873 | Project File Infection | Review the integrity of project files to verify they have not been modified by adversary behavior. Verify a cryptographic hash for the file with a known trusted version, or look for other indicators of modification (e.g., timestamps). |
All related ATT&CK context
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.1 | Current bundle | 47c65bb5d8ca… |
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 M0947Open 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.