Non-Human Identities: Der blinde Fleck der Cloud-Forensik
16.07.2026 cloud-forensiknon-human-identityservice-accountsapi-security
Während Sicherheitsteams jahrelang menschliche Logins, MFA-Umgehungen und Session-Cookies im Blick hatten, hat sich der eigentliche Schwerpunkt verschoben: Maschinenidentitäten – Service-Accounts, API-Keys, OAuth-Tokens, CI/CD-Credentials und zunehmend auch KI-Agenten – sind zur häufigsten und am schlechtesten überwachten Angriffsfläche in Cloud-Umgebungen geworden.
Ein Fallbeispiel: Wie ein CI/CD-Token zur Waffe wurde
Google Threat Intelligence dokumentiert im aktuellen Cloud Threat Horizons Report einen Fall der nordkoreanischen Gruppe UNC4899, der die Dimension des Problems greifbar macht. In den nächsten Phasen pivotierte UNC4899 zur Cloud-Umgebung, führte Aufklärungsaktivitäten durch, darunter die Erforschung bestimmter Pods im Kubernetes-Cluster, etablierte Persistenz und erlangte ein Token für ein hochprivilegiertes CI/CD-Service-Account. Dies ermöglichte es ihnen, sich lateral zu sensibleren Systemen zu bewegen, etwa zu einem Pod, der Netzwerkrichtlinien durchsetzt, wodurch sie aus dem Container ausbrechen und eine Backdoor platzieren konnten. Anschließend bewegte sich der Angreifer zu einem System, das Kundendaten verwaltete (Identitäten, Kontosicherheit, Kryptowährungs-Wallet-Daten) und Datenbank-Credentials unsicher gespeichert hatte.
Das Besondere aus forensischer Sicht: forensische Analysen deuten darauf hin, dass dieser Zugriff nicht notwendigerweise durch einen Kernel-Exploit erreicht wurde – stattdessen imitierte UNC4899 den Effekt eines Host-Level-Escapes, indem Cluster-Admin-Rechte missbraucht wurden, um Node-Level-Dienste zu untersuchen. Die Akteure nutzten diesen Zugriff, um eine Backdoor für persistenten Zugang zu platzieren und das Ablauffenster des Service-Account-Tokens zu umgehen. Kein Exploit-Alarm, kein Malware-Signatur-Treffer – nur ein gestohlenes Token, das genau das tat, wofür es vorgesehen war: authentifizieren.
Warum die Beweislage bei Maschinenidentitäten anders aussieht
Aktuelle Zahlen zeigen das Ausmaß: SpyCloud erfasste 2025 rund 18,1 Millionen offengelegte API-Keys und Tokens, verteilt über Zahlungsplattformen, Cloud-Infrastruktur-Anbieter, Entwickler-Ökosysteme, Kollaborationstools und KI-Dienste. Der Report identifizierte zudem 6,2 Millionen Credentials oder Authentifizierungs-Cookies, die mit KI-Tools verknüpft sind. Das Kernproblem für Forensiker: im Gegensatz zu menschlichen Credentials fehlt bei diesen NHIs oft eine MFA-Durchsetzung, sie werden selten rotiert und operieren mit breiten Berechtigungen. Werden sie offengelegt, können sie Angreifern persistenten Zugriff auf Produktionssysteme, Software-Lieferketten und Cloud-Infrastruktur verschaffen.
Das größte forensische Ärgernis ist aber die Attribution. Ein geteiltes Service-Account-Credential erzeugt in Audit-Logs stets denselben Principal-Namen – unabhängig davon, welcher Mensch, welche Pipeline oder welcher KI-Agent tatsächlich gehandelt hat. Wie ein Anbieter treffend formuliert: Welcher Agent hat die Tabelle gelöscht? Audit und Forensik werden blind, sobald eine Identität geteilt wird. Selbst die Herkunft eines Keys lässt sich oft nicht vollständig rekonstruieren: es gibt keine Möglichkeit zu wissen, wer Zugriff auf einen Key hat. Nutzer könnten ihn herunterladen und mit anderen teilen – etwas, das man nicht nachverfolgen kann.
Immerhin bieten moderne Cloud-Plattformen bei Workload Identity Federation granularere Spuren: In GCP etwa folgen die resultierenden Logs derselben Struktur wie andere Workload-Identity-Flows – das impersonierte GCP-Service-Account erscheint im principalEmail-Feld, während die ursprüngliche Kubernetes-Identität im serviceAccountDelegationInfo.principalSubject-Feld erfasst wird, das den Namespace und Service-Account-Namen enthält und es ermöglicht, genau zu bestimmen, welches Kubernetes-Service-Account die Anfrage ausgelöst hat. Diese Delegationsketten sind aber nur nutzbar, wenn die entsprechenden Audit-Logs überhaupt aktiviert sind und langfristig zentral gesammelt werden.
Konsequenzen für die Praxis
Für IR-Teams bedeutet das: Ein Incident-Response-Playbook, das nur menschliche Logins abdeckt, deckt heute nur einen Teil der Angriffsfläche ab. Wer Maschinenidentitäten forensisch nachvollziehbar machen will, sollte konsequent auf kurzlebige Tokens statt statischer Keys setzen, Delegationsketten und Workload-Identity-Föderation aktiv protokollieren sowie zentrale, tamper-resistente Audit-Log-Pipelines etablieren, statt sich auf provider-native Standardeinstellungen zu verlassen. Der Fall UNC4899 zeigt: Der Unterschied zwischen einer entdeckten Anomalie und Wochen unbemerkter Kompromittierung liegt oft genau in dieser Vorarbeit.
← Zurück zur Übersicht