AN1892: Analytic 1892
On Windows and Unix systems monitor executed commands and arguments that may use shell commands for execution. Shells may be common on administrator, developer, or power user systems depending on job function.
On network device and embedded system CLIs consider reviewing command history if unauthorized or suspicious commands were used to modify device configuration. Monitor logs from installed applications (e.g., historian logs) for unexpected commands or abuse of system features. Monitor for processes spawning from known command shell applications (e.g., PowerShell, Bash). Benign activity will need to be allow-listed. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools.
Analyst context for executives and security teams
AN1892 is a detection analytic about watching command execution and command history for signs that someone is using shells, device CLIs, or application features to change systems or understand the environment. For leaders, the practical issue is visibility: if incident responders cannot reconstruct what commands were run on servers, administrator workstations, network devices, embedded systems, or operational applications such as historians, they may not be able to determine scope, intent, or whether configuration changes created operational risk.
Executive priority
Prioritize this as an evidence-readiness and operational resilience control. The key business question is not simply whether command shells exist, but whether the organization can prove who ran sensitive commands, where they ran, what changed, and whether the activity was authorized. This supports incident response decisions, audit evidence, privileged access oversight, and cyber-physical risk review where device or embedded-system configuration changes could affect operations.
Technical view
SOC and IR teams should validate whether executed commands and arguments are logged where available, whether command history on network device and embedded system CLIs can be reviewed, and whether application logs such as historian logs capture unexpected command use or abuse of built-in features. Detection engineering should focus on processes spawning from known command shell applications such as PowerShell or Bash, while accounting for legitimate administrator, developer, and power-user activity through allow-listing and baselining.
Likely telemetry
- Executed command and command-line argument logs
- Process creation events showing parent-child relationships
- Shell activity from known command shell applications such as PowerShell or Bash
- Network device CLI command history
- Embedded system CLI command history where available
Detection direction
- Confirm that command execution telemetry includes arguments, user context, host/device identity, timestamps, and parent process information where available.
- Tune detections for processes spawning from known shells, but baseline legitimate administrator, developer, and power-user workflows to reduce false positives.
- Review command history and configuration-change evidence for network devices and embedded systems when unauthorized or suspicious changes are suspected.
- Include application-level logs, such as historian logs, because abuse may occur through application features rather than only operating system shells.
- Identify blind spots where shell history is not retained, command arguments are truncated, privileged sessions are not attributable to individuals, or device CLI logging is unavailable.
Mitigation priorities
- Establish or validate logging for command execution, arguments, process ancestry, and privileged user context on systems where supported.
- Enable and retain command history or configuration audit logs for network devices and embedded systems where operationally feasible.
- Collect and review relevant application logs, including historian logs when those applications are in scope.
- Define allow-lists or baselines for expected shell usage by administrators, developers, and power users.
- Correlate suspicious command activity with identity, change-management, and configuration records before escalation decisions.
Analyst notes and limits
The supplied ATT&CK object is an ICS detection analytic with a broad description but no tactics, platforms, relationships, or official detection field beyond the descriptive guidance. The analytic is most useful as a coverage checklist for command and CLI visibility across operating systems, network devices, embedded systems, and relevant applications.
No relationship context, tactic mapping, platform metadata, or formal detection logic was supplied. Local environment details are required to decide which systems support command logging, what activity is normal, what retention is sufficient, and which commands or configuration changes are high risk.
Analytic 1892
On Windows and Unix systems monitor executed commands and arguments that may use shell commands for execution. Shells may be common on administrator, developer, or power user systems depending on job function.
On network device and embedded system CLIs consider reviewing command history if unauthorized or suspicious commands were used to modify device configuration. Monitor logs from installed applications (e.g., historian logs) for unexpected commands or abuse of system features. Monitor for processes spawning from known command shell applications (e.g., PowerShell, Bash). Benign activity will need to be allow-listed. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools.
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 | 9d0f79b830dc… |
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 AN1892Open 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.