During one of the audits, I received an interesting task. The goal was to gain access to the systems responsible for backups and then, perform a ransomware simulation.
During the audit, access was gained to only one of these systems, and this was since most of these machines were outside of the Active Directory (AD). Logging in, even with Domain Administrator (DA) privileges, was restricted, but having DA access allowed me to obtain the local admin password using LAPS, which gave me access to the HYPER-V-B machine. From there, I was able to log into HYPER-V-E (the target machine). Access to the rest (4 others) was not achieved.
Preparation
The simulation involved preparing a program that would simulate the encryption of backups stored on backup systems. To this end, I started by preparing the code. I chose C with the use of WinAPIs. I generated AES-256 encryption with hardcoded keys using AI, as the available AES libraries are quite well-known to AV vendors. A local test on ESET was promising, as it was possible to run the program and bypass ESET (an initial indicator of whether it is worth entering the client’s infrastructure).
The first evasion technique I used was executable bloating, which involved adding 2GB of empty data to the created binary to eliminate cloud scanning:
The first attempt to run the program resulted in receiving the ‘Access is denied’ message and detection by CrowdStrike:
At least the program was blocked after execution and not after being uploaded to the machine. The downside of the additional 2GB is that the binary takes a long time to start, but it’s worth the wait ;).
The second technique I added to my program was unhooking NTDLL, under which AV typically attaches or even replaces it to gain insight into the functions executed by the binary.
In short, this technique involves finding the address in the process memory where this library is located and then replacing it with a new ‘clean’ NTDLL. In this case, I used the NTDLL located on the disk. Other methods include:
- Obtaining NTDLL from the KnownDLL location
- Getting NTDLL from a newly created and suspended process
- Downloading NTDLL from a web server
Running the program with both techniques resulted in detection, but it’s clear that something is going on, so we are getting closer to bypassing the detection:
The third technique I used was creating my own process with a flag that disables the loading of libraries not signed by Microsoft. Below is the code snippet responsible for this:
Execution
After compiling and uploading the binary with three AV evasion techniques, it was finally possible to successfully run the program and encrypt the files from the specified location:
As you can see, there was no need for some mega-advanced techniques (surprisingly) to conduct a ransomware simulation against such EDR. To be honest, I thought I would have to spend much more time on it. Fortunately, the client themselves proposed that, in case of an ‘unsuccessful’ attack, they would turn off the AV to see if someone from the SOC would detect such an attack. Whether they detected it or not, I don’t know - the client didn’t write about it, but my gut feeling tells me they didn’t detect it.
See you next time.
