Shared Module Detection: T1129 and Tuning in Practice

T1129 — Shared Modules. An attacker drops a malicious DLL and gets a legitimate running process to load it. Instead of running their own executable they inject code into a trusted process through a shared library. The detection challenge: DLL loading is extremely high volume. Every application loads dozens of DLLs on startup. The goal is to detect DLLs from suspicious locations — not every DLL load.

Enabling Event ID 7 in Sysmon

Sysmon Event ID 7 captures DLL loading. The SwiftOnSecurity config disables this by default because of volume. The sysmonconfig.xml ImageLoad section was empty:

<ImageLoad onmatch="include">
    <!--NOTE: Using "include" with no rules means nothing will be logged-->
</ImageLoad>

Added selective include rules targeting suspicious locations:

<ImageLoad onmatch="include">
    <ImageLoaded condition="contains">\Temp\</ImageLoaded>
    <ImageLoaded condition="contains">\Downloads\</ImageLoaded>
    <ImageLoaded condition="contains">\AppData\</ImageLoaded>
    <Signed condition="is">false</Signed>
</ImageLoad>

# Reapply config
C:\Windows\Sysmon64.exe -c $env:temp\sysmonconfig.xml

Verifying the group tag

sudo grep -A5 "sysmon_event7" /var/ossec/ruleset/rules/0330-sysmon_rules.xml

Confirmed: sysmon_event7 — no underscore before 7. Different from Event ID 11. Always verify before using.

The detection rules

<!-- Rule 100018 — location-based detection -->
<rule id="100018" level="5">
  <if_group>sysmon_event7</if_group>
  <field name="win.eventdata.imageLoaded" type="pcre2">(?i)(\Temp\|\Downloads\|\AppData\)</field>
  <description>Sysmon: DLL loaded from suspicious location</description>
  <group>sysmon,suspicious_dll_load,T1129,</group>
</rule>

<!-- Rule 100019 — signature-based detection -->
<rule id="100019" level="5">
  <if_group>sysmon_event7</if_group>
  <field name="win.eventdata.signed" type="pcre2">(?i)^false$</field>
  <field name="win.eventdata.imageLoaded" negate="yes" type="pcre2">(?i)WindowsApps</field>
  <description>Sysmon: Unsigned DLL loaded by process</description>
  <group>sysmon,suspicious_dll_load,T1129,</group>
</rule>

<!-- Rule 100020 — correlation — both conditions met -->
<rule id="100020" level="12" frequency="2" timeframe="60" ignore="300">
  <if_matched_group>suspicious_dll_load</if_matched_group>
  <same_location />
  <description>Sysmon: Suspicious DLL load confirmed</description>
  <group>sysmon,suspicious_dll_load,T1129,confirmed,</group>
</rule>

Tuning in real time

Opening Windows Calculator triggered Rule 100019 repeatedly — Calculator loads unsigned DLLs from the WindowsApps folder. This is expected Windows behaviour, not an attack.

The fix: a negate condition to exclude the WindowsApps path:

<field name="win.eventdata.imageLoaded" negate="yes" type="pcre2">(?i)WindowsApps</field>

After the fix, opening Calculator generates zero alerts. A malicious DLL dropped in AppData and loaded by any process would still trigger both 100018 and 100019, causing 100020 to fire at level 12.

The negate tag

negate="yes" inverts the condition — the field must NOT match the specified value. Useful for excluding known-good sources of noise without disabling the broader detection. This is what tuning looks like in practice: a working rule made quieter on legitimate activity while keeping its sensitivity to real attacks.