AN1868: Analytic 1868
Monitor command-line arguments for script execution and subsequent behavior. Actions may be related to network and system information Discovery, Collection, or other scriptable post-compromise behaviors and could be used as indicators of detection leading back to the source script. Scripts are likely to perform actions with various effects on a system that may generate events, depending on the types of monitoring used. Monitor log files for process execution through command-line and scripting activities. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools. Also monitor for loading of modules associated with specific languages. Monitor contextual data about a running process, which may include information such as environment variables, image name, user/owner, or other information that may reveal abuse of system features. Monitor for events associated with scripting execution, such as the loading of modules associated with scripting languages (e.g., JScript.dll, vbscript.dll). Monitor for any attempts to enable scripts running on a system would be considered suspicious. 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.
Analyst context for executives and security teams
This analytic is about making script execution visible before it becomes an unexplained incident. In practical terms, scripts can be used for legitimate administration, but they can also drive discovery, collection, and other post-compromise activity. The business value is not simply detecting “a script”; it is being able to answer who enabled or ran scripting, what the script caused the system to do, and whether that activity fits normal maintenance or administration patterns.
Executive priority
Prioritize this as a visibility and readiness control, especially for environments where script use should be limited, scheduled, or tightly governed. Leaders should ask whether SOC and incident response teams can reconstruct script-driven activity from logs, process context, module loads, and captured script content. This supports operational resilience, audit evidence, and faster incident decision-making because script activity without context can otherwise delay scoping and containment.
Technical view
Validate collection and review of command-line arguments, process execution logs, scripting activity, loaded scripting-language modules, and contextual process data such as image name, user or owner, and environment variables. Since no specific platform or tactic is supplied for this analytic, detection engineering should map it to local systems where scripting is permitted or restricted. Focus on identifying script execution, attempts to enable scripting, execution outside normal patching or administrator windows, and follow-on behavior that may indicate discovery, collection, or other scriptable post-compromise actions.
Likely telemetry
- Command-line arguments for script execution
- Process execution logs
- Scripting activity events
- Loaded modules associated with scripting languages, such as JScript.dll or vbscript.dll where applicable
- Running process context, including image name, user or owner, and environment variables
Detection direction
- Baseline where scripts are normally used, by whom, and during which administrative or patching windows.
- Tune for script execution on systems where scripting is uncommon or newly enabled.
- Correlate script execution with subsequent process, network, system discovery, or collection-related behavior rather than relying on script presence alone.
- Review module loads associated with scripting languages as supporting evidence, not as standalone proof of malicious activity.
- Preserve script files when possible so responders can determine intent and downstream actions.
Mitigation priorities
- Establish governance for where scripts are allowed and who may enable or execute them.
- Ensure logging captures command-line, process execution, scripting events, module loads, and relevant process context before an incident occurs.
- Limit or monitor script enablement on systems where scripts are not expected.
- Define approved maintenance and administrator activity windows to support triage.
- Create incident response procedures for collecting scripts from the file system and correlating them with process and user activity.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS ATT&CK domain, but it does not specify platforms, tactics, or relationship context. The strongest use of this analytic is as a coverage validation checklist for script execution visibility and triage readiness, rather than as a single detection rule.
No official detection logic, platforms, tactics, aliases, labels, or relationships were supplied. Local environment baselines are required to decide what script activity is normal, suspicious, or policy-violating. This summary does not imply active exploitation, attribution, or guaranteed detection coverage.
Analytic 1868
Monitor command-line arguments for script execution and subsequent behavior. Actions may be related to network and system information Discovery, Collection, or other scriptable post-compromise behaviors and could be used as indicators of detection leading back to the source script. Scripts are likely to perform actions with various effects on a system that may generate events, depending on the types of monitoring used. Monitor log files for process execution through command-line and scripting activities. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools. Also monitor for loading of modules associated with specific languages. Monitor contextual data about a running process, which may include information such as environment variables, image name, user/owner, or other information that may reveal abuse of system features. Monitor for events associated with scripting execution, such as the loading of modules associated with scripting languages (e.g., JScript.dll, vbscript.dll). Monitor for any attempts to enable scripts running on a system would be considered suspicious. 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.
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 | c8470e992dee… |
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 AN1868Open 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.