Wie das Antimalware Scan Interface (AMSI) Ihnen hilft, sich gegen Schadsoftware zu schützen
Eine Einführung in das Windows Antimalware Scan Interface (AMSI) finden Sie unter Antimalware Scan Interface (AMSI).
Als Anwendungsentwickler können Sie sich aktiv an der Malware-Abwehr beteiligen. Insbesondere können Sie Ihre Kunden vor dynamischer skriptbasierter Schadsoftware und vor ungewöhnlichen Cyberangriffen schützen.
Nehmen wir als Beispiel an, dass Ihre Anwendung skriptfähig ist: Sie akzeptiert beliebige Skripts und führt sie über eine Skript-Engine aus. Wenn ein Skript für die Skripterstellungs-Engine bereitgestellt werden kann, kann Ihre Anwendung die Windows AMSI-APIs aufrufen, um eine Überprüfung des Inhalts anzufordern. Auf diese Weise können Sie sicher feststellen, ob das Skript böswillig ist oder nicht, bevor Sie sich entscheiden, es auszuführen.
Dies gilt auch dann, wenn das Skript zur Laufzeit generiert wurde. Ein Skript (böswillig oder anderweitig) kann mehrere Durchgänge der De-Obfuskation durchlaufen. Letztendlich müssen Sie jedoch die Skript-Engine mit einfachem, nicht verschleiertem Code bereitstellen. Und das ist der Punkt, an dem Sie die AMSI-APIs aufrufen.
Hier sehen Sie eine Abbildung der AMSI-Architektur, in der Ihre eigene Anwendung durch eines der Felder "Andere Anwendung" dargestellt wird.
Die Windows AMSI-Schnittstelle ist geöffnet. Das bedeutet, dass sie von jeder Anwendung aufgerufen werden kann. und jede registrierte Antischadsoftware-Engine kann die an sie übermittelten Inhalte verarbeiten.
Wir müssen die Diskussion auch nicht auf Skript-Engines beschränken. Möglicherweise ist Ihre Anwendung eine Kommunikations-App und scannt Chatnachrichten auf Viren, bevor sie sie Ihren Kunden anzeigt. Oder vielleicht ist Ihre Software ein Spiel, das Plug-Ins überprüft, bevor Sie sie installieren. Es gibt viele Möglichkeiten und Szenarien für die Verwendung von AMSI.
AMSI in Aktion
Sehen wir uns AMSI in Aktion an. In diesem Beispiel ist Windows Defender die Anwendung, die AMSI-APIs aufruft. Sie können jedoch dieselben APIs in Ihrer eigenen Anwendung aufrufen.
Hier sehen Sie ein Beispiel für ein Skript, das die XOR-Codierungstechnik verwendet, um seine Absicht zu verbergen (unabhängig davon, ob diese Absicht gutartig ist oder nicht). Für diese Abbildung können wir uns vorstellen, dass dieses Skript aus dem Internet heruntergeladen wurde.
Um die Dinge interessanter zu machen, können wir dieses Skript manuell über die Befehlszeile eingeben, sodass keine tatsächliche Datei zu überwachen ist. Dies spiegelt die sogenannte "dateilose Bedrohung" wieder. Es ist nicht so einfach wie das Scannen von Dateien auf dem Datenträger. Die Bedrohung kann eine Hintertür sein, die sich nur im Speicher eines Computers befindet.
Unten sehen wir das Ergebnis der Ausführung des Skripts in Windows PowerShell. Sie werden sehen, dass Windows Defender in der Lage ist, das AMSI-Testbeispiel in diesem komplizierten Szenario zu erkennen, indem Sie lediglich die Standardsignatur des AMSI-Testbeispiels verwenden.
AMSI-Integration mit JavaScript/VBA
Der unten dargestellte Workflow beschreibt den End-to-End-Ablauf eines anderen Beispiels, in dem wir die Integration von AMSI mit der Makroausführung in Microsoft Office veranschaulichen.
- Der Benutzer erhält ein Dokument, das ein (böswilliges) Makro enthält, das statischen Antivirensoftwarescans durch den Einsatz von Techniken wie Obfuskation, kennwortgeschützte Dateien oder anderen ausweicht.
- Anschließend öffnet der Benutzer das Dokument, das das (böswillige) Makro enthält. Wenn das Dokument in der geschützten Ansicht geöffnet wird, klickt der Benutzer auf Bearbeitung aktivieren, um die geschützte Ansicht zu beenden.
- Der Benutzer klickt auf Makros aktivieren, um die Ausführung von Makros zuzulassen.
- Während das Makro ausgeführt wird, verwendet die VBA-Runtime einen zirkulären Puffer, um [1] Daten und Parameter im Zusammenhang mit Aufrufen von Win32-, COM- und VBA-APIs zu protokollieren.
- Wenn bestimmte Win32- oder COM-APIs beobachtet werden, die als hohes Risiko gelten (auch als Trigger bezeichnet) [2], wird die Makroausführung angehalten, und der Inhalt des zirkulären Puffers wird an AMSI übergeben.
- Der registrierte AMSI-Anti-Malware-Dienstanbieter antwortet mit einem Urteil, um anzugeben, ob das Makroverhalten böswillig ist oder nicht.
- Wenn das Verhalten nicht böswillig ist, wird die Makroausführung fortgesetzt.
- Andernfalls schließt Microsoft Office die Sitzung als Reaktion auf die Warnung [3], und der AV kann die Datei unter Quarantäne stellen.
Was bedeutet das für Sie?
Für Windows-Benutzer wird jede schadhafte Software, die Verschleierungs- und Ausweichtechniken auf Windows 10 integrierten Skripthosts verwendet, automatisch auf einer viel tieferen Ebene als je zuvor überprüft und bietet zusätzliche Schutzebenen.
Für Sie als Anwendungsentwickler sollten Sie erwägen, dass Ihre Anwendung die Windows AMSI-Schnittstelle aufruft, wenn Sie von zusätzlichen Überprüfungen und Analysen potenziell schädlicher Inhalte profitieren (und Ihre Kunden schützen) möchten.
Als Anbieter von Antivirensoftware können Sie die Unterstützung für die AMSI-Schnittstelle implementieren. Wenn Sie dies tun, erhält Ihre Engine einen viel tieferen Einblick in die Daten, die Anwendungen (einschließlich Windows 10 integrierten Skripthosts) als potenziell böswillig betrachten.
Weitere Hintergrundinformationen zu dateilosen Bedrohungen
Möglicherweise sind Sie neugierig auf weitere Hintergrundinformationen zu den Arten von dateilosen Bedrohungen, gegen die Windows AMSI entwickelt wurde, um Sie zu schützen. In diesem Abschnitt werfen wir einen Blick auf das traditionelle Katz-und-Maus-Spiel, das sich im Malware-Ökosystem abspielt.
Wir verwenden PowerShell als Beispiel. Sie können jedoch die gleichen Techniken und Prozesse nutzen, die wir mit jeder dynamischen Sprache demonstrieren– VBScript, Perl, Python, Ruby und mehr.
Nachfolgend sehen Sie ein Beispiel für ein schädliches PowerShell-Skript.
Während dieses Skript einfach eine Nachricht auf den Bildschirm schreibt, ist Malware in der Regel wesentlich schadhafter. Sie könnten jedoch leicht eine Signatur schreiben, um diese zu erkennen. Beispielsweise könnte die Signatur nach der Zeichenfolge "Write-Host 'pwnd!'" in jeder Datei suchen, die der Benutzer öffnet. Großartig: Wir haben unsere erste Schadsoftware erkannt!
Nachdem sie jedoch von unserer ersten Signatur erkannt wurden, reagieren Malware-Autoren. Sie reagieren, indem sie dynamische Skripts wie dieses Beispiel erstellen.
In diesem Szenario erstellen Malware-Autoren eine Zeichenfolge, die das auszuführende PowerShell-Skript darstellt. Sie verwenden jedoch eine einfache Zeichenfolgenverkettungstechnik, um unsere frühere Signatur zu unterbrechen. Wenn Sie jemals die Quelle einer werbebeladenen Webseite anzeigen, sehen Sie, dass viele Instanzen dieser Technik verwendet werden, um Werbung blockierende Software zu vermeiden.
Schließlich übergibt der Malware-Autor diese verkettete Zeichenfolge an das cmdlet Invoke-Expression — den PowerShell-Mechanismus zum Auswerten von Skripts, die zur Laufzeit erstellt oder erstellt werden.
Als Reaktion darauf beginnt Antischadsoftware mit der grundlegenden Sprachemulation. Wenn beispielsweise zwei Zeichenfolgen verkettet werden, emulieren wir die Verkettung dieser beiden Zeichenfolgen und führen dann unsere Signaturen für das Ergebnis aus. Leider ist dies ein ziemlich fragiler Ansatz, da Sprachen in der Regel viele Möglichkeiten haben, Zeichenfolgen darzustellen und zu verketten.
Nachdem sie also von dieser Signatur erfasst wurden, werden Malware-Autoren zu etwas komplizierterem wechseln– z. B. der Codierung von Skriptinhalten in Base64, wie in diesem nächsten Beispiel.
Da sie einfallsreich sind, implementieren die meisten Antischadsoftware-Engines auch Base64-Decodierungsemulation. Da wir also auch Base64-Decodierungsemulation implementieren, sind wir eine Zeit lang voraus.
Als Reaktion darauf wechseln Malware-Autoren zu algorithmischer Obfuskation – z. B. einem einfachen XOR-Codierungsmechanismus in den von ihnen ausgeführten Skripts.
An diesem Punkt sind wir in der Regel über das hinaus, was Antiviren-Engines emulieren oder erkennen, sodass wir nicht unbedingt erkennen, was dieses Skript tut. Wir können jedoch mit dem Schreiben von Signaturen für die Obfuskations- und Codierungstechniken beginnen. Tatsächlich macht dies die große Mehrheit der Signaturen für skriptbasierte Schadsoftware aus.
Aber was ist, wenn der Obfuscator so trivial ist, dass er wie viele wohlerzogene Skripts aussieht? Eine Signatur dafür würde eine inakzeptable Anzahl falsch positiver Ergebnisse erzeugen. Hier ist ein Beispielskript stager, das zu gutartig ist, um selbst erkennen zu können.
In diesem Beispiel laden wir eine Webseite herunter und rufen einige Inhalte von ihr auf. Hier sehen Sie die Entsprechung im Visual Basic-Skript.
Was die Dinge in beiden Beispielen noch schlimmer macht, ist, dass die Antiviren-Engine Dateien überprüft, die vom Benutzer geöffnet werden. Wenn sich die schädlichen Inhalte nur im Speicher befinden, kann der Angriff möglicherweise unentdeckt werden.
In diesem Abschnitt wurden die Einschränkungen der Erkennung mithilfe herkömmlicher Signaturen erläutert. Obwohl ein böswilliges Skript mehrere De-Obfuskationsphasen durchlaufen kann, muss es letztendlich die Skripterstellungs-Engine mit einfachem, nicht verschleiertem Code bereitstellen. Und an diesem Punkt rufen die integrierten Skripthosts von Windows 10 die AMSI-APIs auf, um eine Überprüfung dieses ungeschützten Inhalts anzufordern. Und Ihre Anwendung kann dasselbe tun.
Zugehörige Ressourcen
Feedback
Feedback senden und anzeigen für