Top 5 Cybersicherheit-News

Die Top 5 Cybersicherheit-News vom 13. November 2026 handeln von Zugriffen, die weiterliefen, nachdem niemand mehr hinsah. Ein Logistikkonzern meldet einen Einbruch in ein Altsystem, das er durch eine Übernahme geerbt hat. Angreifer nutzten das Vertrauen einer ausgemusterten Datenplattform in die AWS-Konten ihrer Kunden. Gestohlene Cloud-Schlüssel werden binnen Stunden zu KI-Rechnungen im sechsstelligen Bereich. Ein Anbieter von Fernwartungssoftware nahm seine eigene gehostete Plattform vom Netz, nachdem 33 mutmaßliche Zero-Days auf GitHub auftauchten. Und Tausende gekaperte GitHub-Konten brachten einen Stealer in Build-Pipelines, der Cloud-Hintertüren hinterlassen kann. Fünf Angriffsebenen, eine Frage: Welcher Zugriff in Ihrem Unternehmen funktioniert noch, obwohl ihn niemand mehr verantwortet?

1) Maersks Einbruch begann in einem System, das der Konzern geerbt und nicht gebaut hat

Maersk gab am 11. November bekannt, dass ein Unbefugter auf ein lokales Altsystem zugegriffen und Daten daraus kopiert hat, das der Konzern durch eine frühere Übernahme geerbt hatte. Das Unternehmen sagt, es habe das System gesichert, die bisherigen Erkenntnisse sprächen stark dafür, dass keine sensiblen Daten offengelegt wurden, und es gebe keine Hinweise auf Auswirkungen auf andere Maersk-Systeme oder auf Kunden- und Partnersysteme, die über APIs und EDI angebunden sind. Am Wochenende hatte die Ransomware-Gruppe WhiteArmor Maersk auf ihrer Leak-Seite gelistet, 5 Millionen US-Dollar in Bitcoin verlangt und rund 100 GB von der Plattform OCF/LF Logistics beansprucht. Maersk hat den Vorfall nicht mit der Gruppe in Verbindung gebracht, und deren Behauptungen, darunter Fahrerdaten und Klartext-Zugangsdaten, sind nicht verifiziert.

Maersk hat nicht gesagt, wann der Einbruch begann, wie der Angreifer hineinkam und wie viele Daten abflossen. Die Lehre ist deshalb strukturell, nicht forensisch. Ein System, das mit einer Übernahme kommt, behält oft eigene Logins, eigenes Logging und eigene Administratoren und liegt womöglich außerhalb des Programms, das den Kern schützt. Annahme: Das trifft hier zu, denn Maersk spricht von einem lokalen Altsystem. Für das eigene Unternehmen heißt das: Alle Systeme auflisten, die mit einer Übernahme kamen, für jedes einen Verantwortlichen benennen und prüfen, womit es verbunden ist. Maersk rät Kunden außerdem, unerwartete Nachrichten zum Vorfall mit Vorsicht zu behandeln und über den gewohnten Maersk-Kontakt zu prüfen.

Die Aussage, ein Vorfall sei „auf ein lokales System beschränkt“, ist nur so belastbar wie die Übersicht darüber, womit dieses System verbunden war. Integrationspläne budgetieren Verträge und Finanzkonsolidierung. Sicherheitsschulden stehen selten darauf, obwohl auf geerbten Plattformen alte Zugangsdaten und alte Administratoren am längsten überleben. Die Due Diligence endet mit der Unterschrift; das Risiko bleibt, bis das letzte geerbte System abgeschaltet oder unter dieselben Kontrollen gestellt ist wie der Rest.

Read more on: Maersk Statement · Cyber Security News

2) Viele Kunden haben Qubole abgeschaltet, aber dessen Vertrauen in ihre AWS-Konten offen gelassen

Wiz berichtet gemeinsam mit Googles Mandiant, nachdem Sentra verdächtige Aktivität gemeldet hatte, dass unbekannte Angreifer ab dem 14. Oktober mit kompromittierten Zugangsdaten aus dem AWS-Konto von Qubole sts:AssumeRole gegen vom Kunden verwaltete Integrationsrollen aufriefen. Qubole ist eine Cloud-Plattform für Datenverarbeitung, deren Kunden ihr kontenübergreifende Rollen statt langlebiger Schlüssel einräumen. In den Kundenumgebungen durchsuchten die Angreifer Dienste, entnahmen Geheimnisse aus Lambda, Secrets Manager und SSM Parameter Store und luden teils ganze S3-Buckets herunter. Außerdem testeten sie mit TruffleHog AWS-Zugangsdaten, fanden Microsoft-Entra-ID-Geheimnisse und forderten mit Okta-Client-Credentials OAuth-Tokens an. Wiz nannte keine Opferzahl; SecurityWeek berichtet unter Berufung auf Sentra von mehr als einem Dutzend Organisationen. Ein Akteur, der sich n0n nennt, hat sich laut einem von Wiz zitierten Bericht zu der Tat bekannt, was Wiz nicht bestätigt hat. Qubole antwortete The Register nicht.

Laut Wiz haben viele Organisationen Vertrauensrichtlinien aktiv gelassen, auch nachdem sie die Plattform abgekündigt hatten, weshalb sich die Rollen weiter übernehmen ließen. AWS erklärt, die eigenen Dienste seien nicht kompromittiert worden und die Rollen hätten so funktioniert, wie Kunden sie konfiguriert hatten. Praktische Schritte: kontenübergreifende Rollen in IAM prüfen, Rollen für nicht mehr genutzte Integrationen entfernen und Bedingungen wie Quell-IP-Beschränkungen ergänzen. CloudTrail ab 1. Oktober auf AssumeRole-Ereignisse aus dem Qubole-Konto prüfen (ID 805246085872, laut Wiz) und jedes Geheimnis rotieren, das diese Rollen lesen konnten. Rotation beendet bereits ausgestellte Sitzungen nicht, die müssen zusätzlich widerrufen werden.

Eine Vertrauensbeziehung ist eine dauerhafte Berechtigung, und sie läuft nicht ab, wenn die Geschäftsbeziehung endet. Das Offboarding eines Lieferanten gilt meist als Vertragsthema, die technische Freigabe bleibt bestehen. So wird Lieferantenkonzentration zum Single Point of Failure: Ein Satz gestohlener Anbieter-Zugangsdaten öffnet die Türen vieler Kunden gleichzeitig, und die Kontrollen der einzelnen Kunden sehen das Konto des Lieferanten nie.

Read more on: Wiz Research · The Register

3) Gestohlene Cloud-Schlüssel werden zu KI-Rechnungen, teils bis zu einer Million Dollar

In einem Bericht vom 2. November beschreiben die Google Threat Intelligence Group und Mandiant LLMjacking: Angreifer erlangen per Phishing, durchgesickertem Quellcode, falsch konfigurierten Umgebungen oder offenem Client-Code einen API-Schlüssel oder eine Cloud-Identität und lassen eigene Workloads auf den KI-Konten des Opfers laufen, während der Eigentümer zahlt. Google sah Kosten von mehr als 100.000 US-Dollar an einem einzigen Tag und kumulierte Kosten von bis zu einer Million Dollar bei einzelnen Organisationen, bevor der Zugriff gesperrt wurde. Der häufigste Einstieg waren offengelegte oder gestohlene Cloud-Identitäts-Tokens: IAM-Zugangsdaten, Service-Account-Schlüssel, GitHub Personal Access Tokens und Sitzungs-Tokens. Ein als UNC6993 verfolgter Akteur nutzte einen falsch konfigurierten Service-Account-Schlüssel und verursachte mehr als 100.000 US-Dollar Kosten.

Der Bericht beschreibt auch einen Wiederverkaufsmarkt. Sogenannte LLM Mixer leiten unbefugten Zugang weiter und verkaufen ihn, ein Dienst bewirbt einen unbegrenzten Tarif für etwa 60 Dollar im Monat. Separat beschreiben Symantec und Carbon Black ein Graumarkt-Relay, das echte Coding-Assistenten installiert und deren Konfiguration umschreibt, die Sandbox abschaltet und jede Anfrage über eigene Server leitet; Mitarbeitende, die ein westliches KI-Werkzeug ausprobieren wollten, installierten es. Zuerst jeden KI-API-Schlüssel samt Projekt inventarisieren, dann Budgets und Kontingentalarme pro Schlüssel setzen, kurzlebige Zugangsdaten bevorzugen und Schlüssel aus Repositories fernhalten.

KI macht aus einem gestohlenen Zugang sofort Geld, ohne dass der Angreifer erst Daten finden muss, die sich zu stehlen lohnen. Das verändert die Erkennung: Der erste Alarm kann die Rechnung sein, nicht das Endpoint-Werkzeug. Finanzen und Sicherheit brauchen deshalb einen gemeinsamen Alarmweg für Kostensprünge. Hypothese: Kleinere Unternehmen, die KI-Dienste ohne zentrale Verantwortung ausprobieren, sind am stärksten exponiert, weil Schlüssel schneller entstehen als die Regeln, die sie steuern.

Read more on: Google Threat Intelligence · The Hacker News

4) N-able nahm die eigene gehostete Plattform vom Netz, nachdem 33 mutmaßliche Zero-Days online auftauchten

Am 9. November veröffentlichte ein Forscher auf GitHub ein Repository namens Able2Shell mit 33 mutmaßlichen Zero-Day-Schwachstellen in N-central, der Remote-Monitoring-und-Management-Plattform (RMM) von N-able. Es enthält Proof-of-Concept-Code und Exploit-Ketten, die Berichten zufolge zur vollständigen Übernahme des Servers führen. N-able sagte, es habe seine gehostete N-central-Umgebung vorsorglich vom Netz genommen, On-Premises-Kunden zum Gleichen geraten und keine aktive Ausnutzung gesehen. Am 10. November erschien N-central 2026.4 HF2, und laut Field Effect sind alle gehosteten Umgebungen aktualisiert. Die 33 Schwachstellen sind Behauptungen des Forschers. N-able hat sieben CVEs veröffentlicht, die in HF2 behoben sind und die N-able mit CVSS 4.0 zwischen 8,3 und 9,3 bewertet, hat aber nicht gesagt, welche der 33 Funde sie abdecken. Laut Tenable meldet die Statusseite von N-able Scan-Aktivität im Zusammenhang mit dem veröffentlichten Code, und bis zum 10. November war keine bestätigte Kompromittierung eines Kundenservers bekannt.

Eine RMM-Plattform hat privilegierten Zugriff auf Endgeräte, Skripte, Patching und Fernsitzungen jedes Kunden, den ein MSP betreut. Eine Schwachstelle darin ist deshalb eine Schwachstelle bei allen. Wer seine IT von einem MSP betreuen lässt, sollte fragen, ob dieser N-central einsetzt, ob gepatcht wurde und worauf die Plattform in der eigenen Umgebung zugreifen kann. Für On-Premises-Betreiber rät Field Effect, die Administrationsoberfläche auf dedizierte Netze zu beschränken, Administratoranlagen, Skriptausführungen und Konfigurationsänderungen zu prüfen und in der Plattform gespeicherte Zugangsdaten zu rotieren.

GovInfoSecurity zählt dies als den fünften Notfall-Hotfix von N-able seit dem 1. August und argumentiert, KI-gestützte Forschung finde Schwachstellen und Exploits inzwischen schneller, als Hersteller sie verarbeiten können. Ein Hersteller kann nicht mit 90 Tagen für ein Update rechnen, wenn der Exploit-Code an einem Montag öffentlich ist. Für die Resilienzplanung gilt: auflisten, welche Abläufe stillstehen, wenn die Konsole, die alles verwaltet, tagelang abgeschaltet werden muss.

Read more on: N-able Status Page · GovInfoSecurity

5) 4.837 gekaperte GitHub-Konten brachten einen Secret-Stealer in die Build-Pipeline

Seit dem 10. November hat ein Angreifer laut Aikido Security mit gestohlenen Zugangsdaten für 4.837 GitHub-Konten einen Secret-Stealer in Repositories platziert, auf die diese Konten schreiben konnten. Er lief in mindestens 1.806 Repositories. Jeder Versuch begann mit einem Test-Pull-Request mit dem Titel „docs: dependency audit notes“, geöffnet in 61.764 Repositories. SafeDep zählte 8.093 Repositories mit schädlichen Commits zwischen 12:46 UTC am 10. November und 04:36 UTC am 12. November, nur öffentliche Default-Branches eingerechnet. Der Stealer greift ab, was ein CI-Workflow erreichen kann: Actions-Secrets, das Workflow-Token, OIDC-Tokens und Cloud-Zugangsdatendateien. Wie der Angreifer an die Kontozugänge kam, ist nicht geklärt.

Wo der Stealer lief, sind alle Secrets und Cloud-Rollen, die die Workflows erreichen konnten, als kompromittiert zu betrachten. Tokens, OAuth-Freigaben, SSH-Schlüssel und Sitzungen des Commit-Autors widerrufen, 2FA aktivieren und Secrets rotieren. Danach nach Hintertüren suchen, die eine Rotation überleben sollen: Der Stealer kann die Vertrauensrichtlinie einer AWS-Rolle für jedes AWS-Konto öffnen und Azure-AD-Anwendungen föderierte Identitätsdaten mit dem Präfix wfx-ci- hinzufügen, sodass sich Workflows ohne gespeichertes Secret anmelden können. In CloudTrail nach Sitzungen mit dem Namen wfx-* suchen, gefolgt von CreateAccessKey oder UpdateAssumeRolePolicy.

Eine CI-Pipeline ist der Ort, an dem Code, Cloud-Vertrauen und Secrets zusammenkommen, und macht das Konto eines Entwicklers zu einem Infrastrukturkonto. Ein Secret zu rotieren hilft nicht, wenn die Vertrauensrichtlinie dahinter umgeschrieben wurde; das dauerhafte Gut ist das Vertrauen, dasselbe Muster wie in Story 2. Aikido stellte fest, dass im Oktober betroffene Konten in dieser Woche etwa 1.000-mal wahrscheinlicher genutzt wurden als andere aktive Konten, ordnet November aber nicht demselben Akteur zu. Hypothese: Gestohlene Zugangsdaten zirkulieren weiter zwischen verschiedenen Gruppen.

Read more on: Aikido Security Analysis · The Hacker News

Wenn diese Woche etwas zeigt, dann dies:

Alle fünf Vorfälle hingen an Zugriffen, die weiterliefen, obwohl sich ihr Zweck geändert hatte. Das übernommene System hatte noch eine Rolle, die Vertrauensrichtlinie der gekündigten Plattform war noch aktiv, hinter dem KI-Schlüssel stand noch ein Abrechnungskonto, die Verwaltungskonsole erreichte noch jedes Endgerät und das CI-Token noch die Cloud. Eine neue Angriffsklasse war nicht nötig; die Angreifer nutzten Berechtigungen, die kein Prozess je ablaufen lässt. Die strukturelle Angriffsfläche sind Zugriffe ohne Verantwortlichen und ohne Ablaufdatum.

Für Vorstände und CISOs ist ein kurzes Inventar die nützliche Übung. Wer verantwortet jede Vertrauensbeziehung, jeden API-Schlüssel, jede Integration, jede Verwaltungsplattform und jedes geerbte System, wann läuft sie ab und woran würde man ihren Missbrauch erkennen? Wo auf die ersten beiden Fragen die Antwort „niemand“ lautet, wird die dritte selten gestellt. Das Offboarding eines Lieferanten oder die Integration einer Übernahme ist Sicherheitsarbeit, nicht nur Verwaltung.

Wenn Sie wissen möchten, welche geerbten Systeme, Integrationen oder Verwaltungsplattformen in Ihrer Umgebung noch Zugriffe halten, die sie nicht mehr brauchen, erreichen Sie uns über unsere Kontaktseite.