Application developers can now actively participate in malware defense – in a new way to help protect customers from dynamic script-based malware and non-traditional avenues of cyberattack.
Microsoft is making that possible through the Antimalware Scan Interface (AMSI) – a generic interface standard that allows applications and services to integrate with any antimalware product present on a machine. AMSI is currently available through the Windows 10 Technical Preview, and will be fully available when Windows 10 debuts this summer.
How does AMSI help?
To demonstrate the problem we’re trying to address, let’s look at the traditional cat-and-mouse game that plays out in the malware ecosystem.
We’ll use PowerShell as an example, while leveraging the techniques and processes we’ll go through apply to all dynamic languages: VBScript, Perl, Python, Ruby, and more.
Figure 1: An example of a malicious PowerShell script
While this script simply writes a message to the screen, malware is typically more nefarious. A developer can write a signature to detect this one easily – for example, searching for the string: “Write-Host ‘pwnd!‘” in any file that the user opens.
So perfect – we’ve detected our first malware.
After being caught by our first signature, though, malware authors will respond. They respond by creating dynamic scripts.
Figure 2: An example of a dynamic script.
In this scenario, malware authors create a string representing the PowerShell script to run. But they use a simple string concatenation technique to break our earlier signature. If you ever view the source of an ad-laden web page, you’ll see many instances of this technique being used to avoid ad-blocking software.
Finally, they pass this concatenated string to the Invoke-Expression cmdlet – PowerShell’s mechanism to evaluate scripts that are composed or created at runtime.
In response, antimalware software starts to do basic language emulation. For example, if we see two strings being concatenated, we emulate the concatenation of those two strings and then run our signatures on the result. Unfortunately, this is a fairly fragile approach, as languages tend to have a lot of ways to represent and concatenate strings.
So after being caught by this signature, malware authors will move to something more complicated – for example, encoding script content in Base64.
Figure 3: An example of a script content in Base64.
Being cunning and resourceful, most antimalware engines implements Base64 decoding emulation, as well. So, we’re ahead for a time since we also implement Base64 decoding emulation.
In response, malware authors move to algorithmic obfuscation – such as a simple XOR encoding mechanism in the scripts they run.
Figure 4: An example of an algorithmic obfuscation script.
At this point, we’re generally past what antivirus engines will emulate or detect, so we won’t necessarily detect what this script is actually doing. However, we can start to write signatures against the obfuscation and encoding techniques. In fact, this is what accounts for the vast majority of signatures for script-based malware.
But what if the obfuscator is so trivial that it looks like many well-behaved scripts? A signature for it would generate an unacceptable number of false positives.
Figure 5: Sample ‘stager’ script, too benign to detect on its own
In this example, we are downloading a web page and invoking some content from it.
Figure 6: The equivalent in Visual Basic script.
What makes things worse in both of these examples is that the antivirus engine inspects files being opened by the user. If the malicious content lives only in memory, the attack can potentially go undetected.
It’s not all doom and gloom! AMSI on the case
The crux of the issue is that scripting engines can run code that was generated at runtime. This is where the new Antimalware Scan Interface comes in.
Figure 7: AMSI architecture
While the malicious script might go through several passes of deobfuscation, it ultimately needs to supply the scripting engine with plain, unobfuscated code.
When it gets to this point, the application can now call the new Windows AMSI APIs to request a scan of this unprotected content.
The Windows AMSI interface is open. Any application can call it and any registered Antimalware engine can process the content submitted to it. While we’ve been talking about this in the context of scripting engines, it doesn’t need to stop there. Imagine communication apps that scan instant messages for viruses before ever showing them to you or games that validate plugins before installing them.
There are plenty of more opportunities – this is just a start.
AMSI in action
Now, let’s take a look at AMSI in action from an XOR encoding sample downloaded from the internet.
Figure 8: Sample script encoded in Base64.
To make things more interesting, we’ll enter it manually at the command line where there is no file to monitor.
Figure 9: When we ran it, Windows Defender was able to detect the AMSI test sample in this complicated scenario, while only using the bog standard AMSI test sample signature.
What does this mean for you?
If you are a Windows user, the good news is that the benefits of the Antimalware Scan Interface automatically occur with Windows 10.
Malicious software that uses obfuscation and evasion techniques on Windows’ built-in scripting hosts will automatically be inspected at a much deeper level than ever before, providing additional levels of protection.
If you’re an Application developer, consider having your application call the Windows AMSI interface if you want some extra scanning and analysis of potentially malicious content.
If you are an antivirus software vendor, consider implementing support for the AMSI interface. When you do, your engine will have much deeper insight into the data that applications (including Windows’ built-in scripting hosts) consider potentially malicious.
Principal Software Engineer