What is DLL hijacking, and why your new AI plugin might be the easiest way in

I've spent a lot of time this year looking at how organizations are wiring AI into tools that were never built to handle it. Most of that risk gets discussed in terms of data exposure or model behavior. Less attention goes to something more basic: the install process itself. When a team bolts an AI plugin onto a legacy desktop application, they're often adding a new executable, a new set of dependencies, and a new set of folders Windows will search when that application looks for a DLL to load. That's a familiar setup for anyone who has followed DLL hijacking over the years, and it's becoming a more common one.

What is DLL hijacking

Windows applications don't always load their DLLs from a fixed, trusted location. When an app requests a DLL by name rather than by full path, Windows searches a defined order of directories to find it. If an attacker can place a malicious DLL with the right file name somewhere earlier in that search order, the application loads the attacker's code instead of the legitimate library, and it does so with whatever privileges the application already has.

This isn't a new technique. It's been a documented weakness for years, and it keeps working because so many desktop applications, especially older or poorly designed ones, still load DLLs by name instead of by full path. What's changed is the attack surface. Every plugin, add-on, or AI-powered extension installed into a legacy app is a new opportunity for a loosely controlled folder, an unsigned dependency, or a writable directory in the search path.

DLL hijacking example

Picture an engineering team running a CAD application that's been in place for a decade. IT adds an AI plugin that gives users a smart search and summarization layer on top of their drawings. Like a lot of software in this category, the CAD app loads one of its helper DLLs by name instead of by full path, a design decision nobody questioned because it's never caused a visible problem.

An attacker with even limited access to that machine, through phishing, a compromised account, or another foothold, doesn't need to break the AI plugin itself. They just need to drop a DLL with the same file name into a folder that sits earlier in the app's search order. The next time a user launches the app, it loads the attacker's DLL instead, and the malicious code runs with the same privileges as the CAD application. No exploit against the AI plugin required. The plugin just handed the attacker a new folder to work with.

How to detect DLL hijacking

Detection usually comes down to watching for behavior that doesn't match what a legitimate DLL should do:

• Applications loading DLLs by name from unusual or user-writable directories instead of a fully qualified, trusted path
• Unsigned DLLs launched through utilities like rundll32.exe, a common hijack pattern
• File integrity monitoring flagging changes to DLLs that shouldn't change between patch cycles
• Endpoint logs showing a legitimate parent process followed by an unexpected or unsigned DLL load

Another way is to check the file integrity of any DLL in the search path (in fact all files’ integrity) by comparing their hash values to a known good source.

None of this is exotic. It's the same discipline security teams already apply to file integrity and process monitoring, pointed specifically at the folders where third-party plugins and legacy apps tend to introduce weak load-order behavior.

How to prevent DLL hijacking

Prevention generally falls into two categories: fixing the applications, and controlling what's allowed to run on the endpoint.

Fixing the application means using fully qualified paths for DLL loads, tightening folder permissions so standard users can't write to directories the app searches, and keeping vendor software patched. That's the right long-term fix, but it depends on every vendor doing the work, and a lot of the applications most exposed to this issue are exactly the ones least likely to get patched quickly.

Controlling the endpoint means not waiting on the vendor. PolicyPak's DLL Hijack Protection, part of Least Privilege Manager, runs in one of three modes: audit, which logs risky DLL loads without blocking them so teams can assess exposure first; safe elevated, which blocks risky DLL loading for elevated processes; and anti-hijack, which extends that blocking to regular processes running from protected locations like Program Files. It stops the two most common hijack patterns directly: an application loading a DLL by an unqualified name instead of a full path, and an unsigned DLL launched through a utility like rundll32.exe. When a legitimate DLL gets caught by mistake, administrators can allow it by file path, digital signature, or file hash without turning off protection altogether.

If your team is rolling out AI capabilities into applications that predate any of this conversation, DLL hijacking deserves a spot on the risk register, not as a hypothetical, but as a near-term consequence of how those plugins get installed.