Detecting and Mitigating Fileless Storage (T1027.011)

Antivirus scans files. So some adversaries avoid files. They keep payloads and stolen data in places that are not files at all, such as the Windows Registry, the WMI repository, event logs, or memory backed directories on Linux.

MITRE tracks this as Fileless Storage, technique T1027.011, a sub-technique of Obfuscated Files or Information in the Stealth tactic. It applies to Linux and Windows.

How attackers use it

MITRE defines fileless storage broadly: any format other than a file. On Windows, common non-volatile examples are the Registry, event logs and the WMI repository. On Linux, shared memory directories (/dev/shm, /run/shm, /var/run and /var/lock) count, along with the volatile directories on network devices (/tmp and /volatile). Files written there map directly to RAM and are not stored on disk.

Why it works, per MITRE:

• Like in-memory behaviors such as reflective code loading and process injection, it can stay unseen by antivirus and other endpoint tools that can only examine files on disk.
• It can get around the protection of read-only file systems on Linux.

What gets stored: payloads and shellcode, possibly as part of persistence, and collected data that has not yet been exfiltrated. Content is often encrypted, encoded or spliced as well.

Some activity still leaves traces on disk, but in hard to inspect central formats. MITRE names the WMI repository (under %SystemRoot%\System32\Wbem\Repository) and the Registry hive files (under %SystemRoot%\System32\Config).

How to detect it

MITRE's strategy (DET0344) has two analytics.

• Abuse of fileless mechanisms such as Registry keys, WMI classes and event logs to stage payloads, scripts or encoded content outside normal files.
• Use of shared memory directories such as /dev/shm and /run/shm for temporary storage of obfuscated, encoded or executable data without persistence to disk.

Concrete things to watch:

• Registry. Unusually large values, or values containing encoded or script-like data, in keys that normally hold small settings. Watch for processes writing such data and then reading it back to run it.
• WMI. Permanent event subscriptions and unfamiliar classes in the repository.
• Event logs. Entries created by software with no reason to write there, holding strange blobs.
• Linux. Executables or scripts appearing in /dev/shm or /run/shm, and processes launched from those paths.

Keep a baseline. Fileless storage is hard to see because defenders never look. A baseline turns a hidden location into a visible diff.

How to reduce the risk

MITRE lists one mitigation: audit. Periodically review the common fileless storage locations, such as the Registry and the WMI repository, to find abnormal and malicious data.

Make that review a routine, not an incident response step:

1. Choose the locations: Registry run and service keys, the WMI event subscription namespace, and memory backed directories on Linux hosts.
2. Take a clean baseline from a known good system.
3. Compare on a schedule and investigate differences.

Check your own environment

Read-only commands:

# Windows: list WMI permanent event subscription objects
Get-CimInstance -Namespace root\subscription -ClassName __EventFilter
Get-CimInstance -Namespace root\subscription -ClassName CommandLineEventConsumer
Get-CimInstance -Namespace root\subscription -ClassName __FilterToConsumerBinding

# Linux: look at what lives in memory backed directories
ls -la /dev/shm /run/shm 2>/dev/null

# Linux: any running process executing from /dev/shm?
ls -l /proc/*/exe 2>/dev/null | grep -E '/dev/shm|/run/shm'

Then ask:

• Does your endpoint tooling inspect Registry data and WMI, or only files?
• Do you have a baseline of WMI subscriptions per server role?
• Are there rules to flag executable content in memory backed directories?

Quick check

Sources

• MITRE ATT&CK, Fileless Storage (T1027.011)