Microsoft hat gezeigt, dass die Kompromittierung einer einzigen Identität zu einem weitreichenden Zugangsweg in Entwicklungs- und Cloud-Umgebungen werden kann, selbst ohne den Einsatz von Schadsoftware oder die Ausnutzung von Schwachstellen. In einem neuen Bericht der Reihe Cyberattack Series dokumentierte das Microsoft Detection and Response Team (DART), wie sich die Gruppe Storm-3068 von einem kompromittierten Konto zu Azure DevOps, Entwicklungspipelines und Kubernetes-Ressourcen bewegte.
Der Eindringversuch begann mit einem Verfahren zur selbstständigen Zurücksetzung des Passworts. Nachdem der Angreifer Zugriff auf das Benutzerkonto erlangt hatte, registrierte er eigene Authentifizierungsmethoden und erhielt dadurch dauerhaften Zugriff auf die Identität. Anschließend nutzte er legitime Verwaltungstools und automatisierte Skripte, um Repositories, Projekte, Pipelines und Bereitstellungsumgebungen in Azure DevOps zu erfassen.
Von der Identität zu den Bereitstellungspfaden
Azure DevOps war ein besonders wertvoller Punkt, da die Plattform Identität, Softwareentwicklung und Cloud-Betrieb miteinander verbindet. Durch die Kartierung der Bereitstellungspfade und der damit verbundenen Ressourcen identifizierte Storm-3068 Wege, um in andere Teile der Umgebung vorzudringen.
Die Ermittler entdeckten eine bösartige Pipeline, die darauf ausgelegt war, Kubernetes-Zugangsdaten in großem Umfang zu sammeln. Die Pipeline stellte einen Kubernetes-Agenten bereit und führte mehrere Aufgaben aus, um kubeconfig-Dateien zu sammeln, die Verbindungsdetails zu Clustern und Authentifizierungsdaten enthielten. Dank der Berechtigungen des kompromittierten Kontos war die Pipeline zum Zugriff auf mehr als 50 Ressourcen und zur Authentifizierung bei verschiedenen Diensten berechtigt.
Außerdem wurden Skripte der Pipelines so verändert, dass der Fernverwaltungsagent Atera installiert und das Tunneling-Tool Chisel heruntergeladen wurde. Chisel-Befehle wurden verwendet, um einen Reverse-Tunnel zu einer externen IP-Adresse einzurichten, wodurch eine mögliche Ferninteraktion mit Kubernetes-Clustern ermöglicht wurde. Das Untersuchungsteam rekonstruierte die nächste Phase des Angriffs anhand von Azure-DevOps-Auditprotokollen und der Git-Versionshistorie, in der sieben gestohlene kubeconfig-Dateien in ein Repository eingefügt worden waren.
Was zeigt der Fall den Verteidigern?
Die Bedeutung des Vorfalls liegt darin, dass der erste Angriffspunkt allein nicht ausreichte, um das Ausmaß des letztendlichen Zugriffs zu erklären. Das Risiko entstand aus der Vernetzung von Identitätssystemen, Repositories, Build- und Bereitstellungspipelines sowie der Betriebsinfrastruktur. Daher gewährleistet die Absicherung jeder einzelnen Schicht für sich genommen keine Eindämmung eines kompromittierten Kontos, wenn dessen Berechtigungen vertrauenswürdige Wege zu nachgelagerten Schichten öffnen.
DART reagierte mit der Analyse von Daten aus Identitätssystemen, Entwicklungsplattformen und der Cloud-Infrastruktur und arbeitete mit dem Kunden durch tägliche Lagebesprechungen sowie nach Priorität geordnete Anweisungen zur Eindämmung und Behebung zusammen. Außerdem kooperierte das Team mit Microsoft Threat Intelligence, um die Aktivitäten in ihren größeren Kontext einzuordnen.
Praktische Abwehrmaßnahmen
- Überwachung von Aktivitäten zur Zurücksetzung von Passwörtern auf wiederholte Versuche oder Muster, die mehrere Benutzer betreffen.
- Verringerung der Aussetzung privilegierter Konten gegenüber Wegen zur selbstständigen Zurücksetzung und Durchsetzung einer phishingresistenten Multi-Faktor-Authentifizierung.
- Genehmigungspflicht für Codeänderungen und Aktivierung des Branch-Schutzes, um nicht autorisierte Änderungen zu verhindern.
- Direkte Commits in kritische Branches beschränken und für Änderungen eine klare Prüfung und Genehmigung vorschreiben.
- Berechtigungen für Build- und Bereitstellungspipelines kontrollieren und festlegen, wer sie erstellen, ändern oder ausführen darf.
- Das Prinzip der geringsten Privilegien auf Identitäten, Entwicklungsplattformen und Cloud-Ressourcen anwenden, um die Auswirkungen der Kompromittierung eines einzelnen Kontos zu begrenzen.
Warum ist diese Nachricht wichtig?
Dieser Fall zeigt, dass Identitäts-, Azure-DevOps-, Git- und Kubernetes-Protokolle als ein zusammenhängendes Sicherheitsbild gelesen werden müssen, nicht als getrennte Quellen. Die offenen Fragen, die die Quelle aufzeigt, betreffen die Fähigkeit von Organisationen, den Missbrauch legitimer Tools zu erkennen, umgebungsübergreifende Berechtigungen zu überprüfen und das Durchsickern von Zugangsdaten in Repositories zu verhindern, bevor diese für den Zugriff auf die Produktionsumgebung genutzt werden.