Microsoft Windows is the most popular operating system for businesses and its users - it currently holds more that 70 percent of the market share globally! Unfortunately, this also means that Windows is a popular target for attackers, with most malware developers and threat actors targeting the platform.
PowerShell is the powerful scripting language and program that is available on Windows OS and is used by network and system administrators for automation, management, and orchestration.
However, this program is also widely used and abused by attackers. PowerShell based attacks have been a popular attack vector due to being available in all enterprise environments, and usually not being monitored or locked down for most users. The malware used for these attacks are normally loaded from a remote server and run in memory, and when the process closes, the file containing the malware is no longer present on the system.
This type of attack - also known as a fileless attack is a great technique for defeating traditional and next-generation Anti-Virus (AV) software as it usually only scans files stored on the system but struggle to scan and detect anything running in-memory.
Microsoft's solution to detecting and preventing fileless attacks is the Anti-Malware Scanning Interface (AMSI) program. Many AVs rely on this service to "help them out" with preventing these attacks.
/bluevision/Picture1-ic83f.jpg)
Credits - https://www.trendmicro.com/en_ie/research/22/l/detecting-windows-amsi-bypass-techniques.html
AMSI debuted back in 2015 and designed to offer a defense against fileless attacks by scanning the memory of process for malicious buffers and then passing the results on to other defenses on the host like Anti-Virus.
For example, when a malicious PowerShell script finds it way onto a victim's system, the AV will scan that file and find that there is nothing malicious currently in the contents of that file.
In reality, the file is just a download cradle for the real bad stuff. When that file runs, the memory of that will then get passed through to AMSI to be scanned for malicious contents. These contents being certain characters and words which is known to be malicious. This process works great against very basic malware and attacks!
The downside of relying on AMSI to keep you safe from fileless attacks, is that AMSI itself can be bypassed with relative ease and little effort. Meaning that if you only have your AV + AMSI to protect you, you might want to review your defensive stance.
There are a few ways attackers get around AMSI and successfully smuggle a malicious payload on a victim's system without triggering any alerts on Windows Defender. A brilliant post from 0xStarlight shows multiple obfuscation techniques to a command that patches AMSI and allow malicious payloads to be executed.
AMSI will scan patterns and strings for malicious content. One method to prevent payloads from being stopped is obfuscation - i.e. hiding your malicious strings in ways that defenses haven't built detections for yet.
There are many different methods and techniques to this evasion technique, but the methodology remains somewhat similar:
The payload below modifies the behaviour of AMSI by setting the 'amsiInitFailed', 'NonPublic', and 'Static' fields to true, which results in AMSI being disabled because it failed to initialize.
/bluevision/Picture2-qdb9f.png)
Step 2 - Find out what triggers the alert on AMSI.
A really neat program called AMSITrigger can help with identifying what sections in a malicious payload stands out. This is useful for defenders as they can perform initial analysis a suspicious file to determine if it is benign or malicious. Attackers can take advantage of this tool by scanning and obfuscating the alerted sections in their payload.
/bluevision/Picture3-cf712.png)
AMSITrigger detected suspicious strings in the payload. These strings are not malicious by design, but because they are used and abused by attackers, it will be picked up and will trigger the defenses on the system.
Now that the malicious strings have been identified - the obfuscation techniques can be used to try and evade defenses. The first example will be using base64 encoding. Using the PowerShell command and replacing the 'CleartextString' field will turn a clear text sting into a base64 encoded one.
/bluevision/Picture4-z221e.png)
/bluevision/Picture5-da6e1.png)
The base64 encoded strings are gathered, but will need to be decoded for it to work and run on the system.
/bluevision/Picture6-u74dd.png)
Decoding base64 can be done using the command below by replacing the 'EncodedString' field with the encoded payload string.
/bluevision/Picture7-9de81.png)
/bluevision/Picture8-afd49.png)
Finally, by chaining together the decoded payload string along with the base64 encoded payload, and replacing the sections in the original payload, will look something like this:
/bluevision/Picture9-c9372.png)
MimiKatz is a popular tool used by attackers to dump passwords and hashes on a Windows system. Testing if AMSI works by running Invoke-MimiKatz (the PowerShell version) without the AMSI bypass results in it being detected and the payload is blocked and process is stopped.
/bluevision/Picture10-w8098.png)
When the bypass is executed first, AMSI failed to initialize and did not detect or prevent Invoke-MimiKatz from being executed. This results in the passwords and hashes being dumped without any interference from Windows Defender. As long as the attacker keeps this bypassed PowerShell session open, they have the keys to the kingdom on victim's system.
/bluevision/Picture11-a5db2.png)
When testing this AMSI bypass technique to see how the SentinelOne EDR (on default settings) reacts, it is not immediately detected and executes successfully. This again means that the PowerShell session can be used without interference from the defenses. Or so it seemed at first.
/bluevision/Picture12-bb61c.png)
When trying to replicate the attack by running the same Mimikatz command that previously bypassed Windows Defender, the excitement is short lived and the malicious process gets stopped and automatically remediated by the EDR.
/bluevision/Picture13-ke5d4.png)
This could be because SentinelOne hooks into certain processes and monitors for suspicious and malicious events happening on the system. Even though the initial AMSI bypass ran without alerts, the Invoke-MimiKatz command tries to retrieve the hashes and passwords from a program called lsass.exe.
Any program calling lsass.exe is suspicious and SentinelOne knows this, and closely monitors any events that calls the program. EDR detects patterns and events, and deals with malicious events automatically (depending on settings), rather than just relying on scan results from files on the system.
Author: G Botha
