Threat Hunting Exercise: Analyzing Windows DLL Sideloading Signed Binary Proxy Execution Dataset

This hunt uses a simulated endpoint telemetry dataset (win_sysmon_dll_sideload_2022-09-20T160000.json) capturing T1574.002: Hijack Execution Flow (DLL Side-Loading), where an attacker drops a legitimately signed executable alongside a malicious DLL matching an expected import name, causing the trusted binary to load and execute attacker code under its own reputation.

Step 1: Hypothesis Formation

Hypothesis: A known-vulnerable, signed executable (e.g., a legitimate AV/utility binary susceptible to side-loading) is run from a non-standard directory alongside a DLL that was written to disk moments earlier and is not present in the vendor's official distribution, followed by network or process-injection activity originating from the signed process - indicating DLL side-loading rather than legitimate use. Indicators:

• A signed, reputable executable launched from a user-writable directory (Downloads, Temp, AppData) rather than its standard installation path.
• A DLL with a filename matching the executable's expected import, written to the same directory within seconds of the executable itself.
• The signed process subsequently performs anomalous behavior (network connections, process injection, registry persistence) inconsistent with its known legitimate functionality.
• No corresponding software installation or update record for the vendor product on this host.

Null Hypothesis: The vendor application was legitimately installed to a non-standard directory by IT or the user, and the DLL is a genuine component from the installer package. Invalidate by verifying the DLL's hash/signature against the vendor's official release and confirming an installation record.

Rationale: DLL side-loading lets attacker code inherit the trust (and often AV allow-listing) of a legitimately signed binary, making file-reputation-only detection ineffective; catching the directory/timing mismatch between the EXE and its companion DLL is a durable, tool-agnostic detection.

Step 2: Data Sources and Scope

• Sources: Sysmon Event ID 1 (process creation), 7 (image/DLL load), 11 (file creation); EDR module-load telemetry; software inventory/asset management records.
• Scope: ~2022-09-20T16:00:00-16:20:00 UTC; Host: WKS-LEGAL-017 (10.30.9.61); Directory: C:\Users\r.chen\Downloads\update_tool\.
• SIEM Queries (Splunk/ELK):
• index=sysmon EventCode=1 Image="\\Downloads\\.exe" Signed=true
• Companion DLL check: index=sysmon EventCode=11 TargetFilename="*.dll" | join Image [search EventCode=1] | where directory_match
• Post-load behavior: index=sysmon EventCode=3 Image="update_tool"

Step 3: Key Findings

Parsed events (5 shown) confirm a legitimately signed vendor executable was run from a Downloads subfolder alongside a malicious same-named-import DLL written 8 seconds earlier, resulting in outbound C2 beaconing from the trusted process.

Validation:

• Timeline: malicious DLL staged, followed 8 seconds later by the signed executable launched from the same non-standard directory, immediate DLL load, and immediate anomalous outbound connection - a complete and fast side-loading chain.
• False Positives: no software inventory entry for this vendor product exists on the host, ruling out a legitimate but oddly-located installation.
• Correlation: staging timing, execution-path anomaly, DLL load confirmation, and post-load network behavior jointly confirm malicious DLL side-loading.

Step 4: Recommendations & Next Steps

• Immediate Response: Isolate WKS-LEGAL-017, terminate the AcroCEF.exe process, quarantine both the executable and version.dll, block 194.61.55.28 at the perimeter, and determine the delivery vector (email attachment, download link) that placed the pair in the Downloads folder.
• Detection: Sigma-style rule: title: Signed Binary Executed from User Directory with Companion DLL → selection: EventID=1 AND Signed=true AND Image contains '\\Downloads\\' OR Image contains '\\AppData\\' filter: known_portable_apps → condition: selection and not filter.
• Pro Tip: Maintain and continuously update a list of known DLL side-load-vulnerable signed binaries (a well-documented, evolving public list) and alert whenever any of them execute outside their standard installation directory - this drastically narrows the haystack since only a few dozen binaries account for the overwhelming majority of real-world side-loading abuse.

Hypothesis confirmed - an attacker staged a malicious DLL alongside a legitimately signed executable in a user's Downloads folder, achieving trusted-process code execution and C2 beaconing that evaded reputation-based defenses!