Der Anruf kam aus dem Helpdesk selbst

Am 24. April hat BleepingComputer berichtet, über ein finanziell motiviertes Cluster, das Palo Altos Unit 42 als CL-CRI-1116 verfolgt, auch bekannt als BlackFile, auch bekannt als UNC6671, und das CrowdStrike (separat, aber wahrscheinlich dieselben Leute, oder zumindest Cousins) als Cordial Spider bezeichnet. Die Taxonomie ist ein Durcheinander. Das Verhalten ist es nicht.

Hier ist das Verhalten, in der Reihenfolge, in der es Ihnen widerfährt:

1. Sie bekommen einen Anruf. Die Anrufer-ID weist auf die interne IT hin oder kommt nahe genug heran — gefälschtes VoIP oder ein manipulierter CNAM (der menschenlesbare Name, den das Telefonnetz neben einer Nummer anzeigt und der sich, wie sich herausstellt, nicht sonderlich gut authentifizieren lässt). Die Person am Telefon ist freundlich und etwas entschuldigend. Es tut ihr sehr leid, dass sie stört. Es gibt ein kleines Problem mit Ihrem Konto.
2. Um das kleine Problem mit Ihrem Konto zu beheben, möchte sie, dass Sie sich auf einer Unternehmensseite anmelden, deren Link sie Ihnen per SMS schickt — oder Sie manchmal einfach dorthin lotst. Die Seite sieht korrekt aus. Sie hat das Firmenlogo. Sie hat den richtigen Wortlaut. Sie ist nicht die richtige Seite.
3. Sie tippen Ihr Passwort. Die Seite fragt nach Ihrem Einmalcode aus der Authenticator-App. Den tippen Sie auch.
4. Die Seite bedankt sich und zeigt eventuell einen Spinner. Sie legen auf.
5. Der Angreifer auf seinem eigenen Laptop, irgendwo anders, nimmt Ihr frisch eingegebenes Passwort und Ihren frisch eingegebenen sechsstelligen Code, meldet sich innerhalb der nächsten neunzig Sekunden in Ihrem echten SSO-Portal an und — und das ist der elegante Teil — registriert sein eigenes MFA-Gerät auf Ihrem Konto.
6. Er ist jetzt Sie. Er hat einen dauerhaften zweiten Faktor, der in seiner Tasche steckt. Ihr zweiter Faktor funktioniert auch weiterhin, weshalb es niemandem auffällt.
7. Er geht in Salesforce, er geht in SharePoint, er sucht nach Dateien mit den Wörtern „confidential" oder „SSN" darin, lädt alles herunter, was er kann, und eine Woche später erhält Ihr CEO eine siebenstellige Erpresser-Mail von einer Gmail-Adresse. Manchmal erhalten Mitarbeitende laut BleepingComputers Bericht auch Swatting-Drohungen, was ein Maß an Kundenservice ist, das den meisten Erpresserbanden zu lästig wäre.

Wie auch immer.

Wo genau der Angriff stattfindet

Es lohnt sich, präzise zu sein, welcher Teil dieser Kette wo läuft, denn die Kette läuft nicht überall am selben Ort.

Der Anruf läuft über das Telefon. Der Anruf hat Telefonform. Kein Browser, kein Laptop, kein Betriebssystem, das man patchen kann, kann gegen den Anruf selbst etwas ausrichten, weil der Anruf nicht auf dem Laptop läuft. (Man kann Leute schulen, man kann Schilder im Pausenraum aufhängen, man kann den echten Helpdesk nach jedem legitimen Anruf eine Folge-E-Mail schicken lassen, und das alles hilft, aber der Anruf ist, wie man im Fach sagt, ein menschenförmiges Problem.)

Die gefälschte Login-Seite läuft in einem Browser. Konkret läuft sie in irgendeinem Browser, den die Mitarbeiterin gerade auf ihrem Arbeits-Laptop geöffnet hat, in irgendeinem Profil, das sie zuletzt benutzt hat, mit allen Sitzungen, Cookies und Autofill-Passwörtern, die sie zufällig mit sich herumträgt. Dieser Teil ist ein computerförmiges Problem.

Die MFA-Registrierung auf dem echten Konto läuft auf dem Laptop des Angreifers, in dessen Browser, gegen das legitime SSO-Portal. Das ist überhaupt kein Problem im Browser des Nutzers; es ist ein Problem damit, wie das SSO-Portal die MFA-Anmeldung handhabt, wenn jemand das Passwort und ein aktuelles OTP kennt. Ihr IdP (der Identity Provider, der SSO betreibt — Okta, Entra ID, Google Workspace, je nachdem, welcher entschieden hat, dass Ihr Passwort korrekt ist) wertet „ich habe das Passwort und ein frisches OTP" als ausreichenden Beweis, um einen weiteren Faktor hinzuzufügen. Das ist eine Richtlinienentscheidung, und es ist die Richtlinie, mit der die meisten Unternehmen standardmäßig ausgeliefert werden, weil die Alternative wäre, dass sich Nutzer aussperren, sobald sie ihr Telefon ersetzen.

Die Salesforce- und SharePoint-Exfiltration läuft ebenfalls auf dem Laptop des Angreifers, gegen Ihre echte SaaS, mit dessen frisch geprägtem zweiten Faktor. Dieser Teil ist im strengen Sinne kein „Angriff auf den Browser des Mitarbeiters". Es ist der Angreifer, der sich wie ein normaler Mensch anmeldet, denn an diesem Punkt ist er ein normaler Mensch. Der Browser Ihrer Mitarbeiterin saß die letzten drei Schritte aus.

Wenn Sie also nach einem einzelnen technischen Hebel suchen, mit dem Sie BlackFile von Anfang bis Ende verhindern, gibt es keinen. Der Angriff ist auf ein Telefon, eine gefälschte Seite, eine IdP-Richtlinie und den Laptop eines Angreifers verteilt.

Was es gibt — und das ist der einzige Teil der Kette, zu dem ein Browser-Hersteller glaubwürdig etwas sagen kann — ist der zweite Schritt, die gefälschte Login-Seite. Die Seite muss irgendwo gerendert werden. Wo immer sie gerendert wird, tippt die Mitarbeiterin echte Anmeldedaten und ein echtes OTP ein. Die Frage ist also nur: in welcher Art Container möchten Sie, dass dieses Ereignis stattfindet?

Die Seite muss irgendwo gerendert werden

Richtig. Die Seite wird also in einem Browser gerendert. In welchem Browser?

Wenn Sie nichts unternehmen, wird sie in dem Browser gerendert, den die Mitarbeiterin gerade benutzt hat — Chrome auf einem privaten Laptop, Edge auf einem Firmen-Laptop, Safari auf dem iPad, das zufällig griffbereit war. Welcher Browser auch immer es ist, er ist seit einer Weile im Einsatz. Er hat ein Profil, das seit einer Weile existiert. Dieses Profil hat wahrscheinlich bereits Cookies für das echte Unternehmens-SSO-Portal, weil sich die Mitarbeiterin jeden Morgen bei der Arbeit anmeldet. Es hat gespeicherte Passwörter. Es hat einen Autofill-Vorschlag, der hilfreicherweise das tatsächliche Unternehmenspasswort ist — außer, dass Autofill auf einer Phishing-Domain korrekterweise nicht greift (Browser sind darin gut), also tippt die Nutzerin es manuell, was sie ebenfalls gut beherrscht, denn sie hat es schon zehntausendmal getan.

Die gefälschte Seite braucht keines dieser Cookies. Die gefälschte Seite braucht nur, dass die Finger des Nutzers das tun, was Finger tun, wenn eine Seite nach einem Passwort fragt. Die gefälschte Seite sammelt das Passwort. Die gefälschte Seite sammelt das OTP. Die gefälschte Seite ist fertig.

Aber hier ist die Frage, die mich umtreibt. Warum war ausgerechnet der persönliche Browser der Mitarbeiterin, mit seinem langlebigen Profil und seiner Sammlung jeder Seite, bei der sie sich je angemeldet hat, der Ort, an dem die gefälschte Unternehmens-Login-Seite überhaupt gerendert wurde? Die Seite gibt vor, vom Unternehmen zu sein. Die Nutzerin ist bei der Arbeit. Die Nutzerin tut, soweit sie das beurteilt, arbeitsbezogene Dinge. Warum rendert „die Login-Seite des Unternehmens" in derselben Software-Umgebung wie „der Spotify-Share-Link der Cousine" und „ein Etsy-Konto von 2018"?

Das ist, denke ich, die Frage.

Das Argument für den verwalteten Browser, klein gemacht

Hier ist die kleine, schmale, ehrliche Version des Bromure-Arguments für diesen Angriff.

Eine IT-Abteilung kann Bromure als den freigegebenen Unternehmens-Browser ausrollen. Nicht als den einzigen Browser auf dem Laptop — die Nutzerin kann weiter Chrome und Safari für Privates haben — sondern als den einzigen Browser, der konfiguriert, eingerichtet und sichtbar als der Ort gekennzeichnet ist, an dem Unternehmens-SaaS leben soll. Bromure hat eine Enterprise-Tab in den Einstellungen, dessen ganze Aufgabe genau das ist: ein Feld für einen HTTP-Proxy und ein Slot für interne Root-Zertifikate. Zwei Einstellungen. Mehr macht er nicht, und das ist absichtlich alles, was er tut. Eine Organisation konfiguriert diese beiden Dinge einmal, übergibt den Mitarbeitenden ein Bromure-Profil, das vorab so konfiguriert ist, dass es der Unternehmens-CA vertraut und über den Unternehmens-Proxy routet, und lässt das Profil sichtbar zu dem Ort werden, an dem Unternehmens-SaaS lebt.

(Wir behaupten nicht, dass der Enterprise-Tab eine vollständige MDM-Steuerebene ist. Es sind zwei Textfelder. Zwei gut gewählte Textfelder sind manchmal genug.)

Innerhalb von Bromure ist jeder Tab seine eigene wegwerfbare Linux-VM mit eigenem flüchtigem Profil. Wenn also der Salesforce-Tab des Unternehmens öffnet, öffnet er sich in einer verwalteten VM, die den Unternehmens-Proxy kennt und der Unternehmens-CA vertraut. Wenn die Mitarbeiterin getrennt davon den Spotify-Share-Link der Cousine öffnet, öffnet der sich in einer anderen VM mit einem anderen Profil, das nichts davon hat.

Jetzt findet der Anruf weiterhin auf genau dieselbe Weise statt. Die Nutzerin wird weiterhin zu einem Link gelotst. Folgendes ändert sich:

• Der Link öffnet sich beim Klicken in irgendeiner Bromure-VM. Standardmäßig öffnet er sich nicht in derselben VM wie die echte Salesforce-Sitzung der Mitarbeiterin. (Profile in Bromure verschmelzen nicht stillschweigend. Die Seite, die in einem „Wegwerf-Link"-Profil geladen wird, kann keine Cookies aus dem „Unternehmens-Salesforce"-Profil lesen, weil sie in unterschiedlichen VMs mit unterschiedlichen Netzwerkstapeln und unterschiedlichen Festplatten leben.)
• Die Nutzerin tippt möglicherweise trotzdem echte Unternehmens-Anmeldedaten und ein echtes OTP in die Seite. Bromure hält das Tippen nicht auf. Das ist der ehrliche Teil.
• Das Sitzungs-Token (oder, je nach Kit, manchmal nur die Cookies), das die Seite einsammelt, lebt in einem Profil, das die Nutzerin gleich schließen wird, auf einer VM, die gleich gewischt wird, ohne privilegierte Beziehung zu irgendetwas Unternehmens-Bezogenem. Das abgegriffene Token ist in diesem Sinne minderwertig — es ist ein Souvenir aus einem Tab.

Bei diesem letzten Punkt möchte ich vorsichtig sein, denn das ist genau die Art von Sache, bei der man leicht über das Ziel hinausschießt.

In der dokumentierten BlackFile-Kette wird das abgegriffene Token gar nicht benutzt, um sich beim echten Salesforce anzumelden — der Angreifer benutzt die Anmeldedaten und das OTP, um sich von seinem eigenen Laptop aus beim echten SSO-Portal anzumelden, und registriert sein eigenes MFA-Gerät. Die abgegriffenen Cookies wären sowieso nie gegen die echte Unternehmenssitzung wiederverwendet worden, weil es Cookies für eine Phishing-Domain sind, nicht für die echte Domain. Wo Bromures VM-Isolation pro Tab eine Rolle spielt, ist das Bein hinter der gefälschten Seite: jede Mauschelei auf Tab-Seite (Token-Exfiltration zu einem Angreifer-Endpunkt, Folge-Skripte, die versuchen, andere Cookies zu lesen, Weiterleitungsketten, die weitere Payloads abwerfen) ist in einer VM eingesperrt, deren Dateisystem, Netzwerk und Prozessbaum vom Rest des Laptops und von der echten Unternehmens-Browser-Sitzung versiegelt sind. Die gefälschte Seite ist eine gefälschte Seite. Sie darf nur eine gefälschte Seite in einer Box sein.

Der sichtbare Hinweis tut in diesem Diagramm besonders viel Arbeit, und es lohnt sich, das laut auszusprechen. Eine verwaltete Browser-Bereitstellung, deren einzige Funktion „der Salesforce-, SharePoint- oder Workday-Tab des Unternehmens sieht sichtbar anders aus als der Random-Link-Tab" ist, ist für sich allein eine nicht-triviale Verteidigung, denn das kanonische BlackFile-Opfer ist ein müder Mensch, der an einem Donnerstag um 16:45 Uhr einen Anruf bekommen hat. Die sichtbare Unterscheidung ist keine UI-Schnörkelei; sie ist das ganze Spielfeld.

Was das nicht behebt

Ich möchte hierzu weiterhin ehrlich sein, denn das Versagensmuster ist ein Anbieter, der erklärt, wie sein Produkt einen Angriff verhindert hätte, und beim genauen Lesen einen anderen Angriff beschreibt.

Es stoppt den Anruf nicht. Der Anruf läuft auf dem Telefon. Bromure läuft nicht auf dem Telefon, sieht das Telefon nicht und hat keine Meinung zum Telefon. Wenn die Nutzerin abnimmt und von einer freundlichen Stimme überzeugt wird, dass es ein kleines Problem mit ihrem Konto gibt, wird die Nutzerin sich eine gefälschte Login-Seite ansehen. Wir können ändern, in welchem Browser die Seite gerendert wird. Wir können nicht ändern, ob die Nutzerin sie ansieht.

Es stoppt das Tippen nicht. Wenn die Nutzerin echte Anmeldedaten und ein echtes OTP in die gefälschte Seite tippt, sind diese Anmeldedaten und dieses OTP nun im Besitz des Angreifers, unabhängig davon, wo die Seite gerendert wurde. Die Tatsache, dass die Seite in einer wegwerfbaren VM läuft, macht das Getippte nicht ungeschehen.

Es stoppt die MFA-Registrierung nicht. Das MFA-Registrierungs-Bein findet auf dem Laptop des Angreifers statt, gegen den legitimen IdP. Bromure läuft nicht auf dem Laptop des Angreifers, und Bromure ist nicht der IdP. Die Gegenmaßnahme liegt hier auf der IdP-Seite, und sie ist die langweilige: schalten Sie „Step-up-Authentifizierung für neue MFA-Registrierung erforderlich" ein, beschränken Sie Registrierungen auf das Unternehmensnetz oder ein verwaltetes Gerät, alarmieren Sie bei der Registrierung neuer Faktoren — und akzeptieren Sie, dass die Alternative bedeutet, dass sich Nutzer aussperren, wenn sie ein neues Telefon bekommen. Diese Konfigurationsentscheidung kann jeder Okta- und Entra-ID-Admin heute treffen, viele haben es nicht getan, und das ist — gelinde gesagt — der Teil dieser Geschichte, der CISOs eher wachhalten sollte als der Browser-Teil.

Es stoppt im strengen Sinne keinen Echtzeit-AiTM-Proxy-Angriff. Eine separate Klasse von Phishing-Kits (Evilginx, Modlishka, Caffeine, die AiTM-as-a-Service-Mieten zu 2.500 USD pro Stück, die sich zum dominierenden Microsoft-365-Angriffsmuster entwickelt haben) macht Echtzeit-Relay: die Nutzerin tippt in eine Seite, die in Echtzeit zum legitimen IdP weiterleitet. Das Sitzungs-Cookie, das der IdP ausgibt, geht an den Proxy; der Proxy reicht es an den Angreifer weiter. Wenn Sie sich einen BlackFile-artigen Anruf vorstellen, der die Nutzerin auf eine solche Seite lenkt — was BlackFile derzeit nicht zugeschrieben wird, was aber die Richtung ist, in die sich die Kategorie bewegt — dann ist das abgegriffene Cookie ein echtes Sitzungs-Cookie für den legitimen IdP, und die Frage wird, ob es von woanders aus wiedergegeben werden kann. Das ist ein anderer Beitrag und ein schwierigerer, und die ehrliche Antwort umfasst Sitzungsbindungs-Mechanismen (DBSC, mTLS-gebundene Tokens), die meist Sache des IdP und nur teilweise Sache des Browsers sind. Wir werden darüber nicht den Zauberstab schwenken.

Was verwaltetes Bromure schmal tut: es sorgt dafür, dass die gefälschte Seite an einem Ort gerendert wird, der unverwaltet, flüchtig und sichtbar von der verwalteten Unternehmensumgebung verschieden ist. Es beschränkt den Sprengradius beliebiger Tricks nach dem Seitenaufruf (Erweiterungsinstallationen, Schreibvorgänge auf das Host-Dateisystem, Persistenz), die das Kit ziehen könnte, auf eine VM, die ohnehin verschwindet. Und in der dokumentierten BlackFile-Kette verhindert es für sich allein nicht, dass der Angreifer anschließend sein eigenes MFA-Gerät registriert — das ist Sache des IdP. Wir mildern eine der vier Maschinen in der Kette, und zwar die einzige, auf der wir laufen.

Warum das letztlich der einzige Weg ist

Wie auch immer. Schauen Sie. Treten Sie einen Schritt zurück.

Das Bemerkenswerte an BlackFile ist, dass es ein bemerkenswert effizientes Geschäft ist. Sie haben sich Einzelhandel und Hotellerie ausgesucht, weil Einzelhandel und Hotellerie viele Mitarbeitende, verteilte Schichten, Nachtdienste, echte IT-Helpdesk-Teams haben, die Mitarbeitende tatsächlich anrufen, und eine Belegschaft sehr gestresster Menschen, die wirklich nicht der Grund sein wollen, warum die Kassen ausgefallen sind. Sie haben sich Vishing ausgesucht, weil Vishing skaliert (eine Person am Telefon kann in einer Stunde ein Dutzend Ziele anrufen, und die Erfolgsquote ist nach den Maßstäben dieser Branche unglaublich) und weil der Anruf der Teil der Kette ist, den man nicht patchen kann. Sie ernten Anmeldedaten und OTPs, weil Anmeldedaten und OTPs auch im Jahr 2026 immer noch der Vordereingang der meisten Unternehmen sind, trotz eines Jahrzehnts an Vorträgen, die erklären, dass sie es nicht sein sollten.

Der Teil der Kette, den ein Browser beeinflussen kann, ist klein. Es ist eine von vier Maschinen. Sie sollten keinen Browser kaufen, weil er behauptet, BlackFile von Anfang bis Ende zu besiegen. Sie sollten einen Browser kaufen, weil er das Eine, was er gut kann, gut macht — die Unternehmenssitzung an einem verwalteten, identifizierbaren Ort halten und die Random-Link-Sitzung an einem Ort halten, der mit dem Schließen aufhört zu existieren — und Sie sollten ihn dann mit den langweiligen, unspektakulären Maßnahmen auf der IdP-Seite kombinieren, die die Schleife tatsächlich schließen.

Das Telefon wird weiter klingeln. Die Seite wird weiter laden. Die Frage ist nur, wo genau sie lädt und was sie umgibt, wenn sie es tut. Das, wie sich herausstellt, lässt sich ändern.

Quellen:

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10) (referenziert für den breiteren Kontext des AiTM-as-a-Service-Markts, nicht speziell für BlackFile)