ATT&CK Technique
Bash History
T1139 · credential-access
▤ Generate a SIEM detection for T1139
◈ Deployable detections for T1139
⚠ CVEs mapped to T1139
♛ Hunt package for T1139
Bash keeps 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 .bash_history file. For each user, this file resides at the same location: ~/.bash_history.
Typically, this file keeps track of the user’s last 500 commands. 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. Attackers can abuse this by looking through the file for potential credentials.
LinuxmacOS
▸
How to use this page - the detection-engineering loop
Attackers have goals (tactics - “get credentials”, “move laterally”) and techniques are the concrete methods they use to reach them. This page is one method - T1139 - broken into everything you need to catch it.
The loop this page is built for (this is the job):
- Understand the behaviour - read the description and the Atomic Tests to see exactly what the attacker does on a host or network.
- Find the telemetry - what data source would reveal it (process creation, registry, network flow, auth logs). Detection Coverage shows which surfaces already have a rule and which are blind.
- Get or write the detection - adapt ready logic (CAR Analytics, SIEM Detections, Falco, or Sigma via Generate a SIEM detection), or author your own.
- Test it - run an Atomic Test in a lab and confirm your rule actually fires. A detection you have not tested is a hope, not coverage.
- Deploy and tune - push it, then watch for false positives and adjust.
What each panel is for:
Atomic Testssafely reproduce the technique in a lab to validate that a detection fires.
Detection Coveragewhich detection surfaces have a rule for this technique; none is a blind spot to close, or simply not applicable (YARA matches files, not network behaviour).
CAR / SIEM / Falcoready-made detection logic (Splunk SPL, Elastic EQL, Sentinel KQL, Falco) you adapt to your own SIEM.
Mitigationsreduce exposure so the technique is harder to use at all - prevent, not just detect.
Actors / Attributionwho actually uses this, so you prioritise by your own threat model.
Attack Path / LOTLwhat attackers do before and after this step, and the legitimate tools they abuse to do it.
Where this fits: you usually arrive here from a CVE (“which techniques does it enable”) and leave with a tested detection deployed. The buttons above jump straight to building one, the deployable rules, the CVEs that use T1139, and a hunt package.
◈
Detection Coverage
0/9 layersCoverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma)
none
Analytics (MITRE CAR)
none
Runtime / container (Falco)
none
File / malware (YARA)
none
Network (Suricata/Snort)
none
Vuln scan (Nuclei)
none
SIEM (Splunk ESCU)
none
SIEM (Elastic)
none
SIEM (Azure Sentinel)
none
External lookups - second-class, for what we don’t hold ourselves