[{"content":"Am 18. Februar 2026, kurz nach 16 Uhr, freute sich Peter Wendel auf den Feierabend. Dann vibrierte sein Smartphone. Eine SMS, in genau dem Chat-Verlauf, in dem sonst Trade Republic mit ihm spricht — Login-Codes, Sicherheitshinweise, das Übliche. Diesmal stand drin, eine Auszahlung von seinem Konto sei vorgemerkt, die er nicht autorisiert habe. Direkt darunter: eine Notfallnummer. Er rief an. Zwei Stunden später hatte er 100.000 Euro auf ein angebliches \u0026ldquo;Treuhandsammelkonto\u0026rdquo; in Österreich überwiesen. Es war die Altersvorsorge, die er und seine Frau Nicole über 45 Jahre lang aufgebaut hatten.\nWendel ist 63, halbwegs digital sozialisiert, hat sich kurz unbehaglich gefühlt, als ein österreichisches Zielkonto genannt wurde — und sich von der Stimme an der Hotline trotzdem überzeugen lassen. Wer ihm vorwirft, leichtsinnig gewesen zu sein, hat noch nicht verstanden, wie der Angriff aufgebaut war: Die SMS war kein verdächtiger Fetzen mit klobigem Englisch. Sie wurde im gleichen Thread wie die echten Codes von Trade Republic angezeigt. Genau das ist das Problem, über das ich hier schreiben will. Und es ist eines, das die Bundesrepublik seit Jahren ignoriert.\nEine Absenderkennung, in die jede.r schreiben kann, was sie will Wenn du heute eine SMS bekommst und im Display oben \u0026ldquo;Trade Republic\u0026rdquo;, \u0026ldquo;DHL\u0026rdquo; oder \u0026ldquo;Sparkasse\u0026rdquo; steht, ist das nichts weiter als ein Textfeld in einem Datenpaket. Ein Feld in einem Protokoll, das in den Achtzigern entworfen wurde, als SMS noch \u0026ldquo;Hi Mama, bin gleich da\u0026rdquo; hieß. Dieses Textfeld nennt sich alphanumerische Absenderkennung (englisch: Sender ID), und sein zentrales technisches Merkmal ist: Es wird unterwegs nirgends geprüft.\nWer professionell SMS verschickt — seien es Banken, Paketdienstleister, Behörden, aber eben auch Werbeschleudern und Kriminelle —, kauft sich Zugang zu einem SMS-Gateway. Solche Gateways gibt es bei Anbietern in halb Europa für ein paar Euro pro tausend Nachrichten. Im Bestellformular gibst du an, was im Absenderfeld stehen soll. Bis zu elf Zeichen, beliebig. Niemand verifiziert, ob \u0026ldquo;TradeRepubl\u0026rdquo; wirklich von der Trade Republic Bank GmbH kommt. Die Kette zwischen Auftraggeber, Gateway und Mobilfunkanbieter trägt die Kennung einfach durch.\nDas ist kein Bug, sondern die Vorgabe der Spezifikation. Das SMS-Protokoll wurde nie für sicherheitskritische Kommunikation entworfen. Trotzdem nutzen einige Banken den Kanal Jahrzehnte später genau dafür aus — für TANs, Verifikations-Codes und Statusmeldungen. Die meisten deutschen Häuser sind inzwischen abgerückt und setzen auf sichere Verfahren wie App-Benachrichtigungen. Trade Republic gehört zu den wenigen verbliebenen, die SMS noch im Sicherheits-Kontext einsetzen — und genau das pflegt das Vertrauen der Kund.innen in einen Kanal, den niemand authentifiziert.\nIm selben Chat-Verlauf — und damit im selben Vertrauen Der eigentliche Hebel des Angriffs auf Wendel ist nicht die SMS selbst. Es ist die Anzeige auf dem Smartphone. Sowohl iOS als auch Android gruppieren eingehende Nachrichten nach Absendername zu Threads. Wenn die echte Trade Republic monatelang als \u0026ldquo;TradeRepubl\u0026rdquo; zu dir spricht, und plötzlich eine Phishing-SMS mit identischer Sender-ID hereinkommt, dann landet diese Phishing-SMS im selben Chat wie alle echten. Direkt unter dem letzten Login-Code, den du vor zwei Wochen bekommen hast.\nStell dir vor, du bekommst eine E-Mail von deiner Bank — von der Adresse, von der auch die echten Bestätigungen kommen — im selben Mail-Verlauf, direkt unter den letzten echten Antworten. Du würdest den Inhalt nicht anzweifeln. Genau diese Konstellation produziert die alphanumerische Absenderkennung bei SMS, nur ohne die Schutzschichten, die E-Mail-Server inzwischen gegen Absenderfälschung haben.\nGenau diese Masche läuft seit Monaten gegen Trade-Republic-Kund.innen. Die BaFin warnt seit dem 10. März 2026 öffentlich, das Polizeipräsidium Mittelfranken meldet für einen einzigen Bezirk allein in den letzten Wochen Vermögensschäden in mehrfacher Hunderttausend-Höhe. Wer im echten Trade-Republic-Chat eine SMS bekommt, ruft die angegebene Nummer an. Die Trefferquote ist hoch genug, dass es sich für die Täter.innen rechnet, im Stundentakt nachzulegen.\nUK, Irland, Singapur. Und Deutschland. Das technische Problem ist seit Jahren bekannt — und in mehreren Ländern auch gelöst. Großbritannien hat 2018 das SMS SenderID Protection Registry aufgesetzt: Banken, Behörden und Unternehmen registrieren dort ihre legitimen Absenderkennungen. Wer eine SMS unter dem Namen \u0026ldquo;Barclays\u0026rdquo; durch ein UK-Netz schickt, ohne von Barclays autorisiert zu sein, wird auf Netzbetreiber-Ebene blockiert. Aktuell sind mehr als 700 echte Sender-IDs geschützt, über 3.750 Spoofing-Varianten stehen auf einer geteilten Sperrliste — getragen von BT/EE, O2, Three und Vodafone gemeinsam mit dem National Cyber Security Centre und UK Finance.\nIrland und Spanien haben die UK-Lösung 2021 übernommen. Singapur ist noch einen Schritt weitergegangen: Schon mit der freiwilligen Registrierung ab 2022 sanken die SMS-Smishing-Fälle zwischen Q4 2021 und Q2 2022 um 64 %. Seit dem 31. Januar 2023 blockiert die staatliche Regulierungsbehörde IMDA jede nicht registrierte alphanumerische Sender-ID per Default und ersetzt sie durch das Schild \u0026ldquo;Likely-SCAM\u0026rdquo;. Frankreich verlangt von seinen Mobilfunkanbietern seit Oktober 2024, nicht authentifizierte ausländische Anrufe zu unterbrechen — der Sprung auf SMS-Sender-IDs ist regulatorisch in Vorbereitung.\nIn Deutschland: Nichts dergleichen. Die Bundesnetzagentur hat eine SMS-Spam-Meldestelle, aber keine Authentifizierung der Absenderkennungen. Die drei großen Netzbetreiber — Deutsche Telekom, Vodafone, Telefónica/O2 — könnten morgen anfangen, ein Whitelisting nach UK-Vorbild zu implementieren. Sie tun es nicht, weil sie nicht müssen. Solange das Risiko bei den Endkund.innen liegt, ist die Investition in eine Sender-ID-Filterung aus Konzernsicht ein Kostenpunkt ohne Gegenwert. Genau diesen Mechanismus bricht Singapur auf, indem es die Filterung vorschreibt statt empfiehlt.\nWas jetzt zu tun wäre Die deutsche Untätigkeit ist kein Versäumnis, sondern eine Entscheidung. Die Bausteine liegen seit Jahren auf dem Tisch — UK macht es freiwillig, Singapur per Pflicht. Was fehlt, ist die politische Bereitschaft, sie auch hier verbindlich zu machen.\nTrade Republic muss den SMS-Kanal als Sicherheitskanal endlich aufgeben. Der Web-Login läuft zwar primär über App-Push — aber nach 30 Sekunden Wartezeit kann der Code alternativ per SMS verschickt werden. Damit gibt es weiterhin einen direkten SMS-Pfad ins Konto. Geräte-Kopplung, PIN-Reset und Telefonnummer-Verifikation hängen ohnehin am SMS-Kanal. Solange echte Trade-Republic-SMS bei den Kund.innen im Posteingang landen, hat jede Phishing-SMS einen vorbereiteten Andockpunkt. Dass dieser Vertrauensanker auch zivilrechtlich angreifbar werden könnte, argumentiert inzwischen ein Fachanwalt für IT-Recht — neben mangelnder telefonischer Notfall-Erreichbarkeit. In-App-Verifikation ist machbar und wird von anderen Banken längst eingesetzt. Trade Republic ist ein Tech-Unternehmen mit Vollbanklizenz; technische Gründe, daran festzuhalten, gibt es keine.\nDie Bundesnetzagentur muss den deutschen Mobilfunkanbietern verbindlich auferlegen, was UK seit 2018 freiwillig durchhält und Singapur seit 2023 erzwingt: ein Whitelisting der zugelassenen Sender-IDs, mit Sperrliste für alles andere. Solange das nicht passiert, ist jede neue BaFin-Aufklärungskampagne zu Hilfsbereitschaft und Vertrauen die stillschweigende Behauptung, Smishing sei ein Verhaltensproblem der Betroffenen.\nFür Peter Wendel und seine Frau ändert die Regulierung von morgen nichts mehr. Die Kriminalpolizei hatte ihnen schon am Tag der Tat gesagt, dass die Erfolgsaussichten gering seien. Wer ihnen direkt helfen will, kann das in Form einer Spende tun. Wer selbst auf eine solche SMS hereingefallen ist, findet bei JUN Legal kostenlose Musterbriefe für SEPA-Recall und DSGVO-Auskunft — die ersten Schritte gehen ohne Anwalt.\nDie SMS, die Wendel im Februar bekam, hätte in Großbritannien gar nicht erst sein Display erreicht. Sie hätte in Singapur \u0026ldquo;Likely-SCAM\u0026rdquo; als Absender getragen. In Deutschland ist sie im echten Chat-Verlauf gelandet. Das ist keine Lücke im Schutzkonzept — das ist das Schutzkonzept. Solange wir dabei bleiben, sind die nächsten 100.000 Euro nur eine Frage der Zeit.\n","permalink":"https://lwst.io/posts/sms-phishing-alphanumeric-senderids/","summary":"\u003cp\u003eAm 18. Februar 2026, kurz nach 16 Uhr, freute sich Peter Wendel auf den Feierabend. Dann vibrierte sein Smartphone. Eine SMS, in genau dem Chat-Verlauf, in dem sonst Trade Republic mit ihm spricht — Login-Codes, Sicherheitshinweise, das Übliche. Diesmal stand drin, eine Auszahlung von seinem Konto sei vorgemerkt, die er nicht autorisiert habe. Direkt darunter: eine Notfallnummer. Er rief an. Zwei Stunden später hatte er 100.000 Euro auf ein angebliches \u0026ldquo;Treuhandsammelkonto\u0026rdquo; in Österreich überwiesen. Es war die Altersvorsorge, die er und seine Frau Nicole \u003ca href=\"https://www.gofundme.com/f/um-100000eur-betrogen-gesamte-private-altersvorsorge-weg\"\u003eüber 45 Jahre lang aufgebaut hatten\u003c/a\u003e.\u003c/p\u003e","title":"11 Zeichen, keine Authentifizierung"},{"content":"Eine Teams-Einladung landet in meinem Postfach — für ein Meeting, das ich nie angenommen habe. „Bitte bestätige deine Teilnahme unter microsoft.com/devicelogin mit dem Code JK7QH9XW.\u0026quot; Die URL ist echt. Der Code ist echt. Wenn ich ihn eintippe, authentifiziert mein Passkey einen vollständig legitimen Login — und das resultierende Access-Token gehört dem Angreifer.\nDas ist das Vorgehen von Storm-2372, einer Gruppe, die mit moderater Konfidenz Russland zugeordnet wird und sich seit August 2024 durch Microsoft 365 Tenants arbeitet. Bis März 2026 hat The Hacker News 340+ betroffene Organisationen in fünf Ländern dokumentiert. Die Technik trägt einen Namen, der harmlos klingt: Device Code Phishing.\nWofür der Device Code Flow eigentlich gedacht ist Der Device Code Flow ist eine Sign-in-Methode für Geräte, die nicht ohne Weiteres ein Passwort abfragen können — Smart-TVs, IoT-Geräte, Command-Line-Tools, das Display im Konferenzraum. Er teilt das Login auf zwei Geräte auf. Das eingeschränkte Gerät startet den Flow und zeigt einen kurzen Code an. Anschließend öffnet der Nutzer microsoft.com/devicelogin auf seinem Telefon oder Laptop, gibt den Code ein und authentifiziert sich dort wie gewohnt. Sobald er den Login bestätigt, erhält das eingeschränkte Gerät im Hintergrund sein Access-Token, und ist angemeldet.\nIn der Praxis meldet dich so die Azure CLI an, so verbindet sich kubectl mit einem Cluster hinter Entra, so tritt das Konferenzraum-Display einem Teams-Meeting bei. Es ist ein realer, nützlicher Flow.\nDie Seite, auf der der Nutzer unter microsoft.com/devicelogin landet. An die Browsersprache lokalisiert\nMicrosoft druckt direkt auf dieser Seite eine Phishing-Warnung: „Geben Sie keine Codes aus Quellen ein, denen Sie nicht vertrauen.\u0026quot; Die Warnung ist ehrlich und benennt das Problem in einem Satz. Im Moment der Zustimmung hat der Flow nichts, worauf er sich verlassen könnte, außer dem eigenen Urteilsvermögen des Nutzers.\nWarum FIDO2 hier nicht hilft Passkeys sind phishing-resistent, weil sie an die exakte Domain der Login-Seite gebunden sind. Das schützt gegen gefälschte Microsoft-Seiten: Ein Passkey signiert schlicht nichts gegen microsoft-login.com. Im Device Code Flow gibt es aber keine gefälschte Domain. Der Nutzer ist tatsächlich auf microsoft.com/devicelogin, der Browser kommuniziert tatsächlich mit Microsoft, MFA wird tatsächlich erfüllt. Das Login ist echt.\nDie Schwachstelle liegt nicht im Login selbst. Sie liegt im Schritt danach: in der Zustimmung. Der Nutzer gibt den Code ein in der Annahme, sein eigenes Gerät zu autorisieren. Der Flow hat keine Möglichkeit, ihm zu sagen, dass es anders ist. Und weil die Angreiferin den Flow auf ihrer Maschine gestartet hat, erhält sie den Device Code — was bedeutet, dass das resultierende Token in ihrer Session landet.\nAus Sicht von Entra sieht der Sign-in im Nachhinein einwandfrei aus: erfolgreich, MFA-bestätigt, Passkey-signiert. In den Logs fällt nur die Authentifizierungsmethode deviceCode auf — die in den meisten Tenants nicht überwacht wird, weil sie selten vorkommt.\nWas der Angreifer erhält Ein erfolgreiches Device Code Phishing liefert ein Access-Token, das ungefähr eine Stunde gültig ist, und — viel nützlicher — ein Refresh-Token, das je nach Tenant-Konfiguration bis zu 90 Tage gültig bleiben und gegen neue Tokens mit neuen Berechtigungen ausgetauscht werden kann. Damit hat der Angreifer alles, was das Opfer hat.\nStorm-2372 wurde dabei beobachtet, genau das zu tun, was zu erwarten ist: Über die Microsoft Graph API das Postfach des Opfers nach Stichworten wie password, admin, secret, teamviewer, anydesk, ministry, gov zu durchsuchen und die passenden Nachrichten zu exfiltrieren. Lateral Movement erfolgt von dort aus per E-Mail aus dem nun kompromittierten Account an interne Kontakte. Die zweite Welle ist deutlich erfolgreicher, weil der Köder jetzt von einer vertrauenswürdigen Adresse in der eigenen Organisation des Opfers kommt.\nEs gibt kein Phishing-Kit, das man fingerprinten könnte, keine bösartige Domain, die man blockieren könnte, keine Lookalike-Infrastruktur, die man abschalten könnte. Aus Sicht der Verteidigung passiert der gesamte Angriff innerhalb von Microsofts eigenem, legitimem Flow. Viele Admins wissen nicht von dieser Schwachstelle und erwarten spätestens bei der Verwendung von Passkeys, dass ohne Zugriff auf diese kein Login möglich ist.\nWas tatsächlich hilft Microsoft hat die Conditional-Access-Bedingung Authentication Flows 2024 allgemein verfügbar gemacht. Eine Policy, die den Device Code Flow blockiert, beendet das Problem für die meisten Tenants — Device Code wird in normalen Office-Workflows nicht verwendet. Legitime Anwendungsfälle (Konferenzraum-Displays, vereinzelte CLI-Tools) lassen sich über User-Exclusions herausnehmen. Seit Februar 2025 gibt es zusätzlich eine Microsoft-managed Policy, die diesen Block für Tenants aktiviert, die Device Code überhaupt nicht nutzen.\nDie Policy selbst lässt sich in etwa fünf Minuten einrichten:\nIm Microsoft Entra Admin Center zu Protection \u0026gt; Conditional Access \u0026gt; Policies navigieren. New policy klicken und einen Namen vergeben, z.B. Block Device Code Flow. Unter Assignments \u0026gt; Users All users einbeziehen. Service-Accounts und Break-Glass-Accounts, die Device Code benötigen, sowie Nutzer mit CLIs, die darauf angewiesen sind, ausschließen. Unter Target resources All resources (früher All cloud apps) wählen. Unter Conditions \u0026gt; Authentication flows Configure auf Yes setzen und Device code flow auswählen. Unter Access controls \u0026gt; Grant Block access wählen. Enable policy zunächst auf Report-only setzen. Nach ein paar Tagen die Sign-in-Logs auf blockierte Sign-ins prüfen, die sich als legitim erweisen, betroffene Nutzer in die Exclusion-Liste aufnehmen und die Policy dann auf On schalten. Microsoft hat eine Schritt-für-Schritt-Anleitung für dasselbe Vorgehen, falls du es mit einem offiziell dokumentierten Klickpfad abgleichen möchtest.\nAwareness-Training ist die zweite Linie, nicht die erste. Zwei Jahre nach Beginn dieser Kampagne ist „sag deinen Mitarbeitenden, sie sollen keine Codes eingeben\u0026quot; ein Slogan, kein Control. Geschulte Mitarbeitende klicken trotzdem, wenn der Köder aus dem kompromittierten Postfach einer Kollegin oder eines Kollegen kommt — und die nächste Welle ist bereits KI-generiert und auf den Tenant zugeschnitten.\nDie nächste Teams-Einladung in meinem Postfach werde ich lesen im Wissen, dass mein Passkey einen freundlichen Code nicht von einem unfreundlichen unterscheiden kann — und dass Conditional-Access mich trotzdem schützt.\n","permalink":"https://lwst.io/posts/microsoft-entra-device-code-phishing/","summary":"\u003cp\u003eEine Teams-Einladung landet in meinem Postfach — für ein Meeting, das ich nie angenommen habe. \u003cem\u003e„Bitte bestätige deine Teilnahme unter microsoft.com/devicelogin mit dem Code JK7QH9XW.\u0026quot;\u003c/em\u003e Die URL ist echt. Der Code ist echt. Wenn ich ihn eintippe, authentifiziert mein Passkey einen vollständig legitimen Login — und das resultierende Access-Token gehört dem Angreifer.\u003c/p\u003e\n\u003cp\u003eDas ist das Vorgehen von \u003ca href=\"https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/\"\u003eStorm-2372\u003c/a\u003e, einer Gruppe, die mit moderater Konfidenz Russland zugeordnet wird und sich seit August 2024 durch Microsoft 365 Tenants arbeitet. Bis März 2026 hat The Hacker News \u003ca href=\"https://thehackernews.com/2026/03/device-code-phishing-hits-340-microsoft.html\"\u003e340+ betroffene Organisationen in fünf Ländern\u003c/a\u003e dokumentiert. Die Technik trägt einen Namen, der harmlos klingt: \u003cstrong\u003eDevice Code Phishing\u003c/strong\u003e.\u003c/p\u003e","title":"Device Code Phishing: Warum auch Passkeys deinen Microsoft-Tenant nicht retten"},{"content":"Diese Seite ist live. Kein großes Ereignis, aber ein Anfang.\nIch habe diesen Blog gestartet, um meine Gedanken und Erkenntnisse aus der IT-Security festzuhalten — für mich selbst, aber vielleicht auch für andere, die ähnliche Fragen haben.\nWas euch hier erwartet: praxisnahe Themen aus der Arbeit im mittelständischen Umfeld, Einblicke aus dem Masterstudium und gelegentlich Querverweise in die Hochschulpolitik, wenn beides zusammenkommt.\nAlle Beiträge spiegeln meine persönliche Meinung wider — nicht die meines Arbeitgebers oder meiner Universität.\n","permalink":"https://lwst.io/posts/hallo-welt/","summary":"\u003cp\u003eDiese Seite ist live. Kein großes Ereignis, aber ein Anfang.\u003c/p\u003e\n\u003cp\u003eIch habe diesen Blog gestartet, um meine Gedanken und Erkenntnisse aus der IT-Security festzuhalten — für mich selbst, aber vielleicht auch für andere, die ähnliche Fragen haben.\u003c/p\u003e\n\u003cp\u003eWas euch hier erwartet: praxisnahe Themen aus der Arbeit im mittelständischen Umfeld, Einblicke aus dem Masterstudium und gelegentlich Querverweise in die Hochschulpolitik, wenn beides zusammenkommt.\u003c/p\u003e\n\u003cp\u003eAlle Beiträge spiegeln meine persönliche Meinung wider — nicht die meines Arbeitgebers oder meiner Universität.\u003c/p\u003e","title":"Hallo Welt"},{"content":"Moin! Ich bin David Leeuwestein — IT-Security-Lead, Draußen-Mensch und überzeugter Norddeutscher. Im Dayjob schütze ich die IT mittelständischer Unternehmen aus der Region; parallel studiere ich IT-Security im Master an der Universität zu Lübeck. Nachts engagiere ich mich in der Hochschulpolitik für die Interessen von Studierenden.\nIn diesem Blog teile ich meine Erkenntnisse aus der IT-Security. Alle Beiträge spiegeln meine persönliche Meinung wider — nicht die meines Arbeitgebers oder meiner Universität.\nAktuell Stand: April 2026\nStudium: Mastervorlesung \u0026ldquo;Threat Modeling\u0026rdquo; an der Universität zu Lübeck — interessanter Kontrast zwischen STRIDE-Methodik im Hörsaal und der Frage, was davon im betrieblichen Alltag tatsächlich tragfähig ist. Beruf: Refresh der Backup-Strategie für einen mittelständischen Kunden — weg von täglichen Voll-Backups, hin zu einer Kombination aus inkrementell, immutable und offsite. Lesen: Sandworm von Andy Greenberg — historischer Hintergrund zu NotPetya und der Sandworm-Gruppe. Hochschulpolitik: Vorbereitung der nächsten Sitzungsrunde, Schwerpunkt Studienreform und Prüfungsordnung. Diese Liste aktualisiere ich unregelmäßig — wenn sie länger nicht angefasst wurde, ist mein Schreibtisch wahrscheinlich voller, als auf dieser Seite zu erkennen ist.\nKontakt Du hast ein Projekt, bei dem ich helfen kann — oder möchtest einfach in Kontakt treten? Schreib mir gern. Ich antworte normalerweise innerhalb weniger Werktage. Für vertrauliche Anfragen kannst du auch verschlüsselt schreiben (PGP-Schlüssel auf Anfrage).\nE-Mail: blog@lwst.io LinkedIn: linkedin.com/in/david-leeuwestein-934725259 GitHub: github.com/cybertschunk Mastodon: @dd@digitalcourage.social ","permalink":"https://lwst.io/about/","summary":"Über David Leeuwestein","title":"Über mich"}]