Attacking on Behalf of Defense: DLL Sideloading EDR Binaries
by Naor Hodorov
"If you can't beat them, join them" might be the most precise sentence of describing the following article regarding how DLL Sideloading can be insanely critical when it exists on EDR binaries, to perform malicious operations sponsored by them.
Please note that this has been tested (by me) on a couple EDR/XDR products. This article might be an eye opener for various others if they're vulnerable to this technique and now's the time to make sure (actually long ago).
The vendors (which are very much censored in this article) are aware about the issue and explicitly allowed me to submit the article while they're very much censored (understandable).
A small background
As part of our Red Teaming engagements, we at times use DLL Sideloading on a legitimate binary (whether it's Microsoft's or any other validated signature binary), to evade various EDR checks regarding malicious activity and telemetry. Usually it is used by legitimate actors and thread actors as an initial access vector (either by Phishing or any other delivery) to breach the victim's system and gain remote access to the target, and an insanely effective Persistence technique. One DLL Sideloading example triggering "MessageBoxA" WINAPI is shown below, targeting "wermgr.exe" (one random chosen executable, which is part of Microsoft's "System32" binaries):
"wermgr.exe" is a validated, signed by Microsoft binary:
Executing WerMgr.exe in a user-owned directory and watching which DLLs it tries to search for and it misses them, shows that the binary is searching for "wer.dll" in the current directory and it does not find it:
Crafting a DLL which calls "MessageBoxA" API, needs to be seemed-exporting the same functions as the legitimate, original wer.dll. This can be done with a simple program which source code can be viewed here: https://raw.githubusercontent.com/mansk1es/ExportViewer/main/view.cpp
Naming the crafted DLL "wer.dll" (as is it the DLL that it searches for) and placing it in the same directory of wermgr.exe would make the binary load the DLL and execute it on its behalf:
Now this is nice! We have a legitimate Microsoft binary which loads our DLL which can be anything we want.
It doesn't stop at benign binaries (apparently)
At times, after a successful breach with advanced malware which bypassed the hardened and advanced defense mechanisms - dumping LSASS can be a whole different story. This might be the most protected process on the system, and a few people even said to me that they "stopped even trying to dump it" - since that can instantly close their access, trigger the defense mechanisms (that's just been bypassed), etc.
To partially solve the LSASS issue, amazing tools and techniques such as nanodump, MalSecLogon, etc have came out and brought great ways to dump the LSASS process. As time passed by, these techniques became less effective against various defense mechanisms for the reason of updates, malicious-ly signed, behavior detections, etc. (They still work on various, and are amazing in my opinion. It's also a matter of customization).
DLL Sideloading for the rescue
One of my attempts to dump the LSASS process on the great EDR product that I have (which blocks basically all known lsass dumping tools like mentioned earlier), was to attempt and see if the EDR's binary is actually vulnerable to DLL Sideloading. I was amazed to discover that the answer is "yes".
This can be DEVESTATING for the EDR (and victim) to (accidentally probably?) be vulnerable to DLL Sideloading. And the following PoC might explain this better than words.
An attempt to dump lsass with SYSTEM integrity (also tried with a TrustedInstaller token) did not come up with great results:
Of course we were presented with an alert even if we were trying to view the memory region:
Viewing the EDR's binary for potential DLL Sideloading presents surprising results:
Crafting a DLL which uses (the simplest) MiniDumpWriteDump to perform process memory dumping, attempting to Sideload the EDR's binary presents no success. I figured that the reason is since it has been executed from a different directory (Desktop) than its original execution directory (C:\Windows in this case).
So, let's not copy the binary to a new location, and attempt to execute the existing one in the original directory:
Seems like the process is loaded as suspended process, therefore not loading the rest of the DLLs (ntdll only is loaded ofc):
We can't seem to resume the process to make it load the needed DLLs (since it is an actual EDR process, tamper protection is active on it):
But we can resume the thread... (wtf?)
After resuming the thread, the program executes, and instantly dropping but right after it has loaded the rest of the DLLs!
Copying our malicious DLL "userenv.dll" to the EDR's directory and executing the EDR binary:
"x.exe" is a program which resumes the main thread of a remote process. After executing the EDR's binary, copying lsass dumper DLL to the EDR's dir, validating "hi.txt" dump does not exist, we can execute x.exe against the remote suspended program in order to resume its main thread:
Lsass has been successfully dumped, sponsored by the EDR!
Note that the alert is a "Process Termination" alert, rather than memory dump/access alert. This is because the EDR recognizes the new process as its own, and after it stops executing, the EDR thinks that its process has been attempted to be terminated. The alert does not affect this attack whatsoever.
We can parse it on a different machine, with mimikatz:
Yep, you guessed it
Since we can perform malicious actions sponsored by the EDR, we can EASILY bypass its tamper protection and "TerminateProcess" it using the same technique (note: this worked against THIS EDR, not on the Bonus one) :)
Attempting to regularly terminate it (doesn't only stop taskmgr ofc, this is just an example):
Doing so, would (obviously) pop a "Process Termination" alert which prevents us from doing this.
Sideloading it to eternity:
Success!
Bonus
Collaborating with my friend @Dec0ne on this matter, we found yet another (very well known) EDR which seems to be vulnerable to DLL Sideloading.
I will target "version.dll" in this case, attempting to sideload the EDR's executable in order to dump the lsass process. After copying the malicious DLL in the EDR's directory, naming it "version.dll", it seems to be ready to go. The DLL is as simple as "MiniDumpWriteDump" API!
Running the the EDR's main executable to sideload our malicious DLL:
SUCCESS! lsass dumped while the EDR is active, without any alerts as well.
As you can see, successful LSASS dumps have been performed on various, great EDRs.
Last updated
