Red Team Diary, Entry #1: Making NSA’s PeddleCheap RAT Invisible
Hi there,
This is Dimitrios Bougioukas, Director of IT Security Training Services at eLearnSecurity.
With this post eLearnSecurity inaugurates a series of posts (diary entries) that will share both IT Security research endeavors and cutting-edge attacking or evasion techniques. We will do the same for blue-team topics, with a focus on cutting-edge detection methods and tactical analytics.
The reason behind launching these posts is to engage the community and start a discussion around the techniques presented. This way, valuable insights and hopefully the readers’ own techniques can be shared in the “Responses” section at the bottom of each article.
The first post will be about an A/V or EDR evasion technique that I came up with while developing eLearnSecurity’s Penetration Testing eXtreme course. This technique was applicable against a number of A/V and EDR solutions. We (responsibly) contacted all vendors. Some of them hardened their solution against this technique, the others didn’t.
Note: If you don’t like reading lengthy posts scroll down. You will find a narrated video showing the evasion technique in action and how you can replicate it.
At eLearnSecurity we very much like scenario-based explanations. Imagine the following scenario: We are in the post-exploitation phase of a red teaming engagement and we want some kind of stealthy persistence. Sticking to the userland may not do the trick, so let’s move to the kernel.
Kernel-level persistence has been around for a long time. Latest iterations include the packetredirect module of NSA’s RAT PeddleCheap and RedSails. Both essentially bypass the TCP/IP stack of the Windows OS to provide us with stealthy communications and persistence, by manually diverting and manipulating packets. To do so, a (signed) kernel-mode driver is involved.
PeddleCheap is flagged by the vast majority of A/Vs. That being said, we are still going forward with it. We just need to find an A/V or EDR evasion technique in the process… :/
Find below everything I tried until I came up with a technique to make PeddleCheap invisible to some A/V and EDR solutions.
- On-disk method (drop & execute)
First, I started with the basics. Inside local VMs that featured different A/Vs and EDR solutions, I tried dropping an executable that contained the PeddleCheap RAT and executing it.
As you can imagine, by the time the executable touched the disk, the A/V’s or EDR’s signature/pattern database was employed and an alert was triggered.
2. Semi-fileless method (drop XOR-ed version of PeddleCheap, de-XOR & execute in memory)
As any red teamer would have done, I then decided to start moving the execution into the endpoint’s memory. I did so using classic PE injection/process hollowing/dynamic forking. I actually once again dropped an executable that contained a XOR-enrypted PeddleCheap RAT alongside a decrypting function. Upon execution, this decrypting function will de-XOR PeddleCheap and execute it inside the endpoint’s memory and specifically in the same address space as the host process (created by the dropped executable). So, we are currently talking about a semi-fileless method.
Unfortunately I was once again busted (heuristically this time), since the latest A/V and EDR solutions have the ability of taking the .text section of a binary on disk and comparing it with the .text section of the same binary in memory. Due to the decrypting function we previously talked about, the two .text sections will be quite different. Latest A/V and EDR solutions can also detect changing the page permissions to PAGE_EXECUTE_READWRITE (which is necessary during PE injection) and even perform brute-force attacks against XOR encryption implementations.
3. Fileless method (introduce a RAMDisk, drop original PeddleCheap & execute)
APT groups and advanced hacking teams are known for using obscure exploitation methods. This is the road I decided to take as well. I remembered a very interesting technology called RAMDisk. RAMDisks essentially take a portion of an endpoint’s physical RAM and introduce it as a disk to the OS.
When it comes to RAMDisks no PCIe is ever involved. Every disk operation is an affair between the CPU and the endpoint’s memory only.
I thought that anything dropped on a RAMDisk will reside and be executed in memory (fileless method). So I introduced a RAMDisk and dropped an executable containing PeddleCheap (the original one, not XOR-encrypted) on several of my local testing VMs. No alert was triggered and my hopes got high! Then i tried to execute it…
To my surprise, I was once again caught by A/V or EDR solutions.
Quite frustrated, I was banging my head to identify how I was getting caught. This is when I remembered that everything on Windows, the file structures, the directory structures, etc., are all provided to applications through file system drivers. In addition to that, while applications are loaded, DLL files and EXE files are read again through those file system drivers. Over-simplifying things, what A/V or EDR vendors usually do is place some filter drivers on top of those file system drivers to gain (real-time) visibility on what is being loaded. Regardless of a real disk or a RAMDisk being used, those file system drivers are still being involved. So, by the time I tried to execute the executable containing PeddleCheap inside the RAMDisk, the A/V or EDR saw it “passing”, compared it against its pattern/signature database and prevented execution.
4. Fileless method (introduce a RAMDisk, drop original PeddleCheap, drop custom PE loader & execute)
Before calling it a day, I decided to give this a final try. As mentioned, earlier the OS PE-loading mechanics were getting in the way. So, this time I introduced a RAMDisk in my local VMs, dropped an executable containing PeddleCheap but also dropped a custom PE loader to circumvent* the OS’s PE-loading procedure. Up to this point no alert was triggered and everything resided in memory (inside the RAMDisk).
Finally, I provided the executable containing PeddleCheap as an argument to the custom PE loader, and to my surprise some A/V and EDR solutions showed no alert! Back to my attacking machine, a session has been established, PeddleCheap was injected and executed in memory as planned.
*Note that the custom PE loader itself does not circumvent the normal OS PE-loading procedure but that’s OK since it is a benign piece of software, it simply takes another executable as an argument and executes it in memory.
The Attack In Action
For technical details regarding each attempt and to see the covered evasion technique in action, please view the narrated video below.
The Blue Team Perspective
The above technique (and every technique that includes a kernel-mode driver actually) could have been detected as follows.
- Identify the presence of Sysmon Event ID 6 logs (Driver Loaded). See below the (signed) kernel-mode driver(s) that the attack uses appearing inside Sysmon’s logs.
2. Monitor the SHA1 checksum of c:\Windows\System32\Drivers directory.
The covered technique could also be detected by regularly checking for the existence of a new drive or through memory forensics (remember the PAGE_EXECUTE_READWRITE permissions we talked about earlier, PeddleCheap uses similar tradecraft).
No doubt there are way better and stealthier A/V and EDR evasion techniques. This post simply highlights how evasion can be achieved by misusing existing technology (and thinking outside the box).
This technique has been presented during Security BSides Athens. Find the slide deck in the link below.
https://drive.google.com/file/d/1xBwMuF62eYKv3A2TNRgKNVE_nAViSrVZ/view?usp=sharing
