Eine kompromittierte EC2-Instance unter Quarantäne stellen

Wenn GuardDuty oder Ihre Überwachung zeigt, dass eine EC2-Instance bösartige ausgehende Verbindungen herstellt, Kryptowährungen schürft oder Ihr Netzwerk scannt, muss sie isoliert werden.

Die Quarantäne isoliert die Instance von allem anderen, sodass sie keinen weiteren Schaden anrichten kann. Gleichzeitig bleibt sie für die Untersuchung aktiv, anstatt dass Beweismaterial gelöscht wird.

Die sauberste Quarantänemaßnahme besteht darin, die Security Groups der Instance durch eine einzige forensische Gruppe zu ersetzen, die keine eingehenden Regeln und idealerweise auch keine ausgehenden Regeln besitzt.

Da Security Groups zustandsbehaftet und an die Instance gebunden sind, werden dadurch praktisch alle neuen Verbindungen sofort unterbrochen, ohne andere Ressourcen im Subnetz zu beeinflussen.

Beim Stoppen oder Beenden der Instance wird der Arbeitsspeicher geleert, in dem sich ein großer Teil der Malware befinden kann. Außerdem können dabei Spuren des Angreifers zerstört werden.

Bei der Quarantäne bleibt die Instance aktiv, aber isoliert, sodass Sie den Datenträger als Snapshot sichern, den Arbeitsspeicher auslesen und das Verhalten beobachten können. Erst wenn die Beweise sicher erfasst wurden, beseitigen Sie die Bedrohung.

Eine kompromittierte Instance besitzt häufig über ihr Instance Profile eine IAM-Rolle. Der Angreifer kann diese temporären Zugangsdaten möglicherweise ausleiten und an anderer Stelle verwenden.

Ersetzen oder entfernen Sie die Rolle und widerrufen Sie aktive Sitzungen, damit die gestohlenen Zugangsdaten für alle AWS-Services ungültig werden, nicht nur auf der Instance selbst.

Erstellen Sie sofort von jedem angeschlossenen EBS-Volume einen Snapshot, um den Datenträger einzufrieren, und sichern Sie den Arbeitsspeicher, sofern Ihre Werkzeuge dies ermöglichen.

Markieren Sie diese Artefakte als Quarantänebeweise. Wenn Sie Kopien der Snapshots schreibgeschützt auf einer separaten forensischen Instance einbinden, können Sie Untersuchungen durchführen, ohne die Originale zu verändern oder eine erneute Infektion zu riskieren.

Als zusätzliche Schutzschicht können Sie in der Network ACL des Subnetzes eine Verweigerungsregel für die private IP-Adresse der Instance hinzufügen.

NACLs sind zustandslos und gelten an der Grenze des Subnetzes. Dadurch fangen sie jeden Pfad ab, den eine Änderung der Security Group möglicherweise nicht erfasst. Verwenden Sie sie als zusätzliche Absicherung, nicht als primäre Kontrolle.

Wenn sich die Instance hinter einem Elastic Load Balancer oder in einer Auto Scaling-Gruppe befindet, deregistrieren Sie sie, damit kein Traffic mehr an sie weitergeleitet wird.

Versetzen Sie die Auto Scaling-Instance in den Standby-Zustand oder trennen Sie sie, damit die Gruppe Ihre Beweise nicht zerstört, indem sie den vermeintlich fehlerhaften Host ersetzt.

Bei großer Umgebung sind manuelle Schritte zu langsam. Ein gängiges Muster ist: GuardDuty-Finding zu einer EventBridge-Regel zu Lambda, wobei die Security Group ausgetauscht, ein Snapshot der Volumes erstellt, die Rolle entfernt und die Instance markiert wird.

So wird aus einer mehrstufigen Reaktion eine einzige automatisierte Aktion, die innerhalb von Sekunden nach der Erkennung ausgelöst wird.

Die Quarantäne verschafft Ihnen Zeit, um zu klären, wie der Angreifer eingedrungen ist. Prüfen Sie CloudTrail, VPC Flow Logs und Logs auf dem Host, um den Einstiegspunkt zu finden – etwa einen offenen Port, eine ungepatchte Schwachstelle oder ein gestohlenes Zugangstoken.

Ohne Kenntnis der Ursache kann eine neu erstellte Instance auf genau dieselbe Weise kompromittiert werden.

Nachdem die Beweise gesichert und die Ursache verstanden wurde, ersetzen Sie die Instance durch eine saubere, gepatchte AMI, anstatt die infizierte Instance zu bereinigen.

Nur selten lässt sich garantieren, dass eine Backdoor vollständig entfernt wurde. Eine erneute Bereitstellung aus einem vertrauenswürdigen Image ist schneller und wesentlich zuverlässiger als das Bereinigen eines kompromittierten Hosts.

Versehen Sie die unter Quarantäne stehende Instance und ihre Snapshots mit eindeutigen Tags wie Status=Quarantine und der Incident-ID, damit keine Automatisierung und kein Bediener sie versehentlich wieder in Betrieb nimmt oder die Beweise löscht.

Verfolgen Sie sie bis zum Abschluss in Ihrem Incident-Datensatz und bestätigen Sie sowohl, dass die Bedrohung eingedämmt wurde, als auch, dass die forensischen Artefakte erhalten bleiben.

Wählen Sie den richtigen Schritt für Zugangsdaten.

Isolieren Sie eine kompromittierte EC2-Instance, indem Sie eine Security Group einsetzen, die sämtlichen Traffic verweigert, und lassen Sie sie dabei aktiv. Erstellen Sie anschließend Snapshots der EBS-Volumes und sichern Sie den Arbeitsspeicher, bevor Sie Änderungen vornehmen. Entfernen Sie die Rolle des Instance-Profils und widerrufen Sie aktive Sitzungen, damit gestohlene Zugangsdaten ungültig werden. Trennen Sie die Instance von Load Balancern und Auto Scaling und fügen Sie eine NACL-Absicherung hinzu. Automatisieren Sie den gesamten Ablauf ausgehend von GuardDuty, untersuchen Sie die Ursache und erstellen Sie die Instance aus einer vertrauenswürdigen AMI neu.