Detecting T1083 File and directory discovery

How T1083 file and directory discovery shows up in an intrusion

The SOC lead's first question is usually simple: why is an account that should be idle now listing directories across file shares and servers? T1083 File and Directory Discovery is the technique that describes this behavior. It sits under the Discovery tactic (TA0007), which MITRE ATT&CK defines as the adversary trying to figure out the environment. In practice, an intruder who has reached a foothold has not yet learned what the system holds, where sensitive data lives, or which paths lead to more access. Listing files and directories is one of the cheapest ways to answer those questions, and it looks like routine administrative work to anyone who is not watching for it.

Enumeration of this kind tends to target a few categories of material. Directory listings can reveal application configuration that stores connection details, backup archives that contain full copies of databases, scripts with embedded credentials, and key or certificate stores. An attacker who finds these items gains a path to credential access, lateral movement or collection without needing a new exploit. For that reason, a sudden burst of directory browsing from an account with no change request behind it deserves attention even when no malware is present. Benign administrators also browse directories, so the signal is the combination of unexpected identity, unusual timing and a sweep across sensitive locations rather than the listing itself.

Before planning detections, confirm which ATT&CK version your mapping targets. This page uses Enterprise ATT&CK version 20.0, and releases can rename, deprecate or revoke techniques, so record the version alongside every detection rule and coverage claim. Also confirm with your platform team which hosts, appliances and hypervisors generate file access and command execution telemetry in your environment, because coverage gaps on those sources will decide what T1083 detection you can actually support. The MITRE ATT&CK tactic page for Discovery is the natural next read for the tactic definition and linked techniques.

Which telemetry reveals file and directory enumeration

This table maps the data components ATT&CK most often ties to T1083 onto the platforms in scope and names an open-source collector for each. Read each row as a question to answer in your own estate: does this source exist, is it enabled, and does it reach your SIEM. Coverage for File Access and Process Creation depends on audit settings, so confirm each cell before relying on it.

Data component	Linux and ESXi	macOS and network devices	Confirm before relying on it
Process Creation (DC0032)	Auditd execve rules or Wazuh agent process monitoring, forwarded to the SIEM	Endpoint agent process logs where supported; network device logs rarely record process creation	Whether audit rules cover the enumeration binaries and shells you expect, and whether the agent is running on every host
Command Execution (DC0064)	Shell history and command audit records collected by Wazuh or Auditd, with Velociraptor for on-demand hunts	Endpoint telemetry from the chosen agent; device CLI accounting logs if enabled on network devices	Whether shell command capture is enabled, how long history is retained and whether it is tamper-protected
File Access (DC0055)	Auditd file watch rules on sensitive directories, plus Wazuh file integrity monitoring for scoped paths	Endpoint file event logging where the agent supports it; device file access is usually not logged	Which directories are watched, the volume of events produced and whether high-noise paths are excluded on purpose
OS API Execution (DC0021)	Secondary source only; visible through system call auditing where configured	Secondary source only; depends on endpoint agent capabilities	Whether the platform exposes these events at all, since many Linux and macOS deployments will not
Network traffic (Zeek, Suricata)	Zeek and Suricata see file transfers and share access over supported protocols, not local listings	Zeek sees network-facing file share sessions from management or file servers	Whether the sensor sees the relevant segments and whether file protocol parsing is enabled
ESXi and appliance logs	Host syslog forwarded to the SIEM for datastore browsing and shell activity	Syslog from appliances and device management interfaces	Whether shell and datastore access events reach the collector, and whether they are retained long enough to investigate

Detection logic for enumeration bursts and sensitive path access

These four detection ideas share one premise: T1083 activity is ordinary file browsing until the context around it is wrong. Each idea pairs a specific logic with a baseline to tune against and the benign jobs most likely to trigger it. Tune every threshold in your own environment before you alert on it.

Directory listing bursts from unusual parents

Alert when a process that does not normally list directories, such as a web server worker, a database process or a script interpreter, runs many listing commands within a short window. Process Creation and Command Execution telemetry give the parent, the account and the command line, so the logic is a count of distinct listed paths per parent per window. Baseline the rate per host role first. Expect false positives from backup agents, configuration management runs and monitoring checks that walk the filesystem on a schedule, so allowlist them by parent and signed binary rather than by account alone.

Enumeration of sensitive paths

Alert on listing activity that touches configuration, key material or backup directories, such as SSH key stores, TLS certificate folders, cloud credential files and application configuration trees. File Access telemetry on these paths is the strongest signal because few legitimate tasks read them in bulk. Maintain an explicit list of sensitive paths per platform and review it after each change window. Expect false positives from configuration management, certificate renewal jobs and secrets rotation tooling, so label those accounts and tie the exception to a named change record.

Recursive search from service accounts

Alert when a service account performs recursive searches across file systems, for example full-tree find or grep style operations, outside its documented job window. Service accounts usually have predictable behavior, which makes deviation easy to measure. The logic is a per-account baseline of recursive operations and the set of roots they touch. Expect false positives from indexing services, antivirus scans, log shippers and backup verification, so record each account's expected roots and schedules before tuning.

Listing on ESXi datastores and network devices

Alert when interactive or scripted listing occurs against ESXi datastores or the file systems of network devices, which are rarely browsed outside administrative change work. Command Execution and the management plane logs are the sources to check. The logic is any listing from an unexpected administrative session or source address, weighted by time of day. Expect false positives from backup appliances, VM migration tooling and vendor support sessions, so require a change ticket reference or a known management host before treating activity as expected.

How to validate the file discovery detection

This sequence confirms that an approved emulation of T1083 File and directory discovery produces the expected telemetry in the SIEM and that the detection rule fires, with a recorded outcome that can be reviewed and repeated. It is run on a non-production host inside a private cyber range or lab.

Define the emulated behavior in plain terms
The detection owner and the red team lead agree in writing on what the exercise will emulate: a user or process browsing and listing file system locations on a single non-production Linux, macOS or ESXi host, and which data components the rule depends on, such as Process Creation, Command Execution and File Access. The plan names the ATT&CK version being tested, the target detection strategy identifier, and the expected alert logic. Done when the plan is signed off and no one needs to ask what the test is supposed to look like.
Approve the plan and scope the test host
The security lead confirms the exercise runs only on an isolated host or range segment with no production data, and that the people who monitor the SIEM know the test window and the identifiers used. Stop conditions, the person who can halt the run, and the evidence owner are written into the plan. Done when the approval record is stored with the plan and the test host is confirmed as non-production.
Run the emulation under the approved plan
The authorized operator executes only the behavior described in the approved plan, once, with the start and end times logged on the test host. The operator does not vary the technique to test evasion in this sequence, and any deviation is recorded as an exception in the run log. Done when the run log shows the start time, end time, host name, account used and the actions completed, matching the plan.
Confirm telemetry arrives in the SIEM
The detection engineer checks that the events for process creation, command execution and file access from the test host are present in the SIEM, for example through the Wazuh manager or the Security Onion index, before any rule is evaluated. Gaps in agent coverage, log forwarding or parsing are recorded as failures of the telemetry path, not of the rule. Done when the engineer can list the event count per data source for the test window and compare it with the expected count from the plan.
Check the rule fires within the expected window
The detection engineer checks whether the Sigma-derived or native rule raised an alert for the test host and account, and whether the alert arrived within the response window set in the detection standard. If the rule did not fire, the engineer determines whether the cause is the rule logic, a field mapping error or a suppression setting. Done when the alert ID and its timestamp are recorded, or a documented miss is logged with its probable cause.
Record the outcome and retain the evidence
The engineer writes a structured record for the run: timestamps, host, account, event count per data component, alert ID, time from activity to alert, the rule version, and the ATT&CK version targeted. The record is stored with the detection's change history so that a later rule change can be compared against it. Done when the record is complete, reviewed by a second person, and linked to the rule in the detection repository.
Tune and rerun after any gap
Where the run exposed a gap, the detection engineer changes one variable at a time, such as field mapping, agent coverage or rule threshold, and repeats the approved emulation to confirm the change. Each rerun produces its own record so the history shows what changed and why. Done when the rerun record matches the expected telemetry and alert result, or the open gap is accepted in writing by the risk owner.

Preventive controls that limit what discovery can reveal

Discovery techniques such as T1083 only reveal what the executing account can already see and reach. The five ATT&CK mitigations below shrink that visible surface, so each card names the control, the T1083 behavior it limits, and the check to run in the client's own environment.

User account management (M1018)

Limit which accounts can log in to hosts and read application data, and remove unused or shared service accounts. For T1083, an over-permissioned account can enumerate home directories, backup paths and configuration folders that a narrower account could not list. Confirm that interactive accounts on Linux and macOS hosts, and service accounts on ESXi and network devices, have only the directories and roles their job requires. Review this quarterly against the access register, and record who approved each exception.

Operating system configuration (M1028)

Harden file system permissions, default umasks, and access control lists so that world-readable directories do not expose sensitive paths. Many T1083 searches succeed only because permissions on shared or legacy folders are too open. Verify that sensitive directories such as key stores, database data folders and configuration trees are not readable by general user groups, and that sticky or restricted deletion flags are set on shared temporary areas. Test the result with a non-privileged test account, not an administrator.

Audit (M1047)

Audit controls do not stop discovery, but they make recursive listing and broad file searches visible. Enable file access auditing on sensitive paths and ensure that events reach your SIEM with host identity and process name. Confirm that audit policy changes are themselves logged, so an attacker cannot quietly reduce visibility before running a search. Ask your team to document which paths are audited, the retention period in your log platform, and who reviews the alerts.

Network segmentation (M1030)

Segmentation limits which hosts a compromised account can reach to browse network file shares and remote mounts. T1083 often extends to mounted network storage, so a flat network widens the set of directories an attacker can enumerate. Confirm that file servers, NAS devices and management interfaces sit in zones that only approved client subnets can reach, and that firewall rules allow SMB or NFS traffic only from named hosts. Test the rules from a workstation outside the approved zone.

Disable or remove unneeded features (M1042)

Remove shells, file-sharing services, scripting runtimes and debugging tools that are not required on a host, because each one gives an attacker another way to list files. Review installed packages on Linux and macOS, enabled services on ESXi, and enabled features on network devices. Compare the result against the hardening baseline your team has approved, and confirm that removed components cannot be restarted by a standard user account.

What the SOC does when a file discovery alert fires

The first decision is whether the alert reflects a person or process that should be searching the file system. Start by confirming the account that ran the activity, the parent process that spawned the enumeration commands, and the host and session they came from. Then check the change calendar, backup and inventory jobs, and administrator runbooks for a matching task in the same window. A scheduled job that enumerates directories on a schedule is the most common benign explanation, so record the job name and owner before treating the alert as suspicious. If the account is a service identity, confirm that its normal behavior includes walking the paths it touched.

If no legitimate explanation surfaces, scope the activity before deciding on containment. Query the same account and parent process across other hosts and file shares for the same window, and look for similar enumeration patterns from the same source address. Review what happened next: whether the actor opened sensitive paths such as finance, HR, source code or key stores, whether files were copied or archived, and whether any authentication events followed. Preserve evidence early with a collector such as Velociraptor, using an artifact set agreed in advance so that the host state, relevant logs and shell history are captured before any cleanup. Confirm with your own platform team which collection artifacts are deployed and tested.

Escalate when the activity cannot be tied to a known job and is accompanied by access to sensitive paths, use of an account outside its normal role, or activity on more than one host. Write these criteria into the runbook so that the on-call analyst can apply them without waiting for a decision. Containment options range from disabling the account or session, isolating the host, and restricting access to the affected share, to tightening permissions on the paths that were searched. After a confirmed result, feed indicators and timelines back into detection content. After a benign result, tune narrowly by allow-listing the specific job, account and host pairing with an expiry date, not by suppressing the rule across the environment.

Rehearsing T1083 detection in a private cyber range

A private range for T1083 needs enough hosts to show file and directory enumeration on each platform the organization runs. The core layout is a Linux host, a macOS host, an ESXi lab host and a network device simulator, all on an isolated segment with no route to production. Sensors and collectors run beside these targets so every rehearsal produces the same telemetry an operating environment would.

Endpoints: Linux and macOS hosts with the audit or endpoint logging your organization relies on, so process creation and file access events are captured.
Hypervisor and devices: an ESXi lab host and a network device simulator, each with its management logs forwarded to the collector.
Detection stack: Wazuh for host telemetry, with Security Onion, Suricata or Zeek for network visibility, and Velociraptor for hunting and evidence collection.
Time and identity: synchronized clocks and named test accounts, so alerts can be correlated to the scenario.
Isolation: snapshots of each target so the range can be reset between runs.

Confirm with your platform team that each product version supports the log sources you plan to use before the build starts.

Questions from SOC leads and detection engineers

How do I separate file and directory discovery from normal administration?

Start by treating T1083 as a behavior pattern, not a single command. Routine administration, backup jobs, configuration management and software deployment also list directories and read files, so a rule that fires on any ls, find or directory listing will bury the SOC in noise. Build a baseline per host role and per service account, then look for deviations: enumeration of paths outside a system's normal scope, bursts of listing across many unrelated directories in a short window, and listings run from interactive sessions or unusual parent processes. Record which accounts and jobs are expected to enumerate, and suppress only by named identity and path, never by blanket exclusion. Review suppressions at each tuning cycle so that exceptions stay narrow.

Which audit settings do I need for File Access telemetry on Linux?

File Access visibility on Linux depends on what the host audit subsystem is configured to record and where those events are shipped. Confirm with your platform team and your agent documentation which audit rules cover directory reads, which path scopes are watched, and whether the events carry the process, user and working directory context you need to attribute a listing. Watch for high event volume on busy file servers, which can affect disk, CPU and retention budgets, so scope watches to sensitive trees first and expand deliberately. Route the events to Wazuh or your chosen SIEM, and test that a controlled listing from a known account produces the expected record before you write any rule against it.

How do I close logging gaps for ESXi and network devices?

Gaps on ESXi and network devices usually come from logging that is never forwarded, not from a missing detection. Confirm that each host and device sends syslog to a central collector, that the timestamps are synchronized, and that shell or CLI session activity is recorded at a verbosity that shows commands and not just logins. Where a platform cannot emit the command-level detail you need, document that as a known gap, add compensating controls such as restricting management access and monitoring authentication, and record the residual risk with the owner. Ask your vendor which log categories and verbosity levels are available for your exact version, because these capabilities differ between releases.

How do I map the rule to the ATT&CK version we use?

Pin every detection to a named ATT&CK version in its metadata, and record the detection strategy and data component IDs it relies on. Since ATT&CK v18, technique pages reference detection strategies (DET IDs) and analytics, and data components use DC IDs, so a rule written against older mappings may point at deprecated sources. The Enterprise ATT&CK v20 bundle lists Process Creation (DC0032), Command Execution (DC0064) and File Access (DC0055) as the data components most often referenced for Discovery techniques. When a new release arrives, compare your mapping against the MITRE ATT&CK updates page and reconcile any renamed, deprecated or revoked items in a single change record.

How often should we re-run validation after tuning?

Re-run validation after every change that touches the rule, the logging configuration or the baseline, and on a fixed recurring schedule set by your change management policy. A tuning change can silently remove coverage, so the test should confirm that known controlled enumeration still alerts after the change and that the benign administrative jobs stay quiet. Keep the test cases, expected results and dates in version control so auditors and engineers can trace each validation. Also re-validate after platform upgrades, agent changes and ATT&CK version updates, because any of these can alter what telemetry reaches the SIEM. Your team sets the cadence; agree it in writing with any external testing partner.

Can our own team run this detection program without outside help?

Yes, many teams can, provided they have engineers who understand the logging stack, a SIEM they can query and a test environment where enumeration can be run safely. The work splits into baselining, audit configuration, rule authoring, validation and response. Where capacity or skills are thin, a fixed-scope engagement can cover one part, such as building the validation plan or rehearsing detection in a private cyber range, while your staff keep ownership of day-to-day operation. DeployOpen implements and supports open-source platforms inside the client's own infrastructure and runs security testing and cyber range exercises, so scope, deliverables and timelines are agreed in writing before work starts. Ask any provider to name which of these tasks they will hand over to your team.

What drives the cost of this detection work?

The main cost components are staff time for baselining and rule tuning, the logging infrastructure needed to retain File Access and command data, and the time to validate detections in a test environment. One-time costs include the initial baseline, audit configuration and the first validation cycle. Recurring costs include log storage, rule maintenance, re-validation after changes and ATT&CK version reviews. Costs rise with the number of hosts, the breadth of watched directories and the retention period required by your compliance obligations, and fall when you scope monitoring to sensitive systems first. When requesting a quote, ask for the deliverables, the platforms in scope, the logging assumptions and the validation cadence, so you can compare proposals on the same basis.

How DeployOpen builds T1083 detections and range scenarios

DeployOpen works on T1083 File and directory discovery as a fixed-scope engagement inside the client's own infrastructure. The work turns the technique's detection logic into open-source rules, validated telemetry and range exercises that the client's own team can run and maintain.

How we scope

Written scope names the platforms in play, such as ESXi, Linux, macOS or network devices, before any work starts.
Scope lists which telemetry sources exist today, including process creation, command execution and file access logs.
Scope states the ATT&CK version targeted, so detection mappings stay tied to a named release.

How we build

Detection logic for T1083 is written as Sigma rules and mapped to Wazuh or Security Onion data flows.
Collection gaps are closed by configuring audit and file access logging on the in-scope hosts.
Each rule is tested against benign administrative file browsing to measure noise before go-live.

How we hand over

Deliverables include rule source, data source mapping, validation results and a written runbook for analysts.
A cyber range scenario replays T1083 activity so the client's team can rehearse detection and response.
Documentation records known blind spots and the questions to confirm with the client's platform owners.

How we support

Ongoing support is available as a retainer for tuning rules and updating mappings after ATT&CK releases.
Retainers can cover periodic re-testing of T1083 detections after platform upgrades or logging changes.
Support scope, response expectations and review cadence are agreed in writing with the client.

T1083 File and directory discovery