Shared object written into a non-standard directory Linux dynamic linker would trust

Siemphony@siemphonylowT1574.006unverified

AN1209 offers three log sources and only one of them survives scrutiny. Its first, `auditd:SYSCALL::execve with LD_PRELOAD ... set`, is mapped in the brief to `process_creation`/linux — Image/CommandLine fields that mirror a process's own argv. `LD_PRELOAD` is an environment variable, not an argument: `export LD_PRELOAD=/tmp/x.so` followed by a plain command, or the value set persistently in a shell-init file, never appears in that child's argv at all, so a `CommandLine|contains: 'LD_PRELOAD'` selector would only ever catch the narrow case of the assignment typed inline in the same invocation (`env LD_PRELOAD=/tmp/x.so cmd`) and would silently miss the far more common shell-export and profile-persistence forms while looking like it covers the technique. Its third, `linux:osquery`, has no standardised Sigma field vocabulary anywhere in this corpus — the same blocker already recorded against that log source for T1011 and T1499.003. What remains, and what this rule is built on, is the second: an auditd `PATH` record naming a `.so` file — matched with a regex tolerant of the versioned suffixes real shared objects and LD_PRELOAD payloads that mimic them actually carry (`libfoo.so.1`, `libfoo.so.6.1`), since a plain `endswith('.so')` misses every one of those and this is exactly the version-suffix trap that defeats naive extension checks elsewhere in this corpus — written into a directory the dynamic linker has no special trust in but a user process can freely write to — `/tmp`, `/var/tmp`, `/dev/shm` and any path under `/home`. That is MITRE's own MonitoredDirectories knob, populated here with those four; a library staged in one of them is the physical artefact `LD_PRELOAD` (or a written `/etc/ld.so.preload` line) has to point at, regardless of which mechanism set the variable or whether this rule's own execve leg saw it. MITRE's CorrelationWindow knob — correlating this write with the later process that actually loads the library — is not attempted: lib/sigma has no aggregation or cross-event correlation, so this rule is a location-based content match on one write event, nothing more. The macOS leg AN1210 (`DYLD_INSERT_LIBRARIES`/`DYLD_LIBRARY_PATH`) is not attempted either: its log source is `macos:unifiedlog`, unstandardised in this corpus for the same reason as the third leg above. A PATH record like this one is only emitted for a syscall auditd is already watching, and a static `-w` watch cannot cover `/tmp`/`/dev/shm`/`/home` by inode the way it can a fixed file — this needs a broad `-S openat` (or `open`) audit rule with `-F success=1`, which is far higher-volume than a path watch and is not present in any mainstream default configuration; without it, this rule returns zero rows because nothing is being recorded, not because nothing was written. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0435, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 2 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=* | where ((match(type, "(?i)^PATH$") AND match(name, "\\.so(\\.[0-9]+)*$")) AND (match(name, "(?i)/tmp/") OR match(name, "(?i)/var/tmp/") OR match(name, "(?i)/dev/shm/") OR match(name, "(?i)/home/")))

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. -->  <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)^PATH$</field>    <field name="name" type="pcre2">(?i)\.so(\.[0-9]+)*$</field>    <field name="name" type="pcre2">(?i)(/tmp/|/var/tmp/|/dev/shm/|/home/)</field>    <description>Shared object written into a non-standard directory Linux dynamic linker would trust</description>    <mitre>      <id>T1574.006</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.

Elastic · ES|QL

Run this as a search.

Elastic cannot express this construct. ES|QL RLIKE uses Lucene regexp syntax, which has no case-insensitive flag, and Sigma regexes are case-insensitive. Use |contains/|startswith/|endswith, or write the ES|QL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: registry_persistence
Sigma status: experimental
Backends: 2 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 8e6ca8ba-9a5b-4840-bc01-37e0fa589c09

ATT&CKT1574.006

T1574.006Dynamic Linker Hijacking

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.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

This rule looks for a shared object file being written into a directory the Linux dynamic linker has no special trust in but any user process can write to freely — a common staging step before LD_PRELOAD (or a written /etc/ld.so.preload line) points at it to hijack every subsequent process's symbol resolution. It is built from one of AN1209's three offered log sources; the other two were assessed and rejected.

02 · Telemetry you need

An auditd PATH record — the same event type generated for any recorded open/access/write. This requires a broad -S openat (or open) audit rule with -F success=1, not a static -w watch, because the target directories (/tmp, /var/tmp, /dev/shm, /home) can't be pinned by inode the way a single file can. That kind of broad syscall watch is far higher-volume than a path watch and is not present in any mainstream default configuration. Without it, this rule returns zero rows because nothing is being recorded, not because nothing was written.

03 · How the logic works

Three selections, ANDed. selection_path_record gates on type: 'PATH'. selection_object matches the filename with name|re: '\.so(\.[0-9]+)*$' — a regex, not a plain endswith('.so'), specifically because real shared objects and the LD_PRELOAD payloads that mimic them routinely carry a version suffix after the extension (libfoo.so.1, libfoo.so.6.1), which is exactly this corpus's documented version-suffix trap and would have silently missed the most disguise-prone filenames under a naive check. selection_nonstandard_dir requires the same path to contain one of /tmp/, /var/tmp/, /dev/shm/, or /home/ — MITRE's own MonitoredDirectories knob, populated here with those four values by the pipeline, not supplied by MITRE. Two of AN1209's log sources were dropped. The auditd:SYSCALL::execve leg, mapped to process_creation, would need LD_PRELOAD visible in a child's CommandLine, but LD_PRELOAD is an environment variable — set via export or a shell-init file, it never appears in argv at all. A CommandLine|contains: 'LD_PRELOAD' selector would only catch the narrow inline case (env LD_PRELOAD=/tmp/x.so cmd) while silently missing the far more common export and profile-persistence forms. The linux:osquery leg has no standardised Sigma field vocabulary anywhere in this corpus, the same blocker recorded elsewhere. MITRE's CorrelationWindow knob — tying this write to the later process that loads the library — is also not attempted: lib/sigma has no aggregation or cross-event correlation, so this is a single-event content match, nothing more. The macOS leg (AN1210, DYLD_INSERT_LIBRARIES) is skipped for the same unstandardised-log-source reason.

04 · Common false positives

level is low because the loudest matches here are routine, not rare. Python virtual environments and pip installs of any package with compiled C extensions write new .so files under a user's home directory on essentially every install — the dominant benign source on a developer or data-science host. Build and CI pipelines compile shared objects as intermediate artefacts into /tmp or /var/tmp before installing them (autoconf/make, node-gyp, R packages). Container image builds stage .so files in /tmp inside intermediate layers on every CI run. Some desktop audio/graphics/IPC frameworks memory-map or cache libraries under /dev/shm as normal operation.

05 · Detection maturity

tier_1: Unverified and at the lowest DeBMM tier — this rule has never executed against a log line. It needs to be run with a broad openat audit rule active against real staging activity (both benign package installs and, if possible, a simulated LD_PRELOAD drop) before any confidence is assigned.

Tuning & false positivesexperimental · 4 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

Suppress known build agents, CI runner accounts, and virtualenv/pip cache paths first — they will dominate raw volume. Consider narrowing /home/ to exclude common package-manager subpaths (site-packages, .cache/pip) rather than the whole home tree. Because there's no correlation to the process that later loads the file, pair any hit with a lookup for unusual processes reading the same path shortly afterward, done outside this rule.

Declared by the author

Python virtual environments and pip installs of packages with compiled C extensions, which write new .so files under a user's home directory — inside a venv's site-packages or pip's build cache — on essentially every install of a native-extension package, the dominant benign source on any developer or data-science host.
Build and CI pipelines that compile a shared object as an intermediate artefact into /tmp or /var/tmp before installing it to its final location — autoconf/make, node-gyp native addons and R package compilation on a build agent all do this routinely.
Container image builds staging a .so file in /tmp inside an intermediate layer before COPY-ing it into the final image, which fires once per affected build on every CI run.
Desktop and session software that memory-maps or caches shared libraries under /dev/shm — some audio, graphics and IPC frameworks use it as a working area for shared library data as part of normal operation, not file staging.

Noise checkdid not run

The Sigma source did not build into an evaluable rule, so the check did not run. this rule uses a regular expression, which is not evaluated here — an untrusted pattern can be made to run for a very long time

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.

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Test it yourselfin your browser

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

Recordings of T1574.006, evaluated against their — events.

Share this rule

/u/siemphony/8e6ca8ba-9a5b-4840-bc01-37e0fa589c09

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.

Shared object written into a non-standard directory Linux dynamic linker would trust

The detection

detection.yml

Splunk · SPL

Wazuh · XML rule

Sentinel · KQL

Elastic · ES|QL

Community

Verdicts from engineers who deployed it