Loop device created or file loop-mounted as a filesystem

Siemphony@siemphonylowT1564.005unverified

Matches the Linux leg of AN1272: an EXECVE record for `losetup`, or for `mount` carrying a `loop` option, either of which is the concrete mechanism behind the technique's core claim — a filesystem stored inside a regular file rather than a disk partition, so that standard file-system tools never see it as a volume. `losetup` is matched on its own because attaching a file to a loop device is itself the act of creating that abstraction, independent of what happens to the device afterward; `mount` is only matched when one of its next five arguments contains the string `loop`, since a bare `mount` call covers every ordinary bind mount, tmpfs and device mount on the system and would swamp the rule with unrelated noise. Argument position is not fixed — `-o loop`, `-o loop,ro` and `--options=loop` can each land in a different argv slot depending on what else is on the command line — so the five-argument OR mirrors the a1-a4 pattern already used for T1499.001 rather than pinning one position. This rule cannot tell a hidden VFS from an entirely ordinary use of the same two commands: nothing in an EXECVE record carries where the resulting mount point sits, whether it was subsequently unmounted and its backing file deleted, or whether the file itself lives in a location a user would call hidden, so the loudest false positives below are not edge cases, they are the majority of what this rule returns on a typical Linux estate. The Windows analytic (AN1271) and macOS analytic (AN1273) in this technique's brief are not used here: AN1271 asks for "suspicious disk I/O patterns" and "bootkit-like behavior", neither of which names a field on Sysmon EventID 13/14 or Security 4663/4670/4656, and its own MonitoredRegistryKeys knob has no MITRE-supplied values to populate it with; AN1273's {product: macos, service: unifiedlog} source has no established field vocabulary anywhere in this corpus. Prerequisite: raw auditd does not record execve by default, so this returns zero rows until a rule such as `-a always,exit -F arch=b64 -S execve -k exec` is loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0461, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((type="EXECVE" AND a0="*losetup") OR ((type="EXECVE" AND (a0="mount" OR a0="/bin/mount" OR a0="/usr/bin/mount")) AND (a1="*loop*" OR a2="*loop*" OR a3="*loop*" OR a4="*loop*" OR a5="*loop*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "execve" AND TO_LOWER(a0) LIKE "*losetup") OR ((TO_LOWER(type) == "execve" AND (TO_LOWER(a0) == "mount" OR TO_LOWER(a0) == "/bin/mount" OR TO_LOWER(a0) == "/usr/bin/mount")) AND (TO_LOWER(a1) LIKE "*loop*" OR TO_LOWER(a2) LIKE "*loop*" OR TO_LOWER(a3) LIKE "*loop*" OR TO_LOWER(a4) LIKE "*loop*" OR TO_LOWER(a5) LIKE "*loop*")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 6 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)losetup$</field>    <description>Loop device created or file loop-mounted as a filesystem (1/6)</description>    <mitre>      <id>T1564.005</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(^mount$|^/bin/mount$|^/usr/bin/mount$)</field>    <field name="a1" type="pcre2">(?i)loop</field>    <description>Loop device created or file loop-mounted as a filesystem (2/6)</description>    <mitre>      <id>T1564.005</id>    </mitre>  </rule>   <rule id="100002" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(^mount$|^/bin/mount$|^/usr/bin/mount$)</field>    <field name="a2" type="pcre2">(?i)loop</field>    <description>Loop device created or file loop-mounted as a filesystem (3/6)</description>    <mitre>      <id>T1564.005</id>    </mitre>  </rule>   <rule id="100003" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(^mount$|^/bin/mount$|^/usr/bin/mount$)</field>    <field name="a3" type="pcre2">(?i)loop</field>    <description>Loop device created or file loop-mounted as a filesystem (4/6)</description>    <mitre>      <id>T1564.005</id>    </mitre>  </rule>   <rule id="100004" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(^mount$|^/bin/mount$|^/usr/bin/mount$)</field>    <field name="a4" type="pcre2">(?i)loop</field>    <description>Loop device created or file loop-mounted as a filesystem (5/6)</description>    <mitre>      <id>T1564.005</id>    </mitre>  </rule>   <rule id="100005" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(^mount$|^/bin/mount$|^/usr/bin/mount$)</field>    <field name="a5" type="pcre2">(?i)loop</field>    <description>Loop device created or file loop-mounted as a filesystem (6/6)</description>    <mitre>      <id>T1564.005</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: hide_artifacts
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 5ea14faf-680d-49d0-a15f-5a5a1172f2f9

ATT&CKT1564.005

T1564.005Hidden File System

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonhide artifacts

hide artifactsAI draft — unreviewed

01 · What this rule detects

This rule matches the Linux leg of AN1272 in MITRE's Hidden File System detection strategy (DET0461): an EXECVE record for losetup, or for mount where one of its next five arguments contains the string loop. Attaching a file to a loop device — or mounting one with a loop option — is the concrete mechanism behind the technique's core claim: a filesystem stored inside an ordinary file rather than a disk partition, invisible to standard filesystem tools.

02 · Telemetry you need

auditd EXECVE records on Linux. Raw auditd does not capture execve by default; a rule such as -a always,exit -F arch=b64 -S execve -k exec must be loaded first, or this returns zero rows that read as "quiet" but actually mean "blind." Only the Linux analytic (AN1272) is implemented. AN1271 (Windows) asks for registry modifications and "bootkit-like" disk-I/O patterns with no field vocabulary in this corpus, and AN1273 (macOS unifiedlog) has no established field vocabulary here either — neither is used.

03 · How the logic works

selection_losetup fires on any a0 ending in losetup: attaching a file to a loop device is itself the act of creating the hidden-filesystem abstraction, independent of what happens afterward. selection_mount requires a0 to exactly equal mount, /bin/mount or /usr/bin/mount — an equality list, not a substring match, so a bare mount invocation for an ordinary bind mount or tmpfs never fires on its own. selection_loop_evidence then ORs contains: 'loop' across a1 through a5, because -o loop, -o loop,ro and --options=loop can land in different argv slots depending on what else is on the command line — the same five-slot pattern this corpus already uses for T1499.001. The condition is selection_losetup or (selection_mount and selection_loop_evidence).

04 · Common false positives

This is genuinely loud, and the false positives are not edge cases — they are the majority of what the rule returns on a typical estate. snapd loop-mounts a squashfs image for every installed or refreshed snap package, the highest-volume match on any snap-enabled system by a wide margin. Forensic and VM tooling (guestmount, libguestfs, qcow2/vdi conversion scripts) loop-mounts disk images routinely during backup verification or incident response. Provisioning tooling (live-build, debootstrap, cloud-init) and admins browsing install media loop-mount ISOs and rootfs images as part of normal operations. None of this is noise the logic could tune away on its own: an EXECVE record carries no field for where the resulting mount point sits, whether it was later unmounted with its backing file deleted, or whether that file lives somewhere a user would call hidden. level: low reflects that directly.

05 · Detection maturity

tier_1: This rule has never been run against a log line. It sits at the lowest DeBMM maturity tier — authored, unexecuted, unvalidated — until someone runs it against real auditd data, measures its actual false-positive volume against a live snapd and provisioning baseline, and populates AllowedMountPoints and UserContext from that measurement.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE's AllowedMountPoints knob is the natural place to suppress snapd's /var/lib/snapd/snap/ targets and other known-routine mount points; this rule ships no values for it. MITRE's UserContext knob — flagging root escalation around the mount operation — is also unpopulated here and would meaningfully narrow the noise, since the forensic and provisioning tooling above typically runs as an unprivileged or service account rather than freshly-escalated root. Both knobs are left for whoever deploys the rule to populate against their own estate's known loop-mount sources.

Declared by the author

snapd on Ubuntu and other snap-enabled distributions loop-mounts a squashfs image for every installed or refreshed snap package, which is the highest-volume source of matches on any desktop or server running snapd by a wide margin.
Forensic and VM-image tooling such as guestmount, libguestfs and qcow2/vdi conversion scripts that loop-mount a disk image to inspect, repair or convert it as part of routine backup verification or incident response.
Administrators and build engineers loop-mounting an ISO to browse install media or verify a freshly built image, and image-pipeline tooling such as live-build, debootstrap or cloud-init that loop-mounts a rootfs during provisioning.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1564.005, evaluated against their — events.

Share this rule

/u/siemphony/5ea14faf-680d-49d0-a15f-5a5a1172f2f9

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Loop device created or file loop-mounted as a filesystem

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it