Making a State-Backed Implant Invisible: A New Blind Spot in Modern A/V & HIDS Solutions

Thanks a lot for having me. I hope you're having a great time here at B-Sides. And I also hope that you are interested in some APT-like antivirus evasion. My talk is titled Making State-Backed Implant Invisible. It is actually about a newly discovered antivirus evasion technique that I came up with. It is actually about a blind spot of modern antivirus and EDR systems. At the end of this talk, if time allows and if the demo gauge allows, I will drop and execute NSA's implant pedal chip on a machine that is protected by an enterprise-grade and fully updated EDR system without, of course, being detected by using the very technique I am about to show you. For those

that are unfamiliar with Pedalchip, Pedalchip is actually NSA's own remote administration tool.

So some quick facts about myself. My name is Bouyukas Dimitrios. I am the director of IT security training services at eLearn Security and I am also author and IT security research lead within the same company. My interests include advanced adversary simulation, tactical and strategic threat intelligence and purple team tactics. So an amazing amount of buzzwords, but actually some buzzwords that have some true value. Since I am interested in collecting and analyzing the techniques, tactics, and procedures of being used by modern adversaries, But I don't stop there. I very much like incorporating those techniques, tactics and procedures into actual penetration tests or red teaming engagements in order for the blue team to have the opportunity to enhance its detection capabilities.

So I am pretty sure we are all aware of the current state of red and blue teams. Red teams strive towards achieving the minimum detection rate and for this reason they are using more and more obscure exploitation methods to get past organization defenses. Whereas blue teams are known to suffer from what is called alert fatigue and they are unfortunately known to have limited visibility on their endpoints or networks. So my

talk making a step back team plan visible is actually going to be a purple team talk and that means that I will first show you how obscurity can result in effective exploitation and then I will not stop there I will share some tips for our blue team friends in order for them to be able to identify this very technique and the whole class of similarly executed techniques simply by increasing their visibility so imagine that imagine for a minute that we are in the post exploitation phase of a red teaming engagement and what we wanted to do was simply stealthily drop and execute NSA's implant called pedal chip why we wanted to do so we wanted to

do so because we wanted to We needed to add some swag to our post-exploitation activities, but most importantly, we wanted to utilize an amazingly nice post-exploitation module that is called Packet Redirect. Packet Redirect is a post-exploitation module of this remote administration tool that effectively uses a kernel mode driver to bypass the whole TCP IP stack of the operating system. What does that mean? That means that, for example, we can bind a listening port on the machine and whenever the blue team tries to list all those listening ports they are going to miss it simply because that kernel mode driver bypasses the whole TCP IP stack of the machine so we are talking about some very nice and stealthy persistence so let's see together the whole timeline

following which I was I came up with this antivirus evasion technique actually we will see all the little things I tried and failed before I came up with this technique first I tried a non disk method what I simply tried to do was alter and modify the PedalCMP plans code and simply I dropped it to disk. Of course, it was a naive thing to do since I got detected by the EDR system immediately, simply because the EDR system employed its signature or its pattern database in order to match some specific code parts of the implant I have dropped to disk. So an alarm was triggered and of course I was busted. Then I moved to a semi-fileless method. This semi-fileless method used a very old

antivirus evasion technique. This technique is known by many names. It is known by the RunPE name. It is also known as ProcessHallowing. It is known as PortableExecutableInjection. And for the older guys here, it is also known as DynamicForking. What I did was simply create an executable and I dropped this executable. So we're talking about the semi-fileless method. that executable contained an XOR encoded PedalCP implant and it also included a decoding function at the beginning of that file. So by the time this custom executable was executed, the PedalCP implant was going to be de-XORed, decoded in memory and executed within the same memory address space of the original process. So what happens under the hood so that you get a better idea of it? A

new process is created and it is put on a suspended state. It's a process executable section is freed, reallocated, and then filled with the XOR encoded implant. Then the XORing, the de-XORing stub takes over and de-XORs pedal chip of course in memory and then the suspended thread start address is pointed to the now decoded pedal chip implant and execution is resumed. So all in all, to not confuse you, by the time this custom executable is executed, the pedal chip implant is dexored in memory and then executed. So we tried to evade some stuff with a simple exhoring technique, a stub. Unfortunately, once again, I was busted. It is a very old technique, so no doubt

I was going to be busted, simply because the EDR system had the ability to take the .text section of the binary on disk and

and see that it is a lot different than the actual dot text section in memory. This is, of course, because EDR systems and latest defense systems have the ability to see if the actual dot text section on binary matches that in memory. Of course, it will be a lot different because we have the decoding function that we talked about. Another method using which I could have been detected is by detecting the change on the memory page permissions to page execute redrive. This is something that looks suspicious to every AV or EDR vendor around. We needed those changes to the page, to the memory page permissions, because as we have discussed, we need that executable section to be

freed, reallocated, then be filled with the malware contents, then be a de-exhored and all that stuff. So we wanted to have page execute read write on that memory page. So this is something that is probably flagged by every AV vendor or EDR vendor around. The other thing is that I could have also been detected by brute forcing the XOR encoded. This is something that is quite trivial actually to do. This is why malware authors are of course not doing anything like XORing. This is quite naive, but it's worth trying.

So I decided to this time be to act like a very APT actor or like a very advanced adversary and go completely file-less. So what I came up with was using a RAM disk. So I remind you that we are in the post exploitation phase, so I have elevated the system, I can do whatever I want with this machine. Of course, in a stealthy manner, it was a retelling engagement. So what, some first things first. For those that are unfamiliar with RAM disks, RAM disks are pieces of software that simply utilize a kernel mode driver once again, that take a system's unused memory and introduce that unused piece of memory as a storage device. So any input-output operation that happens on

a RAM disk is simply an affair between the CPU and the memory only. We are talking about some very fast input-output operations, but no PCI is involved, no platform controller hub is involved, anything. Anything that happens is between the CPU and the memory. So what I did was, simply install a RAM disk as a post-exploitation step to that machine, and then I dropped the pedal chip implant itself. No XOR encoded stuff and anything. So I simply dropped the real thing. By the time I dropped it, I was surprised to see that it was invisible to the EDR solution. No alert was actually triggered. So my hopes got high and I was quite optimistic that I found something quite nice to present.

Unfortunately, by the time I executed it, I was detected once again by the EDR solution. As you can imagine, I was quite frustrated at that point. I was banging my head against the wall to identify the actual underpinnings based on which I got detected because I thought that I was completely in memory. This is when I remembered that everything on Windows The file structures, the directory structures are all provided to applications to the upper staff you see right here. They are provided to applications using file system drivers. In addition to that, while applications are loaded, they are reading .exe or .dll files again. through those file system drivers. And what antivirus vendors or EDR vendors usually do is that they place a filter

driver on top of those file system drivers. That means that they are in the position of a of checking in real time those .exe or those .dll contents. So by the time they are loaded by the operating system PE loader, those antivirus vendors or those EDR vendors, they can actually check the contents and block execution. So that you understand, I identified, I learned the hard way that regardless of me using a virtual disk, like a RAM disk or a physical disk, Again, those file system drivers were still being involved. This is where I got caught. Thankfully, I discovered this and I decided to give it one last try before I call it a day because it has taken a lot of time to

come up with this conclusion. So I decided to do the following. I once again installed the RAM disk and I also dropped on this RAM disk a custom PE loader. I tried to bypass the whole operating system PE loading procedure. This PE loader is a very simple program that simply iterates another executable's contents and it executes its contents in memory. Something like we did on attempt one, but a bit simpler. By the time I tried to, I gave the pedal chip implant to the custom PE loader as an executable, as an argument, and by the time I executed the custom PE loader with this as an argument, PE injection happened, and to my surprise, actually

no alert was triggered. I managed to bypass the EDR solution and the operating system's PE loading procedure. So that we are 100% accurate, I didn't completely bypass the operating system's PE loading procedure, Pedalchip bypassed the operating system's PE loading procedure simply because the custom PE loader handled the PE loading. But the custom PE loader's execution did not bypass the operating system's P loading procedure. But you know what? We didn't care about this one. We didn't care in the first place because each code is pretty naive. It is pretty naive and it's pretty benign actually. So it simply takes something and executes it in memory. That very something that it takes and executes it in memory, it was not visible by the operating system's P

loading procedure because it was here, it was on the RAM disk, it was in RAM. So this thing did not bypass the operating system's P loading procedure, but we did not care. So this is the actual technique to bypass an EDR system was to introduce a RAM disk and a custom P loader. Now let's share some tips. for our blue team frames. We could have detected this one by leveraging Sysmon. Sysmon is an amazing tool to increase visibility on our endpoints. For those of you that can't see it, Sysmon has a very good Sysmon event ID that it is number six that informs us every time a driver is loaded. We can see some Sysmon logs from the testing machine I tried the technique. We

can see two Sysmonlogs event ID number six that informs us of the two kernel mode drivers that that RAM disk utilized. We can also do the same with a simple partial one-liner using the get win event module and this simple one-liner, those two entries you see here are actually the two kernel mode drivers that have been used while I installed the RAM disk. The detection method number two is that of course we could have scripted a solution in order to baseline. our environment and we could have scripted the solution in order to constantly monitor the C Windows System32 drivers directory and we can always monitor the SAWAT checksum of this directory. Of course the SAWAT checksum of this directory before and after RAM

disk installation would be of course different and I doubt that on enterprise environments new drivers are being installed every day so it is not something that we will trigger a lot of alerts. Detection method number three is that we could have used partial remoting and WMI in order to constantly script a solution and try to identify if a new Storage device has been mounted on our endpoints. Using this command on a regular basis, we could have detected a new storage device being mounted. And once again, I doubt that new storage devices are being mounted to your organization every day. Of course, we could have tried something memory forensics and dump the loaded drivers from memory. Then we could have actually submitted all those drivers to an

antivirus cloud solution and detect if some of these drivers are actually malicious.

So let's now see the actual technique on a very quick video. I remind you that the original pedal chip implant has a rate, a detection rate of 35 out of the 65 AV vendors.

The video will be a bit quick.

No doubt you understood that, right?

So, that you saw was a simple, Python script in order to make the pedal chip implant a char array. This is how what you see here was the first attempt, the XOR encoding stuff. We first made it a char array, a whole char array, and now we are trying, we are using this program here in order to XOR it again in a char array.

No doubt you are going to use Visual Studio if you are trying that stuff, unfortunately. This is the simple, this is how simple it is to extort something using the C language. We are simply appending the whole pedal chip implant right here. These arrays contents are going to be iterated and extort with a static key.

and the output is going to be given to this .txt file. Nothing crazy so far. This is so that you can see that even a simple XOR encoding thing can bypass about 20 of those 35 antivirus vendors. So this is the actual output. This is pedal chip but XOR encoded. So the remaining part is give it to the executable I talked to you about that has the de-exhoring stab that will de-exhor it and execute it in memory. So we once again we will copy paste again this whole char array. This is the decoding, the actual decoding stuff.

And in a minute I will also show you the whole code that the exorged and executed memory so that you can see how simple it is to do so.

We are assigning some simple variables, don't worry about that.

So this is now the actual code that creates a new process, it suspends its state, it fills the contents with the XOR encoded pedal chip implant then the de-XORing stab is going to take place and then you will somewhere here see that the EAX register is going to be pointed to the de-XOR pedal chip implant so that it is executed on memory I am executing this thing I am checking if I get a reverse shell back. This is on my testing machine, no EDR here. I just wanted to see how many antivirus vendors I can bypass using this simple technique. And as you can see, I managed to bypass about 20 of those AV vendors that detected the original

pedal chip. What I'm trying here to do is simply append a real, a legitimate executable digital signature into that custom binary I tried. I wanted to see by appending a real digital signature, but of course it will not be officially digital assigned. It simply steals the digital signature and appends it. I wanted to see how many antivirus vendors I could bypass by adding this additional feature. To my surprise, I managed to bypass, I think, two. Yeah, so by simply appending a fake digital signature, you can bypass two AV vendors, which is nice. So let's go to the real innovative stuff. First you will see the custom PE loader. Its code is quite simple. I took it from GitHub and then simply

tinger the code a little bit because it has some memory relocation issues.

Once again compiling. You don't care about that, but I was too lazy to edit the video. The PLoader simply takes another executable as an argument, it iterates through all its contents and executes them in memory. Only that. So if you submit something like that on a solution like VirusTotal, maybe a couple of them think that it will be suspicious, so it is something benign. And this is actually the RAM disk I utilized. I downloaded the installer package. I renamed it to zip because by the time you install it,

you will see what I'm talking about. By the time you install it, there is a message box there that says that the installation was successful. I didn't want that. I wanted to stealthily execute and install that RAM disk. So I simply remove that executable and once again repackage the whole solution. So we are on the post exploitation phase. I am going to drop this VBS file. It's going to unzip the RAM disk installer. Why I use the VBS? I could have used Parcel, but guys, don't use Parcel all the time. Parcel is heavily monitored. I used it, I used the custom VBS script in order to unzip the contents. It is a lot stealthier. So I'm using syscript in order to execute that VBS. The

ram disk installer is dropped into the ram disk. This is a simple bot that installs the kernel mode drivers of the ram disk. And this command right here actually mounts and creates and formats the RAM disk. The RAM disk was 100 megabytes in size, the mount point was going to be R, and the last thing is that we silently format it to be an NTFS storage device. Nothing crazy so far. Now I'm going to drop the Pedal Chip Implant on the RAM disk, which as we have discussed was invisible. I'm also going to drop the Custom PE Loader into again the RAM disk.

They are here and now I am giving the pedal chip implant to the custom PE loader as an argument. It will take its contents and execute them in memory.

This is now, I did all those on the EDR protected machine. So as you can see I was able to bypass the whole thing and let me show you one last nice step.

This is the packet redirect module I was talking about. As you can see, we are binding a listening port, we are binding port 4449 as a listening port on the compromised machine. But let's see right here. So imagine that a blue team member tried to netstat and see all the listening ports, they see none. Although this listening port is their listening. This is because the packet redirect the Packet Redirect Post-Exploitation module manages to bypass the whole TCP IP stack of the system. So we could have achieved some very nice and stealthy persistence there. So to sum up, I'm closing my presentation. We managed to drop such a notorious, and we managed to drop such an

executable with such a high rate of detection rate regarding the AV vendors without of course being detected by using the technique I showed you.