Most of the times red teams and threat actors need to go to extreme lengths to execute what they need on their victim computer. From heavily obfuscated and complex executables, to the use of living of the land binaries (LOLBins) that are likely to be blocked by protection systems, they try them all. But what would happen if you could execute your own dynamic linked library (DLL) from a trusted process? And what if that process is owned by Microsoft itself?

Back to the basics: What is DLL Hijacking?

DLL hijacking is a technique that leverages processes which call DLLs that do not exist in the file system. This attack is often used to escalate privileges, laterally move to another computer in the network, or achieve persistence on a host.

In addition to the hijacking itself, DLL proxying can also be paired for extra stealth. This technique allows the execution of a malicious DLL, while proxying all functions of the legitimate one. This prevents the software execution from crashing, and can also help in cases where the replaced DLL function name is not known.

How come I never heard of it?

DLL hijacking is not considered a vulnerability by many vendors. The reason for this, is that software may actively require these DLLs for several purposes, from advanced user features, to software testing and debugging.

However, even though calling it a vulnerability is still debatable, what would happen if the missing DLL is invoked from a user-writable directory?

This scenario is exactly where it becomes a security issue. It may happen due to a mistake on the vendor side, a misconfiguration from the IT team, or by the need of the user writing to that specific directory for their daily work.

Microsoft Edge: An (un)expected surprise

During research on a default Windows 11 build, our researcher identified that the “msedge.exe” process (Microsoft Edge) attempts to load the “vcruntime140.dll” from a user-writable path, namely the “%LocalAppData%\Microsoft\Edge\User Data\Domain Actions\3.0.0.16\” folder.

From an attacker perspective, this means that if they manage to set the DLL in that folder, Microsoft Edge will execute it, therefore running malicious code on the victim computer. To make it worse, the code runs under the trusted browser process, lowering chances of being detected by security tools and defenders.

As a way to keep Edge working as intended, we “proxied” the original “vcruntim140.dll” – located in “c:\windows\system32” - and added our malicious code, which connects back to our command & control (C2) server.