Evading AV with Thread Injection
After we have a general understanding of the detection techniques
used in antivirus software and the relative bypass methods,
we can turn our focus to a practical example.
Finding a universal solution to bypass all antivirus products
is difficult and time consuming, if not impossible.
Considering time limitations during a typical penetration test,
it is far more efficient to target the specific antivirus product
deployed in the target network.
For the purposes of this Topic,
we will interact with Avira Free Security on our Windows 11 client.
Once we connect via RDP with the provided credentials,
we’ll notice that Avira is already installed
and can be launched from the Desktop shortcut.
Once started, we can navigate to the Security panel from the left menu
and click on Protection Options:
Launching this menu section will display the currently running protections
where we can verify if the Real-Time Protection feature is enabled
and manually enable it if needed.
As a first step when testing AV products,
we should verify that the antivirus is working as intended.
We will use the Metasploit payload we generated earlier and scan it with Avira.
We’ll first transfer the file to our web server
in which we have apache already running.
After transferring the malicious PE to our Windows client,
we are warned about the malicious content of the uploaded file.
In this case, we are presented with an error message
indicating that our file has been blocked.
Avira displays a popup notification
informing us that the file was flagged as malicious and quarantined.
Depending on how restricted our target environment is,
we might be able to bypass antivirus products with the help of PowerShell.
In the following example,
we’ll use a remote process memory injection technique.
We’ll target the currently executing process,
which in our case will be the x86 PowerShell interpreter.
A very powerful feature of PowerShell
is its ability to interact with the Windows API.
This allows us to implement the in-memory injection process in a PowerShell script.
One of the main benefits of executing a script rather than a PE
is that it is difficult for antivirus manufacturers
to determine if the script is malicious
as it’s run inside an interpreter and the script itself isn’t executable code.
Nevertheless, please keep in mind
that some AV products handle malicious script detection
with more success than others.
Furthermore, even if the script is marked as malicious, it can easily be altered.
Antivirus software will often review variable names, comments, and logic,
all of which can be changed without the need to recompile anything.
To demonstrate an introductory AV bypass,
we we are going to first analyze a well-known version
of the memory injection PowerShell script
and then test it against Avira.
Here we have a basic templated script that performs in-memory injection.
The script starts by importing VirtualAlloc
and CreateThread from kernel32.dll,
as well as memset from msvcrt.dll.
These functions will allow us to allocate memory,
create an execution thread,
and write arbitrary data to the allocated memory, respectively.
The script main logic starts by allocating a block of memory using VirtualAlloc,
which takes each byte of the payload stored in the $sc byte array,
and writes it to our newly-allocated memory block using memset.
As a final step,
our in-memory written payload is executed in a separate thread
using the CreateThread API.
Our chosen payload is missing from our script,
but can be generated using msfvenom.
The resulting output can be copied.
And pasted into the $sc variable of our script.
Next, we are going to verify the detection rate of our PowerShell script.
Our preferred choice would be Antiscan.Me,
but sadly, it does not support ps1 format,
so we have to resort to VirusTotal.
According to the results of the VirusTotal
27 of the 61 AV products flagged our script as malicious,
including Avira.
This is not as promising as expected,
so we need to somewhat circumvent the AV signature logic.
As mentioned, scripts are just interpreted text files.
They are not easily fingerprinted like binary files,
which have a more structured data format.
In order to catch malicious scripts,
AV vendors often rely on static string signatures
related to meaningful code portions,
such as variables or function names.
To bypass this detection logic,
let’s give the variables of the previous script more generic names.
We have updated our script by changing the Win32 hard-coded class name
for the Add-Type cmdlet to iWin32.
Similarly, we have renamed winFunc and sc
to var1 and var2, respectively.
We’ll copy the file to our web directory for transfer to the target.
Once we save the PowerShell script
and transfer it to the target Windows 11 client,
we can run a Quick Scan to verify that our attack vector is undetected.
To run the scan, select Virus Scans,
and then click on Scan under the Quick Scan option.
Once Avira has scanned our script on our Windows 11 machine,
it indicates our script is not malicious.
Since the msfvenom payload is for x86,
we are going to launch the x86 version of PowerShell.
Let’s run bypass.ps1 and analyze the output.
Unfortunately, when we attempt to run our malicious script,
we are presented with an error
that references the Execution Policies of our system,
which appear to prevent our script from running.
A quick review of the Microsoft documentation
on PowerShell execution policies
shows that these policies are set on a per-user rather than per-system basis.
Let’s attempt to view and change the policy for our current user.
First, we are going to retrieve the current execution policy
via the Get-ExecutionPolicy command,
and then set it to Unrestricted
via the Set-ExecutionPolicy command.
The output shows that we have successfully changed the policy
for our current user to Unrestricted.
Before executing our script,
we will start a Netcat listener on our Kali attacker machine
to interact with our shell.
Now we will try to launch the PowerShell script.
The script executes without any problems
and we receive a reverse shell on our attack machine.
This means we have effectively evaded Avira detection on our target.
In mature organizations,
various machine learning software can be implemented
that will try to analyze the contents of the scripts that are run on the system.
Depending on the configuration of these systems and what they consider harmful,
our scripts may need to be altered or adapted for the target environment.