Keynote: Dylib Hijacking on macOS: Dead or Alive?

Keynote: Dylib Hijacking on macOS: Dead or Alive?

Speakers: Patrick Wardle (Founder, Objective-See Foundation / DoubleYou)

Conference: Ekoparty Miami

YouTube: https://www.youtube.com/watch?v=bcWs_FCdzyM

Overview

In this insightful keynote from Ekoparty Miami, renowned macOS security researcher Patrick Wardle challenges the prevailing notion that dyld hijacking on macOS is a defunct attack vector. While Apple has introduced a suite of formidable mitigations aimed at neutralizing this threat, Wardle demonstrates that sophisticated attackers can still exploit weaknesses in these defenses, allowing for local privilege escalation, stealthy persistence, and evasion of popular security tools. The presentation not only revisits the mechanics of dyld hijacking but also broadens its scope to illustrate how dynamic libraries are consistently leveraged by advanced persistent threats, widespread malware, and zero-day exploits on macOS.

Wardle, known for his deep dives into macOS internals and founder of Objective-See, provides a comprehensive analysis, moving from fundamental definitions to concrete proof-of-concept demonstrations. He meticulously dissects Apple's security mechanisms like App Translocation, Notarization, and Library Validation, exposing their limitations and revealing practical bypasses. The talk culminates in a strong call to action for defenders, outlining new programmatic approaches using macOS's Endpoint Security framework and other APIs to detect and prevent malicious dynamic library loading, emphasizing that ignoring these critical components of modern operating systems is no longer an option for robust security.

Background

▶ Watch: Introduction to Dylib Hijacking and core concepts (0:00)

At its core, this talk revolves around the fundamental concept that security decisions on operating systems like macOS are predominantly made at the process level. This means that any code loaded within a trusted process inherits its permissions and entitlements. For adversaries, this presents a powerful opportunity: if a malicious library can be injected into a highly privileged or widely trusted process, the attacker effectively gains the capabilities of that process. Historically, however, security tools and operating system APIs have provided limited visibility into the specific dynamic libraries loaded by a given process, creating a blind spot that attackers have long exploited for stealth and persistence.

A library is reusable compiled code loaded at runtime, while a dependency is a library a program requires. On macOS, these are known as dynamic libraries or dylibs, and the system component responsible for loading them is the dynamic linker (dyld). The concept of library hijacking first gained public prominence on Windows, with the NSA describing such vulnerabilities as early as 1998, and HD Moore bringing widespread attention to the issue in 2010, leading to numerous CVEs and patches from Microsoft. Five years later, in 2015, Patrick Wardle discovered that macOS was similarly vulnerable to these attacks.

The vulnerability stems from how dyld resolves run path dependencies. When a developer creates an application with its own local libraries, they cannot hardcode absolute paths, as the application's final location on a user's system is unknown. Instead, they use @rpath prefixes in LC_LOAD_DYLIB load commands. These indicate that the library's path should be resolved relative to the executing program. The dyld then consults LC_RPATH load commands within the binary, which specify a list of directories to search. The critical flaw arises because dyld loads the first dynamic library it finds that matches the required name. If a legitimate dependency is located in a secondary search path, a local attacker can place a malicious dylib with the identical name in a primary search path. The dyld will then naively load the attacker's library, granting it the full trust and capabilities of the host process, all without modifying the original application binary or breaking its code signature.

In 2015, when Wardle first unveiled this, "everything was vulnerable." This included a vast array of Apple's own applications, Microsoft products, and third-party software. The implications were severe, allowing for stealthy persistence (e.g., by hijacking dylibs in auto-starting Apple programs), manipulation of software builds (by injecting into Xcode), and even remote attacks that bypassed Gatekeeper by packaging vulnerable applications with external malicious dylibs on disk images. While not every vulnerable application presented a critical security risk (e.g., hijacking Notepad++ might not yield significant privileges), the widespread nature of the vulnerability underscored a systemic issue in macOS's dependency loading mechanism.

Key Findings

▶ Watch: Apple's Mitigations and the Dylib Hijack Resurgence (16:50)

Despite Apple's significant efforts to mitigate dyld hijacking, Patrick Wardle's research unequivocally demonstrates that the attack is not dead on recent versions of macOS, specifically macOS 26 (referring to the internal version number likely used during the talk's preparation, implying modern macOS). His findings reveal critical shortcomings in Apple's implemented security measures and offer new techniques for adversaries.

One of the most significant discoveries is a bypass for App Translocation. Apple introduced translocation (also known as Gatekeeper path randomization) to prevent internet-downloaded applications from loading external malicious content by copying them to a secure, randomized, read-only location. However, Wardle found that symlinking directly to the application's executable binary within the application bundle, rather than the application itself, prevents translocation. This allows an application to run directly from its original (potentially untrusted) location on a disk image or zip archive, enabling it to load external malicious dylibs that would otherwise be severed by translocation. This effectively re-opens a remote attack vector, making it possible to distribute notarized-but-vulnerable applications that then load unverified malicious code.

For local hijacks, Wardle proved they are still viable. Using his open-source tool, dylib hijack scanner, he identified several third-party applications vulnerable to dyld hijacking on modern macOS. The key criteria for a vulnerable application are:

1. It has a run path dependency and multiple run path directories, with the legitimate dylib located in a secondary search path.
2. It is a third-party application (Apple's own apps are now heavily locked down).
3. Crucially, it either does not opt into the hardened runtime or has library validation disabled. This last point is vital because library validation, a powerful Apple mitigation, prevents applications from loading dylibs not signed by Apple or the application developer. Many applications, like Adobe Photoshop, disable library validation to support third-party plugins, creating an Achilles' heel.

Wardle demonstrated a successful hijack against Adobe Photoshop, which met all these criteria. He crafted a malicious dylib that mimicked the legitimate libtbd 12.6.dylib dependency. To ensure compatibility and prevent application crashes, the malicious dylib was carefully designed to match the legitimate library's version number and, more elegantly, to provide all expected exports using the linker's re-export directive (LC_REEXPORT_DYLIB). This directive allows the malicious dylib to simply point to the original, legitimate dylib for all its exports, making the hijack seamless to the application.

Furthermore, Wardle uncovered two critical flaws in Apple's local mitigations:

1. Bypassing App Protection/TCC: While macOS prevents direct modification of applications in the /Applications directory, attackers can easily bypass this by copying the target application to a writable temporary location (e.g., /tmp), injecting the malicious dylib, and then copying the modified application back.
2. Failed Gatekeeper Revalidation: Even after modifying an application, Gatekeeper is supposed to detect the tampering and revalidate the entire application bundle, blocking its execution if the code signature is broken. However, Wardle demonstrated that macOS's runtime revalidation mechanism is flawed. Despite a noticeable delay (around 25 seconds for Photoshop), the system failed to detect the injected dylib and allowed the tampered Photoshop to launch successfully. This critical failure allows the malicious dylib to execute within the trusted process.

The successful hijack of Photoshop illustrated profound stealth and security tool evasion. The injected dylib inherited all of Photoshop's entitlements, including Full Disk Access and network permissions. Wardle showed how common security tools like Lulu (firewall), ES Logger (Endpoint Security monitor), and Santa (whitelisting/binary authorization tool) were effectively blind to the malicious activity. These tools primarily perform runtime code signing checks on the main application binary, which remains untampered. As a result, they incorrectly identify the process as legitimate Photoshop, allowing the malicious dylib's actions (e.g., network connections, file access) to proceed unhindered.

Beyond dyld hijacking, Wardle highlighted that dynamic libraries are a pervasive vector for adversaries. He cited examples from:

• Equation Group (NSA): Their first-stage macOS implant was distributed as a dylib, leveraging the DYLD_INSERT_LIBRARIES environment variable for injection and stealth.
• Flashback Malware: An early widespread Mac malware, it installed itself as a dylib in Safari, modifying its info.plist to inject the library for browser stream manipulation.
• 3CX Supply Chain Attack: Malicious code was embedded within libffmpeg.dylib inside a signed and notarized 3CX application, executing via a constructor function to download a second-stage payload. This demonstrated how Apple's notarization initially missed sophisticated dylib-based malware.
• Code Colorist Exploit: A recent zero-day exploit that used a carefully crafted sandbox profile to control the loading of a swift demangle dylib by the core symbolication library within powerful system processes, ultimately bypassing System Integrity Protection (SIP).

These examples underscore that dylibs are not just a historical vulnerability but a continuously exploited component across the spectrum of macOS threats.

Technical Deep Dive

▶ Watch: Why Firewalls and EDR Miss Dylib Hijacks (28:00)

The technical foundation of dyld hijacking on macOS rests on the intricacies of how the dyld (dynamic linker) loads applications and their dependencies. When a user launches an application, dyld is responsible for preparing it for execution, which includes mapping the binary into memory and, critically, resolving and loading all required dynamic libraries.

The blueprint for these dependencies is embedded within the application's Mach-O binary in structures known as load commands. Specifically, the LC_LOAD_DYLIB command specifies a dependency on a particular dylib. For system libraries, these paths are often absolute (e.g., /usr/lib/libSystem.dylib). However, for developer-provided libraries within an application bundle, absolute paths are impractical due to the application's variable installation location. This is where run path dependencies, identified by the @rpath prefix in LC_LOAD_DYLIB, come into play.

When dyld encounters an @rpath dependency, it needs to determine the actual file path. It does this by consulting LC_RPATH load commands, which define a list of directories where the dylib might reside. dyld iterates through these directories in order, loading the first dylib it finds that matches the specified name. This ordered search is the root cause of the dyld hijacking vulnerability: if a legitimate dylib is in a later search path, an attacker can plant a malicious dylib with the same name in an earlier search path, ensuring their code is loaded instead. Crucially, this attack does not modify the main application binary, thus preserving its code signature.

Apple has rolled out several mitigations since Wardle's initial findings in 2015:

• Remote Attack Fix: An early fix blocked applications on disk images from referencing dylibs outside their bundle, addressing the Gatekeeper bypass for external dependencies.
• Gatekeeper Path Randomization / App Translocation: For applications downloaded from the internet, macOS now copies the application bundle to a randomized, read-only location (an "app translocation folder") before execution. This severs any external references, preventing the app from loading malicious content from other parts of the original disk image.
• Bypass: Wardle demonstrated that symlinking directly to the executable binary inside the application bundle (e.g., MyApp.app/Contents/MacOS/MyApp) instead of the .app bundle itself prevents translocation, allowing the application to run from its original, potentially untrusted, location.
• Notarization: Developers must submit their applications to Apple for automated scanning and approval before distribution. This measure aims to prevent attackers from repackaging legitimate, vulnerable applications with malicious dylibs and distributing them. While effective against basic repackaging, the 3CX supply chain attack showed that sophisticated malware can still be embedded within notarized dylibs.
• Library Validation: This is arguably Apple's most potent mitigation. When an application opts into the hardened runtime (a security feature applied at build time), macOS enforces that it can only load dylibs signed by Apple or by the application's own developer.
• Bypass/Exception: The effectiveness of library validation is contingent on the application opting into it. Many third-party applications, particularly those supporting plugins (like Adobe Photoshop), explicitly disable library validation, creating a window for dylib hijacking.
• App Protection: macOS prevents unauthorized modification of applications within the /Applications directory, even with root privileges. Furthermore, Gatekeeper is designed to revalidate the code signature of any application detected as modified before allowing it to run.
• Modification Bypass: Attackers can circumvent App Protection by copying the target application to a writable location (e.g., /tmp), injecting their malicious dylib, and then copying the modified application back to /Applications.
• Gatekeeper Revalidation Bypass: Wardle's critical finding here is that macOS's runtime revalidation of modified application bundles is flawed. Despite a significant delay, the system fails to detect the injected dylib and allows the tampered application to run, effectively ignoring the broken code signature.

Crafting a malicious dylib to perform a hijack requires careful attention to detail. The attacker's dylib must:

1. Match the legitimate dylib's version number: Failure to do so will cause dyld to crash. This is a straightforward setting in development environments like Xcode.
2. Provide the same exports: Applications link against dylibs expecting specific functions or symbols (exports). If the malicious dylib doesn't provide these, the application will crash. Wardle highlighted an elegant solution: the LC_REEXPORT_DYLIB load command. This linker directive allows the malicious dylib to declare that it re-exports all symbols from the legitimate dylib. When dyld loads the malicious dylib and looks for symbols, it's redirected to the original library, ensuring the application functions normally while the malicious code (e.g., in a constructor function) executes.

Beyond hijacking, Wardle showcased how dynamic libraries are a favored vector for various threats:

• Equation Group (NSA) implant: This nation-state malware was designed as a dylib, using the DYLD_INSERT_LIBRARIES environment variable to inject itself into target processes. This environment variable forces dyld to load a specified dylib into any subsequent process that is launched, offering a powerful injection mechanism.
• Flashback Malware: This early, widespread macOS malware also installed itself as a dylib. It achieved persistence and injection into Safari by modifying the browser's info.plist file to set the DYLD_INSERT_LIBRARIES environment variable, pointing to its malicious dylib. This allowed the malware to hook browser functions for financial gain.
• 3CX Supply Chain Attack: In this high-profile attack, malicious code was stealthily embedded within libffmpeg.dylib, an internal dependency of the legitimate 3CX application. The dylib, though signed and notarized by Apple, contained a constructor function that executed automatically upon loading, initiating a download of a second-stage payload. This demonstrated how sophisticated attackers can bypass notarization by hiding malicious logic within legitimate-looking dylibs.
• Code Colorist Exploit: This exploit targeted macOS's core symbolication library, which attempts to load a swift demangle library from specific paths. By combining a specially crafted sandbox profile to block access to the default system path (/usr/lib) and controlling a user-controlled environment variable that specified an alternative search path, the attacker could force system applications with powerful entitlements to load their malicious swift demangle dylib. This ultimately allowed for System Integrity Protection (SIP) bypass and privilege escalation.

These examples underscore the versatility and stealth offered by dynamic libraries as an attack surface, making them a critical area for both offensive and defensive security research.

Demo / Proof of Concept

▶ Watch: Notarized 3CX Supply Chain Attack via Dylib (34:00)

Patrick Wardle’s presentation included compelling demonstrations to illustrate the continued viability of dyld hijacking on modern macOS and the challenges it poses to existing security tools.

The first step in any dyld hijacking attack is identifying vulnerable applications. Wardle used his open-source tool, dylib hijack scanner, which implements the criteria discussed earlier: an application must have a run path dependency (@rpath), multiple run path directories with the legitimate dylib in a secondary location, be a third-party application, and crucially, either not opt into the hardened runtime or have library validation disabled. Running this scanner on his system, Wardle identified several vulnerable applications, choosing Adobe Photoshop as the target for the proof of concept.

Photoshop was an ideal target because:

1. It had a run path dependency on libtbd 12.6.dylib.
2. The libtbd dylib was located in a secondary search path within Photoshop's bundle.
3. Significantly, Photoshop had library validation disabled, likely to support its extensive plugin ecosystem. This meant it would willingly load a dylib not signed by Adobe, including an attacker's malicious one.

The exploitation unfolded in a live demonstration:

1. A malicious libtbd 12.6.dylib was crafted. This dylib contained attacker-controlled code (e.g., to open a "secret file" that normally required Full Disk Access) and, critically, used the LC_REEXPORT_DYLIB load command to proxy all other expected exports to the legitimate libtbd dylib.
2. To bypass macOS's App Protection (which prevents modification of applications in /Applications), Photoshop was first copied to a writable temporary directory (e.g., /tmp).
3. The malicious libtbd dylib was then injected into Photoshop's application bundle at the primary search path location.
4. The modified Photoshop application was copied back to the /Applications directory.
5. When Photoshop was launched, macOS initiated a validation process, resulting in a noticeable delay (approximately 25 seconds). However, to Wardle's surprise (and the audience's), the system failed to detect the tampering and allowed the modified Photoshop to launch successfully.
6. Upon launch, the injected malicious dylib executed its code, demonstrating its ability to open the "secret file" – an action that would typically require Full Disk Access, which the hijacked Photoshop process inherently possessed. This confirmed that the malicious dylib inherited the full privileges of the trusted application.

The demonstration further highlighted the profound stealth achieved by dyld hijacking, particularly in evading common security tools:

• Lulu (Firewall): Wardle's own open-source firewall, Lulu, uses Apple's network extension framework and performs runtime code signing checks on processes attempting network access. When the hijacked Photoshop (via the malicious dylib) attempted to connect to the internet, Lulu's checks only validated the main Photoshop binary, which remained untampered. Consequently, Lulu reported Photoshop as legitimate and allowed the connection, unaware it originated from an injected malicious component.
• Endpoint Security (ES Logger): Using macOS's built-in eslogger utility to monitor file open events, the malicious dylib's attempt to access the "secret file" was logged. However, the event was attributed solely to the "Photoshop" process, with no indication that it originated from an injected malicious dynamic library. The granularity of Endpoint Security events, at the process level, obscured the true source of the activity.
• Santa (Binary Authorization): Santa, a strict whitelisting security tool, is designed to only allow pre-approved binaries to run. Wardle demonstrated that Santa, likely relying on similar main-binary code signing checks as Lulu, allowed the hijacked Photoshop to execute without issue, failing to detect the injected dylib.

These demonstrations served as a stark reminder that while Apple has implemented numerous security features, critical gaps remain, allowing sophisticated dyld hijacking attacks to succeed and remain undetected by widely deployed security solutions.

Defensive Implications

▶ Watch: Blocking Malicious Dylibs with Endpoint Security (43:00)

Patrick Wardle's talk provides a critical blueprint for defenders to detect and prevent malicious dynamic library abuse on macOS. He emphasizes that security tools must move beyond solely examining the main application binary and gain deeper visibility into loaded dylibs.

1. Static Analysis of Load Commands:

Defenders can programmatically parse the Mach-O headers and load commands of any application. By extracting all LC_LOAD_DYLIB entries, a comprehensive list of all dynamic libraries an application will attempt to load at runtime can be generated.

• Malware Detection: This list can be used to identify suspicious dylibs. For instance, in the 3CX supply chain attack, static analysis of libffmpeg.dylib would have revealed its malicious constructor function.
• Vulnerable Application Identification: By also parsing LC_RPATH commands and checking for run path dependencies where the legitimate dylib is found in a secondary location, defenders can proactively identify applications vulnerable to hijacking. Wardle's dylib hijack scanner tool provides open-source code for this.

2. Improved Code Signing Validation:

The current runtime code signing APIs in macOS (codesign) are insufficient as they only validate the main executable binary, ignoring injected dylibs.

• File System Code Signing APIs: While macOS does have APIs to perform a full, recursive code signature validation of an entire application bundle (including all its contents, like injected dylibs), these are extremely slow (e.g., 60 seconds for Photoshop). This makes them impractical for real-time security checks (e.g., by a firewall). However, they could be employed by background scanners or integrity monitoring tools to periodically validate application integrity. Apple's failure to perform this comprehensive validation at runtime during application launch is a critical flaw.

3. Runtime Detection of Loaded Dylibs (New Capability):

A significant finding for defenders is a method to retrieve a list of all currently loaded dynamic libraries for any running process, even without special entitlements. This addresses the long-standing visibility gap.

• API: The key is the proc_pidinfo API with the PROC_PIDREGIONPATHINFO constant. This API returns a list of memory regions for a given process ID.
• Mechanism: By iterating through these regions and filtering for executable ones, defenders can extract the file paths of all loaded dylibs.
• Detection Logic: With this list, security tools can:
• Detect Name Collisions: Identify instances where multiple dylibs with the same base name are loaded by a single process (e.g., two libtbd dylibs). This is highly suspicious.
• Check Code Signing: For any colliding dylibs, verify their code signing information. If one is legitimately signed by the application developer (e.g., Adobe) and the other has an ad-hoc or missing signature, it's a strong indicator of a hijack. This provides a programmatic, runtime method to detect active dylib hijacks.

4. Prevention at Load Time with Endpoint Security:

The most powerful defensive measure involves using the Endpoint Security (ES) framework to prevent malicious dylibs from loading in the first place.

• Event of Interest: Defenders can register for ES_EVENT_TYPE_NOTIFY_MMAP or ES_EVENT_TYPE_AUTH_MMAP events. These events are triggered whenever a file is mapped into memory. Critically, when a dylib is loaded, an mmap event occurs.
• Interception and Decision: When an mmap event for an executable region (indicating a dylib load) occurs, macOS will pause the loading process and consult the registered Endpoint Security client.
• Prevention Logic: The security tool can then:
• Extract the path of the dylib attempting to load.
• Perform real-time checks: Is it a known malicious dylib? Is it signed correctly? Does it match known hijack patterns?
• If deemed malicious or suspicious, the security tool can return deny to the operating system, preventing the dylib from being loaded and executed. This allows for proactive blocking of dylib hijacks, supply chain attacks, and dylib-based exploits at the earliest possible stage.

In summary, Wardle's talk equips defenders with specific tools and strategies, moving beyond traditional security paradigms to address the often-overlooked threat surface of dynamic libraries on macOS.

Key Takeaways

• Dylib Hijacking is Alive: Despite Apple's significant investment in mitigations, dyld hijacking remains a viable attack vector on modern macOS due to persistent flaws in App Translocation and, critically, the incomplete runtime validation of modified application bundles by Gatekeeper.
• Adversaries Love Dylibs: Dynamic libraries are a preferred mechanism for nation-state actors, widespread malware, and zero-day exploits on macOS due to their inherent stealth, ability to inherit process privileges, and historical lack of visibility from security tools.
• Security Tools Are Often Blind: Current macOS security solutions, including firewalls (e.g., Lulu), Endpoint Security monitors (e.g., ES Logger), and whitelisting tools (e.g., Santa), often fail to detect malicious dylibs because they primarily validate the main application binary, overlooking injected or malicious dynamic library components.
• New Defensive Capabilities Exist: Defenders now have powerful programmatic ways to detect and prevent dylib-based attacks. This includes using the proc_pidinfo API to list loaded dylibs for runtime detection of hijacks and, most effectively, leveraging the Endpoint Security framework's MMAP events to intercept and deny the loading of malicious dynamic libraries at the earliest possible stage.
• Apple's Role in Mitigation: For dyld hijacking to be truly "dead," Apple must address the App Translocation bypass (symlinking) and, more importantly, ensure that its runtime application validation performs a complete and robust check of the entire application bundle's code signature, blocking any execution if tampering is detected.

About the Speaker(s)

Patrick Wardle is a prominent figure in the macOS security research community, widely recognized for his in-depth investigations into Apple's operating system. He is the co-founder of the Objective-See Foundation, a non-profit organization dedicated to creating free, open-source macOS security tools and fostering community knowledge. Wardle is also the author of "The Art of Mac Malware" book series, a comprehensive resource for understanding macOS threats, and a co-founder of Objective-C, a leading conference focused on macOS and iOS security. His work consistently highlights critical vulnerabilities and provides innovative defensive solutions, making him a trusted authority in the field.