Wie das Antimalware Scan Interface (AMSI) Ihnen hilft, sich vor Schadsoftware zu schützen
Eine Einführung in das Windows Antimalware Scan Interface (AMSI) finden Sie unter Antimalware Scan Interface (AMSI).
Als Anwendungsentwickler*in können Sie sich aktiv an der Abwehr von Schadsoftware beteiligen. Insbesondere können Sie Ihre Kund*innen vor dynamischer skriptbasierter Schadsoftware und vor ungewöhnlichen Cyberangriffen schützen.
Nehmen wir beispielsweise 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 dazu auffordern, die Inhalte zu überprüfen. Auf diese Weise können Sie sicher feststellen, ob das Skript böswillig ist oder nicht, bevor Sie entscheiden, es auszuführen.
Dies trifft auch dann zu, wenn das Skript zur Laufzeit generiert wurde. Ein Skript (böswillig oder anderweitig) kann mehrere Deobfuscation-Prozesse 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.
Ein Szenario, dass nicht einzig und allein auf Skript-Engines beschränkt werden muss. Ihre Anwendung ist möglicherweise eine Kommunikations-App und überprüft Chatnachrichten auf Viren, bevor sie sie Ihren Kund*innen anzeigt. Oder aber Ihre Software ist 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). In diesem Beispiel können wir uns vorstellen, dass dieses Skript aus dem Internet heruntergeladen wurde.
Um das Beispiel noch interessanter zu machen, können wir dieses Skript manuell über die Befehlszeile eingeben, sodass keine tatsächliche Datei überwacht werden muss. Dies spiegelt die sogenannte „dateilose Bedrohung“ wieder. Dies ist nicht so einfach wie das Überprüfen von Dateien auf dem Datenträger. Bei der Bedrohung könnte es sich um eine Hintertür handeln, 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 es lediglich die Standardsignatur des AMSI-Testbeispiels verwendet.
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/die Benutzer*in erhält ein Dokument, das ein (böswilliges) Makro enthält, das Techniken wie Obfuskation, kennwortgeschützte Dateien oder andere Techniken verwendet, um statischen Antivirensoftwarescans zu entgehen.
- Anschließend öffnet der/die Benutzer*in das Dokument, das das (böswillige) Makro enthält. Wenn das Dokument in der geschützten Ansicht geöffnet wird, klickt der/die Benutzer*in auf Bearbeitung aktivieren, um die geschützte Ansicht zu verlassen.
- Der/die Benutzer*in 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 aus Aufrufen von Win32-, COM- und VBA-APIs zu protokollieren.
- Werben bestimmte Win32- oder COM-APIs beobachtet, die als hochriskant eingestuft werden (auch als Trigger bezeichnet) [2], wird die Makroausführung unterbrochen und der Inhalt des zirkulären Puffers wird an AMSI übergeben.
- Der registrierte AMSI-Anti-Malware-Dienstanbieter bewertet, ob das Verhalten des Makros böswillig ist oder nicht.
- Wenn das Verhalten nicht böswillig ist, wird die Ausführung des Makros fortgesetzt.
- Wenn das Verhalten böswillig ist, 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*innen wird jede schadhafte Software, die Verschleierungs- und Ausweichtechniken auf integrierten Skripthosts von Windows 10 verwendet, automatisch auf einer viel tieferen Ebene als je zuvor überprüft und es werden zusätzliche Schutzebenen bereitgestellt.
Als Anwendungsentwickler*in sollten Sie erwägen, die Windows AMSI-Schnittstelle aufzurufen, wenn Sie von zusätzlichen Überprüfungen und Analysen potenziell schädlicher Inhalte profitieren (und Ihre Kund*innen schützen) möchten.
Als Anbieter*in von Antivirensoftware können Sie die Unterstützung für die AMSI-Schnittstelle implementieren. Dadurch gewähren Sie Ihrer Engine einen viel tieferen Einblick in die Daten, die Anwendungen (einschließlich in Windows 10 integrierte Skripthosts) als potenziell böswillig einstufen.
Weitere Hintergrundinformationen zu dateilosen Bedrohungen
Sie wollen möglicherweise mehr darüber erfahren, vor welchen Arten dateiloser Bedrohungen Windows AMSI Sie verteidigen kann. In diesem Abschnitt werfen wir einen Blick auf das traditionelle Katz-und-Maus-Spiel, das in der Malware-Umgebung stattfindet.
Als Beispiel verwenden wir PowerShell. Sie können jedoch die gleichen Techniken und Prozesse nutzen, die wir mit jeder dynamischen Sprache demonstrieren: VBScript, Perl, Python, Ruby und viele andere.
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önnen jedoch einfach eine Signatur schreiben, um diese zu erkennen. Die Signatur könnte beispielsweise in allen vom Benutzer oder von der Benutzerin geöffneten Dateien nach der Zeichenfolge „Write-Host 'pwnd!“ suchen. Großartig: Wir haben unsere erste Schadsoftware erkannt!
Doch nachdem sie von unserer ersten Signatur erkannt wurde, werden die Ersteller*innen der Schadsoftware reagieren. Sie werden dynamische Skripts erstellen, wie die, die in diesem Beispiel aufgeführt sind.
In diesem Szenario erstellen Malware-Entwickler*innen eine Zeichenfolge, die das auszuführende PowerShell-Skript darstellt. Hierzu verwenden sie jedoch eine einfache Technik zur Verkettung von Zeichenfolgen, die unsere vorherige Signatur unterbrechen sollen. Sollten Sie jemals die Quelle einer werbebeladenen Webseite anzeigen, werden Sie sehen, dass zahlreiche Instanzen dieser Technik dazu verwendet werden, Software zur Blockierung von Werbung zu umgehen.
Schließlich übergibt der/die Entwickler*in der Schadsoftware diese verkettete Zeichenfolge an das Cmdlet Invoke-Expression – den PowerShell-Mechanismus zum Auswerten von Skripts, die zur Laufzeit erstellt wurden.
Als Reaktion darauf beginnt die Antischadsoftware mit der Emulation der Basissprache. 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 handelt es sich hierbei um einen recht fragilen Ansatz, da Sprachen in der Regel viele Möglichkeiten haben, Zeichenfolgen darzustellen und zu verketten.
Nachdem die Entwickler*innen der Schadsoftware von dieser Signatur erfasst wurden, werden sie zu einem komplizierteren Ansatz wechseln, beispielsweise zum Codieren von Skriptinhalten in Base64, wie im nächsten Beispiel dargestellt ist.
Da die meisten Antischadsoftware-Engines einfallsreich sind, implementieren sie auch die Base64-Decodierungsemulation. Dank der Implementierung der Base64-Decodierungsemulation gewinnen wir einen Zeitvorsprung.
Als Reaktion darauf wechseln Malware-Entwickler*innen zu algorithmischer Obfuskation, beispielsweise zu einem einfachen XOR-Codierungsmechanismus in den Skripts, die sie ausführen.
Wenn es so weit kommt, bedeutet das in der Regel, dass wir in Bezug darauf, was die Antiviren-Engines emulieren oder erkennen, überholt wurden, sodass wir nicht unbedingt erkennen werden, was dieses Skript tut. Wir können jedoch Signaturen schreiben, um den Obfuskations- und Codierungstechniken entgegenzuwirken. Tatsächlich ist die große Mehrheit der Signaturen für skriptbasierte Schadsoftware genau darauf zurückzuführen.
Was passiert aber, wenn der Obfuskator so trivial ist, dass er sich von den zahlreichen, sich richtig verhaltenden Skripts nicht unterscheiden lässt? Eine Signatur dafür würde eine inakzeptable Anzahl falsch-positiver Ergebnisse generieren. Hier ist ein Beispiel für ein Stager-Skript, das zu gutartig ist, um erkannt zu werden.
In diesem Beispiel laden wir eine Webseite herunter und rufen einige Inhalte daraus auf. Hier sehen Sie das Äquivalent im Visual Basic-Skript.
Was die Dinge in beiden Beispielen noch komplizierter macht, ist die Tatsache, dass die Antiviren-Engine Dateien überprüft, die vom Benutzer oder von der Benutzerin geöffnet werden. Befinden sich die schädlichen Inhalte nur im Speicher, so wird der Angriff möglicherweise nicht entdeckt.
In diesem Abschnitt wurden die Grenzen der Erkennung mithilfe herkömmlicher Signaturen aufgezeigt. Obwohl ein böswilliges Skript mehrere Deobfuscation-Phasen durchlaufen kann, muss es letztendlich die Skripterstellungs-Engine mit einfachem, nicht verschleiertem Code bereitstellen. Und an diesem Punkt – wie im ersten Abschnitt beschrieben – rufen die in Windows integrierten Skripthosts die AMSI-APIs auf, um eine Überprüfung dieser nicht geschützten Inhalte anzufordern. Und Ihre Anwendung kann dasselbe tun.