Simple Techniques to Bypass AVs | By Siddharth Sharma

Simple Techniques to Bypass AVs

AVs have been bypassed by adversaries for many years and as long as AVs exist, new techniques will continue to be developed. One of the techniques known as obfuscation is mostly being used for this purpose by attackers but there are certain other techniques as well through which we could bypass AVs/EDRs. In this blog, we will explore some of the other techniques so,

Let’s begin:

We start with a simple injection technique using CreateRemoteThread WIN user api to inject shellcode in the given remote process, below image is the code snippet:

On running the above code, it asks for a PID and then shellcode using WriteProcessMemory gets written into the address space of the given process and at last it gets executed using CreateRemoteThread api.

DEMO:

Let’s check this on VT:

Oops!! We have a good detection rate.

BYPASS

In the above code the shellcode I used was generated using msfvenom and on being injected it pops calculator in the victim PC, msfvenom has become a very popular tool being used to generate shellcodes and AVs/EDRs are well aware of it but still there are techniques which could lead to bypassing these shellcodes from AV engines.

First, we start with just removing the bad characters from our shellcode (-b “\x00\xff”) and would see what detection ratio we have on VT:

Here we go, we have two AVs (ClamAV and Cylance) which detect our injector(though i could’nt believe why only two), but still we have two enemies, so why don’t we apply another technique, the Direct-Syscall technique, simply meaning bypassing user mode api hooks which is a general behaviour of AVs for detection.

Let’s look that how the CreateRemoteThread WIN user api call goes. On doing some analysis I found that at low level CreateRemoteThread calls NtCreateThreadEx and then it all goes into kernel space as shown below:

And then:

Or simply we could see that in windbg as well by loading the executable:

Above assembly code just shows the switching of code to kernel mode, where we have a Syscall id being stored in EAX register depending the PC version we use (Win 7,8 or 10). For our case we had Win7 x64 SP1 of which Syscall ID is A5.

So now we just add .asm file to our injection project and will add the assembly code including declaration.

Modified code:

NOTE: Make sure that Microsoft Macro Assembler files are included in “Build Customizations” options.

Let’s now check the detection rate:

Okayyy we still have one detection, this time Cylance fell asleep, so let’s try one more technique against ClamAV.

Sometimes AVs flag unsigned binaries as suspicion so why not we just sign this with our own generated cert,

So for that, I just generated a code signing infrastructure and signed our binary with that cert:

Here .pfx is generated cert with which we sign our injector using signtool utility and as we can see it has been signed so let’s check this on VT again:

And here we go it’s all clear and this is how we could just bypass simple msfvenom generated shellcode, although this time ClamAV had a timeout but maybe it could detect this second time.

In future blogs we will look into the analysis and detection of how real time malwares applied these techniques on other apis to bypass or to hinder the analysis.

References:

https://github.com/j00ru/windows-syscalls

https://evasions.checkpoint.com/

https://outflank.nl/blog/

About Siddharth:

• Interested in cybersecurity, his blog: https://threatblogs.wordpress.com/
• Student currently pursuing bachelors of technology (Computer Science)
• Interested in malware analysis,reversing and forensics.
• Did internship at Computer Emergency Response Team, India (CERT-In)