Detect Dylib Hijacking in Sumo Logic CSE
Adversaries on macOS may execute malicious payloads by placing a malicious dynamic library (dylib) in a path that a victim application searches at runtime. The macOS dynamic linker searches paths in order: @rpath (relative run-path), @loader_path, @executable_path, and standard system paths (/usr/lib, /System/Library). If an application references a dylib with a weak link (LC_LOAD_WEAK_DYLIB) and the dylib does not exist, an adversary can plant a malicious dylib with the correct name at the expected path. The Empire post-exploitation framework includes modules specifically for scanning and exploiting dylib hijacking vulnerabilities.
MITRE ATT&CK
- Technique
- T1574 Hijack Execution Flow
- Sub-technique
- T1574.004 Dylib Hijacking
- Canonical reference
- https://attack.mitre.org/techniques/T1574/004/
Sumo Detection Query
(index=osquery OR index=jamf OR _sourceCategory=mac/filevents OR _sourceCategory=mac/osquery)
| where sourcetype matches "osquery*" or sourcetype matches "jamf*"
| where path matches "%.dylib"
| where path matches "/tmp/%" or path matches "/var/folders/%" or path matches "/Users/%/Library/%" or path matches "/private/tmp/%" or path matches "/Users/%/Library/Application Support/%"
| eval suspicious_path = if(path matches "/tmp/%" or path matches "/private/tmp/%", "temp_path",
if(path matches "/var/folders/%", "var_folders",
if(path matches "/Users/%/Library/Application Support/%", "app_support", "user_library")))
| eval rpath_indicator = if(path matches "%@rpath%", 1, 0)
| fields _time, host, path, action, sha256, pid, process_name, suspicious_path, rpath_indicator
| sort by _time descDetects macOS .dylib file creation and modification events in paths exploitable via dylib hijacking. Correlates file events from osquery or Jamf log sources to identify newly written shared libraries in directories traversed by the macOS dynamic linker when resolving @rpath or @loader_path references.
Data Sources
Required Tables
False Positives & Tuning
- Package managers such as Homebrew writing dylibs to user-owned Library paths during install or upgrade operations
- Electron-based applications unpacking bundled native modules as .dylib files into Application Support directories
- Software developers running local builds or debug sessions that produce .dylib artifacts in /tmp or /var/folders
Other platforms for T1574.004
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1List Vulnerable Applications Using otool
Expected signal: Process creation event for otool. No file creation events generated. This is a read-only reconnaissance action. macOS audit logs (if enabled) would show the file read operations.
- Test 2Create Malicious Dylib in @rpath Location
Expected signal: File creation event for .dylib file in user Library path. Process creation events for gcc (if installed). The dylib file will appear as unsigned in code signing checks (codesign -v ~/Library/test-hijack/libtest.dylib).
- Test 3Verify DYLD Environment Variable Propagation
Expected signal: Process creation event for ls with DYLD_PRINT_LIBRARIES environment variable set. The output shows which dylibs ls loads. macOS SIP (System Integrity Protection) may suppress DYLD_* variables for protected binaries.
References (6)
- https://attack.mitre.org/techniques/T1574/004/
- https://objective-see.com/blog/blog_0x46.html
- https://www.virusbulletin.com/uploads/pdf/magazine/2015/vb201503-dylib-hijacking.pdf
- https://malwareunicorn.org/workshops/macos_dylib_injection.html#5
- https://github.com/EmpireProject/Empire/blob/master/lib/modules/python/situational_awareness/host/osx/HijackScanner.py
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1574.004/T1574.004.md
Unlock Pro Content
Get the full detection package for T1574.004 including response playbook, investigation guide, and atomic red team tests.