Cybersecurity-News September 2026: Gefälschte Tokens, geleakte Schlüssel

Die Cybersecurity-News im September 2026 wurden von gefälschten Tokens, wiederverwendeten Sitzungen und geleakten API-Schlüsseln dominiert, die auch nach einer Passwortänderung weiterfunktionierten oder nie ein Passwort benötigt hatten. Zwei Schwachstellen stehen bereits im Known Exploited Vulnerabilities-Katalog der CISA, und ein geleakter Schlüssel eines Anbieters gefährdete über 100.000 Websites.

• Cisco ISE: CVE-2026-76460, eine Authentifizierungsumgehung mit bestätigter aktiver Ausnutzung (Cisco).
• EvilTokens: Microsoft hat einen Device-Code-Phishing-Dienst zerschlagen, der mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Organisationen in Verbindung steht (Microsoft).
• Brevo und Cloudflare: Ein kompromittierter API-Schlüssel setzte mehr als 100.000 Websites einem potenziellen Risiko aus (Sansec).
• JFrog Artifactory: Eine Schwachstelle, die in Honeypots ausgenutzt wurde, um Administrator-Tokens auszustellen (SecurityWeek).
• Cleo Harmony: Ein öffentlicher Exploit für eine Schwachstelle im JWT-Refresh-Token (SecurityWeek).
• CyberArk: 10 Sicherheitsbulletins an vier Terminen, darunter ein kritisches (CyberArk).
• GitHub-App-Schlüssel: GitGuardian stellte fest, dass 474 von 4.802 geleakten privaten Schlüsseln noch gültig waren und sich als 440 Apps authentifizierten (GitGuardian).
• NIST IR 8587: Finale Leitlinie zum Schutz von Tokens und Assertions, veröffentlicht am 15. September (NIST).

Jeder der folgenden Fälle zeigt eine andere Art, wie Zugangsdaten weiter funktionieren, obwohl sie es nicht mehr sollten: gefälscht, wiederverwendet, geleakt oder auf Abruf ausgestellt. Details, betroffene Versionen und Fixes folgen, mit einer kurzen Liste von Maßnahmen für Teams am Ende.

Aktive Ausnutzung einer Authentifizierungsumgehung in Cisco Identity Services Engine (CVE-2026-76460)

Cisco veröffentlichte am 16. September 2026 einen Sicherheitshinweis zu CVE-2026-76460, einer kritischen, nicht authentifizierten Schwachstelle zur Authentifizierungsumgehung in einer Identity Services Engine (ISE)-API. Cisco bewertet sie mit CVSS 3.1 Base 10.0 (kritisch) und bestätigte eine aktive Ausnutzung. Die CISA fügte die CVE am selben Tag ihrem Known Exploited Vulnerabilities-Katalog hinzu.

Was geschah: Eine speziell gestaltete Anfrage an den betroffenen API-Endpunkt ermöglicht es einem Angreifer, die webbasierte Verwaltungsoberfläche von ISE zu umgehen und ohne gültige Zugangsdaten unbefugten Zugriff auf ein betroffenes ISE- oder ISE-PIC-Gerät zu erlangen. Ciscos PSIRT bestätigte, dass Angriffe in freier Wildbahn bekannt waren. Das genaue Datum, an dem die Ausnutzung begann, wurde nicht offengelegt.

Warum das wichtig ist: ISE ist eine Plattform für Richtlinien zum Netzwerkzugriff. Unbefugter Zugriff könnte je nach Implementierung ein erhebliches Risiko für Verwaltungs- und Richtlinienvorgänge darstellen, aber die verfügbaren Quellen belegen nicht, dass bei jedem Kunden nachgelagerte RBAC- oder MFA-Entscheidungen verändert wurden. Die Auswirkung hängt davon ab, wie eine bestimmte Organisation ISE einsetzt.

Handlungsempfehlung: Laut Cisco behebt kein Workaround die Schwachstelle. Ein Upgrade auf eine fehlerbereinigte Version ist die vollständige Lösung. Als vorübergehende Abhilfemaßnahme empfiehlt Cisco Infrastructure-ACLs (iACLs), die am betroffenen Gerät nur den erforderlichen Management- und Control-Plane-Verkehr zulassen. Prüfen Sie die access.log jedes Knotens auf verdächtige Benutzernamen, und gleichen Sie Netzwerk- und Firewall-Protokolle außerhalb der Appliance selbst ab. Das sind Schritte zur Erkennung und Reaktion, kein Ersatz für das Patchen.

Quellen: Cisco; CISA KEV

Microsoft zerschlägt EvilTokens, einen OAuth-Device-Code-Phishing-Dienst

Am 22. September 2026 zerschlug die Digital Crimes Unit von Microsoft gemeinsam mit Partnern die Infrastruktur hinter EvilTokens, einer Phishing-as-a-Service-Plattform, die mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Organisationen weltweit in Verbindung steht.

Was geschah: EvilTokens missbrauchte OAuth-2.0-Device-Authorization-Flows, den Mechanismus für Geräte ohne Browser, etwa Smart-TVs oder CLI-Tools, um Nutzer dazu zu bringen, eine Anmeldung im Namen des Angreifers zu genehmigen. Microsoft legte separat Social-Engineering-Aktivitäten mit Passkey-Bezug offen, die seit Mai 2026 beobachtet wurden. In einer untersuchten Abfolge führte ein Passkey-Köder zu Device-Code-Phishing. Bei anderen untersuchten Mustern nutzten Angreifer Helpdesk-Vorwände oder registrierten vom Angreifer kontrollierte Authentifizierungsmethoden. Die Berichterstattung von Microsoft belegt nicht, dass jede Abfolge alle diese Schritte zu einer einzigen Angriffskette kombinierte.

Warum das wichtig ist: Device-Code-Phishing umgeht genau die Teile der Authentifizierung, auf die sich die Abwehr am stärksten konzentriert. Es gibt keine gefälschte Login-Seite, die auffällt, und kein Passwort, das auf der Seite eines Angreifers eingegeben wird. Das Opfer genehmigt die Anmeldung über die echte, legitime Seite von Microsoft und hält den Vorgang für Routine. Allerdings kann einem Opfer ohne aktive Microsoft-Sitzung weiterhin ein echtes Passwort und eine MFA-Abfrage angezeigt werden, sodass diese Technik nicht grundsätzlich jeden Authentifizierungsschritt aushebelt.

Handlungsempfehlung: Deaktivieren Sie Device-Code-Authentifizierungsflows für Nutzer, die sie operativ nicht benötigen, und überwachen Sie ein ungewöhnlich hohes Volumen an Device-Code-Anmeldungen als Erkennungssignal. Wo der Flow wirklich erforderlich ist, sichern Sie ihn über eine Richtlinie für bedingten Zugriff ab.

Quellen: Microsoft; Microsoft (Aktivitäten mit Passkey-Bezug)

Ein einzelner überprivilegierter Cloudflare-API-Schlüssel gefährdete über 100.000 Websites

Am 14. September 2026 nutzten Angreifer einen kompromittierten, breit berechtigten Cloudflare-API-Schlüssel der E-Mail- und Marketingplattform Brevo, um einen bösartigen Cloudflare Worker einzusetzen, der von Brevo eingebettete Assets auf Kundenseiten veränderte.

Was geschah: Die Telemetrie von Sansec zeichnete auf, dass der bösartige Worker am 14. September von 16:05 bis 20:13 UTC Inhalte auslieferte, rund vier Stunden lang. Der Incident-Bericht von Brevo beschreibt den Worker als etwa fünfeinhalb Stunden aktiv, ein längeres Zeitfenster, als Sansec direkt beobachtet hat. Sansec schätzte, dass in diesem Zeitraum mehr als 100.000 Websites, die betroffene Brevo-Komponenten einsetzen, bösartigen Inhalten ausgesetzt gewesen sein könnten.

Warum das wichtig ist: Ein einzelner, langlebiger Cloudflare-API-Schlüssel mit vollen Berechtigungen, der an einen Anbieter für Marketing-Automatisierung gebunden war, wurde zum Verteilungskanal für bösartigen Code auf einer großen Zahl von Drittanbieter-Websites. Cloud-API-Schlüssel mit weit gefassten Berechtigungen und ohne Ablaufdatum sind genau der Zugangsdatentyp, den eine klassische Passwortrichtlinie nicht abdeckt.

Handlungsempfehlung: Beschränken Sie API-Schlüssel auf den minimalen Berechtigungsumfang, den eine Integration tatsächlich benötigt, legen Sie auch für Schlüssel auf Servicelevel ein Ablaufdatum fest, und führen Sie kontinuierliches Secret-Scanning nicht nur in Passwort-Tresoren der Mitarbeiter, sondern auch über Repositories und Deployment-Pipelines hinweg durch. Eine Überwachung auf unerwartete Worker-Deployments oder Routing-Änderungen hätte dies wahrscheinlich schneller aufgedeckt als eine manuelle Prüfung.

Quellen: Sansec; Brevo

JFrog-Artifactory-Schwachstelle zur Ausstellung von Admin-Tokens genutzt (CVE-2026-82329)

JFrog veröffentlichte am 28. August 2026 einen Fix für CVE-2026-82329. Am 1. September meldete WatchTowr Honeypot-Aktivitäten, die darauf hindeuten, dass Angreifer die Schwachstelle ausnutzten, um Administrator-Tokens zu generieren.

Was geschah: Die Honeypots von WatchTowr erfassten Ausnutzungsversuche von einer kleinen Zahl von Quell-IPs, von denen einige offenbar nur zur Verifizierung dienten statt zu vollständigen Angriffen zu führen. Das belegt, dass die Schwachstelle ausnutzbar ist und getestet wird. Es belegt kein breites Scannen im gesamten Internet oder eine bestätigte Massenausnutzung von Kundeninstanzen.

Warum das wichtig ist: Artifact-Repositories stehen nahe am Zentrum der Software-Lieferkette. Sie unterhalten Federation-Vertrauensbeziehungen zu anderen Repositories und enthalten häufig eingebettete Zugangsdaten für nachgelagerte Systeme. Ein Angreifer, der einen Admin-Token generieren kann, muss keinen stehlen – er erzeugt gültigen Zugriff auf Abruf.

Handlungsempfehlung: Aktualisieren Sie selbst gehostete Artifactory-Instanzen auf die fehlerbereinigte Version Ihres Branches: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 oder 7.161.20. Laut JFrog waren betroffene Cloud-Umgebungen bereits abgesichert. Wenn Protokolle eine Ausnutzung oder verdächtige Token-Ausstellungen zeigen, widerrufen Sie potenziell offengelegte Admin-Tokens, stellen Sie sie neu aus, und prüfen Sie die Federation-Konfigurationen. Die verfügbaren Berichte stützen eine in Honeypots beobachtete Ausnutzung, nicht eine bestätigte Kompromittierung von Kundeninstanzen.

Quellen: JFrog; SecurityWeek

Öffentlicher Exploit für eine Schwachstelle im JWT-Refresh-Token von Cleo Harmony (CVE-2026-84115)

Ein öffentlicher Exploit für CVE-2026-84115 wurde am 2. September 2026 gemeldet, kurz nachdem der CVE-Eintrag am 1. September veröffentlicht worden war.

Was geschah: Die Schwachstelle betrifft Cleo-Harmony-Versionen bis 5.8.1.10 und ist in Harmony 5.8.1.11 behoben. Der CVE-Eintrag beschreibt ein remote ausnutzbares Problem im JWT-Refresh-Token-Handler unter /api/connections: Die Manipulation des Bearer-Arguments führt zu fehlerhafter Rechteverwaltung. SecurityWeek beschreibt dasselbe Problem als Ermöglichung von Authentifizierungsumgehung und Rechteausweitung. Die verfügbaren Berichte belegen öffentliche Ausnutzbarkeit und eine Reproduktion durch Forscher. Sie belegen keine bestätigte Ausnutzung bei Kundensystemen und auch nicht, dass ein manipulierter Token über den Ablauf der ursprünglichen Sitzung hinaus bestehen bleibt.

Warum das wichtig ist: Refresh-Tokens sollen eine Sitzung unauffällig verlängern, ohne eine erneute Anmeldung zu erzwingen. Eine Schwachstelle in der Validierung macht aus dieser Komfortfunktion ein potenzielles Persistenzrisiko – Grund genug zu patchen, auch ohne bestätigte Ausnutzung.

Handlungsempfehlung: Aktualisieren Sie zügig auf Harmony 5.8.1.11. Bei Verdacht auf eine Gefährdung folgen Sie der aktuellen Anleitung von Cleo, prüfen Sie Authentifizierungs- und Rechteänderungen aus dem relevanten Zeitraum, und widerrufen Sie ausstehende Refresh-Tokens, wo die Implementierung das unterstützt. Die Existenz eines öffentlichen Exploits allein bestätigt weder eine Kompromittierung noch einen fortbestehenden Zugriff.

Quellen: NVD; SecurityWeek

CyberArk veröffentlicht zehn Sicherheitsbulletins für seine PAM-Produktlinie

CyberArk veröffentlichte im September 2026 zehn Sicherheitsbulletins in vier datierten Chargen.

Was geschah: CyberArk veröffentlichte im September 2026 in vier Chargen zehn Sicherheitsbulletins. Sie adressieren Probleme mit hohem Schweregrad in Agenten für Endpoint Privilege Management, selbst gehosteten Gateway- und Vault-Komponenten, Analytik für privilegierten Zugriff und der Verwaltung von Datenbank-Zugangsdaten, sowie ein kritisches Problem – CA26-44 –, das bestimmte selbst gehostete Versionen von Password Vault Web Access (PVWA) betrifft.

Warum das wichtig ist: PAM-Systeme verwalten häufig privilegierte Zugangsdaten und sensible Infrastruktur oder stellen den Zugriff darauf bereit. Eine konzentrierte Reihe von Sicherheitsupdates ist eine Erinnerung daran, dass diese Umgebungen kontinuierliches Patch-Management, klare Zugriffs-Governance und verlässliche Nachvollziehbarkeit erfordern. Die Advisories deuten für sich genommen nicht auf eine aktive Ausnutzung hin.

Handlungsempfehlung: Organisationen, die betroffene Produkte einsetzen, sollten die Advisories prüfen und die Behebung nach Schweregrad, Gefährdung und möglichen Auswirkungen auf zugangsdatenbezogene Systeme priorisieren. Allgemeiner sollten Sicherheitsteams stets im Blick behalten, wer auf sensible Zugangsdaten zugreifen kann, und diesen Zugriff bei Bedarf überprüfen können.

Quelle: CyberArk; CyberIAM-Bulletin-Board

Geleakte private Schlüssel von GitHub Apps funktionieren noch lange nach ihrer Offenlegung

GitGuardian testete 4.802 geleakte private Schlüssel von GitHub Apps, die in öffentlichen Quellen gefunden wurden, und stellte fest, dass sich 474 davon weiterhin als 440 verschiedene aktive Apps authentifizieren ließen.

Was geschah: Ein privater Schlüssel einer GitHub App hat kein automatisches Ablaufdatum und kann so lange nutzbar bleiben, bis er manuell widerrufen oder gelöscht wird. Von den 474 noch gültigen Schlüsseln, die GitGuardian testete, verfügten 207 über Schreibrechte für Repository-Inhalte, 40 konnten selbst gehostete Runner verwalten, 98 konnten Workflows steuern, und 44 besaßen Rechte zur Organisationsverwaltung. Ein Schlüssel, der vor Jahren committet wurde, kann sich weiterhin authentifizieren, wenn er nicht widerrufen oder gelöscht wurde.

Ein verwandtes Muster zeigte sich bei einer Schwachstelle im API-Management von WSO2, CVE-2026-5430. Der Advisory datiert auf Mai 2026, die CVE wurde im August veröffentlicht. Die Nachricht im September war eine Meldung über Ausnutzung, keine neue Offenlegung. Ein Angreifer kann ein JSON Web Token (JWT) mit einem nicht unterstützten Signaturalgorithmus erstellen und die fehlerhafte Validierung von WSO2 ausnutzen, um die Authentifizierung zu umgehen. Der Dienst muss dafür nicht selbst einen Token ausstellen. Der Honeypot von WatchTowr erfasste am 13. September gefälschte JWTs mit Administratorrechten gegen das System, und die CISA fügte die CVE am 24. September ihrem Known Exploited Vulnerabilities-Katalog hinzu. Backend-Zugangsdaten, Consumer-Keys oder Secrets wurden als potenziell erreichbar gemeldet, nicht als bestätigt gestohlen.

Warum das wichtig ist: Ein öffentliches Leak schafft potenziell dauerhaften Zugriff, bis der Schlüssel widerrufen oder gelöscht wird. Es belegt für sich genommen nicht, dass der Schlüssel tatsächlich genutzt oder auf Daten zugegriffen wurde. Der WSO2-Fall zeigt ein verwandtes Muster eine Ebene tiefer im Stack: Ein Angreifer braucht gar keinen geleakten Schlüssel, wenn sich die Validierungslogik selbst dazu verleiten lässt, einen gefälschten Schlüssel zu akzeptieren.

Handlungsempfehlung: Legen Sie für jeden GitHub-App-Schlüssel einen Verantwortlichen und einen dokumentierten Rotations- bzw. Widerrufsprozess fest. Bei Verdacht auf oder Bestätigung einer Gefährdung erzeugen Sie umgehend einen Ersatz und widerrufen oder löschen den alten Schlüssel; eine regelmäßige Rotation verkürzt die Gefährdungsdauer, auch wenn GitHub keinen einheitlichen Rhythmus vorschreibt. Für WSO2-Implementierungen spielen Sie den Fix des Herstellers ein, prüfen Sie die Protokolle für das Ausnutzungsfenster im September, und rotieren Sie die Zugangsdaten, auf die die API-Management-Schicht Zugriff hatte.

Quellen: GitGuardian; GitHub-Dokumentation; WSO2-Advisory; The Hacker News

NIST und CISA finalisieren Leitlinie zum Schutz von Identitäts- und Zugriffstokens

NIST und CISA finalisierten IR 8587 am 15. September 2026, nach einem ersten öffentlichen Entwurf vom 22. Dezember 2025.

Was geschah: Die Implementierungsleitlinie richtet sich vor allem an Bundesbehörden und die von ihnen genutzten Cloud-Dienstanbieter und behandelt Identitätstokens, Zugriffstokens und Assertions in SSO-, Federation- und API-Zugriffsszenarien. Ihre Empfehlungen fassen Praktiken für Schlüsselverwaltung, Token-Verifizierung, Lebenszyklus (einschließlich Gültigkeitsdauer und Widerruf) und kontinuierliche Überwachung zusammen, wobei die Verantwortlichkeiten zwischen Anbietern, nutzenden Behörden und Cloud-Konsumenten aufgeteilt sind.

Warum das wichtig ist: Mehrere der oben beschriebenen Vorfälle – gefälschte JWTs, über Validierungsschwachstellen generierte Admin-Tokens, nie ablaufende API-Schlüssel – fallen in genau die Kategorien, die dieser Bericht behandelt: Lücken bei der Verifizierung, fehlende Lebenszykluskontrollen und unklare Verantwortung zwischen Anbieter und Kunde für den Widerruf. Diese Überschneidung ist auch für Organisationen außerhalb des Bundesbereichs nützlich.

Handlungsempfehlung: Nutzen Sie NIST IR 8587 als praktische Checkliste für die aktuellen Praktiken: Stellen Sie sicher, dass Token-Gültigkeitsdauern begrenzt sind, dass Widerrufswege getestet und nicht nur dokumentiert sind, und dass die Sitzungsprotokollierung genug Details erfasst, um einen tokenbasierten Vorfall nachträglich rekonstruieren zu können.

Quellen: NIST; CISA

CloudSEK beschreibt BigBear 2.0, einen Adversary-in-the-Middle-Dienst, der Microsoft-365-Sitzungen nach der MFA wiederverwendet

CloudSEK veröffentlichte seine Untersuchung zu BigBear 2.0 am 7. September 2026. Das TRIAD-Team entdeckte die Operation im Juni, was nicht belegt, wann die gesamte Kampagnenaktivität begann.

Was geschah: Der auf Evilginx2 basierende Adversary-in-the-Middle-Dienst leitete Microsoft-365-Anmeldungen um. Er erfasste Zugangsdaten und das von Microsoft ausgestellte Sitzungscookie, nachdem Opfer die MFA abgeschlossen hatten, und ließ Angreifer anschließend die authentifizierten Sitzungen wiederverwenden. Das Panel von CloudSEK enthielt 4.148 Sitzungscookie-Datensätze und 474 abgeschlossene, MFA-umgangene Authentifizierungen. BleepingComputer berichtete, dass 258 verschiedene Organisationen mindestens eine solche abgeschlossene Kompromittierung erlitten, während 461 Organisationen im breiteren Zieldatensatz auftauchten. Die Zahl 4.148 ist eine Zählung von Cookie-Datensätzen, keine bestätigte Zahl eindeutiger Opfer. (CloudSEK; BleepingComputer)

Warum das wichtig ist: Eine MFA, die das Opfer auf einer proxybasierten Seite abschließt, schützt nicht mehr, sobald das Sitzungscookie gestohlen ist. Der Angreifer übernimmt eine bereits authentifizierte Sitzung. Codes und Push-Genehmigungen stoppen dieses Muster nicht.

Handlungsempfehlung: Priorisieren Sie phishingresistente Methoden wie Passkeys und FIDO2-Sicherheitsschlüssel für Administratoren und Nutzer mit hohem Risiko. Überprüfen Sie Richtlinien für bedingten Zugriff, die Sitzungen an konforme Geräte binden. Lösen Sie einen Alarm aus, wenn sich IP-Adresse oder Gerät einer Sitzung kurz nach der MFA ändern.

Quellen: CloudSEK; BleepingComputer

Okta analysiert Infostealer-Dump mit 44.791 eindeutigen JWTs, 1.843 Tokens zum Zeitpunkt der Veröffentlichung noch gültig

Okta veröffentlichte am 9. September 2026 eine Untersuchung zu einem 7-GB-Infostealer-Dump, der am 2. August auf Telegram veröffentlicht wurde.

Was geschah: Der Dump enthielt Daten von 5.871 infizierten Rechnern. Okta identifizierte 44.791 eindeutige JWTs, darunter 555, die wahrscheinlich mit der Authentifizierung von KI-Diensten zusammenhängen, sowie 2.937 authentifizierungsbezogene JWEs. Zum Zeitpunkt der Veröffentlichung des Dumps waren 1.843 JWTs und JWEs noch nicht abgelaufen. Laut Okta könnten nicht abgelaufene Sitzungs-Secrets potenziell wiederverwendet werden, um die zugangsdatenbasierte Authentifizierung zu umgehen. Die Untersuchung meldete keine erfolgreiche Wiederverwendung oder eine bestätigte Account-Übernahme. Ob eine Wiederverwendung funktioniert, hängt vom jeweiligen Dienst und von Kontrollen wie Token-Bindung oder IP-Allowlisting ab. (Okta)

Warum das wichtig ist: Infostealer nehmen alles mit, was auf dem Endgerät liegt, und Tokens sind ein Teil dieser Beute. Die Gültigkeitsdauer eines Tokens bestimmt, wie lange ein gestohlenes Secret nützlich bleibt. Die KI-Dienst-Tokens in diesem Datensatz zeigen, dass die Gefährdung inzwischen auch neuere Tools erreicht, die Teams häufig außerhalb des zentralen Identitätsmanagements einführen.

Handlungsempfehlung: Verkürzen Sie Token-Gültigkeitsdauern, wo der Dienst das zulässt, und binden Sie Tokens an ein Gerät oder Netzwerk, wo das unterstützt wird. Widerrufen Sie nach einer Infostealer-Infektion Sitzungen und rotieren Sie Secrets – nicht nur das Passwort zurücksetzen. Nehmen Sie Konten für KI-Dienste in Ihr Inventar von Tokens und API-Schlüsseln auf.

Quelle: Okta

JeetBot-Twitch-Erweiterung leitete OAuth-Tokens über vom Betreiber kontrollierte Proxys weiter

Die bösartige Twitch-Browser-Erweiterung JeetBot verzeichnete über Chrome und Firefox hinweg rund 30.500 Installationen aus dem Store (eine Installationsschätzung, keine bestätigte Zahl kompromittierter Nutzer).

Was geschah: Socket fand heraus, dass die Erweiterung kontobezogene Twitch-OAuth-Tokens erfasste und sie über vom Betreiber kontrollierte Proxys in einem &auth=-Query-Parameter weiterleitete. Die Berichterstattung belegt nicht, dass die Tokens für unbefugte Aktivitäten genutzt wurden. Firefox-Version 85.8.7 (16. September) und Chrome-Version 85.8.9 (gemeldet am 25. September) beendeten die Weiterleitung. Der Betreiber widersprach der Einstufung der Erweiterung als bösartig, räumte aber Sicherheits- und Offenlegungsprobleme ein. (Socket)

Handlungsempfehlung: Prüfen Sie installierte Browser-Erweiterungen, und behandeln Sie jeden Token, der in einer URL aufgetaucht ist, als offengelegt. Nutzer von JeetBot sollten der App den Zugriff auf ihr Twitch-Konto entziehen.

Quelle: Socket

Microsoft Entra aktiviert Passkeys automatisch vor der Abschaltung von SMS- und Sprach-MFA

Microsoft Entra begann am 1. September 2026 damit, Passkeys automatisch für Public-Cloud-Nutzer zu aktivieren, für die SMS- oder Sprach-MFA bereits in der Entra-Richtlinie für Authentifizierungsmethoden oder in den Legacy-Einstellungen aktiviert war.

Was geschah: Wenn diese Nutzer sich das nächste Mal anmelden und die MFA abschließen, werden sie aufgefordert, einen Passkey zu registrieren. Diese Aufforderung lässt sich in der Regel vertagen, und bis zum 1. Februar 2027 steht ein vorübergehendes Opt-out für den Tenant zur Verfügung. Die von Microsoft bereitgestellte SMS- und Sprachzustellung wird für die meisten Nutzer am 1. Februar 2027 und für globale Administratoren und externe Nutzer am 1. Juli 2027 abgeschaltet. Organisationen mit einem berechtigten Bedarf können SMS oder Sprache über einen unterstützten Telefonieanbieter fortführen. Diese Konfigurationsoption ist für den 30. Oktober 2026 geplant.

Warum das wichtig ist: Die Änderung verschiebt den Standard weg von telefonbasierten Faktoren – genau der Art, die laut der oben beschriebenen BigBear-2.0-Kampagne weitergeleitet werden kann. Tenants, die nichts unternehmen, sehen schon jetzt Registrierungsaufforderungen und verlieren 2027 die von Microsoft bereitgestellte SMS- und Sprachzustellung.

Handlungsempfehlung: Erfassen Sie, welche Nutzer und Serviceprozesse noch auf SMS oder Sprache angewiesen sind. Beginnen Sie die Passkey-Registrierung mit Administratoren und externen Nutzern, für die die Frist am frühesten endet. Entscheiden Sie vor dem 1. Februar 2027, ob Sie einen Telefonieanbieter benötigen oder diese Methoden ganz abschalten können.

Quelle: Microsoft Learn

Was das für Ihr Team bedeutet

Die meisten Fälle dieses Monats laufen darauf hinaus, dass Zugangsdaten weiter funktionierten, obwohl sie es nicht mehr sollten. Sechs Schritte, mit denen Ihr Team ähnliche Probleme vermeiden kann:

1. Nicht-menschliche Zugangsdaten inventarisieren. Erfassen Sie API-Schlüssel, Service-Account-Tokens, private Schlüssel von GitHub Apps und CI/CD-Secrets genauso wie Benutzerkonten. Geben Sie jedem einen namentlich benannten Verantwortlichen und einen dokumentierten Plan für Ablauf oder Rotation. In den Fällen Brevo und GitHub App ging es jeweils um Schlüssel, die niemand verfolgt hat.
2. Berechtigungen einschränken und Ablaufdaten setzen. Vergeben Sie für jeden Schlüssel nur die Berechtigungen, die die Integration tatsächlich benötigt, und setzen Sie überall dort ein Ablaufdatum, wo der Anbieter das unterstützt. Wo das nicht möglich ist, planen Sie eine manuelle Rotation.
3. Widerruf testen, bevor Sie ihn brauchen. Prüfen Sie für jeden Anbieter, was der Widerruf einer Sitzung, eines JWT, einer OAuth-Berechtigung oder eines Refresh-Tokens tatsächlich bewirkt. Durchlaufen Sie nach einem Vorfall den gesamten Widerrufsweg, statt sich auf die Dokumentation zu verlassen. Widerrufen Sie Sitzungen und rotieren Sie Secrets – nicht nur das Passwort zurücksetzen.
4. OAuth- und Sitzungslücken schließen. Deaktivieren Sie Device-Code-Flows für Nutzer, die sie nicht benötigen, und wechseln Sie Administratoren vor der Abschaltung von Microsofts SMS- und Sprach-MFA 2027 zu Passkeys oder FIDO2-Schlüsseln. Binden Sie Sitzungen an Geräte, wo das unterstützt wird.
5. Exponierte Identitätsinfrastruktur zuerst patchen. Cisco ISE, JFrog Artifactory, Cleo Harmony und WSO2 stellen Zugriff für alles aus, was dahinter liegt, oder validieren ihn. Behandeln Sie deren Updates vorrangig vor dem routinemäßigen Patchen.
6. So protokollieren, dass sich ein Vorfall rekonstruieren lässt. Halten Sie Sitzungs- und Token-Protokolle detailliert genug, um zu zeigen, wer sich wo mit welchem Token authentifiziert hat. NIST IR 8587 ist dafür und für die obigen Punkte eine brauchbare Checkliste.

Weiterführende Informationen finden Sie in unseren Leitfäden zum Lebenszyklus der Secrets-Rotation und zu hartcodierten Secrets.

Monatlicher Cybersecurity-Rückblick: Authentifizierung unter Beschuss

Die Vorfälle im August 2026 umgingen die Authentifizierung vollständig: bestätigte Exploits in N-able N-central und SharePoint, über 9.300 offengelegte AWS-Schlüssel und Mirage2FA, das Sitzungen nach der MFA übernahm. Hier ist, was IT- und Sicherheitsteams zuerst patchen und prüfen müssen.

PassworkPasswork Team

Post-Quanten-Passwortsicherheit: Was sich ändert und was zu tun ist

Grovers Algorithmus setzt einem korrekt gehashten Passwort kaum etwas entgegen. Shors Algorithmus zerlegt dagegen den RSA-Schlüsselaustausch direkt daneben. Hier ist das dreistufige Audit, das zeigt, welches der beiden Probleme bei Ihnen wirklich relevant ist.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: Die KI-Bedrohung über 6 Mio. US-Dollar, die niemand behebt

Die globalen Kosten von Datenschutzverletzungen erreichten 2026 mit 4,99 Mio. US-Dollar einen neuen Höchststand, bei einer Erkennungszeit von 247 Tagen. KI-gestützte Angriffe steigen um 56 %, doch die eigentliche Krise ist: Verteidiger setzen KI überall ein – außer genau dort, wo Angreifer eindringen. 92 % der von KI-Angriffen betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

PassworkAlex Muntyan