Die meisten Unternehmen wiegen sich in falscher Sicherheit. Der Glaube: „Wir haben Microsoft 365 und die Authenticator-App aktiviert, uns kann nichts passieren.“ Die Realität, die wir bei Incident-Response-Einsätzen sehen, ist eine andere.

Das folgende, anonymisierte Einsatzprotokoll dokumentiert einen erfolgreichen, mehrstufigen Cyberangriff, den unser Team kürzlich forensisch analysiert und abgewehrt hat. Es zeigt, wie Angreifer Vertrauensstellungen ausnutzen und Zwei-Faktor-Authentifizierung (MFA) in Echtzeit aushebeln.

1. Rekonstruktion der Kill-Chain

Der Angriff begann nicht mit einer schlecht geschriebenen E-Mail eines „nigerianischen Prinzen“, sondern nahm seinen Ursprung im Microsoft 365-Tenant eines vertrauenswürdigen externen Geschäftspartners (Patient Null). Ein Angreifer verfügte dort über authentifizierten Zugriff (MAPI) und versendete aus dem echten Postfach heraus Schadnachrichten an unseren Kunden.

Die Methodik zur Umgehung von Sicherheitsfiltern:

  • Cloud-Speicher Missbrauch: Um signaturbasierte E-Mail-Filter (Defender, Barracuda etc.) zu umgehen, beinhaltete die E-Mail keinen direkten Schad-Link, sondern einen legitimen Microsoft OneDrive-Link (1drv.ms). Das dort hinterlegte Dokument enthielt erst die Weiterleitung zur Infrastruktur des Angreifers.
  • Cloaking (Bot-Erkennung): Der Aufruf der Angreifer-Infrastruktur führte zunächst auf ein serverseitiges Prüfskript. Dieses evaluierte die Client-Umgebung, um automatisierte Analyse-Tools von Sicherheitsanbietern aktiv abzuweisen und ausschließlich reguläre, menschliche Anwender passieren zu lassen.
  • Adversary-in-the-Middle (AiTM): Nach Verifikation des Clients erfolgte die Weiterleitung auf eine gefälschte Microsoft-Authentifizierungsseite. Die Angreifer fungierten als unsichtbarer Proxy zwischen dem Anwender und den echten Microsoft-Servern. Durch die Eingabe der Nutzerdaten und Bestätigung in der MFA-App wurde der gültige Sitzungs-Token des Kontos in Echtzeit durch die Angreifer abgegriffen. Die Zwei-Faktor-Authentifizierung war damit wirkungslos.

2. Forensische Nachweise (Technical Evidence)

Wir belassen es nicht bei Vermutungen. Die technische Analyse der Header und der Netzwerk-Telemetrie lieferte klare Beweise.

Verifikation der Ursprungsquelle (Original-Header)

Die Prüfung der Originalnachricht belegte die Authentizität des Absenders. Es handelte sich um kein Spoofing: Authentication-Results: dkim=pass […] spf=pass […] dmarc=pass X-MS-Exchange-CrossTenant-AuthAs: Internal Befund: Der Versand erfolgte über eine reguläre, authentifizierte Benutzersitzung unter Nutzung des MAPI-Protokolls des kompromittierten Geschäftspartners.

Analyse der Angreifer-Infrastruktur

Die netzwerktechnische Überprüfung der extrahierten Ziel-URLs (mittels cURL) dokumentierte die eingesetzten Verschleierungsmethoden: HTTP/2 301 Moved Permanently server: cloudflare set-cookie: PHPSESSID=[Session-ID]; path=/ Befund: Nutzung von Cloudflare zur IP-Maskierung; Protokollwechsel zur Analyse-Erschwerung; Session-Tracking (PHPSESSID) zur serverseitigen Steuerung des AiTM-Phishings in Echtzeit.

Entschlüsselung des polymorphen Schadcodes

Der Abruf des Quelltextes offenbarte ein JavaScript, welches explizit auf Security-Tools prüfte: if(/bot|crawl|spider|headless|phantom|puppet|selenium|lighthouse|wget|curl|scan/i.test(navigator.userAgent))return!1;

Um die Bot-Filterung zur forensischen Beweissicherung zu umgehen, simulierten wir einen regulären Windows-Client inkl. HTTP-Redirect-Follow. Im gesicherten Quelltext stießen wir auf die clientseitige Entschlüsselungsroutine des Angreifers: const tvOoEK… = (rplQ…, EdrX… = 15) => rplQ….map(n => String.fromCharCode(n - EdrX…)).join(’’); const VVjnkPP… = tvOoEK…([116, 133, 112, 123]); Befund: Die ASCII-Verschiebung um den Wert 15 generiert den String eval. Dies initiierte die Ausführung des dynamisch entschlüsselten Payloads zur finalen Kompromittierung des Opfers. Die Rohdaten wurden gesichert und den Ermittlungsbehörden (ZAC) übergeben.

3. Die harten Konsequenzen für Unternehmen

Ein gestohlener Session-Token bedeutet Vollzugriff auf das Microsoft 365-Konto – völlig unabhängig davon, ob Sie eine Authenticator-App nutzen oder SMS-Codes empfangen. Der Angreifer ist im System.

Die primären Risiken in diesem Moment:

  • Data Exfiltration: Geräuschloser, unautorisierter Informationsabfluss von Unternehmens- und Kundendaten.
  • Lateral Movement: Nutzung des legitimen Kontos, um weitere Geschäftspartner zu infizieren oder Ransomware im lokalen Netzwerk vorzubereiten.
  • Persistenz: Anlegen unauffälliger Postfachregeln (Inbox Rules), um die Kommunikation auch nach einem Passwortwechsel weiter zu überwachen.

Was schützt wirklich?

Wenn klassisches MFA nicht mehr ausreicht, muss die Architektursebene greifen. Reine Anwenderschulungen (“Klicken Sie auf keine falschen Links”) scheitern spätestens dann, wenn der Link von einem bekannten Geschäftspartner kommt und auf einen echten Microsoft-OneDrive-Speicherort verweist.

Wirkungsvoller Schutz erfordert Zero-Trust-Architekturen und Conditional Access Policies: Der Zugriff auf Unternehmensdaten darf nicht nur an ein Passwort und einen 2FA-Code geknüpft sein, sondern muss zwingend an den Hardware-Status des Endgeräts (Compliance) und kryptografiebasierte FIDO2-Hardware-Token gebunden werden. Eine Maschine, die wir nicht verwalten, darf keine Daten abrufen – auch nicht mit dem richtigen Passwort.

Nur wer die IT-Infrastruktur als Gesamtsystem denkt und absichert, überlebt den ersten Kontakt mit professionell orchestrierten Angriffen.