AN0293: Analytic 0293
Execution of hash cracking binaries or scripts (e.g., john, hashcat) following access to shadow file or dumped hashes
Analyst context for executives and security teams
This analytic matters because local hash cracking activity on Linux is a strong signal that an intruder, insider, or unauthorized process may be trying to turn obtained password hashes into usable credentials. For leaders, the business issue is not the cracking tool name itself; it is whether the organization can prove it monitors sensitive credential material access and subsequent suspicious execution well enough to contain identity compromise before it spreads.
Executive priority
Prioritize this as an identity and incident-response readiness question for Linux environments: can teams detect access to shadow files or dumped hashes, correlate it with execution of tools or scripts such as john or hashcat, and respond before cracked credentials enable broader access? This supports control validation for privileged access protection, SOC monitoring coverage, and audit evidence around credential-handling safeguards. Because the ATT&CK object provides no official detection logic or relationships, local risk ranking should depend on where Linux systems hold privileged accounts, administrative access, or business-critical workloads.
Technical view
For SOC and detection teams, validate whether Linux telemetry can connect two behaviors in sequence: access to sensitive password hash sources, such as shadow file access or dumped hashes, followed by execution of hash cracking binaries or scripts. Detection should not rely only on static process names, because legitimate security testing may use the same tools and renamed binaries or scripts may evade simple matching. IR teams should treat confirmed correlation as a credential-compromise investigation path: identify the account, host, parent process, command context, accessed files, copied hash material, and any subsequent authentication activity.
Likely telemetry
- Linux process execution events, including command line, executable path, parent process, user, and timestamp
- File access telemetry for sensitive credential stores such as shadow file access where available
- Shell history or command auditing where collected and appropriate
- Endpoint detection or audit logs showing script execution and binary invocation
- File creation or transfer evidence for dumped hash files
Detection direction
- Validate correlation logic between sensitive hash-file or dumped-hash access and later execution of hash cracking tools or scripts on Linux.
- Tune for legitimate administrative, password-audit, or red-team activity so alerts retain business context rather than becoming generic tool detections.
- Avoid depending only on process names such as john or hashcat; review command-line patterns, executable location, parent process, file access context, and user role.
- Confirm whether telemetry exists for both sides of the behavior. A common blind spot is collecting process execution without reliable sensitive-file access evidence, or vice versa.
- Because no official ATT&CK detection text or relationship context is supplied, test candidate analytics against local Linux logging configuration and approved security tooling workflows.
Mitigation priorities
- Restrict and monitor access to sensitive Linux credential material using least privilege and appropriate file permissions.
- Limit where hash cracking tools may be installed or executed, especially on production Linux systems, while preserving approved security testing processes.
- Centralize Linux audit and endpoint telemetry needed to reconstruct process execution and sensitive-file access.
- Define an incident response playbook for suspected hash access and cracking activity, including credential reset decisions, privileged account review, and follow-on authentication hunting.
- Use approved password-audit activity as a control-validation exercise to confirm monitoring, exception handling, and evidence retention.
Analyst notes and limits
This object is a detection analytic, not a technique description. The supplied fields identify Linux as the platform and describe execution of hash cracking binaries or scripts after access to shadow files or dumped hashes. No tactics, official detection logic, or relationship context were supplied, so the practical value is in validating telemetry correlation and response workflow rather than assuming a specific adversary objective.
This take is limited to the supplied MITRE fields and external reference for AN0293. It does not assert active exploitation, attribution, business impact, or guaranteed detection. Local environment evidence is required to determine whether this behavior is malicious, authorized testing, or administrative activity.
Analytic 0293
Execution of hash cracking binaries or scripts (e.g., john, hashcat) following access to shadow file or dumped hashes
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 | 2666e95b5c6d… |
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 AN0293Open 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.