Using DInvoke and Sliver to Evade OpenEDR and Escalate Privileges
Hello everyone, I finally decided to go beyond just evading Defender and move into EDR evasion. This past days I’ve been playing with Xcitium OpenEDR, a free EDR solution.
In this article I’ll evade OpenEDR running on a Windows machine along with Windows Defender on, then how to escalate privileges to a High Integrity User and then dump the machines credentials.
Most EDRs monitor API calls by hooking user mode Windows dlls. For example if a program uses the kernel32.dll to use the Windows API functions, which also calls the Native Api in ntdll.dll, the EDR will hook itself into the DLLs and monitor any suspicious API calls such as VirtualAlloc or CreateThread which are often used to load shellcode.
To bypass the hooks using C sharp, we are going to use DInvoke, which sort of copies the dlls in memory and dynamically loads the API calls rather than loading the API calls from the dlls.
To work on this project I have a Windows VM with Visual Studio that has both Windows Defender and OpenEDR running with the Administrator Documents folder added as an exception in both so that we can work properly.
To make things simpler I’m going to modify an already made shellcode loader that uses DInvoke made by Kara-4search.
Opening the project in Visual Studio we see it has hardcoded shellcode and we can replace it with our own.
However I’m going to modify it so it instead loads the shellcode from a .bin file which will be downloaded from my web server.
I’ll add the System.Net library.
So we can use WebClient DownloadData function to download the file from the url as bytes.
Now I’ll save the project for now. I’m going to use InvisbilityCloak to obfuscate it like I’ve done in my past articles to make sure it evades signature detections.
I’ll rename the project “Jinzo” then reverse all strings.
And now lets open the project and we will see it obfuscated it.
Before compiling I’ll change the properties to make it a Windows Application. This way it won’t open a console that the victim user can see.
Now I will replace every instance of the word DInvoke.
And now compile it as Realese with x64 architecture.
Now we have our loader ready.
To make sure Defender doesn’t detect this executable as malicious I’ll run DefenderCheck.
No threat found!
Now let’s move to my kali machine to create our shellcode which will be an Sliver C2 beacon.
I’ll start Sliver
And generate a http beacon.
I could have just made the output file shellcode but in my experiments I realized this evaded detection better if I first generated an executable then converted it to .bin with Donut.
(TheWover also made donut? A true legend)
I’ll convert the beacon to .bin using donut with the -e 3 for encryption and -b 1 to not add Amsi bypass because the used Amsi bypass gets detected.
Now I’ll start my python http server from where the shellcode will be downloaded.
And start http listeners in Sliver.
Now with everything set lets give our executable to our fictional Victim!
I’ll log in into OpenEDR Platform close all old alerts and only filter for new ones that may be created when we run our payload against our victim.
Now let’s login as our victim user in Windows which I called lain, lets assume we managed to trick the user into downloading our executable. This user has both OpenEDR and Defender active (Please if you are recreating this disable sample submission in Defender).
Now lets click the executable, simulating our victim user, and we get connection from our beacon!
Now lets use the beacon and run sa-whoami a bof (Beacon Object File) that runs whoami /all in a more safe way because running it from a shell can trigger an alert in OpenEDR (Can be added to Sliver doing armory install sa-whoami).
We see our user is part of the administrator group but not in a high integrity process meaning we have to bypass UAC (User Access Control) to get a shell with full Administrator privileges.
The following repository contains useful Beacon Object Files that can be loaded to Sliver to bypass UAC. (Follow the steps in the repository to install them)
I’m going to use the CmstpElevatedCOM method to get a new beacon process running as Administrator.
We get a new beacon! Now lets use it and run sa-whoami again.
We have now a High Integrity shell!
Now with this privileges you would try to exfiltrate data to help us move laterally, say for example dumping all credentials from Lsass. However the issue is EDRs heavily monitor Lsass. Anything we try that tries to interact with Lsass in memory generates the following alert in OpenEDR:
Instead of going for Lsass I’m going to first try to dump SAM (Security Account Manager) Which would be more OPSEC friendly.
I’m not even going to use the default mimikatz Beacon Object File in Sliver because it makes our beacon get eaten by Defender, instead I’m going to use SharpSAMDump.
Compiling the project in Visual Studio produces a .NET executable that we can use with execute-assembly.
(Ignore the errors, if you check the code it already handles the exception so the error doesn’t crash our beacon)
Now that we have the administrator hash we can try to use it with Impacket secretsdump.py to see if we can obtain even more hashes.
Let’s use the -skip-sam flag since we already got SAM credentials through SharpSAMDump and also because SAM dumping through secretsdump.py sometimes alerts Defender.
We got the jackpot and have a bunch of credentials! Since this was a Domain Controller we get the contents of NTDS.dit and we also get kerberos keys we can use with Rubeus or GetTGT.py requesting TGTs.
Now let’s see how many alerts we made in our EDR.
Mostly alerts of “Run Virtually in Containment”, OpenEDR has a feature where it will run unknown executable and processes in a sort of Virtual Sandbox, it didn’t stop us from doing what we did here however in my experiments it does big alerts if we try to mess too much processes memory (Like dumping Lsass as I explained before) or sometimes stop us if we are writing files. Since we didn’t do any of that we don’t get any big alerts but still it does point to the Blue Team that an Unknown executable was run unless we trick them to overlook it (Say we know they run some custom internal software, we can try renaming our file like that software).
The “Add File to Application Control” alert just simply alerts that a new file was created which can be easily overlooked because I’ve seen this alert trigger literally for any new file including safe ones.
Aside from those alerts, it didn’t detect our file as malicious, it didn’t detect privilege escalation and it didn’t detect our credential dumping, we where able to successfully do most of the Red Teaming Attack Lifecycle without triggering any major alerts.
If you have any recommendations for any other Free EDRs that I can use for testing or any better tactics for better evasion and OPSEC let me know!
