Sieben Microsoft-365-Konten geknackt – alle waren verwaiste Dienstkonten

|Autor: QUASA-Redaktion|5 Min. Lesezeit
Sieben Microsoft-365-Konten geknackt – alle waren verwaiste Dienstkonten

Laut Proofpoints Analyse vom 22. September 2026 kompromittierte eine mit TeamFiltration durchgeführte Kampagne sieben Microsoft-365-Konten – ausnahmslos unverwaltete Funktions- oder Dienstkonten ohne erzwungene Mehrfaktor-Authentifizierung (MFA); zwischen dem 21. Juli und dem 16. August registrierten die Forschenden 32.825 Authentifizierungsereignisse gegen 5.714 Konten in 28 Tenants. Der Schwerpunkt lag auf Chile. Alle bestätigten Übernahmen betrafen einen großen Einzelhändler dort.

Der Bericht von eSecurity Planet bestätigt, dass für keines der sieben übernommenen Konten in der ausgewerteten Telemetrie zuvor legitime Benutzersitzungen zu sehen waren und sechs Übernahmen innerhalb von sieben Minuten erfolgten. Das bedeutet nicht, dass die Konten seit ihrer Einrichtung nie eine Aufgabe erfüllt hatten. Es zeigt aber, warum ein Identitätsinventar, das nur Beschäftigtenkonten regelmäßig überprüft, den entscheidenden Zugangspunkt dieser Kampagne übersieht.

Wie das Password Spraying ablief

Die Angreifer verteilten Passwortversuche auf viele Adressen, statt zahlreiche Varianten gegen nur ein Konto zu testen. TeamFiltration kann gültige Konten über die Teams-API ermitteln und die Versuche über wechselnde Infrastruktur ausführen. In dieser Kampagne stammten die beobachteten Anmeldungen von AWS-EC2-Adressen. Ein in der Standardkonfiguration des Werkzeugs hinterlegter, inzwischen alter Teams-User-Agent half bei der Zuordnung; für sich allein ist ein solcher Kennwert noch kein Beweis für eine bestimmte Person oder Gruppe hinter dem Angriff.

Die beobachtete Aktivität begann bei chilenischen Finanzinstituten und verlagerte sich später auf den Einzelhändler. Dort konzentrierten sich die bestätigten Übernahmen und die Aktivitäten nach der Anmeldung. Die Zahl erfolgreicher Logins war gemessen an allen angegriffenen Konten klein, doch sie beschreibt nur den Erfolg des Passwortversuchs. Über die Reichweite eines übernommenen Kontos entscheiden dessen Berechtigungen und die Zugriffsregeln der jeweils angesprochenen Anwendung.

Warum gerade die verwaisten Konten betroffen waren

Die übernommenen Identitäten waren für Aufgaben wie Ticketverwaltung, Lieferantenzahlungen, Kassensysteme und die Bearbeitung von Anfragen angelegt worden. In der verfügbaren Telemetrie fehlte bei ihnen eine frühere legitime Benutzersitzung, während sie weiterhin für Anmeldungen offenstanden. Der Begriff „verwaist“ beschreibt daher die fehlende erkennbare Betreuung dieser aktiven Konten, nicht eine gesicherte Aussage über jeden einzelnen früheren Einsatz.

Die zeitliche Nähe der Übernahmen spricht für gemeinsam vergebene oder leicht vorhersehbare Zugangsdaten aus einem Einrichtungsprozess; die tatsächlich verwendeten Passwörter sind öffentlich nicht belegt. Das fehlende MFA-Erfordernis ist dagegen für die kompromittierten Konten dokumentiert. Auch eine bestätigte Übernahme persönlicher Beschäftigtenkonten enthält die Untersuchung nicht. Der gemeinsame Nenner der Erfolge ist damit präzise benennbar: weiter aktive betriebliche Identitäten ohne erkennbare Betreuung und zusätzlichen Anmeldeschutz.

Welche Zugriffe nach der Anmeldung sichtbar wurden

Bei mehreren übernommenen Konten folgten Anmeldungen an Microsoft Teams, Microsoft Office oder OneDrive. Dieses Muster ist mit Funktionen von TeamFiltration vereinbar, die nach einem Login Inhalte abrufen können. Aus Anmeldeereignissen allein folgt jedoch kein nachgewiesener Datenabfluss. Ob Nachrichten oder Dateien tatsächlich heruntergeladen wurden und in welchem Umfang, lässt sich aus den veröffentlichten Sign-in-Daten nicht entscheiden.

Bei einem Konto wechselte die Aktivität kurz nach der Übernahme von der AWS-Infrastruktur zu einem deutschen VPN-Knoten. Ein Versuch, das Unternehmens-VPN zu erreichen, scheiterte an MFA oder einer Regel für bedingten Zugriff. Beim Azure Portal erschien eine Aufforderung zur MFA-Einrichtung; außerdem verzeichnete die Telemetrie Aktivitäten bei OfficeHome und SharePoint Online sowie eine Token-Anfrage im Zusammenhang mit Microsoft Graph. Der gesperrte VPN-Weg zeigt eine wirksame Grenze für diese Anwendung, aber keine rückwirkende Sperre der bereits erfolgten Microsoft-365-Anmeldung.

Was Administratoren im eigenen Tenant prüfen können

Der Fall legt eine Prüfung nahe, die bei allen betrieblichen Identitäten beginnt, auch wenn sie technisch als Benutzerkonto angelegt wurden. Die Microsoft-Dokumentation für Entra-Dienstkonten unterscheidet verwaltete Identitäten, Dienstprinzipale und Benutzerkonten, die als Dienstkonten dienen. Sie empfiehlt, Eigentümer, Zweck, Berechtigungen und erwartete Lebensdauer zu dokumentieren sowie Anmeldungen und Ressourcenzugriffe regelmäßig auszuwerten. Gerade die letzte Kategorie muss im Inventar ausdrücklich erfasst werden.

  1. Zuerst aktive Funktions- und Dienstkonten ihrem Zweck, einer Anwendung oder einem Skript und einem verantwortlichen Eigentümer zuordnen. Konten ohne nachvollziehbare Aufgabe oder Zuständigkeit verdienen Vorrang; vor einer Deaktivierung müssen mögliche technische Abhängigkeiten geklärt werden.
  2. Danach Anmeldeprotokolle und Ressourcenzugriffe im verfügbaren Beobachtungszeitraum abgleichen. Eine fehlende Benutzersitzung ist ein Warnsignal, kein Beweis für Unbrauchbarkeit: Ein automatisierter Prozess kann anders erscheinen als ein interaktiver Login.
  3. Bei weiterhin nötigen Konten Berechtigungen, Passwortalter und Zugangsdatenverwaltung prüfen. Besteht der Verdacht auf ein geteiltes oder nie gewechseltes Passwort, sollte es kontrolliert ersetzt werden; für passende Arbeitslasten kommen verwaltete Identitäten oder Dienstprinzipale in Betracht.
  4. Für interaktive Anmeldungen MFA und bedingten Zugriff je Zielanwendung prüfen. Ein Schutz, der den Zugang zum Unternehmens-VPN stoppt, sagt noch nichts über die Regeln für Teams, SharePoint oder andere Microsoft-365-Dienste aus.
  5. Wiederholte Fehlversuche über wechselnde AWS-Adressen, den auffälligen älteren Teams-User-Agent und einen Wechsel zu einem VPN-Knoten nach erfolgreichem Login gemeinsam bewerten. Jeder einzelne Hinweis kann auch eine andere Ursache haben.

Was über die Folgen noch nicht feststeht

Veröffentlicht sind die bestätigten Kontoübernahmen, die sichtbaren Anmeldungen an weitere Anwendungen und der blockierte Zugang zum Unternehmens-VPN. Nicht veröffentlicht ist ein gesicherter Umfang möglicher Datei-, Chat- oder E-Mail-Abflüsse; ebenso fehlen die konkreten Passwörter und Angaben zu weiteren Auswirkungen beim betroffenen Einzelhändler. Die Untersuchung belegt damit eine Lücke bei der Verwaltung betrieblicher Identitäten, lässt aber die Folgen jenseits der beobachteten Kontozugriffe offen.

Lesen Sie auch:

Teilen:

Newsletter abonnieren

Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.

0