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. The install process itself gets much less attention. 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 more common.

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. The attack surface, not the technique, has changed. 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

Let’s use the example of 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, and no one thinks to question it because it's never caused a visible problem.

An attacker with limited access to that machine, through phishing, a compromised account, or another foothold, doesn't even need to break the AI plugin. They just need to drop a DLL with the same file name into a folder that sits earlier in the app's search order. Then when a user launches the app, it loads the attacker's DLL, and the malicious code runs with the same privileges as the CAD application. 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.

This is 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. This approach works, but it depends on every vendor doing the work, and a lot of the applications most exposed to this issue are the 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.