Wie Die Antimalware Scan Interface (AMSI) Ihnen hilft, sich vor Schadsoftware zu schützen
Eine Einführung in die Windows Antimalware Scan Interface (AMSI) finden Sie unter Antimalware Scan Interface (AMSI).
Als Anwendungsentwickler können Sie aktiv am Schutz vor Schadsoftware teilnehmen. Insbesondere können Sie Ihre Kunden vor dynamischer skriptbasierter Schadsoftware und vor nicht herkömmlichen 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 bereit ist, kann Ihre Anwendung die amsi-APIs Windows aufrufen, um eine Überprüfung des Inhalts anzufordern. Auf diese Weise können Sie sicher bestimmen, ob das Skript schädlich ist, bevor Sie es ausführen.
Dies gilt auch, wenn das Skript zur Laufzeit generiert wurde. Skripts (schädlich oder anderweitig) können mehrere Durchläufe der Entblendung durchlaufen. Letztendlich müssen Sie die Skript-Engine jedoch mit einfachem, nicht verborgenem Code bereitstellen. An diesem Punkt rufen Sie die AMSI-APIs auf.
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. Dies bedeutet, dass jede Anwendung sie aufrufen kann. und jede registrierte Antischadsoftware-Engine kann den an sie übermittelten Inhalt verarbeiten.
Wir müssen die Diskussion auch nicht auf Skript-Engines beschränken. Möglicherweise handelt es sich bei Ihrer Anwendung um eine Kommunikations-App, die Sofortnachrichten auf Viren überprüft, bevor sie Ihren Kunden angezeigt wird. Oder Vielleicht ist Ihre Software ein Spiel, das Plug-Ins überprüft, bevor sie installiert werden. 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 die gleichen APIs aus Ihrer eigenen Anwendung aufrufen.
Im Folgenden finden Sie ein Beispiel für ein Skript, das die XOR-Codierungstechnik verwendet, um die Absicht auszublenden (unabhängig davon, ob diese Absicht unbedenklich 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 gestalten, können wir dieses Skript manuell in der Befehlszeile eingeben, damit keine tatsächliche Datei überwacht werden kann. Dies spiegelt die sogenannte "dateilose Bedrohung" wider. Dies ist nicht so einfach wie das Scannen von Dateien auf dem Datenträger. Die Bedrohung kann eine Hintertür sein, die sich nur im Arbeitsspeicher eines Computers befindet.
Im Folgenden sehen Sie das Ergebnis der Ausführung des Skripts in Windows PowerShell. Sie werden feststellen, dass Windows Defender das AMSI-Testbeispiel in diesem komplizierten Szenario erkennen kann, indem sie lediglich die STANDARDMÄßIGE AMSI-Testbeispielsignatur 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 in die Makroausführung innerhalb Microsoft Office veranschaulichen.

- Der Benutzer erhält ein Dokument, das ein (bösartiges) Makro enthält, das statische Antivirensoftwarescans unter Verwendung von Techniken wie Verschleierung, kennwortgeschützten Dateien oder anderem ausweicht.
- Der Benutzer öffnet dann das Dokument, das das (schädliche) 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-Laufzeit einen Kreispuffer, 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 (auch als Trigger bezeichnet) 2 angesehen [ ] werden, wird die Makroausführung angehalten, und der Inhalt des Kreispuffers wird an AMSI übergeben.
- Der registrierte AMSI-Antimalware-Dienstanbieter antwortet mit einem Diktat, um anzugeben, ob das Makroverhalten schädlich ist.
- Wenn das Verhalten nicht böswillig ist, wird die Makroausführung fortgesetzt.
- Andernfalls schließt Microsoft Office die Sitzung als Reaktion auf warnung [ 3, und der AV kann die Datei unter Quarantäne stellen, wenn das Verhalten schädlich ] ist.
Was bedeutet dies für Sie?
Für Windows Benutzer wird jede Schadsoftware, die Verschleierungs- und Abwehrtechniken auf den integrierten Skripthosts von Windows 10 verwendet, automatisch auf einer wesentlich tieferen Ebene als je zuvor überprüft und bietet zusätzliche Schutzebenen.
Ziehen Sie für Sie als Anwendungsentwickler in Betracht, 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 erwägen, Unterstützung für die AMSI-Schnittstelle zu implementieren. Wenn Sie dies tun, erhält Ihre Engine viel tiefere Einblicke in die Daten, die Anwendungen (einschließlich der integrierten Skripthosts von Windows 10) als potenziell schädlich betrachten.
Weitere Hintergrundinformationen zu dateilosen Bedrohungen
Möglicherweise möchten Sie mehr Hintergrundinformationen zu den Arten von dateilosen Bedrohungen erhalten, die Windows AMSI ihnen helfen soll, sich dagegen zu schützen. In diesem Abschnitt werfen wir einen Blick auf das herkömmliche Katzen- und Mausspiel, das im Malwareökosystem vorkommt.
Wir verwenden PowerShell als Beispiel. Sie können jedoch die gleichen Techniken und Prozesse nutzen, die wir mit jeder dynamischen Sprache — VBScript, Perl, Python, Ruby und mehr veranschaulichen.
Hier ist ein Beispiel für ein schädliches PowerShell-Skript.

Während dieses Skript einfach eine Nachricht auf den Bildschirm schreibt, ist Schadsoftware in der Regel schädlicher. Sie können jedoch problemlos eine Signatur schreiben, um diese zu erkennen. Beispielsweise könnte die Signatur nach der Zeichenfolge "Write-Host 'pwnd!' suchen." in einer beliebigen Datei, die der Benutzer öffnet. Toll: Wir haben unsere erste Schadsoftware erkannt!
Nach der Erkennung durch unsere erste Signatur reagieren Malwareautoren jedoch. Sie reagieren, indem sie dynamische Skripts wie dieses Beispiel erstellen.

In diesem Szenario erstellen Autoren von Schadsoftware 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 werbeladenen Webseite anzeigen, werden Sie feststellen, dass viele Instanzen dieser Technik verwendet werden, um Werbeblockierungssoftware zu vermeiden.
Schließlich übergibt der Schadsoftwareautor diese verkettete Zeichenfolge an den Invoke-Expression — PowerShell-Mechanismus des Cmdlets, um Skripts auszuwerten, die zur Laufzeit erstellt oder erstellt werden.
Als Reaktion darauf beginnt die 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 recht anfälliger Ansatz, da Sprachen in der Regel viele Möglichkeiten haben, Zeichenfolgen darzustellen und zu verketten.
Nachdem sie von dieser Signatur abgefangen wurden, wechseln Autoren von Schadsoftware zu etwas Komplizierteren, z. B. zum Codieren von — Skriptinhalten in Base64, wie in diesem nächsten Beispiel.

Da die meisten Antischadsoftware-Engines ressourcenreich sind, implementieren sie auch die Base64-Decodierungsemulation. Da wir also auch die Base64-Decodierungsemulation implementieren, sind wir eine Weile weiter.
Als Reaktion darauf wechseln Autoren von Schadsoftware zu algorithmischer Verschleierung, — z. B. zu einem einfachen XOR-Codierungsmechanismus in den skripts, die sie ausführen.

An diesem Punkt wird im Allgemeinen nicht erkannt, welche Antiviren-Engines emuliert oder erkannt werden, sodass wir nicht unbedingt erkennen, was dieses Skript tut. Wir können jedoch damit beginnen, Signaturen für die Verschleierungs- und Codierungstechniken zu schreiben. Tatsächlich ist dies der Grund für den Großteil der Signaturen für skriptbasierte Schadsoftware.
Aber was geschieht, wenn der Obfuscator so trivial ist, dass er wie viele gut verhaltende Skripts aussieht? Eine Signatur dafür würde eine unzulässige Anzahl falsch positiver Ergebnisse generieren. Hier ist ein Beispiel-Stagerskript, das zu gut für die Erkennung ist.

In diesem Beispiel laden wir eine Webseite herunter und laden inhalte davon auf. Dies ist die Entsprechung in Visual Basic Skript.

Erschwerend kommt in beiden Beispielen hinzu, dass die Antiviren-Engine Dateien untersucht, die vom Benutzer geöffnet werden. Wenn sich der schädliche Inhalt nur im Arbeitsspeicher befindet, kann der Angriff möglicherweise nicht erkannt werden.
In diesem Abschnitt wurden die Einschränkungen bei der Erkennung mit herkömmlichen Signaturen erläutert. Obwohl ein schädliches Skript mehrere Durchläufe der Entleerung durchlaufen kann, muss es letztendlich die Skript-Engine mit einfachem, unauffälligem 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, wie im ersten Abschnitt oben beschrieben. Und Ihre Anwendung kann dasselbe tun.