Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1552.003: Shell History

Adversaries may search the command history on compromised systems for insecurely stored credentials.

On Linux and macOS systems, shells such as Bash and Zsh keep track of the commands users type on the command-line with the "history" utility. Once a user logs out, the history is flushed to the user's history file. For each user, this file resides at the same location: for example, `~/.bash_history` or `~/.zsh_history`. Typically, these files keeps track of the user's last 1000 commands.

On Windows, PowerShell has both a command history that is wiped after the session ends, and one that contains commands used in all sessions and is persistent. The default location for persistent history can be found in `%userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt`, but command history can also be accessed with `Get-History`. Command Prompt (CMD) on Windows does not have persistent history.[1][2]

Users often type usernames and passwords on the command-line as parameters to programs, which then get saved to this file when they log out. Adversaries can abuse this by looking through the file for potential credentials.[3]

EnterpriseT1552.003Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Shell History matters because routine administrator or developer command history can become an unplanned credential store. If users pass usernames, passwords, tokens, or other secrets as command-line parameters, those values may persist in Bash, Zsh, or PowerShell history and give an intruder a fast path from one compromised workstation or server to broader access.

Executive priority

Treat this as a credential hygiene and resilience issue, not just an endpoint artifact. Leaders should ask whether privileged users, Linux/macOS administrators, and Windows PowerShell users can leave reusable credentials in history files, whether SOC teams can see suspicious access to those files, and whether operating system configuration standards reduce persistent exposure. This is relevant to incident scoping, audit evidence for secure configuration, and prioritizing basic controls that prevent one compromised host from becoming an identity compromise.

Technical view

ATT&CK lists Shell History as credential-access sub-technique T1552.003 under Unsecured Credentials, covering Linux, macOS, and Windows. Detection text is not provided by MITRE for this object, but the related DET0385 strategy specifically focuses on access and parsing of .bash_history files for credential harvesting. SOC and IR teams should validate visibility into reads of user shell history files such as ~/.bash_history and ~/.zsh_history, and Windows PowerShell persistent history at %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt, as well as use of Get-History where observable.

Likely telemetry

  • Endpoint file access telemetry for shell history paths, including user context and process name
  • Process execution and command-line telemetry for shells and tools interacting with history files
  • PowerShell activity telemetry sufficient to identify history access, including Get-History where collected
  • File integrity or audit events on history files in user profiles
  • Incident response collection of local user history files during credential exposure triage

Detection direction

  • Validate coverage separately for Linux, macOS, and Windows because history storage and observability differ by shell and platform.
  • Use DET0385 as a starting point for .bash_history access/parsing, but do not assume it covers Zsh history or Windows PowerShell history without local validation.
  • Tune for unusual processes, non-owner access, bulk collection, or scripted parsing of history files while accounting for legitimate administration, backup, EDR, and user shell behavior.
  • During investigations, search history artifacts for exposed credentials only under controlled IR procedures, then treat any discovered secrets as potentially compromised.
  • Correlate shell history access with the broader T1552 Unsecured Credentials pattern when assessing credential-theft risk.

Mitigation priorities

  • Prioritize operating system configuration hardening as identified by ATT&CK mitigation M1028.
  • Review shell and PowerShell history settings to reduce unnecessary persistence of sensitive command data where business operations allow.
  • Harden permissions and user profile access so history files are not broadly readable beyond the intended user and authorized administrators.
  • Reduce the practice of passing credentials as command-line parameters through administrative standards and secure operational procedures.
  • Include shell history review in secure configuration baselines and incident response credential-rotation criteria.
Analyst notes and limits

T1139 Bash History is revoked by this sub-technique, so current analysis should use T1552.003. The related software S0599 Kinsing is documented as using this object, but that relationship should be treated as context only and not as evidence of activity in any specific environment.

MITRE provides no official detection text for this object. The supplied detection relationship is narrower than the full technique because it names .bash_history specifically, while the technique also covers Zsh and Windows PowerShell history. Local shell configuration, audit policy, endpoint tooling, and user behavior determine actual exposure and detection feasibility.

Official MITRE ATT&CK definition

Shell History

Adversaries may search the command history on compromised systems for insecurely stored credentials.

On Linux and macOS systems, shells such as Bash and Zsh keep track of the commands users type on the command-line with the "history" utility. Once a user logs out, the history is flushed to the user's history file. For each user, this file resides at the same location: for example, `~/.bash_history` or `~/.zsh_history`. Typically, these files keeps track of the user's last 1000 commands.

On Windows, PowerShell has both a command history that is wiped after the session ends, and one that contains commands used in all sessions and is persistent. The default location for persistent history can be found in `%userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt`, but command history can also be accessed with `Get-History`. Command Prompt (CMD) on Windows does not have persistent history.[1][2]

Users often type usernames and passwords on the command-line as parameters to programs, which then get saved to this file when they log out. Adversaries can abuse this by looking through the file for potential credentials.[3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1552 Unsecured Credentials This object subtechnique of Unsecured Credentials.
Enterprise T1139 Bash History Bash History revoked by this object.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0599: Kinsing

Kinsing is Golang-based malware that runs a cryptocurrency miner and attempts to spread itself to other hosts in the victim environment. [1][2][3]

ContainersLinux
Relationship explorer

All related ATT&CK context

uses · Malware S0599: Kinsing Enterprise mitigates · Mitigation M1028: Operating System Configuration Enterprise subtechnique of · Technique T1552: Unsecured Credentials Enterprise detects · Detection Strategy DET0385: Detect Access and Parsing of .bash_history Files for Credential Harvesting Enterprise revoked by · Technique T1139: Bash History Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1028: Operating System Configuration

Operating System Configuration involves adjusting system settings and hardening the default configurations of an operating system (OS) to mitigate adversary exploitation and prevent abuse of system functionality. Proper OS configurations address security vulnerabilities, limit attack surfaces, and ensure robust defense against a wide range of techniques. This mitigation can be implemented through the following measures:

Disable Unused Features:

- Turn off SMBv1, LLMNR, and NetBIOS where not needed. - Disable remote registry and unnecessary services.

Enforce OS-level Protections:

- Enable Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and Control Flow Guard (CFG) on Windows. - Use AppArmor or SELinux on Linux for mandatory access controls.

Secure Access Settings:

- Enable User Account Control (UAC) for Windows. - Restrict root/sudo access on Linux/macOS and enforce strong permissions using sudoers files.

File System Hardening:

- Implement least-privilege access for critical files and system directories. - Audit permissions regularly using tools like icacls (Windows) or getfacl/chmod (Linux/macOS).

Secure Remote Access:

- Restrict RDP, SSH, and VNC to authorized IPs using firewall rules. - Enable NLA for RDP and enforce strong password/lockout policies.

Harden Boot Configurations:

- Enable Secure Boot and enforce UEFI/BIOS password protection. - Use BitLocker or LUKS to encrypt boot drives.

Regular Audits:

- Periodically audit OS configurations using tools like CIS Benchmarks or SCAP tools.

*Tools for Implementation*

Windows:

- Microsoft Group Policy Objects (GPO): Centrally enforce OS security settings. - Windows Defender Exploit Guard: Built-in OS protection against exploits. - CIS-CAT Pro: Audit Windows security configurations based on CIS Benchmarks.

Linux/macOS:

- AppArmor/SELinux: Enforce mandatory access controls. - Lynis: Perform comprehensive security audits. - SCAP Security Guide: Automate configuration hardening using Security Content Automation Protocol.

Cross-Platform:

- Ansible or Chef/Puppet: Automate configuration hardening at scale. - OpenSCAP: Perform compliance and configuration checks.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
ced044272d15f678...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle ced044272d15…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Microsoft about_History

    Microsoft. (2024, January 19). about_History. Retrieved June 13, 2025.

    Open source URL
  2. [2]
    Medium

    Michael Koczwara. (2021, March 14). Windows privilege escalation via PowerShell History. Retrieved June 13, 2025.

    Open source URL
  3. [3]
    External to DA, the OS X Way

    Alex Rymdeko-Harvey, Steve Borosh. (2016, May 14). External to DA, the OS X Way. Retrieved September 12, 2024.

    Open source URL
  4. [4]
    mitre-attack T1552.003
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use