AN1867: Analytic 1867
Monitor for any suspicious attempts to enable script execution on a system. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible, to determine their actions and intent. Monitor executed commands and arguments for actions that could be taken to collect internal data. Monitor for unexpected files (e.g., .pdf, .docx, .jpg) viewed for collecting internal data. Monitor for information collection on assets that may indicate deviations from standard operational tools. Examples include unexpected industrial automation protocol functions, new high volume communication sessions, or broad collection across many hosts within the network.
Analyst context for executives and security teams
This analytic is about spotting suspicious information collection in an ICS environment, especially when script execution is newly enabled, commands appear to gather internal data, unexpected documents or images are accessed, or assets show unusual collection behavior. For leaders, the value is not just detecting a script: it is confirming whether the organization can recognize early reconnaissance or data-gathering activity before it affects operational resilience or incident response decisions.
Executive priority
Treat this as a validation point for ICS monitoring maturity. Security and operations leaders should ask whether script use is expected on critical systems, whether administrative activity is tied to approved patching or maintenance windows, and whether the SOC can distinguish normal engineering activity from broad collection across hosts or unusual industrial protocol behavior. This supports incident triage, audit evidence, and cyber-physical risk governance because unexplained collection activity in operational networks may indicate loss of visibility or control over sensitive operational information.
Technical view
SOC and IR teams should validate monitoring for script-enablement events, executed commands and arguments, file access involving unexpected document or image types, and network/asset behavior that deviates from standard operational tools. The supplied analytic does not specify platforms or ATT&CK tactics, so implementation should be based on local ICS asset roles, approved administration patterns, maintenance windows, and expected industrial automation protocol functions. Capture scripts from the file system where possible so responders can determine intent and scope.
Likely telemetry
- Script execution enablement or configuration-change logs
- Command execution records with command-line arguments
- File system telemetry for script files and accessed documents or images
- Asset activity baselines for standard operational and engineering tools
- Network session metadata, including high-volume or broad host-to-host communication
Detection direction
- Baseline where scripts are normally used and alert on newly enabled script execution outside approved administration or patching activity.
- Review executed commands and arguments for signs of internal data collection, while accounting for legitimate maintenance and engineering workflows.
- Tune detections around unexpected file access patterns, especially document or image viewing that is unusual for the asset role.
- Compare industrial protocol functions, communication volume, and collection breadth against normal operational behavior for each asset or zone.
- Correlate suspicious collection indicators with maintenance windows and known administrator actions to reduce false positives.
Mitigation priorities
- Define and document where script execution is authorized in the ICS environment and under what operational conditions.
- Restrict or review script execution enablement on systems where scripts are not normally required.
- Maintain asset-role baselines for approved tools, expected protocol functions, and normal communication patterns.
- Ensure incident responders can collect relevant scripts, command histories, and file access evidence without disrupting operations.
- Use change-management and maintenance records as required context for SOC triage and compliance evidence.
Analyst notes and limits
The object is an ICS ATT&CK detection analytic, not a technique description. Its practical value is strongest when mapped to local operational baselines: approved scripting, expected administrator activity, normal industrial protocol use, and standard asset communication patterns. No relationship context was supplied, so no related techniques, campaigns, software, groups, or mitigations are inferred.
The supplied object has no platforms, tactics, formal detection field, or relationships. The description provides monitoring guidance but not a complete detection rule, data model, or threshold. Local ICS architecture, logging availability, maintenance practices, and asset criticality are required to make this actionable.
Analytic 1867
Monitor for any suspicious attempts to enable script execution on a system. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible, to determine their actions and intent. Monitor executed commands and arguments for actions that could be taken to collect internal data. Monitor for unexpected files (e.g., .pdf, .docx, .jpg) viewed for collecting internal data. Monitor for information collection on assets that may indicate deviations from standard operational tools. Examples include unexpected industrial automation protocol functions, new high volume communication sessions, or broad collection across many hosts within the network.
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 | 25b96e13f714… |
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 AN1867Open 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.