CaptiveCrunch: Hotel-WLAN als Einfallstor – laut Microsoft wieder aktiv

Plot Twist: Die Veröffentlichung im Juli hat CaptiveCrunch nicht beendet. Am Montag, dem 5.10.2026, hat Microsoft ein Update zu der Spionagekampagne CaptiveCrunch nachgelegt, die über Captive Portals im Hotel-WLAN auf Reisende zielt. Dieses Update ist der Anlass dieses Artikels.

Spoiler: Laut Microsoft Threat Intelligence hat Storm-2945 die Aktivität am 29.9.2026 wieder aufgenommen. Zwischen Erstbericht und Wiederaufnahme liegen 60 Tage, das ist unsere Rechnung bei digital-magazin.de. Laut Microsoft-Update stammen 5 von 17 gelisteten Indikatoren aus dem Fenster vom 29.9. bis 1.10.

Wenig überraschend für alle, die Blocklisten für statisch halten. Den Basisbericht vom 31.7.2026 finden Sie bei Microsoft Threat Intelligence zu CaptiveCrunch. Der Großteil der Technikbeschreibung stammt aus diesem Juli-Text. Neu sind bei CaptiveCrunch laut Update die Wiederaufnahme, eine Rust-Variante der Malware CornFlake und aktualisierte Infrastruktur-Indikatoren.

Ehrlich gesagt: Das klingt nach einem Thema für Spezialisten. Ist es aber nicht. Es betrifft jede Person, die auf Dienstreise kurz das Gast-WLAN im Hotel nutzt.

Hand aufs Herz: Wer fragt im Hotel schon, wer das Captive Portal betreibt? Eben.

Update statt Entwarnung: CaptiveCrunch und das Hotel-WLAN

Zuerst die Grundlage, ohne Bauplan. Ein Captive Portal ist die Seite, die Sie im Hotel, auf der Konferenz oder am Flughafen sehen, bevor das WLAN freigeschaltet wird. Zimmernummer, Nachname, ein Häkchen bei den Nutzungsbedingungen. Jede reisende Person kennt das Ritual.

Genau deshalb taugt das Hotel-WLAN als Kulisse für CaptiveCrunch. Ein Portal wirkt wie ein Service des Hauses, nicht wie ein Risiko. Es spiegelt Vertrauen vor, das an dieser Stelle niemand geprüft hat. Bei CaptiveCrunch ist diese Kulisse das eigentliche Einfallstor.

Laut Microsoft Threat Intelligence setzt CaptiveCrunch auf manipulierten Netzverkehr und Captive Portals. Microsoft zitiert Beobachtungen von ReliaQuest in Hotels, Konferenzzentren und anderen geteilten Orten; Ziel seien laut dieser Einschätzung die Konten von Geschäftsreisenden. Dazu gibt es laut Microsoft Hinweise auf Android. Mehr braucht es hier nicht, und mehr bekommen Sie hier auch nicht.

Zur Zuordnung: Laut Microsoft ist Storm-2945 ein Sub-Cluster von Midnight Blizzard. Das ist das Assessment von Microsoft. Midnight Blizzard ordnen die USA und Großbritannien dem russischen SVR zu, und Microsoft nennt es ebenfalls so. Der Name CaptiveCrunch bezeichnet die Kampagne, nicht mehr.

Der Juli-Bericht verweist laut Microsoft außerdem auf ReliaQuest. Demnach geraten Hotels, Konferenzzentren und andere Shared Venues ins Visier, mit dem Ziel, Zugang zu Konten von Geschäftsreisenden zu bekommen. Beachten Sie das Ziel. Es geht nicht um das Zimmer-WLAN als solches, sondern um die Identitäten, die sich dort anmelden.

Eine Randnotiz zur Einordnung: Microsoft nennt Ähnlichkeiten in den Taktiken zur DNS-Hijacking-Offenlegung vom April 2026 (Forest Blizzard), schreibt CaptiveCrunch aber Storm-2945 zu. Dabei lasse ich es bewusst.

Das Pikante am CaptiveCrunch-Update vom 5.10.: Laut Microsoft deckt sich die erneuerte Aktivität mit Berichten von Black Lotus Labs. Demnach sollen mehrere Hospitality-Managed-Service-Provider betroffen sein. Fortgesetzter Upstream-Zugang habe ein schnelles Re-Deployment begünstigt. Ich lese das so: Wer an einer Stelle sitzt, die viele Häuser versorgt, muss nicht jedes Hotel einzeln neu aufsetzen.

Das ist meine Interpretation, keine Microsoft-Aussage. Brisant ist sie trotzdem, denn hinter manchem Hotel-WLAN steckt ein Dienstleister, den Gäste nie zu Gesicht bekommen.

Ehrlich gesagt verführt schon das Wort WLAN zu falscher Ruhe. Es klingt nach Infrastruktur, dabei ist ein Hotel-WLAN oft ein Zusammenspiel aus Router, Portal und externem Betreiber. Wer CaptiveCrunch verstehen will, muss das Portal als Teil der Angriffsfläche sehen und nicht als Türsteher.

Nicht verwechseln: Midnight Blizzard ist nicht Star Blizzard

Am selben Tag erschien bei uns ein Stück zu Star Blizzard RedFlick. Wer CaptiveCrunch und RedFlick nacheinander liest, bringt womöglich die Farbpalette durcheinander: Blizzard hier, Blizzard dort. Ein Namensschema ist kein Beweis für Verwandtschaft.

Zur Klarstellung. Star Blizzard RedFlick zielt laut dortigem Stück auf Phishing-Mails und einen anderen Cluster-Kontext. CaptiveCrunch betrifft laut Microsoft Storm-2945 unter Midnight Blizzard, das US und UK dem SVR zuordnen. Der Vektor ist das Captive Portal im Hospitality-WLAN, die Zielgruppe sind Reisende.

Zwei Stories. Zwei Verteidigungsbilder. CaptiveCrunch ist die Hotel-WLAN-Variante.

Bei Phishing-Mails schauen Sie auf Postfach, Absender und Anmeldeseiten. Bei CaptiveCrunch schauen Sie auf das Netz, in dem Sie gerade hängen, und auf alles, was dieses Netz Ihnen anzeigt. Mal ehrlich: Wer beides in einen Topf wirft, verteidigt am Ende keines von beiden richtig.

Ich finde, das ist die eigentliche Lehre der Doppelmeldung. Eine Awareness-Schulung, die nur Vorsicht bei E-Mails kennt, lässt die Dienstreise außen vor. Dabei sitzen Ihre Reisenden im Zug, im Flieger und im Messehotel, und dort hilft kein Mailfilter, wenn das Hotel-WLAN das Gegenüber ist.

Übernehmen Sie keine Details aus dem einen Fall in den anderen. Die Schutzlogik unterscheidet sich, und Zahlen aus dem RedFlick-Stück übernehmen wir hier ausdrücklich nicht.

60 Tage später: die Kampagne läuft weiter

Jetzt zur Chronologie. Alle Daten stammen von Microsoft, die Rechnung am Ende ist unsere.

Seit Februar 2026 beschreibt Microsoft Device-Code- und OAuth-Phishing, laut Microsoft KI-unterstützt. Das ist Kontext, nicht der Haupthaken dieses Textes. Seit Anfang Mai 2026 beobachtet Microsoft DNS- und HTTP-Manipulation an Captive Portals. Seit dem 16.7.2026 läuft laut Microsoft Device-Code-Phishing über CaptiveCrunch-Landingpages. Am 31.7.2026 erschien der Erstbericht.

Als Timeline gelesen heißt das: Bis zum Erstbericht lief die Portal-Manipulation grob rund drei Monate. Drei Monate, in denen das Hotel-WLAN für Reisende Alltag blieb und noch kein öffentlicher Bericht dazu vorlag. Das sollte Ihnen zu denken geben.

Dann das Update. Laut Microsoft beobachtete Microsoft Threat Intelligence am 29.9.2026, dass Storm-2945 CaptiveCrunch wieder aufnimmt, mit manipuliertem Netzverkehr und Captive Portals im Hospitality-Sektor. Am 5.10.2026 folgte die Aktualisierung des Blogs. Zwischen Erstbericht am 31.7. und Wiederaufnahme am 29.9. liegen 60 Tage, unsere Rechnung bei digital-magazin.de.

Zwei Monate. Das ist kürzer als manches Beschaffungsprojekt.

Jetzt die Statistik, bitte mit Vorsicht. Microsofts Indikatoren-Tabelle führt 17 Einträge. Davon haben 5 ein „first seen“ zwischen 29.9. und 1.10., das ist das Update-Fenster. 12 sind älter. Es sind also 5 von 17 gelisteten Indikatoren, und keine Quote über Angriffe. Eine Indikatorenliste ist kein Angriffszähler, und wer das verwechselt, rechnet sich Zahlen zurecht, die es nicht gibt.

Der Clou: Der Anteil sagt etwas über Frische, nicht über Ausmaß. Wer jeden einzelnen Eintrag sperrt, hat nur den Stand von gestern gesperrt, während die Wiederaufnahme von CaptiveCrunch bereits neue Einträge erzeugt. Hand aufs Herz: Wann wurde bei Ihnen zuletzt eine Liste nach dem Wochenende angepasst?

Dazu passt, was Microsoft ergänzt. Wo Infostealer ausgeliefert wurde, handelte es sich laut Microsoft um eine Rust-Variante von CornFlake, mit Merkmalen, die zu fortgesetzter KI-gestützter Malware-Entwicklung passen („consistent with continued AI-enabled malware development“). Microsoft dankt der Google Threat Intelligence Group (GTIG) für die Zusammenarbeit beim Tracking der Wiederaufnahme. Laut Microsoft enthält der Blog neuere Netzwerk-Infrastruktur-Indikatoren, Detections und Hunting Guidance. Die Hunting-Hinweise lesen Sie bitte im Original.

Was Microsoft nicht liefert, sagen wir ebenso trocken: Es gibt keine Opferzahlen. Es gibt keine Länderliste, die Rede ist von mehreren Ländern und von weltweiter Aktivität. Und es gibt keinen belegten Fall aus dem deutschsprachigen Raum, den wir hier erzählen könnten. Wer so etwas behauptet, erfindet es.

Fehlende Zahlen sind kein Zeichen von Harmlosigkeit. Sie sind ein Zeichen dafür, dass wir sie nicht kennen. Wer CaptiveCrunch einschätzen will, arbeitet mit Lücken, und wer jedes Hotel-WLAN als möglicherweise fremdes Terrain behandelt, kommt damit besser zurecht.

CornFlake und ChocoShell: Schutzbedarf statt Bauanleitung

Bevor Sie auf Details hoffen: Hier gibt es keine Funktionsbeschreibung. Wir nennen die Labels, weil Sie sie in Berichten zu CaptiveCrunch wiederfinden, und wir beschreiben, was geschützt werden muss. Das genügt für gute Entscheidungen.

CornFlake ist laut Microsoft eine Windows-RAT. Im Juli beschrieb Microsoft eine Go-Variante, das Update beobachtet auch eine Rust-Variante. Zum Schutzbedarf: Laut Microsoft-Juli-Angabe reicht die Exfiltration bis zu 1.000 Dateien beziehungsweise 500 MB pro Zyklus. Lesen Sie das als Frage an Ihre Datenhaltung. Was liegt auf einem Reiselaptop, das dort nicht liegen müsste?

ChocoShell ist laut Microsoft ein PowerShell-Infostealer. Als Schutzbedarf nennt Microsoft Browser-Sessions von 6 Chromium- und 5 Firefox-Familien-Browsern, M365-SSO-Tokens und WLAN-Passwörter. Der Kern: Es geht um laufende Anmeldungen, nicht nur um Kennwörter.

Das ist der Knackpunkt. Wer eine gültige Sitzung mitnimmt, braucht das Passwort nicht mehr. Wie Sie dieses Risiko in der Breite angehen, haben wir im Beitrag zu Token-Diebstahl und Defense-Maßnahmen aufgeschrieben.

Für den Alltag heißt das dreierlei. Erstens: Ein Reiselaptop ist ein Endgerät mit erhöhtem Risiko und gehört entsprechend gepflegt, überwacht und eingeschränkt. Zweitens: Sitzungen und Tokens sind Ihr Schutzobjekt, nicht nur Passwörter. Drittens: Gespeicherte WLAN-Zugangsdaten sind keine Nebensache, denn Microsoft zählt sie ausdrücklich zum Schutzbedarf.

Meiner Einschätzung nach unterschätzen viele Teams den dritten Punkt. Das Hotel-WLAN vom Montag steckt am Freitag oft noch im Profil. Mein Rat, ausdrücklich keine Microsoft-Angabe: Entfernen Sie nach der Reise gespeicherte Gastnetze aus dem WLAN-Profil des Geräts, und lassen Sie automatisches Verbinden mit unbekannten Netzen ausgeschaltet.

Mehr technische Tiefe gibt es hier nicht. Keine Abläufe, keine Dateinamen, keine Befehle. Wer CaptiveCrunch abwehren will, braucht keine Anleitung zum Angriff, sondern eine klare Liste dessen, was er absichern möchte.

Was Microsoft Reisenden und der IT gegen CaptiveCrunch rät

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of business travelers with laptops and coffee sitting in a modern hotel lobby during a trade fair, seen from a distance, screens not visible, warm light, no logos, no readable text, no signage, no watermarks, 16:9

Der Abschnitt „How to protect against CaptiveCrunch activity“ im Microsoft-Bericht liest sich unspektakulär. Der Clou: Genau deshalb wirkt er. Die Maßnahmen setzen dort an, wo die Kulisse aufgebaut wird, nämlich am Vertrauen in das Netz.

Beginnen wir bei der Haltung. Behandeln Sie Gast- und Hospitality-Netze als nicht vertrauenswürdig. Nicht als „meistens okay“, sondern als fremdes Terrain. Das gilt fürs Hotelnetz ebenso wie fürs Konferenz-WLAN am Messestand.

Bevorzugen Sie private Konnektivität, wo praktikabel. Microsoft nennt mobile Hotspots, Satellit und eSIM-basierte Mobilfunkdaten statt öffentlichem WLAN. Ich finde, das ist die unterschätzteste Empfehlung. Sie kostet etwas Datenvolumen und erspart die Vertrauensfrage am Hotel-WLAN.

Für die Praxis heißt das: Klären Sie vor der Reise, wer den Hotspot bereitstellt, wie das Datenvolumen abgerechnet wird und was gilt, wenn der Mobilfunk im Gebäude schwach ist. Hier entscheidet die Vorbereitung. Wer erst im Hotel feststellt, dass der Tarif kein Roaming enthält, greift zum Gast-WLAN, und damit ist die Empfehlung verpufft. Vergeben Sie für den eigenen Hotspot außerdem ein langes, eigenes Kennwort und geben Sie es nicht an den Nachbartisch weiter.

Für Firmengeräte rät Microsoft, WLAN-Verbindungen zu Netzen zu unterbinden, die nicht per MDM provisioniert sind. Das ist eine Policy-Frage, keine Schulungsfrage. Wer das Hotel-WLAN technisch nicht zulässt, muss niemanden überzeugen, es zu meiden.

Ergänzend nennt Microsoft Enterprise-Travel-Router oder -Hotspots mit Tunnel zurück zur Firma als Option. Erwägen Sie das, wenn Reisende häufig unterwegs sind. Meine Ergänzung: Legen Sie fest, wer das Gerät beschafft, wer es konfiguriert und wer es zurücknimmt, bevor es jemand im Hotel zum ersten Mal einschaltet.

Dann zum Verhalten am Portal. Laden Sie keine Software-Updates, Zertifikate, Browser-Updates, Netzwerk-Troubleshooting-Tools oder Security-Utilities, die ein Captive Portal oder ein unerwarteter Web-Prompt anbietet. Prüfen Sie Update-Anfragen über vertrauenswürdige Betriebssystem-Mechanismen, nicht über Pop-ups. Ein Portal, das Ihnen ein „Browser-Update“ anbietet, ist kein Update-Dienst. Punkt.

Praktisch gewendet: Aktualisieren Sie Betriebssystem und Browser vor der Abreise im Büro oder zu Hause, damit unterwegs gar kein Anlass für ein Update entsteht. Dann fällt jeder Hinweis am Portal sofort aus dem Rahmen. Weisen Sie Reisende zudem an, ein Portal, das mehr verlangt als eine schlichte Anmeldung, der IT zu melden, statt es zu bedienen.

Dazu gehört Awareness für ClickFix-artige Prompts. Fake-Verifikationen und Anweisungen, Befehle selbst auszuführen, sind als bösartig einzustufen. Sagen Sie das in jeder Reiseschulung in einem Satz: Wenn eine Webseite verlangt, dass Sie Befehle selbst ausführen, ist das kein Service. Nicht nachfragen, nicht ausprobieren, Seite schließen und melden.

Bei Identitäten empfiehlt Microsoft Passkeys und MFA, für privilegierte Konten phishing-resistente MFA. Dazu kommen Conditional Access, Sign-in-Risk-Policies und das Auswerten von Risky-sign-in-Reports. Wie phishing-resistente Anmeldung in der Praxis aussieht, zeigt unser Beitrag mit Checks zu Passkeys und phishing-resistenter Anmeldung.

Zum Device Code Flow: Erlauben Sie ihn nur dort, wo er nötig ist. Microsoft empfiehlt, ihn wo immer möglich zu blockieren („wherever possible“). Das passt zum Bild der Kampagne, in der laut Microsoft Device-Code-Phishing über CaptiveCrunch-Landingpages läuft. Prüfen Sie in Ihrem Tenant, wer ihn tatsächlich braucht. Oft sind es weniger Personen, als Sie denken.

Meine Praxisempfehlung dazu: Dokumentieren Sie jede Ausnahme für den Device Code Flow mit Begründung und Ablaufdatum. So wird aus einer Ausnahme keine Dauerlösung.

Zwei Regeln für Registrierungen. Verwenden Sie keine Firmen-Credentials auf Hotel-, Konferenz- oder Gastnetz-Registrierungsseiten wieder. Und geben Sie bei Buchung und Registrierung so wenig wie möglich über Identität, Organisationszugehörigkeit und Reisedetails preis. Ein eigenes Passwort aus dem Passwortmanager kostet Sekunden. Jedes zusätzliche Feld ist Futter für gezielte Ansprache.

Der Patch- und Phishing-Kontext gehört dazu, auch wenn er hier nicht der Beleg ist. Wer sich dafür interessiert, findet ihn in unserer Einordnung zum Microsoft Digital Defense Report. Zahlen daraus dienen hier nicht als Nachweis für CaptiveCrunch.

Alle genannten Maßnahmen sind Microsoft-Empfehlungen, ausgenommen meine Praxishinweise. Keine davon ist exotisch, und keine ist eine Garantie. Wer Ihnen vollständige Sicherheit verspricht, sollte Ihr Misstrauen wecken.

Messe-Saison: Szenario im Messehotel ohne Opferzahlen

Der BSI-Kalender nennt zwei Termine, die für Reisende interessant sind: die Smart Country Convention in Berlin vom 13. bis 15.10.2026 und die it-sa Expo&Congress in Nürnberg vom 27. bis 29.10.2026. Beide Termine sind Kalenderrahmen, kein Vorfall.

Stellen Sie sich vor, eine Vertriebsleiterin reist zur it-sa. Das Messehotel ist gebucht, der Koffer gepackt, der Laptop voll mit Kundendaten. Alles Fiktion, aber nah an vielen Dienstreisen. Abends checkt sie ein, und am Laptop erscheint das WLAN des Hauses mit einem Portal, das einen Login verlangt oder ein „Update“ anbietet.

Was jetzt zählt, ist nicht ihr Reaktionsvermögen, sondern die Vorbereitung. Beginnen wir bei der IT. Laut Microsoft sollte sie Gastnetze als nicht vertrauenswürdig behandeln. Das Firmengerät darf sich per MDM-Policy gar nicht erst mit einem nicht provisionierten Hotel-WLAN verbinden. Stattdessen nutzt die Vertriebsleiterin den mobilen Hotspot oder eine eSIM, oder einen Enterprise-Travel-Router mit Tunnel zurück zur Firma, falls das Unternehmen das erwogen hat. So bleibt die Entscheidung gegen CaptiveCrunch keine Willensfrage am Abend.

Die Identität ist ebenfalls vorbereitet. Ihr Konto nutzt Passkeys, wo das möglich ist, und phishing-resistente MFA, weil sie privilegierte Rechte hat. Der Device Code Flow ist in Entra blockiert, soweit es der Betrieb zulässt. Auffällige Anmeldungen landen in Sign-in-Risk-Policies und Risky-sign-in-Reports, die jemand auch tatsächlich liest.

Und die Vertriebsleiterin selbst? Sie weiß, dass sie nichts von einem Captive Portal installiert. Kein Browser-Update, kein Zertifikat, kein Sicherheitswerkzeug, nichts. Fordert eine Seite sie auf, Befehle selbst auszuführen, schließt sie die Seite und ruft die IT an. Auf der Registrierungsseite des Messehotels nutzt sie keine Firmen-Zugangsdaten und gibt nur das Nötigste preis.

Vor der Abreise hat die IT mit ihr geklärt, welche Kontaktstelle erreichbar ist, wenn im Hotel etwas seltsam aussieht. Auch das gehört zur Vorbereitung. Ein Portal, das ungewöhnlich fragt, ist ein Fall für die Meldung und nicht für die Neugier.

Dieselbe Logik gilt am Messestand. Konferenz-WLANs gehören laut Microsoft ausdrücklich zu den genannten Zielen. Wer also am Stand kurz ins Veranstaltungsnetz geht, wählt ein Netz, das Microsoft zu den Zielen zählt. Mit dem Hotspot im Rucksack entfällt die Abwägung.

Stellen Sie sich weiter vor, die Vertriebsleiterin hat am Messetag zwei Termine außerhalb des Geländes: ein Café, ein Kundenbüro. Die Regel bleibt gleich. Eigenes Netz zuerst, fremdes Gast-WLAN nur nach Rücksprache mit der IT. Konsequenz zählt hier mehr als Misstrauen im Einzelfall.

Die Vorbereitung lässt sich als kurze Reise-Routine festhalten, wohlgemerkt als meine Empfehlung. Vor der Abfahrt: Geräte aktualisieren, Hotspot testen, nur die nötigen Daten mitnehmen. Unterwegs: eigenes Netz nutzen, Portal-Prompts ignorieren, Auffälliges melden. Nach der Rückkehr: gespeicherte Hotel-WLANs aus dem Profil entfernen und das Gerät wie gewohnt in den Büroalltag zurückführen.

Mal ehrlich: Das ist keine Heldengeschichte. Es ist eine langweilige Dienstreise. Genau so soll sie sein.

Ich will nichts dramatisieren. Microsoft liefert keine Opferzahlen und keinen Messebezug. Das Szenario zeigt nur, wie die Empfehlungen gegen CaptiveCrunch im Reisealltag ineinandergreifen. Hakt es, dann meist an dem einen Gerät, das das falsche Hotel-WLAN doch noch kennt.

Und was ist mit Reisenden ohne Unternehmensgerät? Für sie gilt dieselbe Haltung, nur ohne Policy: Hotspot, eSIM und Skepsis gegenüber jedem Pop-up im Gastnetz.

Was Sie vor dem nächsten Hotel-Check-in prüfen

Eine Checkliste, bewusst nüchtern. Gehen Sie sie mit Ihrem Team durch, bevor die nächste Dienstreise gebucht wird. Beantworten Sie jede Frage mit einem Beleg, nicht mit einem Gefühl. Wer CaptiveCrunch ernst nimmt, beginnt hier.

• Wird jedes Gast-WLAN, vom Hotel bis zum Flughafen, als nicht vertrauenswürdig behandelt?
• Sind mobiler Hotspot oder eSIM auf Dienstreisen der Standard, nicht die Ausnahme?
• Ist der Device Code Flow in Entra blockiert, wo immer möglich?
• Nutzen Privilegierte Passkeys oder andere phishing-resistente MFA?
• Verhindert das MDM manuell hinzugefügte Hotel-WLANs auf Firmengeräten?
• Sind Mitarbeitende geschult, Update-Prompts am Portal zu ignorieren, wie sie im Zusammenhang mit CaptiveCrunch beschrieben werden, und keine selbst auszuführenden Befehle zu akzeptieren?
• Werden Firmen-Credentials nie auf Registrierungsseiten von Hotels, Konferenzen oder Gastnetzen verwendet?
• Sind Sign-in-Risk-Policies aktiv?
• Gibt es eine Travel-Router-Policy mit Tunnel zurück zur Firma, oder zumindest eine bewusste Entscheidung dagegen?
• Haben Sie die Risky-sign-in-Reports im Blick, und liest sie jemand regelmäßig?

Spoiler: Oft scheitert es nicht an Technik, sondern an Zuständigkeit. Wer prüft die Reiserichtlinie? Wer besitzt die Conditional-Access-Regeln? Wer liest die Reports? Diese Fragen sind unbequemer als jede Konfiguration.

Drei Zusatzfragen ergänze ich aus eigener Praxis, sie stammen nicht von Microsoft:

• Gibt es eine Ansprechstelle, die Reisende erreichen, wenn ein Hotel-WLAN ungewöhnliche Aufforderungen zeigt?
• Werden gespeicherte WLAN-Profile aus Hotels nach der Reise von den Geräten entfernt?
• Ist festgelegt, welche Daten auf Reiselaptops nicht liegen sollen?

Wir bei digital-magazin.de würden mit zwei Punkten starten: Device Code Flow prüfen und die MDM-Regel für Gast-WLANs. Beides lässt sich in kurzer Zeit klären. Der Rest ist Pflege.

Und dann ein Punkt, der auf keiner Liste steht: Üben Sie es. Spielen Sie mit Reisenden durch, was sie am Portal tun und wem sie es melden. Eine Regel, die nie geübt wurde, ist am Abend im Hotel nur ein Satz in einer Richtlinie.

Was bleibt?

Plot Twist zum Schluss: Das größte Risiko dieser Meldung ist nicht die Malware. Es ist die Gewohnheit. Das Captive Portal ist so alltäglich, dass kaum jemand es hinterfragt. CaptiveCrunch setzt dort an, wo Routine herrscht.

Ich finde, das Update vom 5.10. liefert eine bittere, aber nützliche Erkenntnis. Die Veröffentlichung im Juli hat die Kampagne nicht beendet. Nach 60 Tagen lief CaptiveCrunch laut Microsoft wieder an, und das Update listet neue Indikatoren. Blocklisten gegen CaptiveCrunch veralten schneller als das Reiseprogramm, das gilt für 17 Einträge genauso wie für jede längere Liste.

Meiner Einschätzung nach hilft deshalb, was unabhängig von der Liste wirkt: eigenes Netz, harte Identität, Device Code Flow aus, wo möglich, keine Klicks auf „Browser-Update“-Prompts am Portal. Das klingt nach wenig. Es ist genau das, was Microsoft empfiehlt, und es wirkt, weil es nicht vom nächsten Indikator abhängt.

Offen bleibt, wie groß die Kampagne ist. Microsoft nennt keine Opferzahlen und keine Länder, nur mehrere Länder und weltweite Aktivität. Lesen Sie das als Lücke im Lagebild, nicht als Entwarnung. Einen europäischen Blick bietet unser Beitrag zum europäischen Lagebild, als Verweis und ohne Zahlenvergleich. Bis die Lücke kleiner wird, bleibt jedes Hotel-WLAN, jedes Konferenz-WLAN und jedes Gastnetz ein Netz, dem Sie nichts anvertrauen sollten, was Sie nicht verlieren wollen.

Die Frage bleibt unbequem: Würden Ihre Reisenden beim nächsten Check-in wirklich den Hotspot einschalten, oder doch das Portal bedienen?

Dann buchen Sie das nächste Hotel mit einem klaren Plan. Der Rest ist Routine.