Overview

File and Directory Discovery (T1083) refers to adversaries actively enumerating the file system — listing directories, searching for specific file types, and mapping out where sensitive data lives on a host or network share. Attackers use this information to locate credentials, configuration files, backups, intellectual property, and staging areas before pivoting to their actual objective.

Because file enumeration is a near-universal step in both targeted intrusions and commodity malware campaigns, detecting it early gives defenders a high-value chokepoint — one of the few opportunities to catch an attacker before they’ve achieved their actual goal. Missing this technique means missing critical pre-exfiltration and pre-lateral-movement signals.

Attacker Perspective

Attackers enumerate files and directories immediately after gaining initial access to understand the environment, validate they’re on the right target, and identify where their most valuable data resides.

• Credential harvesting setup: Threat actors run dir /s /b C:\Users\*\AppData\Roaming\Microsoft\Credentials\* or find / -name "*.kdbx" 2>/dev/null to locate password databases, browser credential stores, and SSH keys before running dedicated dumping tools.
• Ransomware pre-encryption staging: Ransomware families like LockBit use tree /F /A C:\ or custom file-walker binaries to build a complete file inventory, then filter for high-value extensions (e.g., .docx, .sql, .bak) to prioritize encryption targets.
• Data exfiltration targeting: APT groups use PowerShell such as Get-ChildItem -Recurse -Include *.pdf,*.xlsx -Path C:\Users or Linux locate -i "confidential" to find documents matching keyword patterns before staging them for exfiltration.
• Network device reconnaissance: Adversaries with access to Cisco or similar devices run dir flash:, show nvram, or dir all-filesystems to enumerate configuration files and firmware images that could reveal credentials or architecture details.

This technique is attractive because it uses built-in OS tools that generate minimal noise, blends naturally with legitimate admin activity, and provides the attacker with a precise roadmap of the environment at essentially zero cost.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line capture, you will only see the process name and miss the actual discovery commands.
• Windows — Sysmon Event ID 1 (Process Create): Deploy Sysmon with a configuration that captures CommandLine, ParentImage, User, Hashes, and CurrentDirectory. Sysmon provides richer data than native 4688 and is the preferred source where available. Minimum Sysmon config should include rules for dir, tree, find, where, and PowerShell discovery cmdlets.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging = Enabled, or set registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures the actual content of PowerShell commands including Get-ChildItem and Invoke-Expression wrappers that would otherwise be obfuscated.
• Windows — PowerShell Module Logging (Event ID 4103): Enable via GPO alongside Script Block Logging: Turn on Module Logging = Enabled, then set * in the module names list to capture all modules. This catches pipeline execution details that 4104 may miss.
• Linux — auditd Process Execution Rules: Add the following rules to /etc/audit/rules.d/discovery.rules:
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/find -k file_discovery,
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/ls -k file_discovery,
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/locate -k file_discovery,
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/tree -k file_discovery.
  These generate EXECVE and PROCTITLE audit records with full arguments. Restart auditd after changes: service auditd restart.
• Linux — auditd with ausearch/aureport or forwarded to SIEM via auditbeat/Filebeat: If using Elastic, deploy Auditbeat with the auditd module enabled. If using Splunk, use the Splunk Add-on for Unix and Linux which reads /var/log/audit/audit.log. Ensure log forwarding is configured so records tagged with key=file_discovery reach the SIEM.
• macOS — Endpoint Security Framework / Unified Log: Use an EDR agent (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) that hooks the Endpoint Security Framework to capture es_event_exec_t events, which provide process arguments for commands like ls, find, and mdfind. Alternatively, enable OpenBSM auditing: set lo,ex flags in /etc/security/audit_control to capture exec events, then restart the audit daemon with audit -s.
• ESXi — Shell and API Logging: Enable ESXi Shell and SSH logging by configuring syslog to forward to your SIEM: set Syslog.global.logHost via vSphere or esxcli. Shell commands executed via the ESXi shell generate entries in /var/log/shell.log; ensure this file is included in the syslog forwarding configuration.
• EDR Telemetry (cross-platform): If you have CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne deployed, these provide pre-normalized process execution events with parent/child relationships and command lines. This is the highest-fidelity source and should be the primary detection layer where available, supplementing or replacing native OS log sources.
• Network Device CLI Logging: Enable archive log config and logging on Cisco IOS/IOS-XE devices and forward syslog to your SIEM. Commands like dir, show flash, and dir all-filesystems will appear in the command authorization log if AAA command accounting is configured: aaa accounting commands 15 default start-stop group tacacs+.

Key Indicators

• Windows CMD discovery bursts: In Event ID 4688 or Sysmon Event ID 1, look for Image ending in cmd.exe or tree.com with CommandLine containing patterns like dir /s, dir /b, tree /F, or where /r. Especially suspicious when ParentImage is a non-standard parent such as mshta.exe, wscript.exe, cscript.exe, rundll32.exe, or any Office application.
• PowerShell file enumeration: In Event ID 4104 (Script Block Log), look for ScriptBlockText containing Get-ChildItem or its alias gci combined with flags like -Recurse, -Include, or -Filter targeting sensitive paths such as C:\Users, C:\Windows\System32\config, ADMIN$, or \\ UNC paths. Example pattern: Get-ChildItem -Recurse -Include *.config,*.xml,*.kdbx.
• Linux rapid find/locate execution: In auditd records with key=file_discovery, look for EXECVE records where a0=find with arguments targeting sensitive paths: /etc/passwd, /home/, /root/, /var/backups/, /.ssh/, or searching for extensions like -name "*.pem", -name "*.key", -name "id_rsa". Also flag locate -i password or locate .ssh.
• Unusual process spawning discovery tools: In Sysmon Event ID 1 or EDR telemetry, flag when find.exe (Windows), tree.com, or where.exe is spawned by unexpected parents: ParentImage in (powershell.exe, python.exe, java.exe, node.exe, nginx.exe, apache.exe). These suggest web shell or scripting-engine-based post-exploitation.
• High-volume file enumeration in short window: In any process execution log, look for the same User or ProcessId generating more than 20 file/directory listing commands within a 60-second window. This pattern is characteristic of automated post-exploitation frameworks like Cobalt Strike, Metasploit, or custom C2 agents running file walker modules.
• Sensitive directory targeting: In any log source, flag enumeration commands that explicitly reference high-value paths: C:\Windows\NTDS\, C:\Windows\System32\config\, /etc/shadow, /etc/sudoers, ~/.ssh/, /var/lib/, \\ADMIN$, \\C$, \\SYSVOL, or \\NETLOGON.
• macOS mdfind/spotlight abuse: In EDR or Unified Log, look for mdfind invocations with queries targeting credential-related terms: mdfind -name ".pem", mdfind kMDItemDisplayName = "*password*", or mdfind -onlyin /Users kind:document spawned from a non-GUI process.
• Network device file enumeration: In syslog from network devices, look for AAA command accounting entries containing dir flash:, dir nvram:, show flash, or dir all-filesystems from user accounts that do not normally access device CLIs interactively, or from source IPs not in your approved management network.

Detection Logic

Rule 1 (Broad — High Sensitivity): Windows File Discovery via Built-in CLI Tools
IF process.name IN ("cmd.exe", "powershell.exe", "pwsh.exe")
AND process.command_line MATCHES ("dir /s", "dir /b", "tree /F", "where /r", "Get-ChildItem.*-Recurse", "gci.*-Recurse")
AND NOT process.parent.name IN ("explorer.exe", "svchost.exe")
AND NOT user.name IN [known_admin_service_accounts]
THEN alert(severity=LOW, rule="T1083 - File Discovery via CLI")

This broad rule catches the majority of interactive and scripted file enumeration on Windows. Expect moderate-to-high volume (10–50 alerts/day in a typical enterprise) and use it primarily as a hunting baseline. The exclusion of explorer.exe parents removes most user-initiated GUI file browsing.

Rule 2 (Medium — Balanced): File Discovery from Anomalous Parent Process
IF process.name IN ("cmd.exe", "powershell.exe", "find.exe", "where.exe", "tree.com", "ls", "find", "locate")
AND process.command_line MATCHES ("dir /s", "/s /b", "-Recurse", "find / ", "find /home", "find /etc", "locate *.key", "locate *.pem")
AND process.parent.name IN ("mshta.exe", "wscript.exe", "cscript.exe", "rundll32.exe", "regsvr32.exe", "python.exe", "python3", "java.exe", "node.exe", "WINWORD.EXE", "EXCEL.EXE", "nginx", "apache2", "httpd")
THEN alert(severity=HIGH, rule="T1083 - File Discovery from Suspicious Parent")

This rule targets a high-confidence pattern: discovery tools being called from script interpreters, Office applications, or web server processes — all classic indicators of initial access exploitation or web shell activity. Expect low volume (0–5 alerts/day) with high fidelity.

Rule 3 (Targeted — High Precision): Enumeration of Sensitive System Paths
IF process.command_line MATCHES (
"C:\\Windows\\NTDS", "System32\\config", "/etc/shadow", "/etc/passwd",
"\\.ssh", "id_rsa", "*.kdbx", "*.pfx", "*.key", "ADMIN$", "\\SYSVOL",
"\\NETLOGON", "/var/backups", "/root/.bash_history"
)
AND process.name IN ("cmd.exe", "powershell.exe", "find.exe", "find", "locate", "mdfind", "grep")
AND NOT process.name = "antivirus_scanner.exe"
AND NOT user.name IN [known_security_scanning_accounts]
THEN alert(severity=CRITICAL, rule="T1083 - Sensitive Path Enumeration")

This rule is narrowly scoped to file system searches that directly target credential stores, SSH keys, AD databases, and certificate files. Any hit here warrants immediate investigation. Expected volume: 0–2 alerts/day with very high true-positive rate. Tune out known vulnerability scanners and DLP agents by their process or user names.

Rule 4 (Behavioral — Burst Detection): High-Frequency File Enumeration in Short Window
IF COUNT(process.name IN ("dir", "ls", "find", "tree", "Get-ChildItem", "locate"))
WHERE user.name = same_user AND host.name = same_host
WITHIN 60 seconds > 15
AND NOT user.name IN [backup_service_accounts, software_deployment_accounts]
THEN alert(severity=MEDIUM, rule="T1083 - High-Frequency File Discovery Burst")

This rule catches automated file walkers embedded in post-exploitation frameworks that rapidly enumerate multiple directories in sequence. A human typing commands rarely exceeds 15 discovery commands per minute. Tune the threshold based on your environment’s baseline; backup software and software deployment tools (SCCM, Ansible) may legitimately exceed this threshold and should be excluded by service account name.

Tuning Guidance

• IT Administration and Helpdesk Scripts: Legitimate sysadmin scripts frequently use dir /s, Get-ChildItem -Recurse, and find for software inventory, log collection, and troubleshooting. Exclude by adding user.name IN [known_admin_accounts] AND process.parent.name IN ("psexec.exe", "schtasks.exe", "wsmprovhost.exe") only when the source host is an identified management workstation (host.name IN [admin_jump_hosts]).
• Backup and Archiving Software: Agents like Veeam, Backup Exec, Commvault, and Windows Backup enumerate the file system constantly as part of normal operation. Identify their service account names (e.g., svc_veeam, svc_backup) and exclude user.name IN [backup_service_accounts] or exclude by process.parent.name IN ("VeeamAgent.exe", "BackupExecAgentAccelerator.exe").
• Antivirus and EDR Scanners: Security products perform their own file system traversal. Exclude by process name or hash: add AND NOT process.parent.name IN ("MsMpEng.exe", "SentinelAgent.exe", "CSFalconService.exe", "cylancesvc.exe") to rules where these generate noise.
• Software Deployment Tools: SCCM, Ansible, Puppet, Chef, and similar tools run discovery commands during inventory collection. Exclude process.parent.name IN ("ccmexec.exe", "ansible", "puppet", "chef-client") or the associated service accounts.
• Developer Workstations: Developers routinely run find, ls -la, Get-ChildItem, and similar commands in terminals. Consider scoping your detection rules to server assets and excluding endpoints tagged as developer workstations (host.tags NOT CONTAINS "developer") from the broadest rules while keeping sensitive-path rules enabled everywhere.
• CI/CD Pipelines: Build agents (Jenkins, GitHub Actions runners, Azure DevOps agents) frequently traverse file systems as part of build and test steps. Identify their host names or service accounts and create an explicit allowlist exclusion for these sources.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event from the source log (Sysmon Event ID 1, auditd EXECVE record, or EDR telemetry) and confirm the CommandLine, ProcessId, User, and Timestamp fields are populated and match the alert. Do not rely solely on the SIEM alert summary — inspect the raw log to rule out parsing errors or false field extractions.
2. Identify the affected host and user: Confirm the hostname, IP address, and OS version from your asset inventory, and determine whether the account that executed the command is a standard user, service account, or privileged account. Flag immediately if the user has Domain Admin, local Administrator, or root privileges, as the blast radius is substantially larger.
3. Pull the full process chain: In your EDR console or SIEM, query for all processes with the same ProcessGuid (Sysmon) or SessionId and trace the full parent-child chain back to the originating process. Look specifically for whether the chain originates from a browser, Office document, web server, or remote access tool — this determines whether you are dealing with exploitation, phishing, or insider threat.
4. Identify what was targeted: Review the exact CommandLine arguments to determine which paths and file types were enumerated. Cross-reference the targeted paths against your data classification inventory — enumeration of paths containing credentials, source code, PII, or financial data significantly escalates severity and should trigger immediate escalation to Tier 2.
5. Check for network connections and files written to disk: In Sysmon Event ID 3 (Network Connection) and Event ID 11 (File Create), or equivalent EDR events, look for outbound connections or new files created by the same process or user within 10 minutes of the discovery activity. Enumeration followed by an outbound connection or a new compressed archive (.zip, .7z, .tar.gz) is a strong indicator of active exfiltration staging.
6. Look for lateral movement from this host: Query your SIEM for Event ID 4624 (Logon) with LogonType = 3 (network) originating from this host, SMB connections (port 445) in NetFlow or firewall logs, and WMI or WinRM execution events (Sysmon Event ID 1 with parent = WmiPrvSE.exe or wsmprovhost.exe) within the 2-hour window following the discovery activity. If other hosts are involved, scope them into the investigation immediately.
7. Escalation decision: Treat the alert as a confirmed incident requiring escalation if any of the following are true: the process chain originates from an exploitation vector (browser, Office, web shell); sensitive credential or AD-related paths were targeted; network connections followed the discovery activity; or the user account is privileged and the activity falls outside documented maintenance windows. Treat it as benign and close after documenting if the process chain is entirely consistent with a known admin or backup tool, the user has a documented ticket or change record, and no sensitive paths or follow-on activity were observed.

Response Playbook

Containment

• Isolate the host (leave it powered on): Use your EDR console (CrowdStrike Network Containment, Microsoft Defender for Endpoint Device Isolation, or SentinelOne Network Quarantine) to isolate the host from the network immediately while preserving it for forensic memory capture. Do not power off — volatile memory may contain active C2 connections, encryption keys, or injected shellcode.
• Disable the affected user account: In Active Directory, run Disable-ADAccount -Identity [username] or use the Azure AD portal to disable the account. If the account is a service account, coordinate with the application owner before disabling, but prioritize containment if active compromise is confirmed.
• Kill the identified malicious process: If the process is still running, use your EDR to terminate it by ProcessId. Document the PID, process name, hash, and parent before terminating. Do not simply close a terminal window on the host — use the EDR to ensure the kill is logged and complete.
• Block identified C2 IPs and domains: If outbound network connections were identified in step 5 of the investigation, immediately submit the IPs and domains to your firewall team or SOAR playbook for blocking at the perimeter firewall and internal DNS sinkhole. Also add them to your proxy block list if one exists.
• Revoke active sessions and tokens: Invalidate all active Kerberos tickets for the affected account using klist purge on the host, or force a ticket invalidation via Set-ADUser -Identity [username] -Replace @{msDS-SupportedEncryptionTypes=0} followed by a password reset. For cloud-integrated environments, revoke OAuth tokens and Azure AD refresh tokens via the Microsoft Entra portal or Revoke-AzureADUserAllRefreshToken.

Eradication

• Remove identified persistence mechanisms: Check for new scheduled tasks (Event ID 4698), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\Software\Microsoft\Windows\CurrentVersion\Run), new services (Event ID 7045), and WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter). Remove any entries not present in your approved baseline.
• Search for and delete dropped payloads: Use your EDR’s file search capability or query Sysmon Event ID 11 (File Create) for any new executables, scripts, or archives created by the malicious process or user in the hours surrounding the incident. Pay particular attention to %TEMP%, %APPDATA%, C:\ProgramData\, /tmp/, and /var/tmp/. Delete confirmed malicious files and submit hashes to your threat intelligence platform.
• Reset credentials for all involved accounts: Force a password reset for the affected user account and any service accounts whose credentials may have been visible in the enumerated files. If the attacker accessed C:\Windows\System32\config\ or the NTDS database path, treat the entire domain as potentially compromised and initiate a full Kerberoastable account and krbtgt password reset.
• Check lateral movement targets for backdoors: For every host identified in investigation step 6, run the same persistence checks (scheduled tasks, registry run keys, new services, WMI subscriptions) and look for the same file hashes and process names found on the initially compromised host. Do not assume a clean bill of health without active verification.
• Rotate secrets and API keys that may have been exposed: If the enumerated paths included cloud credential files (~/.aws/credentials, ~/.azure/, gcloud config directories, .env files, or application configuration files with embedded secrets), rotate those credentials immediately in the respective cloud console and audit CloudTrail/Azure Activity Log/GCP Audit Log for any use of those credentials from unexpected IPs or time windows.

Recovery

• Verify the host is clean before reconnecting: Before removing network isolation, run a full AV/EDR scan, review all persistence locations one final time, and confirm no unexpected listening ports or scheduled tasks remain. If confidence in the host’s integrity is below 90%, re-image from a known-good baseline rather than attempting to clean in place — the cost of re-imaging is always lower than the cost of a second breach from an overlooked backdoor.
• Re-enable the user account only after confirming no persistence remains: Coordinate with the user’s manager and confirm the account is clean, the password has been reset, and MFA has been re-enrolled before