KI-gestützte Identitätsangriffe: Wenn der Helpdesk zum Einfallstor wird

Montagmorgen. Im Helpdesk wartet bereits die nächste Anfrage: Eine neue Mitarbeiterin meldet sich. Ihr Smartphone sei verloren gegangen, erklärt sie am Telefon. Deshalb komme sie nicht mehr durch die Multi-Faktor-Authentifizierung. Gleich stehe ein wichtiger Termin an. Ob man ihr bitte schnell helfen könne?

Die Geschichte passt. Sie kennt den Namen ihrer Führungskraft, ihre Personalnummer und interne Abläufe. Sogar die Stimme klingt so, wie man sie erwartet hätte: etwas nervös, freundlich, erleichtert darüber, endlich jemanden erreicht zu haben. Der Helpdesk setzt das Passwort zurück und richtet einen neuen MFA-Faktor ein. Alles wirkt wie ein normaler Supportfall. Kurz darauf besitzt ein Angreifer einen technisch gültigen Zugang zum Unternehmen.

Im Tech Talk mit Consist beschreibt Sunny Begala von CrowdStrike fast genau dieses Vorgehen:

Angreifer nutzen KI, um beim IT-Helpdesk anzurufen und Mitarbeitende zu imitieren. Normalerweise geben sie sich als neue Mitarbeiterin aus.

Die Szene ist also zugespitzt. Der Ablauf leider nicht. Die gemeinsame Sicherheitswarnung von CISA und FBI zu Scattered Spider beschreibt Voice Phishing, den Missbrauch vertrauenswürdiger Supportprozesse und Helpdesk-Anrufe, mit denen Passwörter oder MFA-Token zurückgesetzt werden sollen. Das Unangenehme daran: Der Helpdesk hat geholfen. Genau dafür ist er da.

Was ist ein identitätsbasierter Angriff?

Bei einem identitätsbasierten Angriff nutzen Cyberkriminelle gestohlene, erschlichene oder missbräuchlich zurückgesetzte Zugangsdaten. Für die Systeme sieht es zunächst so aus, als melde sich ein berechtigter Nutzer an. Kein verdächtiger E-Mail-Anhang. Kein Schadprogramm, das sofort Alarm schlägt. Jemand besitzt ein gültiges Passwort und möglicherweise sogar einen neu registrierten MFA-Faktor. KI macht diese Angriffe glaubwürdiger. Sie kann öffentlich verfügbare Informationen auswerten, passende Nachrichten formulieren und Stimmen oder Videobilder imitieren. Der Angreifer wirkt damit nicht wie jemand, der hektisch ein fremdes Passwort ausprobiert. Er wirkt wie eine Kollegin, die dringend Unterstützung braucht.

Sunny warnt im Interview davor, Angreifer nur als technische Signale zu betrachten:

Das sind echte Leute. Sie sind kreativ. Sie versuchen immer, Technologie selbst zu nutzen – und KI nutzen sie heute schon häufig.

Diese Menschen recherchieren, probieren verschiedene Ansprechpartner aus und suchen den Moment, in dem Hilfsbereitschaft stärker ist als der vorgeschriebene Prüfprozess. Sichtbar wird der Angriff häufig erst durch das Verhalten des Kontos: ein neues Gerät, ein ungewöhnlicher Anmeldeort, zusätzliche Berechtigungen oder der Zugriff auf Systeme, die der tatsächliche Nutzer bisher nie benötigt hat.

Warum neue Mitarbeitende besonders glaubwürdige Ziele sind

Eine neue Mitarbeiterin kennt noch nicht jeden internen Ablauf. Sie hat möglicherweise noch keinen persönlichen Kontakt zum Helpdesk. Login-Probleme, fehlende Berechtigungen und nicht funktionierende Geräte überraschen in den ersten Arbeitstagen niemanden. Genau das macht die Geschichte so plausibel.

Die Angreifer rufen nicht nur einmal an. Sie versuchen es bei verschiedenen Leuten und nutzen LinkedIn-Profile. Dann sehen sie: Hier hat jemand neu angefangen und hätte einen guten Grund für einen Passwort-Reset.

Unternehmenswebsites, soziale Netzwerke und Stellenanzeigen liefern reichlich Material:

• Wer gerade neu angefangen hat
• Welche Führungskraft zu welcher Abteilung gehört
• Welche Cloud- und Collaboration-Dienste verwendet werden
• Wie die E-Mail-Adressen aufgebaut sind
• Welcher externe Dienstleister den Support übernimmt

Keine dieser Informationen muss geheim sein. Zusammengesetzt ergeben sie eine brauchbare Legende. Ein Angreifer könnte wissen, dass eine Mitarbeiterin vor wenigen Tagen als neue Sales Managerin angefangen hat, Microsoft 365 verwendet und direkt an eine öffentlich genannte Vertriebsleiterin berichtet. Für den Helpdesk klingt der Anruf dann nicht wie ein Angriff. Er klingt wie Dienstag.

Der Angriff beginnt mit Vertrauen

Social Engineering arbeitet gern mit Dringlichkeit. In wenigen Minuten beginnt der Kundentermin. Die Führungskraft wartet. Die Mitarbeiterin ist unterwegs. Das Smartphone ist weg. Der Ton bleibt freundlich, während der Druck langsam wächst. Der Mensch im Helpdesk möchte das Problem lösen. Er hört jeden Tag von gesperrten Konten, vergessenen Passwörtern und kaputten Geräten. Misstrauen ist nicht seine Kernaufgabe. Hilfsbereitschaft schon.

Sunny beschreibt diese menschliche Seite des Angriffs ziemlich treffend:

Die meisten Menschen sind sehr nett. Sie glauben nicht, dass jemand sie anlügen oder etwas von ihnen stehlen möchte. Wenn man immer das Beste von jemandem erwartet, kann man getäuscht werden – gerade mit KI.

Deshalb reicht die Aufforderung „Seid bei solchen Anrufen einfach vorsichtiger“ nicht aus. Sie überträgt das komplette Risiko auf eine Person, die unter Zeitdruck eine glaubwürdige Geschichte bewerten soll. Der Prüfprozess muss den Helpdesk schützen. Auch dann, wenn die Stimme vertraut klingt.

Passwort und MFA werden zurückgesetzt

Gelingt die Täuschung, erhält der Angreifer ein neues Passwort, einen zurückgesetzten MFA-Faktor oder einen temporären Zugang. Ab diesem Moment arbeitet er nicht mehr gegen die Eingangstür. Der Helpdesk hat ihm einen neuen Schlüssel ausgestellt. Account Recovery verdient deshalb denselben Schutz wie die normale Authentifizierung. Die aktuellen NIST Digital Identity Guidelines verlangen je nach Schutzniveau mehrere unabhängige Recovery-Nachweise oder eine erneute Identitätsprüfung. Ein Recovery-Ereignis soll außerdem eine Benachrichtigung an den tatsächlichen Kontoinhaber auslösen. Eine starke MFA-Lösung hilft wenig, wenn sich ihr Rücksetzprozess mit einem überzeugenden Telefonat umgehen lässt.

Auch dieses Szenario kommt im Interview sehr konkret zur Sprache:

Sie sagen zum Beispiel: Ich habe mein Handy verloren. Wenn man den MFA-Reset und die anderen Ereignisse innerhalb von vielleicht fünf Minuten zusammensieht, merkt man: Das ist schon komisch. Natürlich kann so etwas passieren – aber die Kombination ist auffällig.

Der einzelne Reset ist plausibel. Der MFA-Wechsel vielleicht auch. Erst die zeitliche Nähe zu einer neuen Anmeldung oder zusätzlichen Berechtigungen verändert die Geschichte.

Warum gültige Konten für Angreifer so wertvoll sind

Viele klassische Sicherheitsmaßnahmen suchen nach bekannten Dateien, Schadcode oder auffälligen technischen Mustern. Wer sich mit einem gültigen Konto anmeldet und vorhandene Administrationswerkzeuge verwendet, hinterlässt andere Spuren.

Der CrowdStrike Global Threat Report 2026 zeigt, wie stark sich die Bedrohungslage bereits verschoben hat:

• 82 Prozent der 2025 erfassten Erkennungen waren malwarefrei.
• Die Aktivität KI-gestützter Angreifer nahm gegenüber dem Vorjahr um 89 Prozent zu.
• Die schnellste beobachtete eCrime Breakout Time lag bei 27 Sekunden.

Malwarefrei heißt nicht spurenfrei. Der Angreifer verzichtet lediglich auf die Schadsoftware, nach der klassische Schutzmechanismen suchen könnten. Stattdessen nutzt er gültige Zugangsdaten, freigegebene Anwendungen und vorhandene Systemwerkzeuge. Für das Security-Team beginnt eine unangenehme Detektivarbeit. Ein Administrator darf auf kritische Systeme zugreifen. Eine Mitarbeiterin darf Dateien aus der Cloud laden. Ein Helpdesk darf Passwörter zurücksetzen. Keines dieser Ereignisse ist allein verdächtig.

Access Broker: Der erste Angreifer muss nicht der letzte sein

Im Interview weist Sunny auf einen weiteren Teil des kriminellen Ökosystems hin: Access Broker.

Ein Hacker kommt hinein, stiehlt Zugangsdaten und verkauft sie weiter. Andere Hackergruppen können diesen Zugang dann benutzen. Das passiert wirklich schnell.

Der erste Angreifer muss also nicht die Person sein, die später Daten verschlüsselt oder aus dem Unternehmen abzieht. Zugangsdaten selbst sind eine Ware. Ein Angreifer verschafft sich Zugang. Ein anderer kauft ihn. Eine dritte Gruppe übernimmt möglicherweise die spätere Erpressung.

Für das betroffene Unternehmen bleibt nur wenig Zeit:

Man muss sich das vorstellen: Das kann in weniger als fünf Minuten passieren. Dann haben sie schon Wege gefunden, sich weiter auszubreiten.

Ein erfolgreich zurückgesetztes Konto ist deshalb kein isolierter Helpdesk-Vorfall. Es kann der Startpunkt einer wesentlich größeren Angriffskette sein.

So wird aus einem Telefonat eine Angriffskette

Nach der Anmeldung muss nicht sofort etwas Spektakuläres passieren. Vielleicht liest der Angreifer zunächst E-Mails, durchsucht interne Verzeichnisse oder prüft, welche Anwendungen erreichbar sind. Er lernt das Unternehmen von innen kennen.

Danach versucht er möglicherweise:

• zusätzliche Authentifikatoren zu registrieren,
• aktive Sitzungen und Tokens zu übernehmen,
• weitere Konten zu kompromittieren,
• Gruppenmitgliedschaften zu verändern,
• privilegierte Zugänge zu finden,
• Cloud- oder SaaS-Anwendungen aufzurufen.

Je mehr Rechte das kompromittierte Konto bereits besitzt, desto weniger Lärm muss der Angreifer verursachen. Der Weg kann anschließend über mehrere Systeme führen. Die erste Anmeldung erfolgt über die Unternehmensidentität. Danach geht es auf einen Laptop, in eine SaaS-Anwendung und vielleicht weiter in die Cloud.

Jedes System sieht einen anderen Ausschnitt:

System	Was es zunächst sieht
Helpdesk-System	Einen abgeschlossenen Supportfall
Identity Provider	Eine erfolgreiche Anmeldung
Endpoint-Lösung	Einen legitimen Prozess
Cloud-Plattform	Einen berechtigten Nutzer
SaaS-Anwendung	Einen regulär angemeldeten Account

Zusammengenommen entsteht ein Muster. Getrennt voneinander bleibt vieles harmlos.

Welche Signale den falschen Nutzer verraten

Eine gute Detection muss wissen, was direkt vor und nach einer Anmeldung passiert ist. Was wurde am Konto verändert? Von welchem Gerät kam der Zugriff? Welche Berechtigungen besitzt die Person? Hat sie diese Rechte früher überhaupt verwendet?

Sunny beschreibt den Kern der Verhaltensanalyse in einem einfachen Satz:

Unsere KI sucht nach dem, was für diese Person nicht normal ist.

Dieses „nicht normal“ kann in verschiedenen Systemen sichtbar werden:

Datenquelle	Mögliches Warnsignal
Helpdesk-System	Passwort- und MFA-Reset in kurzer Folge
Identity Provider	Anmeldung von einem neuen Gerät oder aus einer ungewöhnlichen Region
Endpoint-Telemetrie	Verwendung von Administrationswerkzeugen, die für diese Person untypisch ist
Active Directory oder IAM	Neue Gruppenmitgliedschaft oder zusätzliche Berechtigung
Cloud-Plattform	Zugriff auf bisher nie verwendete Workloads oder Datenbestände
SaaS-Anwendung	Massenhafter Download oder ungewöhnliche API-Nutzung
Threat Intelligence	Infrastruktur oder Vorgehensweise passt zu bekannten Angriffsmustern

Ein einzelnes Signal löst möglicherweise noch keinen Alarm aus. Mehrere passende Signale innerhalb weniger Minuten sollten eine andere Geschichte erzählen. Genau hier wird aus gesammelten Logdaten tatsächlich Security.

Warum MFA allein das Problem nicht löst

MFA bleibt eine wichtige Schutzmaßnahme. Die eingesetzten Verfahren unterscheiden sich allerdings deutlich. SMS-Codes, Einmalpasswörter und Push-Benachrichtigungen können durch Phishing, SIM-Swapping oder wiederholte Freigabeanfragen angegriffen werden. CISA empfiehlt deshalb phishingresistente Verfahren auf Basis von FIDO oder WebAuthn. Dabei wird die Anmeldung kryptografisch an den echten Dienst gebunden. Ein abgefangener Code lässt sich nicht einfach auf einer gefälschten Website verwenden.

Doch auch phishingresistente MFA schützt den Recovery-Prozess nicht automatisch. Entfernt der Helpdesk den bisherigen Faktor und registriert einen neuen, verlagert sich der Angriff. Der Angreifer muss die MFA technisch gar nicht brechen. Er überzeugt einen Menschen davon, sie für ihn neu einzurichten. Das Problem verschwindet also nicht mit einem weiteren Häkchen in der Produktkonfiguration.

Was Unternehmen konkret ändern können

Gebt dem Helpdesk einen belastbaren Prüfprozess

Personalnummer, Geburtsdatum oder der Name der Führungskraft sind keine starken Identitätsnachweise. Solche Informationen können öffentlich verfügbar oder bereits gestohlen sein. Sensible Änderungen sollten über einen registrierten, unabhängigen Kanal bestätigt werden. Für privilegierte Konten braucht es möglicherweise strengere Regeln oder eine zweite Freigabe. Der Helpdesk darf dabei nicht allein gelassen werden. Wenn der Prüfprozess unter Zeitdruck regelmäßig umgangen wird, liegt das Problem nicht bei der einzelnen Supportperson.

Bewertet Reset und Anmeldung als zusammenhängendes Ereignis

Ein Passwort-Reset ist normal. Ein MFA-Wechsel kann ebenfalls legitim sein. Kommen ein neues Gerät, eine ungewöhnliche Region und der Zugriff auf administrative Systeme hinzu, verändert sich die Bewertung. Dafür müssen Helpdesk-, Identity- und Security-Daten zusammenkommen. Sonst sieht jedes Team nur seinen kleinen, scheinbar harmlosen Teil.

Begrenzt privilegierte Zugriffe

Administrationsrechte sollten nur vorhanden sein, wenn sie tatsächlich benötigt werden.

Sunny stellt dazu im Interview eine sehr praktische Frage:

Wer sollte diese Berechtigung haben? Und braucht die Person sie für zwei Minuten oder für zwei Stunden?

Just-in-Time- und Just-Enough-Access verkleinern den Raum, in dem sich ein kompromittiertes Konto bewegen kann. In gewachsenen Umgebungen ist das selten schnell erledigt. Über Jahre angesammelte Gruppenmitgliedschaften, temporäre Rechte, die nie entfernt wurden, und alte Servicekonten machen Berechtigungen schwer durchschaubar. Genau diese vergessenen Zugänge sind für Angreifer interessant.

Überwacht Änderungen an der Identität

Neue Authentifikatoren, veränderte Recovery-Kontakte und zurückgesetzte Konten sind sicherheitsrelevante Ereignisse. Sie gehören protokolliert und mit anderen Signalen korreliert. Der tatsächliche Nutzer sollte sofort eine Benachrichtigung erhalten – nicht Stunden später in einem Sammelreport.

Bereitet die Reaktion vor

Das Sperren des Passworts beendet einen Identitätsangriff möglicherweise nicht. Bereits ausgestellte Tokens und aktive Sitzungen können weiter gültig sein.

Ein Response-Playbook sollte beantworten:

• Wie werden aktive Sessions widerrufen?
• Welche neu registrierten Faktoren müssen entfernt werden?
• Welche Berechtigungen und Gruppen wurden verändert?
• Auf welche Systeme und Daten wurde zugegriffen?
• Welche weiteren Konten könnten betroffen sein?

Wer diese Fragen erst während des Vorfalls diskutiert, verliert Zeit, die ein Angreifer längst nutzt.

Welche Rolle EDR, XDR und Identity Protection spielen

Endpoint Detection and Response zeigt, was auf einem Endgerät geschieht. Identity Protection bewertet Identitäten, Berechtigungen und Authentifizierungsverhalten. XDR kann Signale aus mehreren Sicherheitsbereichen verbinden. Ein gestohlenes Passwort beendet die Verteidigung nicht. Nach der Anmeldung beginnt eine neue Phase, in der das Verhalten des Kontos sichtbar wird.

CrowdStrike Falcon kann dafür Endpoint-, Identity- und Cloud-Signale innerhalb der Plattform korrelieren. Verhaltensanalyse und Threat Intelligence liefern zusätzlichen Kontext. Im Tech Talk spricht Sunny außerdem über die Verbindung aus automatisierten Signalen und menschlichem Threat Hunting:

Wir bekommen automatisiert ein Signal: Hier ist etwas merkwürdig. Gleichzeitig haben wir menschliche Teams, die proaktiv nach bösartigen Aktivitäten suchen.

Eine Plattform repariert trotzdem keinen schwachen Helpdesk-Prozess. Sie entscheidet auch nicht von allein, welche Mitarbeiter welche Rechte benötigen. Das bleibt Arbeit. Technisch, organisatorisch und manchmal ehrlich gesagt ziemlich mühsam. Sie kann jedoch die Signale verbinden, die sonst in getrennten Systemen liegen. Damit erhält das Security-Team eine Chance, den falschen Nutzer hinter einem richtigen Passwort zu erkennen.

Der Moment nach dem Reset zählt

Der gefährlichste Teil eines identitätsbasierten Angriffs sieht häufig völlig normal aus. Ein Anruf. Ein Ticket. Ein erfolgreicher Login. Sunny macht im Gespräch deutlich, warum Security-Teams genauer hinsehen müssen: Angreifer verstehen die menschlichen Abläufe, nutzen öffentlich verfügbare Informationen und passen ihre Geschichte an ihr Ziel an. KI hilft ihnen dabei, schneller und glaubwürdiger zu werden. Unternehmen sollten deshalb davon ausgehen, dass ein Passwort bekannt oder ein Konto bereits übernommen sein könnte. Dann stellt sich eine andere Frage: Verhält sich hier gerade wirklich die Person, der dieses Konto gehört? Genau diese Frage muss sich über Helpdesk, Identity, Endpoint und Cloud hinweg beantworten lassen.

Weiterführende Informationen

Consist hat den Tech Talk mit CrowdStrike geführt und daraus eine Cybersecurity-Masterclass entwickelt. Darin sprechen die Expertinnen und Experten darüber, wie sich moderne Angriffe verändern und welche technischen sowie organisatorischen Antworten Unternehmen darauf brauchen. Consist unterstützt Unternehmen außerdem dabei, Endpoint-, Identity- und Cloud-Security in eine Sicherheitsarchitektur zu übersetzen, die im Alltag funktioniert.