Ihr Backup ist nicht unabhängig, wenn dieselbe Identität es löschen kann

Ein Angreifer versuchte innerhalb von sieben Minuten, mehr als 100 Azure Storage Accounts zu löschen. Er löschte zudem einen Key Vault, eine Function App und einen App Service Plan. Auch Schutzsperren von Azure Site Recovery und Azure Backup wurden angegriffen. Einige Löschversuche scheiterten an vorhandenen Schutzmechanismen. Viele Storage Accounts wurden jedoch gelöscht.

Der von Microsoft als Storm-3168 bezeichnete Angreifer brauchte dafür kein kompromittiertes Administratorkonto. Er nutzte zwei Service Principals, also technische Identitäten, mit denen Anwendungen auf Azure-Ressourcen zugreifen. Eine dieser Identitäten verfügte bereits über die notwendigen Rollen. Der Angriff missbrauchte somit keine unbekannte Superkraft. Er nutzte Berechtigungen, die das Unternehmen selbst vergeben hatte.

Für den CISO liegt genau dort das Problem. Ein Backup kann technisch funktionieren und trotzdem keine unabhängige Wiederanlaufoption sein. Wenn eine kompromittierte Workload-Identität Produktivdaten, Schlüssel und Schutzmechanismen der Recovery-Ebene erreicht, teilt die Wiederherstellung den Vertrauensbruch des laufenden Betriebs.

Der blinde Fleck trägt keinen Benutzernamen

Service Principals melden keine verdächtige Reise, vergessen kein Passwort und reagieren auf keine Phishing-Schulung. Sie arbeiten im Hintergrund, oft über Jahre. Ihre Rechte wachsen mit neuen Anwendungen, Automatisierungen und Projekten. Was für einen Menschen als übermächtige Rolle auffallen würde, bleibt bei einer technischen Identität leicht als betriebliche Notwendigkeit bestehen.

Microsoft beobachtete in der betroffenen Azure-Umgebung zwei kompromittierte Service Principals. Einer führte über mehr als 15 Stunden mehr als 300 erfolgreiche Leseoperationen aus und kartierte die Umgebung. Der zweite begann später mit der Zerstörung und dem Sammeln weiterer Zugangsmöglichkeiten. In 35 Minuten verzeichnete Microsoft mehr als 150 destruktive oder auf Zugangsdaten gerichtete Operationen. Wie die erste Identität tatsächlich kompromittiert wurde, ist nicht abschliessend geklärt. Microsoft fand jedoch Client-ID, Tenant-ID und ein Secret in der Versionshistorie eines öffentlichen GitHub-Issues. Ob genau dieses Secret verwendet wurde, konnte Microsoft nicht bestätigen. Der Befund zeigt dennoch eine häufige Fehlannahme: Ein gelöschtes Secret ist nicht widerrufen. Solange es gültig bleibt, können Kopien in Historien, Caches oder Logs weiter funktionieren.

Das Backup war erreichbar, bevor der Krisenstab zusammentrat

Die öffentliche Diskussion konzentriert sich auf den Begriff «agentischer Angriff». Microsoft ordnet die Aktivität JADEPUFFER zu und beschreibt die Abläufe als stark automatisiert oder geskriptet. Für die Risikobeurteilung ist jedoch nicht entscheidend, ob jeder Schritt durch künstliche Intelligenz geplant wurde. Entscheidend ist die Geschwindigkeit, mit der eine berechtigte Maschinenidentität eine ganze Cloud-Umgebung verändern konnte.

Die produktiven Ressourcen waren nicht das Ende des Angriffswegs. Der Service Principal versuchte auch, Schutzsperren von Azure Site Recovery und Azure Backup zu löschen. Rund 30 Minuten nach der zerstörerischen Sequenz rief er zudem erfolgreich Schlüssel von mehr als 30 Storage Accounts ab, darunter Konten im Umfeld von Azure Site Recovery. Eine bestätigte Datenexfiltration oder Lösegeldforderung nennt Microsoft nicht.

Damit ist nicht belegt, dass die Wiederherstellung im untersuchten Fall vollständig zerstört wurde. Belegt ist etwas anderes: Der Angreifer konnte die Recovery-Ebene mit derselben kompromittierten Identität erreichen. Ein Restore-Plan, der auf unveränderte Schlüssel, vertrauenswürdige Automatisierung und eine intakte Verwaltungsumgebung angewiesen ist, wird unter diesen Bedingungen selbst zum Untersuchungsgegenstand.

Damit ändert sich auch die Reihenfolge im Incident Response. Bevor aus einem Backup wiederhergestellt wird, muss geklärt sein, ob die dafür benötigten Identitäten, Schlüssel und Steuerungswege noch vertrauenswürdig sind. Sonst kann ein technisch erfolgreicher Restore dieselbe kompromittierte Vertrauenskette erneut in Betrieb nehmen.

Unabhängigkeit ist eine Eigenschaft der Kontrolle

Die Frage «Haben wir ein Backup?» reicht deshalb nicht. Der CISO muss wissen, welche Identität kritische Produktionsressourcen löschen kann und ob dieselbe Berechtigung auch Backup-Schutz, Schlüssel oder Wiederanlaufautomatisierung verändert. Dieser Nachweis darf sich nicht auf Rollenbezeichnungen beschränken. Entscheidend sind die tatsächlich wirksamen Rechte über Gruppen, Abonnemente und geerbte Zuweisungen hinweg.

Microsoft empfiehlt für Azure Backup unter anderem gesperrte Unveränderbarkeit und eine Mehrpersonenautorisierung über Resource Guard. Für eine stärkere Trennung kann Resource Guard in einem anderen Tenant liegen. Dann genügt eine kompromittierte Identität aus dem produktiven Tenant nicht, um geschützte kritische Operationen freizugeben. Das ist kein vollständiger Schutz gegen jeden Angriff. Es schafft aber eine Kontrolle, die nicht automatisch mit derselben Vertrauenskette fällt.

Der zweite Nachweis entsteht erst beim Wiederanlauftest. Ein Restore in eine isolierte Umgebung muss mit Notfallidentitäten funktionieren, die nicht von den möglicherweise kompromittierten Produktivzugängen abhängen. Dabei ist zu prüfen, ob Schlüssel verfügbar und vertrauenswürdig sind, ob die wiederhergestellten Daten einen definierten Zeitpunkt abbilden und ob die notwendige Steuerung auch dann funktioniert, wenn der primäre Tenant als unsicher behandelt wird.

Der Entscheid des CISO

Storm-3168 macht aus der Verwaltung technischer Identitäten eine Frage der Cyberresilienz. Lang laufende Secrets müssen aus Quellcode, Tickets und Konfigurationen verschwinden oder nach einer Offenlegung sofort widerrufen werden. Breite Rollen für Service Principals brauchen eine fachliche Begründung, eine kurze Lebensdauer und eine Überwachung, die ungewöhnliche Inventarisierung, massenhafte Löschungen und Schlüsselabrufe nicht als normale Automatisierung hinnimmt.

Der notwendige Entscheid lautet nicht, ob noch ein weiteres Backup erstellt wird. Zu entscheiden ist, welche Wiederanlaufkontrolle ausserhalb der Reichweite einer kompromittierten Produktionsidentität liegen muss. Kann diese Trennung nicht nachgewiesen werden, ist das Restrisiko bekannt: Die Organisation besitzt Sicherungskopien, aber möglicherweise keinen vertrauenswürdigen Weg zurück in den Betrieb. Ein Backup schützt Daten nur so lange, wie der Angreifer seine Schutzmechanismen nicht beherrscht. Unabhängige Wiederherstellung beginnt deshalb nicht beim Speichermedium. Sie beginnt bei der Identität, die es gerade nicht löschen darf.

Quellen

• Microsoft Security Research: Storm-3168 und kompromittierte Service Principals
• Microsoft Learn: Sicherheitspraktiken für Azure Backup
• Microsoft Learn: Mehrpersonenautorisierung mit Resource Guard
• The Hacker News: unabhängige Einordnung der Angriffskette