Trojaner: Forscher warnen vor Missbrauch des AWS SSM-Agent

Foto: rafapress – shutterstock.com

Cyberkriminelle gehen immer mehr dazu über, bereits vorhandene Dienstprogramme selbst zu hacken statt auf maßgeschneiderte, automatisierte Malware zu setzen. Dieser als “living of the land” bekannte Ansatz erstreckt sich auch auf Cloud-Infrastrukturen. Angreifer nehmen Dienste und Tools ins Visier, die Cloud-Anbieter als Teil ihres Ökosystems zur Verfügung stellen.

Forscher der Incident-Response-Firma Mitiga haben kürzlich gezeigt, wie der AWS Systems Manager (SSM) Agent von Angreifern gekapert und in einen Remote-Access-Trojaner (RAT) verwandelt werden kann. Der SSM-Agent ermöglicht es AWS-Kunden auf EC2-Instanzen (virtuelle Server in der Amazon Elastic Compute Cloud), lokale Server sowie virtuelle Maschinen in anderen Clouds zuzugreifen, um sie über den AWS-System-Manager remote zu verwalten und zu steuern.

Das Konzept ist laut den Mitiga-Forschern einfach: Habe ein Angreifer Zugriff auf einen Endpunkt erlangt, auf dem bereits ein SSM-Agent installiert ist, könne dieser ausgenutzt werden, um den Endpunkt zu kontrollieren und ihn zu einem RAT verwandeln. Dazu müsse der Eindringling vorher keine Backdoor ausnutzten oder einen RAT hochladen.

“Indem sie Befehle von einem separaten, böswilligen AWS-Konto ausführen, bleiben die vom SSM-Agenten durchgeführten Aktionen im ursprünglichen AWS-Konto verborgen und hinterlassen keine Spuren des Eindringens, ” heißt es in dem Bericht.

Die Vorteile des Hijackings eines SSM-Agenten

Der SSM-Agent ist ein leistungsfähiges Tool, das die Remote-Ausführung von Befehlen und das Sammeln von Daten über den Computer ermöglicht, ähnlich wie ein Trojaner. Der Unterschied besteht darin, dass der SSM-Agent quelloffen ist, von Amazon entwickelt und digital signiert wurde. Er ist auf vielen Amazon Machine Images (AMIs) vorinstalliert, die Kunden auf ihren EC2-Instanzen wie Amazon Linux, SUSE Linux Enterprise, macOS und Windows Server einsetzen können. Das Tool ist auch in einigen System-Images enthalten, die von Drittanbietern auf dem AWS Marketplace bereitgestellt oder von der Community entwickelt werden.

Der größte Vorteil für Angreifer besteht darin, dass der SSM-Agent bereits auf der Whitelist vieler Endpoint Detection and Response (EDR)- oder Antivirenlösungen steht, die wahrscheinlich auf einem von AWS verwalteten Server eingesetzt werden. Keine einzige von 71 Antiviren-Engines des von Google betriebenen Online-Dienstes VirusTotal stuften die Binärdatei als bösartig ein.

Zudem kann der SSM-Agent so konfiguriert werden, dass er mit einem bestimmten Amazon AWS-Konto kommuniziert. Dadurch bietet er Angreifern eine einfache Befehls- und Steuerungsoption, ohne dass sie eine zusätzliche Infrastruktur entwickeln oder bereitstellen müssen, die normalerweise zum Hosten eines RAT-Kontrollfelds erforderlich wäre. Alles, was sie brauchen, ist ein AWS-Konto.

Eine Parallele wäre die PowerShell-Schnittstelle, die in Windows integriert und für die Automatisierung von Verwaltungsaufgaben konzipiert ist. Da PowerShell so leistungsfähig ist und über eine eigene Skriptsprache verfügt, wurde sie im Laufe der Jahre von sehr vielen Angreifern übernommen, was Microsoft dazu zwang, immer mehr Warnungen, Schutzmaßnahmen und Sicherheitskennzeichen hinzuzufügen. Dennoch gibt es immer noch ganze Post-Exploitation- und Lateral-Movement-Frameworks, die in PowerShell geschrieben sind, sowie Open-Source-Malware.

Ausführen mehrerer SSM-Agent-Instanzen

Die Idee, den SSM-Agenten als Trojaner oder Hintertür zu verwenden, ist nicht neu. Andere Cloud-Ingenieure und Sicherheitsforscher haben bereits vor diesem Missbrauchspotenzial gewarnt. Mitiga ging jedoch noch einen Schritt weiter und zeigte, wie man den Agenten auf subtilere Weise und sogar ohne Root-Zugriff missbrauchen kann.

Der direkteste Weg, den SSM-Agenten in einem Szenario nach der Kompromittierung zu missbrauchen, in dem der Angreifer bereits über Root- oder Administratorrechte auf dem Rechner verfügt, besteht darin, den Dienst zu stoppen und ihn mit einem neuen Aktivierungscode zu starten. Dabei wird das vom Angreifer kontrollierte AWS-Konto verknüpft und sein Hybridmodus aktiviert. In diesem Modus richtet der Agent einen Persistenzmechanismus ein, der es ihm ermöglicht, beim Neustart des Systems erneut zu starten.

Das Problem bei diesem Ansatz ist, dass der Besitzer des Kontos, unter dem die kompromittierte EC2-Instanz läuft, sofort merkt, dass etwas nicht stimmt, da er den SSM-Zugriff auf diese Maschine unter seinem eigenen Konto verliert, sobald der Agent gekapert wurde.

Um dieses Problem zu lösen, suchte Mitigate nach Möglichkeiten, den ursprünglichen Agenten unangetastet zu lassen und eine zweite Instanz auszuführen, die abtrünnig ist und sich mit dem Konto des Angreifers verbindet. Obwohl der Agent so konzipiert ist, dass er nicht ausgeführt werden kann, wenn bereits ein SSM-Agent-Prozess vorhanden ist, kann dies auf mehrere Arten umgangen werden: durch Ausnutzung der Linux-Namespaces-Funktion, um den Agenten in einem anderen Namespace auszuführen, oder durch Aktivierung des “Container”-Modus für die zweite Agenteninstanz, der keine Root-Rechte erfordert. Der Containermodus ist eingeschränkt, da er nicht über das RunCommand-Modul verfügt, aber er ermöglicht es Angreifern, eine Remote-Sitzung zu öffnen, um auf den Rechner zuzugreifen.

Bereitstellen eines zweiten SSM-Agentenprozesses

Auf Windows-Rechnern gelang es den Forschern, einen zweiten SSM-Agentenprozess zu starten, indem sie bestimmte Umgebungsvariablen so konfigurierten, dass die Konfiguration an einem anderen Ort abgelegt wurde.

Ironischerweise besteht eine Möglichkeit, eine zweite SSM-Agenteninstanz bereitzustellen, ohne über Root-Rechte auf dem Rechner selbst zu verfügen. Die darin vorhandene SSM-Instanz lässt sich verwenden, um Befehle zum Einrichten der zweiten Instanz zu erteilen, da der Agent bereits mit hohen Rechten läuft. Dies erfordert Zugriff auf das AWS-Konto des Opfers, das bereits für die Verwaltung der Maschine über SSM verwendet wird.

Da ein AWS-Konto zur Steuerung eines gekaperten SSM-Agenten erforderlich ist, ist diese Methode allerdings nicht für alle Angreifer attraktiv. Das Problem: Wenn sie dasselbe Konto zur Steuerung mehrerer Rechner verschiedener Opfer verwenden, braucht nur einer von ihnen die Kompromittierung zu entdecken und AWS zu melden, und das Konto wird gesperrt.

Es stellte sich heraus, dass der SSM-Agent über zwei Konfigurationsoptionen namens http_proxy und https_proxy verfügt. Sie können verwendet werden, um den Datenverkehr des SSM-Agenten an eine vom Angreifer kontrollierte IP-Adresse statt an eine Amazon-Adresse zu leiten. Die Mitiga-Forscher waren in der Lage, einen Mock-Server zu erstellen, den ein Angreifer auf seiner Seite laufen lassen konnte, um die RunCommand-Funktion zu nutzen, ohne sich tatsächlich auf den AWS SSM-Service zu verlassen.

Erkennen und Verhindern von Angriffen durch den SSM-Agenten

Die Forscher haben einige Indikatoren für eine Kompromittierung veröffentlicht, anhand derer sich erkennen lässt, ob zwei SSM-Agent-Instanzen ausgeführt werden. So heißt es zum Beispiel: Wenn mehr als ein Verzeichnis mit einem anderen Instanznamen als der ursprünglichen Instanz-ID zu sehen ist, ist das verdächtig.

Sie empfehlen außerdem, den SSM-Agenten aus der Zulässigkeitsliste einer Antiviren- oder EDR-Lösung zu entfernen, damit sie sein Verhalten scannen und ihrer SIEM-Lösung (Security Information and Event Management) Erkennungstechniken für ein solches Hijacking hinzufügen können.

“Das AWS-Sicherheitsteam bot eine Lösung an, um den Empfang von Befehlen vom ursprünglichen AWS-Konto beziehungsweise der ursprünglichen AWS-Organisation einzuschränken, indem der VPC-Endpunkt (Virtual Private Cloud) für Systems Manager verwendet wird”, so die Forscher. “Wenn sich Ihre EC2-Instanzen in einem privaten Subnetz ohne Zugang zum öffentlichen Netzwerk über eine öffentliche IP-Adresse oder einen NAT-Gateway befinden, können Sie den System Manager-Service dennoch über einen VPC-Endpunkt konfigurieren. “Auf diese Weise werde sichergestellt, dass die EC2-Instances nur auf Befehle reagieren, die von Auftraggebern innerhalb ihres ursprünglichen AWS-Kontos oder ihrer Organisation stammen. Um diese Einschränkung effektiv zu implementieren, empfehlen die Experten, die Dokumentation zur VPC-Endpunkt-Richtlinie zu lesen. (jm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.