Last updated
Was this helpful?
Last updated
Was this helpful?
In Visual Studio, create an empty C# project and name it "AV_Evasion". Create a C# class and name it "Dropper.cs".
On Kali, generate a vanilla meterpreter reverse shell payload with msfvenom:
Upload msgbox64.exe to :
This payload does not pass Windows Defender check.
On Kali, generate MessageBox payload in C# format:
In Visual Studio, write a dropper in C#:
Build it and upload the executable to VirusTotal:
This payload does not pass Windows Defender check.
Build it and upload the executable to VirusTotal:
This payload does not pass Windows Defender check.
Before you run a suspicious executable, AV will spawn a tiny virtual machine (aka sandbox) to execute the executable and see if it is malicious.
Most sandboxes will dynamically rename the payload. To determine whether we are inside a sandbox or not, we can use System.Diagnostics.Process.GetCurrentProcess() to get process information during runtime. If the process name changes, then we are inside a sandbox. In such case, we should simply exit the program:
Right click the solution "AV_Evasion", go to "Add Reference..." and add System. Build it and upload the executable to VirusTotal:
This payload passes Windows Defender check.
Generate MessageBox shellcode in PowerShell format with msfvenom:
Write a Dropper in PowerShell:
This script is flagged by AMSI easily:
AMSI scans for malicious activity in memory.
https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal
The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product that's present on a machine. AMSI provides enhanced malware protection for your end-users and their data, applications, and workloads.
AMSI is agnostic of antimalware vendor; it's designed to allow for the most common malware scanning and protection techniques provided by today's antimalware products that can be integrated into applications. It supports a calling structure allowing for file and memory or stream scanning, content source URL/IP reputation checks, and other techniques.
However, I have tried many payloads and all of them are blocked by the latest Win11. We will investigate more in the "AMSI Bypass" section.
A fiber is a thread inside of a thread.
https://docs.microsoft.com/en-us/windows/win32/procthread/fibers
A fibe is a unit of execution that must be manually scheduled by the application. Fibers run in the context of the threads that schedule them. Each thread can schedule multiple fibers. In general, fibers do not provide advantages over a well-designed multithreaded application. However, using fibers can make it easier to port applications that were designed to schedule their own threads.
Fibers give us an alternative way to execute shellcode on a host in a manner that AV is not used to scanning.
Generate encoded MessageBox payload with msfvenom:
Upadte Dropper.cs:
Build it and upload the executable to VirusTotal:
We can obfuscate the payload with the "double reverse" technique: reverse the shellcode and then call Array.Reverse().
At a high level, once PowerShell is invoked, amsi.dll is injected into the process and executed. AMSI_Scan_Buffer is then used to scan for malicious activity. Because of the way AMSI is currently implemented, the namespace can also patch back into it. Matt Graber wrote the original AMSI bypass for patching the Scan Buffer function to all return clean . This has been "fixed" by Microsoft by adding that as a known malicious signature. However, signature detection isn't very good and can be bypassed fairly easily. The site was setup to create AMSI bypasses. We can easily pull down a payload and get around AMSI to allow our script to run. We will need to keep trying payloads in PowerShell until one works as intended.
