Windows 10 to offer application developers new malware defenses

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.

An example of a malicious PowerShell script

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.

An example of a dynamic script.

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.

An example of a 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.

An example of an algorithmic obfuscation script

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.

Sample 'stager' script, too benign to detect on its own

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.

The equivalent in Visual Basic script

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.

AMSI architecture

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.

Sample script encoded in Base64

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.

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.

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.


Lee Holmes

Principal Software Engineer

Comments (29)

  1. Glenn Faustino says:

    Cool! This is great.

  2. MC says:

    The ability to invoke screening of suspect input is very cool, but to make sure I'm understanding the built-in component; in Windows 10 any point in a powershell script that could execute dynamic code will auto call AMSI, eval invoke-expression, etc?

  3. timo says:

    Can there be multiple registered antimalware engines? If yes, can the caller somehow choose which provider to use for the Scan() call, or is the content always scanned with all the registered engines? Is the caller able to tell which engine(s) detected
    the content?

  4. bigger says:

    this categories will influence many security vendors!!!

  5. Ben says:

    This kills other competitons software security, this shapes up as a greatest OS of all time!

  6. Lee Holmes says:

    @MC: Correct. In-box scripting languages that dynamically evaluate code (PowerShell, VBScript, JScript) will automatically call AMSI before executing that code.

    Lee Holmes [MSFT]

    1. Ni Linyu says:

      Dear Lee Holmes
      could you give me code example about
      How to use these functions to complete scan?
      How to implement the AMSI
      could you help me to explain the parameters of these functions.

      I don’t how to use these.

  7. Xudong Guan [MSFT] says:

    @Timo: Ideally we only want one engine (a.k.a AMSI provider) to register, and Windows Defender will unregister from AMSI and shut itself down when another AV engine registers with Action Center. In the case where there are multiple providers registered,
    AMSI.dll will try to instantiate all of them during initialization. On each scan trigger, it calls providers with a pre-defined order, one-by-one, until S_OK (meaning a scan was performed successfully and scan result returned in the out parameter) is returned
    by one of them. This is not a common scenario, and this behavior might be refined in the future. The COM API exposes an output interface pointer to the provider, which can be used to tell which provider did this scan. HTH.

    1. Ni Linyu says:

      Dear Xudong Guan
      could you give me code example about
      How to use these functions to complete scan?
      How to implement the AMSI
      could you help me to explain the parameters of these functions.

      I don’t how to use these.

    2. Pluto Koder says:

      Hi Xudong Guan,

      I need your help. I have implemented IAntimalwreprovider. Can you please give me some guidance on how should I register this provider? Any references or links will also work.

    3. Pluto Koder says:

      Hi Xudong Guan ,
      I have implemented the providers and registered it successfully. When I call amsiscan apis then the providers scan method gets called. This works fine. But when I execute some scripts from powershell then only initialization methods are called . Scan method is not called. Is there any settings or any other requirement which will make powershell call the providers scan method.?

  8. codemaniac says:

    This is cool! Any C# or C/C++ sample code for this?

  9. Rakesh says:

    Looks neat. Windows 10 is getting better every day. Kudos to MS

  10. hypothesis says:

    Would nefarious malware authors be able to register their own AMSI provider which allow malware test to pass?

  11. newsages says:


  12. Meitzi says:

    I like this idea.

    However, I'm wondering how data is handed. Lets say, usually exe file does no include personal data, password etc. So, normally you could send samples quite safely. But, if you send sample using this engine, it may contain very personal data, clear passwords

  13. pradeep says:

    Hi Lee,
    I tried to test the capability of AMSI by building the AMSI Client with server as windows defender. But as soon as I called AmsiInitialize it got failed with error code 0x80070057 (Parameters are incorrect). I am not sure why I am facing this error code.

    Let me know if you find any obvious issue in code file.
    I tried on Windows 10 x86 ( Build-10041.0.150313-1821)

    // amsiClient.cpp : Defines the entry point for the console application.

    #include "stdafx.h"
    //#include "sal.h"
    #include "amsi.h"

    int AMSIIntegration()
    HAMSICONTEXT amsiContext;
    HRESULT hres;

    hres=CoInitializeEx(0, COINIT_MULTITHREADED);
    hres = AmsiInitialize(L"AMSIClient", 0,&amsiContext);
    if( FAILED(hres) )
    std::wcout< CoUninitialize();
    return -1; // Program has failed.

    HAMSISESSION amsiSession;
    hres = AmsiOpenSession(amsiContext, &amsiSession);
    if( FAILED(hres) || amsiSession == nullptr )
    std::wcout< if( FAILED(hres))
    std::wcout<<L"AmsiScanString failed !!. hres = "<< std::hex << hres << std::endl;
    return -1;
    std::wcout<<L"Scan Result = " << scanResult< }

    return 0;

    int _tmain(int argc, _TCHAR* argv[])
    return 0;

    1. Midhunlal G says:

      I got it [c++ code] working in the latest Windows 10 build.

  14. Xudong Guan [MSFT] says:

    @Pradeep: Looks like you may be using an old header/SDK (or there is a bug in the SDK), but AmsiIntialize() should only take two arguments.

    STDAPI AmsiInitialize(
    _In_ LPCWSTR appName,
    _Outptr_ HAMSICONTEXT* amsiContext);

    1. Ni Linyu says:

      Dear,Lee Holmes
      Do you kown the AMSI how to use?The first parameter in AmsiInitialize is appName. I don’t kown which appName I should use.

  15. Lee Holmes [MSFT] says:

    @hypothesis – Preventing malicious software from running on the machine is the goal of the Antimalware industry. If malware has avoided detection – especially when running as an Administrator – its capabilities are equivalent to that of the operating system
    itself. That's why the industry puts such effort into robust sample collection, reporting, and cross-company sharing.

  16. GrayHat says:

    @Lee: You're right, if a piece of malware is running on your box with elevated privileges then it's game over; on the other hand, we already saw "fake AVs" in a past and now one of those critters may hoow the AMSI and play dirty; I think that it would
    be a good idea requiring AMSI apps (scanners) to have a valid/trusted code signature

  17. ranta says:

    In the AMSI documentation on MSDN, I don't see anything about how to register an AMSI provider. I wildly guess that feature requires an NDA like Windows Security Center integration does, and perhaps a Microsoft signature like Early Launch Anti-malware

  18. MaxFLipz says:

    I take it this will find its way into Windows Server vNext? In the meanwhile, if AMSI is open, can a server place a call into AMSI running on a Windows 10 workstation for malicious code scanning on/at runtime to gain these benefits?

  19. Lukor says:

    @ranta I second to this question? Can you guys suggest how do we obtain the information about being a AMSI provider?

  20. Ni Linyu says:

    Could you show me how to use the AMSI with C++? Thanks

  21. Swapnil Mahajan says:

    Will you please explain registration process with Security Center.
    Do we need to signed any agreement with MS?
    Will you please provide the name of the document where MS has mentioned the process of registration with Security Center.

  22. rohan says:

    how to implement this interface?
    In which namespace do the provider class register?

  23. Midhunlal G says:

    Please note that second parameter
    _In_ DWORD coInit
    in AmsiInitialize () function is not present in the latest API.

Skip to main content