DLL-Sideloading

What is it?

It is a form of DLL-Hijacking by-proxy.

What is DLL-Hijacking

DLL-Hijacking is when a application loads a dll-file from a location where an attacker can write. Replacing that DLL with a DLL containing a payload of their choice, will compromise the account running the application. This could be a ordinary user, a administrator or even "NT System", if the application is a service. You cannot replace just any DLL-file. It has to be a file not really needed for the application to function properly. That means it isn't possible in just any application either.

An example:

Autodesk AutoCAD 2007 - 'color.dll' DLL Hijacking

DLL-Sideloading

In DLL-sideloading, we also look for dll-files located in locations where we could write. But here, we use a dll-proxy file containing our payload and proxying the applications requests to the original file or a local copy of the original file. This way, we don't break the application and it will continue to work normally.

Even if the application doesn't have DLL-files in its application directory, it could be vulnerable for this kind of attack if it doesn't call the DLL-file(s) using absolute path. What happens then, is that it will look in its current location first and then look in %PATH% to find it.

Like in the screenshot below: Microsoft Teams, trying to load dbghelp.dll from current folder first, fails and continues looking for it in PATH, finding the requested file in c:\windows\system32

A lot of the modern applications, installed in the users %appdata% appears to be vulnerable to DLL-Sideloading. As the user have full control over that folder an attacker could use this to gain access and persistance through e.g. a phishing attack.

In this video, I have shown how a DLL-Sideloading attack works and also that enabling AppLocker without enforcing DLL-rules, is of no use at all.