Detecting and Mitigating Hidden Files and Directories (T1564.001)

The oldest hiding trick is still in use: mark a file as hidden and hope nobody lists it. Hidden Files and Directories (T1564.001) is a Stealth technique for Linux, macOS and Windows, and a subtechnique of Hide Artifacts.

How attackers use it

MITRE explains that most operating systems have a concept of hidden files, to keep normal users from accidentally changing special ones. Hidden files do not appear in a GUI or in normal command-line listings. Users have to ask for them with GUI prompts or command line switches, which MITRE gives as dir /a on Windows and ls -a on Linux and macOS.

On Linux and macOS, a file or folder is hidden by putting a dot as the first character of its name. These are hidden by default from Finder and from standard command-line tools like ls. macOS also has a UF_HIDDEN flag that hides a file from Finder.app but still lets it be seen in Terminal.app. On Windows, users mark files as hidden with the attrib.exe binary.

Many legitimate applications create hidden files and folders to avoid clutter. MITRE's example is SSH, which creates a hidden .ssh folder with known hosts and keys. Adversaries may also name a file with only a space character to hide it.

The effect is simple: any analysis that does not specifically look at hidden files misses what is stored there.

How to detect it

MITRE's analytics, by platform:

• Windows. Suspicious use of attrib.exe or PowerShell commands to set the hidden attribute on files or directories, and processes creating files with alternate data streams.
• Linux. Creation of files or directories with a leading dot in privileged directories such as /etc, /var and /usr/bin, using auditd logs for file creations where the name begins with a dot and the user or process context is unusual.
• macOS. chflags hidden or SetFile -a V used to hide files, and creation of dot-prefixed hidden files, by watching process execution and file metadata changes that set UF_HIDDEN.

The pattern to remember is location. A hidden file in a home directory is normal. A hidden file in /usr/bin is not.

What normal looks like

Hidden files are everywhere on a healthy system, so blanket alerts on them are useless. A few common examples show why. Shell configuration files in home directories start with a dot. The .ssh folder, as MITRE notes, holds known hosts and keys. Applications create hidden folders for settings and caches. On Windows, system files and folders carry hidden or system attributes by default.

So the question is never "is it hidden?" It is "is it hidden somewhere it should not be, or created by something that should not be creating it?"

Where to concentrate

Focus on places where nobody should be creating hidden things:

• System directories such as /etc, /usr/bin and /var, which MITRE names for the Linux analytic.
• Web server roots and upload directories.
• Temporary directories, where a dot-prefixed or space-named directory is a classic hiding spot.
• Shared drives and service account profiles.

MITRE also mentions file names made of a single space. Those do not trigger a dot-prefix rule, so include a check for names that are empty or only whitespace.

Make hidden files visible by default

Many analysis mistakes come from tools that skip hidden files without saying so. Set your forensic and scanning procedures to include them. On Windows, the attrib command can list attributes for a folder tree, where an H marks hidden and an S marks system, for example attrib /s /d C:\Users\Public. On Linux and macOS, use ls -la and find with a name pattern that begins with a dot.

When you find something

1. Do not open or run it. Record the full path, owner, timestamps and permissions.
2. Check what created it, using file creation audit records or endpoint telemetry.
3. Look at the neighbors: other files created around the same time, and any process or scheduled job that references the path.
4. Collect it for analysis using your normal evidence handling, and then remove it as part of cleanup.

How to reduce the risk

MITRE does not list a mitigation for this subtechnique, because hidden attributes are an ordinary operating system feature. Defense is about visibility: include hidden files in your scans, listings and forensics by default, and alert on attribute changes where they should not happen.

Check your own environment

These commands read state only.

# Windows (cmd): list hidden files in the current directory
dir /a:h

# Linux or macOS: list all files including hidden ones, with details
ls -la

# macOS: show file flags such as hidden
ls -lO

# Linux: find dot-prefixed files recently created in system directories
find /etc /usr/bin /var -name '.*' -type f -mtime -7 2>/dev/null

Then ask:

• Do your file integrity or endpoint tools scan hidden files and directories?
• Are directory listings in your forensic runbooks done with the show-hidden switches?
• Do you have auditd rules (Linux) or endpoint rules (macOS, Windows) that flag hidden file creation in privileged locations?

Common mistakes

• Alerting on every dot file. The volume buries the real finding.
• Running scans that skip hidden files by default and trusting a clean result.
• Forgetting about the file named with a space, which a leading dot rule will not match.

Quick check

Sources

• MITRE ATT&CK T1564.001: Hidden Files and Directories