Es ist 09:47 Uhr an einem Mittwoch im April, als bei der IT-Hotline der Hanselberg Präzisionstechnik GmbH ein Anruf eingeht. Die Stimme klingt freundlich, leicht gehetzt, der Akzent unauffällig. Der Anrufer stellt sich als Erik vor – „aus der zentralen IT, neuer Kollege, ich bin gerade auf Ihrer Liste gelandet“. Es gehe um eine kurze Authentifizierungsprüfung. Ein Routinefall. Im Hintergrund klingelt ein Telefon, jemand spricht gedämpft, das Geräusch eines Großraumbüros. Die Mitarbeiterin am Helpdesk lächelt, nickt, öffnet das Ticketsystem.

Achtundzwanzig Minuten später ist Hanselberg Präzisionstechnik kein souveränes Unternehmen mehr. Niemand hat eine Tür aufgebrochen, kein Server ist gefallen, keine Firewall hat Alarm geschlagen. Die Multi-Faktor-Authentifizierung hat funktioniert, das Single-Sign-On hat sauber durchgereicht, der Conditional-Access hat keine Anomalie gemeldet. Und doch sind in diesem Moment Konstruktionsdaten eines Triebwerks-Zulieferprojekts, die Lohnliste der gesamten Belegschaft und die strategische Roadmap für 2027 auf einem Server in der Karibik zur Abholung bereit.

Der Vorfall, den wir hier erzählen, ist fiktiv – aber er ist die Konsensgeschichte aus dutzenden realen Vorfällen, die das deutsche Bundesamt für Sicherheit in der Informationstechnik, die US-amerikanische CISA und die Threat-Intelligence-Teams von Mandiant, Microsoft und ReliaQuest seit Anfang 2026 mit einer Frequenz veröffentlichen, die in zehn Jahren Cyber-Berichterstattung beispiellos ist. Die Methode hat einen Namen, der unspektakulär klingt: Vishing, kurz für Voice Phishing. Was sie zur dominanten Eintrittspforte für Datendiebstahl im deutschen Mittelstand gemacht hat, ist die Kombination aus drei Dingen: eine professionalisierte Angreiferszene, billige KI-Stimmenklone und der Umstand, dass die meisten Informationssicherheits-Konzepte der letzten Dekade auf eine Welt ohne Live-Phishing optimiert wurden.

Wie Hanselberg Präzisionstechnik fiel: die Mechanik einer modernen Identitätsattacke

Die Hanselberg Präzisionstechnik GmbH ist mit 340 Mitarbeitenden ein typischer süddeutscher Mittelständler. Hauptsitz in Schwäbisch Gmünd, zwei Werke, eine Tochter in Tschechien. Hauptkunden sind Tier-1-Lieferanten der Luftfahrt- und Automobilindustrie. Die IT besteht aus fünf Personen plus einem externen Dienstleister für die Server-Landschaft. Markus Walter ist seit acht Jahren IT-Leiter und gilt zu Recht als gewissenhaft. Microsoft 365 mit Conditional Access ist seit 2022 produktiv, Okta SSO seit 2024, MFA überall verpflichtend, Phishing-Schulungen jährlich. Auf Papier eine solide Posture.

Schritt 1: Die Zielauswahl

Hanselberg ist auf der Liste der Angreifer aufgetaucht, weil ein Mitarbeiter im Vertrieb sich auf LinkedIn als „SAP-Berechtigungsadministrator“ bezeichnet. Diese eine Information ist aus Sicht der Angreifergruppe Gold wert: Sie verrät, dass es im Haus SAP gibt, dass es Berechtigungs-Workflows gibt und dass der Vertrieblerin in der Berechtigungsverwaltung zumindest eine zweite Rolle zugetraut wird. Die Angreifer fügen Hanselberg zu einer Liste von ungefähr zweihundert deutschen Mittelständlern hinzu, deren Mitarbeitende auf LinkedIn ähnliche Hinweise hinterlassen haben.

Innerhalb der Gruppe – die sich seit Anfang 2026 unter dem Sammelbegriff „Scattered LAPSUS Hunters“ (SLH) zusammengefunden hat, einem Bündnis aus den Akteuren ShinyHunters, Scattered Spider und LAPSUS$ – wird die Liste an Affiliate-Crews verteilt. Eine dieser Crews übernimmt Hanselberg.

Schritt 2: Die Vorbereitung

Eine Woche vor dem Anruf wird auf einer kurzen Domain-Variante (hanselberg-id-portal.com) eine Phishing-Infrastruktur ausgerollt. Sie nutzt das Open-Source-Framework Evilginx in einer angepassten Version, die als Adversary-in-the-Middle (AiTM) zwischen dem Opfer und dem echten Okta-Login sitzt. Die Seite sieht pixelgenau aus wie das Okta-Login von Hanselberg, weil sie die echten Inhalte live durchreicht. Was das Opfer eingibt, sieht der Angreifer in Echtzeit – inklusive der MFA-Antwort. Mit dem Session-Cookie, das Okta nach erfolgreicher Authentifizierung ausstellt, kann der Angreifer den Browser des Opfers bis zur nächsten Re-Authentifizierung übernehmen.

Parallel werden zwei Stimmenproben des realen IT-Leiters Markus Walter aus einem öffentlich verfügbaren YouTube-Vortrag extrahiert und in ein Voice-Cloning-Modell eingespeist. Das Modell ist seit 2025 frei verfügbar, läuft auf einer Mittelklasse-GPU, und produziert eine Imitation, die in einem dreißigsekündigen Telefonat über VoIP nicht von der Originalstimme zu unterscheiden ist. Diese Imitation ist nicht für den Helpdesk gedacht – sie ist Reserve, falls eine Rückrufprüfung initiiert wird.

Schritt 3: Der Anruf

Der eigentliche Vishing-Anruf am Mittwochmorgen ist auf zwei parallele Aktionen ausgelegt. Während der Anrufer „Erik“ die Helpdesk-Mitarbeiterin in ein Gespräch über eine angebliche Authentifizierungsprüfung verwickelt, lockt eine zweite Person das eigentliche Opfer – die Vertriebsmitarbeiterin – per E-Mail auf die vorbereitete Phishing-Domain. Die E-Mail trägt das Hanselberg-Logo, kommt von it-security@hanselberg-id-portal.com und behauptet, ein Sicherheitsupdate erfordere eine erneute Anmeldung. Die Helpdesk-Mitarbeiterin, die parallel im Telefonat mit „Erik“ erfährt, dass es um genau diese Mitarbeiterin gehe, bestätigt arglos, dass alles seine Ordnung habe.

Die Vertriebsmitarbeiterin gibt ihre Zugangsdaten ein. Das AiTM-Framework reicht sie an das echte Okta weiter. Okta sendet eine Push-Benachrichtigung an ihr Smartphone. Sie bestätigt – schließlich hat sie ja gerade das Login angestoßen, die Helpdesk-Kollegin hat es ihr telefonisch nachher noch bestätigt. Die MFA-Antwort wird vom Framework durchgereicht, und der Session-Cookie landet in den Händen der Angreifer.

Schritt 4: Die Eskalation

In den nächsten zehn Minuten passieren Dinge, die in keinem Posture-Bericht auftauchen. Der Angreifer importiert das Cookie in einen Browser auf einem Server in Bulgarien, der so konfiguriert ist, dass sein User-Agent und seine Schriftarten exakt dem Endgerät der Vertriebsmitarbeiterin entsprechen. Conditional Access von Microsoft prüft die Geräte-Compliance, sieht aber nur, dass das Cookie gültig ist und das Endgerät auf den ersten Blick passt. Der Angreifer öffnet OneDrive, SharePoint, das CRM, das ERP-Frontend. Er lädt nichts herunter, sondern nutzt den eingebauten OAuth-Mechanismus von Salesforce, um eine vermeintlich legitime „Data-Loader“-App mit dem Konto der Vertrieblerin zu verknüpfen. Dieser OAuth-Token überlebt die nächste Anmeldung, das nächste MFA-Reset, sogar die Sperrung des Kontos. Es ist ein eigener, unabhängiger Schlüssel zum Königreich.

Über diesen Token werden in den folgenden vier Tagen Stück für Stück 84 Gigabyte an Konstruktionsdaten, Lieferantenverträgen und HR-Daten exfiltriert. Niemand bemerkt es, weil das CRM-Auditing OAuth-Apps anders behandelt als Endbenutzer-Zugriffe und weil das SIEM des externen Dienstleisters nur Events aus der Microsoft-Welt korreliert, nicht aus Salesforce.

Schritt 5: Die Erpressung

Erst am dritten Mai erhält Markus Walter eine E-Mail. Absender: eine Wegwerf-Adresse, Logo: das eigene SLH-Branding. Die Forderung: 1,2 Millionen Euro in Monero. Der Beweis: ein Auszug aus den Konstruktionsdaten eines Triebwerks-Zulieferprojekts, das unter NDA mit einem deutschen Luftfahrt-Konzern steht. Markus Walter setzt sich, telefoniert mit dem Geschäftsführer, mit dem Wirtschaftsanwalt, mit dem Cyber-Versicherer. Er fragt sich, was er hätte besser machen sollen.

Technische Analyse: warum klassisches MFA nicht reicht

Die Geschichte von Hanselberg ist keine Geschichte von schlechter Hygiene. Sie ist eine Geschichte davon, dass die in den 2010er-Jahren entwickelten MFA-Verfahren – TOTP-Codes, Push-Bestätigungen, SMS – auf eine Bedrohungslage reagiert haben, in der Phishing-Seiten statisch und Angreifer langsam waren. Beide Annahmen gelten 2026 nicht mehr.

Ein klassischer Push-Faktor sagt dem Identity-Provider sinngemäß: „Hier ist ein Mensch, der seine Anmeldung bestätigt.“ Was er nicht sagen kann, ist: „Hier ist der Mensch, der gerade auf der echten Seite des Identity-Providers gelandet ist.“ Die AiTM-Architektur nutzt genau diese Lücke. Aus Sicht des Identity-Providers passt alles. Aus Sicht des Anwenders passt alles. Nur in der Mitte – und damit für die Angreifer – gibt es eine zweite, unsichtbare Sitzung.

Die einzige MFA-Variante, die diese Lücke schließt, ist phishing-resistente MFA auf Basis von WebAuthn / FIDO2. Hier signiert der zweite Faktor (ein YubiKey, ein im Endgerät eingebauter Authenticator, ein Passkey) eine kryptografische Challenge, die fest an die echte Domain des Identity-Providers gebunden ist. Steht im Browser nicht hanselberg.okta.com, sondern hanselberg-id-portal.com, weigert sich der Authenticator, die Challenge zu signieren. Das Opfer kann zustimmen, so oft es will – die Antwort kommt schlicht nicht zustande.

Diese Eigenschaft ist nicht nur eine inkrementelle Verbesserung. Sie ist der einzige Weg, AiTM strukturell zu neutralisieren. Wer in den letzten zwei Jahren mit Microsoft, Okta, Google oder dem BSI gesprochen hat, hat dieselbe Empfehlung gehört: Phishing-resistente MFA für privilegierte Konten ist kein Luxus mehr, sondern Stand der Technik.

User Story – Was Markus Walter heute anders machen würde

Markus Walter, der IT-Leiter, hat sich in den Wochen nach dem Vorfall eine Liste gemacht. Sie ist zu lang für einen einzelnen Beitrag, aber sie hat fünf Schwerpunkte, die er auch in Vorträgen vor anderen Mittelständlern beschreibt.

1. Phishing-resistente MFA als Basis, nicht als Kür

Hanselberg hat innerhalb von acht Wochen alle administrativen und ein Drittel aller produktiven Konten auf FIDO2-Hardware-Tokens und Passkeys umgestellt. Die Beschaffungskosten lagen bei rund 18 Euro pro Mitarbeiter und Token, die Einführungskosten waren überschaubar, die Akzeptanz hoch – nicht zuletzt, weil das tägliche Klicken auf Push-Benachrichtigungen wegfiel. „Wir hätten das längst tun können“, sagt Walter heute. „Aber wir hatten den falschen Vergleichsmaßstab: Wir haben gefragt, ob es nötig sei, statt zu fragen, was es kostet, wenn es passiert.“

2. Helpdesk-Hardening

Der Anruf an die Hotline war in der Hanselberg-Geschichte das eigentliche Einfallstor. Die neue Hotline-Anweisung sieht vor, dass jede Identitäts- oder Berechtigungsanfrage über das Telefon ausschließlich nach Rückruf an die im Active Directory hinterlegte Nummer behandelt wird. Eine zweite Maßnahme: Authentifizierungsfragen, die der Mitarbeiter selbst nicht beantworten könnte (etwa der Name des unmittelbaren Vorgesetzten zwei Reorganisationen zurück). Eine dritte: ein internes Wort des Tages, das jeden Morgen in einer Slack-Push-Benachrichtigung an alle berechtigten Rollen geht und das in jedem Helpdesk-Kontakt fallen muss. Diese drei Maßnahmen klingen banal. Sie sind genau deshalb wirksam, weil Vishing-Crews auf der genauen Annahme operieren, dass Banales nicht gemacht wird.

3. Just-in-Time-Privilegien und OAuth-Hygiene

Die zweite große Lücke war der OAuth-Token, der nach der Sperrung des Kontos weiterhin Daten exfiltrierte. Hanselberg hat in seinem Salesforce, in Microsoft 365 und in der internen SSO-Plattform eine harte Regel etabliert: Drittanwendungen mit OAuth-Zugriff werden nur durch einen Administrator und mit Zeitfenster genehmigt, alle bestehenden Verbindungen alle 90 Tage neu bestätigt. Privilegierte Konten erhalten ihre Rechte nur auf Anforderung („Just-in-Time“) für höchstens vier Stunden. Diese Maßnahmen reduzieren nicht die Wahrscheinlichkeit eines Vorfalls, aber sie verkürzen das Zeitfenster eines erfolgreichen Angreifers von Wochen auf Stunden.

4. Identity-Centric Detection

Das SIEM von Hanselberg korrelierte vor dem Vorfall ausschließlich Events aus dem Microsoft-Umfeld. Heute fließen Identity-Logs aus Okta, OAuth-Aktivitäten aus Salesforce, M365 Audit Logs und das DNS-Logging zusammen in eine zentrale Plattform. Die wichtigste Detection-Regel: jede Anmeldung, deren Geo-Location, Geräte-Fingerprint und Login-Zeit zueinander stimmen, aber von einer ASN kommt, die in den letzten 30 Tagen nicht zu diesem User gesehen wurde. Diese Regel hätte den Bulgarien-Server in Echtzeit auffallen lassen.

5. Tabletop-Übungen, die wirklich wehtun

Walter hat im November 2026 eine Tabletop-Übung mit der Geschäftsführung, der Personalabteilung und dem Wirtschaftsprüfer durchgeführt, die genau das Hanselberg-Szenario nachgespielt hat. „Wir haben in zwei Stunden mehr über unsere blinden Flecken gelernt als in zwei Jahren Audits“, sagt er. Die wichtigsten Erkenntnisse betrafen nicht die Technik, sondern die Kommunikation: Wer informiert wen, wann, in welcher Reihenfolge? Welche Aussagen darf der Geschäftsführer öffentlich machen, welche nicht? Wer entscheidet, ob die Cyber-Versicherung kontaktiert wird?

Breitere Einordnung: das SLH-Phänomen und die Industrialisierung der Identitätsattacke

Der Zusammenschluss von ShinyHunters, Scattered Spider und LAPSUS$ zur Scattered LAPSUS Hunters ist mehr als ein Branding-Manöver. Threat-Intelligence-Berichte aus den ersten Monaten 2026 beschreiben eine Struktur, die einer kriminellen Franchise ähnelt: zentrale Infrastrukturteams stellen die Phishing-Frameworks, das Voice-Cloning, die Datenleck-Plattformen und die Erpressungs-Verhandler bereit. Affiliate-Crews bekommen Ziele zugewiesen, führen die Operationen durch und teilen die Erlöse nach einem festen Schlüssel. Diese Industrialisierung sorgt dafür, dass auch eher unscheinbare Mittelständler in den Fokus geraten – schlicht weil die Crews quantitativ arbeiten und die Kostenstruktur pro angegriffenem Unternehmen extrem niedrig ist.

Für die deutsche Industrie heißt das: Es gibt kein „zu klein für Cyberkriminalität“ mehr. Eine Hanselberg Präzisionstechnik mit 340 Mitarbeitern ist nicht uninteressant – sie ist gerade interessant genug, weil sie wertvolle Zulieferer-Daten hält und gleichzeitig nicht über die Sicherheits-Ressourcen eines DAX-Konzerns verfügt. Die Logik der Angreifer ist nicht „Wir suchen den größten Fisch“, sondern „Wir suchen den profitabelsten pro investierter Stunde“.

Regulatorischer Druck: NIS2, DORA und die Frage der Berichtspflicht

Mit der Umsetzung der NIS2-Richtlinie ist in Deutschland seit Dezember 2025 Recht, was lange nur Empfehlung war: Unternehmen, die als „wesentlich“ oder „wichtig“ eingestuft sind, müssen erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden initial und innerhalb von 72 Stunden detailliert beim BSI melden. Ein Vorfall wie der von Hanselberg fällt klar in diesen Bereich, sobald die Verfügbarkeit oder Vertraulichkeit signifikant betroffen ist. Wer die Meldepflicht verpasst, riskiert nicht nur Bußgelder bis zu zehn Millionen Euro oder zwei Prozent des Jahresumsatzes – er riskiert auch persönliche Haftung der Geschäftsleitung. Mehr dazu in unserem Beitrag zu den NIS2-Pflichten und wie eine Compliance-Software diese Prozesse strukturiert.

Handlungsempfehlungen für IT-Leiter und Geschäftsführer

Wenn wir die Lehren aus dem Hanselberg-Szenario in eine Liste gießen, die ein deutscher Mittelständler in den nächsten 90 Tagen umsetzen kann, sieht sie so aus:

Sofort (innerhalb von 14 Tagen): Bestandsaufnahme aller administrativen Konten und privilegierten Rollen. Identifikation aller Konten, die heute noch ausschließlich mit Push-MFA, SMS oder TOTP geschützt sind. Erstellung eines Migrationsplans hin zu phishing-resistenter MFA. Hardening der Helpdesk-Prozesse für identitätsbezogene Anfragen.

Mittelfristig (innerhalb von 90 Tagen): Einführung eines Just-in-Time-Privilegien-Modells für Administratoren. Inventur aller OAuth-Verbindungen in den großen SaaS-Plattformen. Aufbau eines zentralen Identity-Logs mit Korrelationsregeln über mindestens drei Quellen (IdP, Cloud-Office, ERP/CRM). Tabletop-Übung mit der Geschäftsführung.

Strategisch (innerhalb von zwölf Monaten): Einführung einer durchgängigen Zero-Trust-Architektur mit Geräte-Compliance, Identity-First-Detection und einem Notfall-Playbook, das die Beziehung zur Cyber-Versicherung, zum BSI und zu externen Forensik-Partnern eindeutig regelt. Schulungsprogramm, das nicht auf E-Mail-Phishing beschränkt ist, sondern Vishing, QR-Code-Phishing und KI-Stimmen explizit adressiert.

Die einzelnen Maßnahmen sind keine Geheimwissenschaft. Was sie selten macht, ist die Konsequenz, mit der sie umgesetzt werden – und die Bereitschaft, dafür Komfort und gewohnte Prozesse aufzugeben. Für viele IT-Leiter ist die schwierigste Hürde nicht die Technik, sondern die Vermittlung gegenüber der Geschäftsführung, dass „wir hatten doch schon MFA“ keine ausreichende Antwort mehr ist.

Ausblick: was 2026 noch bringen wird

Die nächste Welle der Identitätsattacken wird drei Eigenschaften haben. Erstens: noch bessere Stimmenklone, die in Echtzeit auf Gespräche reagieren statt nur Voicemails zu hinterlassen. Zweitens: stärkere Integration zwischen Phishing-Frameworks und großen KI-Modellen, sodass die Angreifer-Seite mit dem Opfer textuell auf einem Niveau interagiert, das menschliche Sicherheits-Awareness an ihre Grenzen bringt. Drittens: Ausweitung von der reinen Datenexfiltration auf manipulative Eingriffe – Buchungen verändern, Verträge fälschen, Lieferketten umlenken. Wer 2027 noch glaubt, dass „wir haben nichts zu verbergen“ ein Argument sei, wird eines Besseren belehrt werden.

Die gute Nachricht: Die Verteidigungsseite hat ihre Werkzeuge. Phishing-resistente MFA, identitätszentrische Detection, OAuth-Hygiene und ein nüchterner Helpdesk-Prozess sind keine Zukunftsmusik, sondern Stand der Technik. Was fehlt, ist in vielen Häusern die Entscheidung, sie auch umzusetzen.

Wenn Sie diese Entscheidung in Ihrem Unternehmen unterstützen wollen – sei es durch eine ehrliche Bestandsaufnahme, ein Tabletop-Szenario, das wirklich wehtut, oder durch die Einführung phishing-resistenter MFA – dann ist pleXtec ein Partner mit Erfahrung in genau diesen Projekten. Sprechen Sie uns über das Kontaktformular an, und wir besprechen mit Ihnen, wie ein realistischer Fahrplan für die nächsten 90 Tage aussehen kann. Markus Walter, der IT-Leiter unserer fiktiven Hanselberg Präzisionstechnik, hätte sich gewünscht, dieses Gespräch zwei Monate früher geführt zu haben.