Before an intruder steals a cloud key, an SSH key or a kubeconfig file, it has to find it, and that search through home directories, process environments and shared folders is a step defenders can watch for. MITRE ATT&CK T1083 File and Directory Discovery covers listing files and directories on a host or share to find information worth taking, encrypting or abusing. ATT&CK v20 maps it on Windows, Linux, macOS, ESXi and network devices, records hundreds of procedure examples, and maps no preventive mitigation, because reading directories is ordinary behaviour. This guide focuses on the version of the technique that hurts non-human identities most: walks that hunt for credential files such as .env, ~/.aws/credentials, ~/.kube/config and private SSH keys. It covers real cases, the telemetry in the ATT&CK v20 detection strategy, decoy files that make detection precise, and how to shrink what a walk can find. It is for detection engineers, platform teams and secrets owners and contains no attack procedures.
Key takeaways
- Discovery precedes credential theft. The search for credential files is T1083; reading and using them is T1552 Unsecured Credentials. Catching the search gives you minutes or hours before a key is used.
- Breadth and depth are the signal. ATT&CK v20 detection strategy DET0370 tunes on time window, recursion depth and user context, for example dozens of directory queries in seconds by an unexpected account.
- Decoy files remove the noise. A fake credentials file that no legitimate process ever opens turns file auditing from a firehose into a near certain alert.
- Short-lived credentials shrink the prize. A walk that finds only an expired token or a workload identity binding finds nothing reusable.
- Servers and build agents matter most. Directory walks by a web server account, a CI runner or a container process are far rarer than walks by people, and far more dangerous.
What the technique covers
ATT&CK v20 describes T1083 as enumerating files and directories, or searching specific locations on a host or network share for certain information, and notes that the results shape what the adversary does next. It has no sub-techniques. Neighbouring IDs are separate: listing drives and volumes is T1680 Local Storage Discovery, collecting the found data is T1005 Data from Local System, and taking credentials from files is T1552.001 Credentials In Files and T1552.004 Private Keys. For credential exposure itself, see the MITRE ATT&CK T1552 Unsecured Credentials Guide; this page is about spotting the search.
| Target | Typical location | Why attackers look |
|---|---|---|
| AWS CLI credentials and config | ~/.aws/credentials, ~/.aws/config (including under /root) | Long-lived access keys that work from anywhere |
| Kubernetes kubeconfig | $HOME/.kube/config by default, or the file named in KUBECONFIG | Cluster endpoints, client certificates or tokens. See the Leaked Kubeconfig Response guide. |
| SSH private keys and config | ~/.ssh/ (private keys, config, known_hosts) | Access to other servers and Git hosting; known_hosts lists where to go next |
| Environment files | .env files in application and repository directories | Database passwords, API keys and cloud keys. See Environment Variables and .env Files. |
| Process environments | /proc/<pid>/environ on Linux, container environment variables | Secrets injected at runtime, never written to disk |
| Developer configuration | .gitconfig, shell history, IDE and package manager config files | Tokens, usernames and internal hostnames |
| Business data | File shares, source code, network diagrams, backups | Targets for exfiltration and for encryption |
How adversaries use it: real cases
- Cloud credential hunting (TeamTNT): Cisco Talos documented a TeamTNT credential stealer that searched
/proc/*/environfor variables containing "AWS", read container environment variables, and looked for/root/.aws/credentialsand AWS CLI credential files under/home. The earlier TeamTNT worm stole AWS credential and configuration files from exposed Docker hosts; its lessons include removing static keys from servers and planting canary credentials. - Developer machine sweep (torchtriton): the malicious package in the PyTorch torchtriton supply chain attack read
/etc/hostsand/etc/passwd, every file under$HOME/.sshbelow 99,999 bytes,.gitconfigand the first 1,000 files of the home directory. A single install was enough to sweep a developer's keys. - Identity and admin material (Scattered Spider): ATT&CK records the group enumerating files and directories of interest, including source code, user provisioning, MFA device registration and network diagrams, citing CrowdStrike. See the Scattered Spider Threat Actor Profile.
- Critical infrastructure (Volt Typhoon): ATT&CK records the group enumerating directories containing vulnerability testing and cyber related content and facilities data such as construction drawings, citing CISA advisory AA24-038A. See the Volt Typhoon Threat Actor Profile.
- Ransomware targeting: ATT&CK records Medusa Group searching for files to encrypt and exfiltrate, and Black Basta and BlackCat enumerating files for encryption, while LockBit 2.0 excludes core system files. Encryption is the T1486 step that follows; see the MITRE ATT&CK T1486 Data Encrypted for Impact guide.
What to detect and where
ATT&CK v20 detection strategy DET0370 "Recursive Enumeration of Files and Directories Across Privilege Contexts" has one analytic per platform. The log sources below are from DET0370; the detection ideas are NHI Mgmt Group recommendations.
| Platform | Log sources in DET0370 | Detection idea |
|---|---|---|
| Windows | Security 4688 (process creation); Sysmon 11 (file creation) | Recursive listings such as dir /s or tree from a non-standard parent or account; DET0370 gives ">50 directory queries in 30s" as an example burst threshold to tune |
| Linux | auditd execve and PATH records | find, locate or ls over broad trees or other users' home directories by a service account, script or container process |
| macOS | Unified log process events; fs_usage file system calls | Script or unsigned process walking user directories outside normal workflows |
| ESXi | Shell command logging; hostd vSphere file API access | Datastore and configuration enumeration by remote users or from non-vCenter sources. See the ESXi Logs Detection Guide. |
| Network devices | Syslog CLI command logging | dir, show flash or NVRAM listing by unexpected accounts or from unexpected source addresses |
Watch the files, not only the commands
Command line rules miss implants and scripts that walk directories through APIs. File access auditing on the targets closes that gap:
- Linux: an audit watch rule (
auditctl -w <path> -p r -k <key>) on credential paths that only one known process should read, such as/root/.aws/on a server that uses an instance role. Red Hat notes that audit volume can affect performance, so watch a few precise paths, not whole home directories. - Windows: event 4663 under Audit File System records a used access right, but only where the object's SACL has a matching ACE. Put a read-access SACL (ReadData, shown as ListDirectory on folders) on a small set of sensitive or decoy paths rather than on whole volumes.
- Containers and Kubernetes: runtime security sensors that report reads of
/proc/*/environ, service account token paths or mounted secrets by a process other than the application.
Decoy files
MITRE D3FEND lists Decoy File (D3-DF) as a deceptive technique. Place a convincing but fake credentials file, .env or private key where a sweep will find it, with a file access audit rule and, ideally, a canary credential inside that alerts when used. Because nothing legitimate reads it, an alert on the file or the credential is high confidence. See the Honeytokens and Canary Credentials Guide.
Cutting the noise
- Baseline the walkers: backup agents, antivirus and EDR scans, file indexers, DLP discovery, build tools and package managers all list directories. Record them by process, signer, account and host group.
- Score the target, not just the volume: a broad walk that touches
.ssh,.aws,.kubeand.envpaths in one session matters more than a deep walk of a media folder. - Weight by identity: walks by web server accounts, database service accounts, CI runners or container processes should alert at lower thresholds than walks by interactive users.
- Chain with what follows: a walk followed by archive creation (T1074 staging), outbound transfer or first use of a cloud key from a new address should escalate automatically.
Reducing what a walk can find
ATT&CK v20 maps no mitigations to T1083. The controls below are NHI Mgmt Group recommendations aimed at making a successful search worthless.
| Control | What to do | Effect |
|---|---|---|
| Remove static cloud keys from hosts | Use instance roles, workload identity federation and short-lived session credentials instead of ~/.aws/credentials on servers | The file a sweep looks for does not exist |
| Keep secrets out of files and environments | Fetch secrets at runtime from a secrets manager, mount them with tight permissions, avoid committing .env files | Fewer plaintext secrets on disk and in /proc. See the Secrets Management Guide. |
| Protect SSH keys | Passphrases or hardware-backed keys, SSH certificates with short validity | A copied key is unusable or expires quickly. See the SSH Key Management Guide. |
| File permissions and separation | Credential files readable only by their owner; application accounts unable to read other users' home directories | Limits what a compromised service account can walk |
| Kubeconfig hygiene | Short-lived exec-based credentials instead of static tokens; treat untrusted kubeconfig files with suspicion, as the Kubernetes documentation warns they can lead to code execution or file exposure | Reduces value and risk of the file |
| Developer sandboxes | Run untrusted packages and nightly builds in containers without access to personal keys | The torchtriton style sweep finds nothing |
| Secret scanning | Scan repositories, images and file shares for credentials on a schedule | Finds the files before an attacker does. See the Git Secret Scanning Guide. |
Small and large organisations
A small organisation should first remove static cloud keys from servers, plant two or three decoy credential files on high-value hosts and developer machines, and alert on any read of them. A large organisation adds DET0370 analytics per platform, file access auditing on a defined list of credential paths, runtime sensors on container hosts, and scheduled secret scanning across file shares and images, with findings feeding rotation.
Where identity fits
This technique is, in practice, the search phase of non-human identity theft. Cloud access keys, kubeconfig credentials, SSH keys, API tokens in .env files and CI secrets are all files or environment values, and every one of them is a non-human identity's credential. Two practices follow: inventory where each machine credential lives on disk, and alert when anything other than its owning process reads it. When a sweep is detected, rotate every credential the walking account could read, not only the ones you saw it open.
How to test your coverage
- Plant the decoys first: deploy decoy files on a pilot host and confirm a read by any process produces an alert within your target time.
- Emulate safely: on an approved test host, run a recursive listing of home directories from a service account and from a script host, using an authorised framework such as Atomic Red Team tests mapped to T1083.
- Confirm telemetry: check that process creation with command line, auditd
PATHrecords and 4663 events for the audited paths reach the SIEM. - Tune: run your backup, EDR and DLP scans and confirm they are excluded by process and signer, not by path.
- Roll back: remove temporary audit rules that generate excessive volume, keep the decoys, and record results in your ATT&CK coverage map.
Metrics
- Static key count: number of hosts with cloud credential files on disk, trending to zero for servers.
- Decoy coverage: share of high-value servers and developer machines with a tested decoy credential.
- Time to detect: minutes from a test sweep to an analyst alert.
- Precision: share of directory walk alerts closed as known tooling.
- Rotation time: hours from a confirmed sweep to rotation of all credentials the account could read.
Related discovery techniques: T1680 Local Storage Discovery, T1135 Network Share Discovery and T1082 System Information Discovery; collection often follows through T1005 Data from Local System.
Framework mapping
| Framework | Relevant items |
|---|---|
| MITRE ATT&CK v20 | TA0007 Discovery; T1083; related T1680; follow-on T1552.001, T1552.004, T1005, T1074, T1486 |
| ATT&CK detection | DET0370 Recursive Enumeration of Files and Directories Across Privilege Contexts |
| MITRE D3FEND | D3-DF Decoy File, D3-FAPA File Access Pattern Analysis, D3-PSA Process Spawn Analysis |
| MITRE ATLAS | For AI agents and model artefacts on local systems, see AML.T0037 Data from Local System |
| NIST SP 800-53 Rev. 5 | AU-12 Audit Record Generation, SI-4 System Monitoring, AC-6 Least Privilege |
| NIST CSF 2.0 | DE.CM-09 (computing hardware, software and data monitored), DE.AE-02 (adverse events analysed), PR.AA-05 (access permissions managed) |
| CIS Controls v8.1 | Control 3 Data Protection, Control 8 Audit Log Management |
Practitioner checklist
- List the credential file paths that exist on your servers, build agents and developer machines.
- Replace static cloud keys on servers with instance roles or federated short-lived credentials.
- Plant decoy credential files on high-value hosts and alert on any read or any use of the canary inside.
- Add audit watch rules or SACLs for a short list of real credential paths with a single legitimate reader.
- Deploy DET0370 style analytics for recursive walks by service accounts, script hosts and container processes.
- Baseline backup, EDR, DLP and indexing tools by process and signer.
- Run untrusted packages and builds in sandboxes without access to personal keys.
- Rotate every credential reachable by an account that performed a confirmed sweep.
Standards and references
- MITRE ATT&CK: File and Directory Discovery (T1083)
- MITRE ATT&CK: Unsecured Credentials (T1552)
- MITRE D3FEND: Decoy File
- Microsoft Learn: 4663 An attempt was made to access an object
- Red Hat: Auditing the system (RHEL 9 Security hardening)
- Kubernetes: Organizing Cluster Access Using kubeconfig Files
- Cisco Talos: TeamTNT targeting AWS and Alibaba
Related NHI Mgmt Group resources: Discovery and Reconnaissance Techniques Guide · MITRE ATT&CK T1552 Unsecured Credentials Guide · Environment Variables and .env Files · Honeytokens and Canary Credentials Guide