[{"content":"A Teams invitation lands in my inbox — for a meeting I never accepted. \u0026ldquo;Please confirm your attendance at microsoft.com/devicelogin with the code JK7QH9XW.\u0026rdquo; The URL is real. The code is real. If I type it in, my passkey authenticates a perfectly legitimate login — and the resulting access token belongs to the attacker.\nThis is how Storm-2372 operates — a group attributed with moderate confidence to Russia, working its way through Microsoft 365 tenants since August 2024. By March 2026, The Hacker News had documented 340+ affected organisations across five countries. The technique has a name that sounds harmless: device code phishing.\nWhat the device code flow is actually for The device code flow is a sign-in method for devices that can\u0026rsquo;t easily ask you to type a password — smart TVs, IoT devices, command-line tools, the display in the meeting room. It splits the login across two devices. The constrained device starts the flow and shows a short code. The user then opens microsoft.com/devicelogin on their phone or laptop, enters the code, and authenticates there as usual. Once they confirm the login, the constrained device receives its access token in the background and is signed in.\nIn practice, this is how the Azure CLI signs you in, how kubectl connects to a cluster behind Entra, how the conference-room display joins a Teams meeting. It\u0026rsquo;s a real, useful flow.\nThe page the user lands on at microsoft.com/devicelogin. Localised to the browser language\nMicrosoft prints a phishing warning right on this page: \u0026ldquo;Geben Sie keine Codes aus Quellen ein, denen Sie nicht vertrauen.\u0026rdquo; — don\u0026rsquo;t enter codes from sources you don\u0026rsquo;t trust. The warning is honest, and it names the problem in one sentence. At the moment of consent, the flow has nothing to fall back on except the user\u0026rsquo;s own judgement.\nWhy FIDO2 doesn\u0026rsquo;t help here Passkeys are phishing-resistant because they\u0026rsquo;re bound to the exact domain of the login page. That defends against fake Microsoft pages: a passkey simply won\u0026rsquo;t sign anything against microsoft-login.com. But in the device code flow, there is no fake domain. The user really is on microsoft.com/devicelogin, the browser really is talking to Microsoft, MFA really is being satisfied. The login is genuine.\nThe weakness isn\u0026rsquo;t in the login itself. It\u0026rsquo;s in the step that follows: consent. The user enters the code thinking they\u0026rsquo;re authorising their own device. The flow has no way to tell them otherwise. And because the attacker started the flow on their own machine, they receive the device code — which means the resulting token lands in their session.\nFrom Entra\u0026rsquo;s perspective, the sign-in looks immaculate afterwards: successful, MFA-confirmed, passkey-signed. In the logs, only the authentication method deviceCode stands out — and most tenants don\u0026rsquo;t monitor it, because it\u0026rsquo;s rare.\nWhat the attacker gets A successful device code phish yields an access token valid for about an hour, and — far more useful — a refresh token that, depending on tenant configuration, can stay valid for up to 90 days and be exchanged for new tokens with new permissions. With those, the attacker has whatever the victim has.\nStorm-2372 has been observed doing exactly what you\u0026rsquo;d expect: using the Microsoft Graph API to search the victim\u0026rsquo;s mailbox for keywords like password, admin, secret, teamviewer, anydesk, ministry, gov, then exfiltrating the matching messages. Lateral movement happens from there through email sent from the now-compromised account to internal contacts. The second wave is far more successful, because the lure now comes from a trusted address inside the victim\u0026rsquo;s own organisation.\nThere\u0026rsquo;s no phishing kit to fingerprint, no malicious domain to block, no lookalike infrastructure to take down. From a defender\u0026rsquo;s perspective, the entire attack happens inside Microsoft\u0026rsquo;s own legitimate flow. Many admins aren\u0026rsquo;t aware of this weakness and assume — once passkeys are in use — that no login is possible without access to them.\nWhat actually helps Microsoft made the conditional access condition Authentication Flows generally available in 2024. A policy that blocks the device code flow ends the problem for most tenants — device code isn\u0026rsquo;t used in normal Office workflows. Legitimate use cases (conference-room displays, occasional CLI tools) can be carved out with user exclusions. Since February 2025, there\u0026rsquo;s also a Microsoft-managed policy that enables this block for tenants that don\u0026rsquo;t use device code at all.\nThe policy itself takes about five minutes to set up:\nIn the Microsoft Entra admin center, go to Protection \u0026gt; Conditional Access \u0026gt; Policies. Click New policy and give it a name, e.g. Block Device Code Flow. Under Assignments \u0026gt; Users, include All users. Exclude service accounts, break-glass accounts that need device code, and users with CLIs that depend on it. Under Target resources, choose All resources (formerly All cloud apps). Under Conditions \u0026gt; Authentication flows, set Configure to Yes and select Device code flow. Under Access controls \u0026gt; Grant, select Block access. Set Enable policy to Report-only first. After a few days, check the sign-in logs for blocked sign-ins that turn out to be legitimate, add the affected users to the exclusion list, then flip the policy to On. Microsoft has a step-by-step walkthrough for the same procedure if you want to compare against an officially documented click path.\nAwareness training is the second line, not the first. Two years into this campaign, \u0026ldquo;tell your staff not to enter codes\u0026rdquo; is a slogan, not a control. Trained staff click anyway when the lure comes from a colleague\u0026rsquo;s compromised mailbox — and the next wave is already AI-generated and tailored to the tenant.\nI\u0026rsquo;ll read the next Teams invitation in my inbox knowing that my passkey can\u0026rsquo;t tell a friendly code from an unfriendly one — and that conditional access protects me anyway.\n","permalink":"https://lwst.io/en/posts/microsoft-entra-device-code-phishing/","summary":"\u003cp\u003eA Teams invitation lands in my inbox — for a meeting I never accepted. \u003cem\u003e\u0026ldquo;Please confirm your attendance at microsoft.com/devicelogin with the code JK7QH9XW.\u0026rdquo;\u003c/em\u003e The URL is real. The code is real. If I type it in, my passkey authenticates a perfectly legitimate login — and the resulting access token belongs to the attacker.\u003c/p\u003e\n\u003cp\u003eThis is how \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 operates — a group attributed with moderate confidence to Russia, working its way through Microsoft 365 tenants since August 2024. By March 2026, The Hacker News had documented \u003ca href=\"https://thehackernews.com/2026/03/device-code-phishing-hits-340-microsoft.html\"\u003e340+ affected organisations across five countries\u003c/a\u003e. The technique has a name that sounds harmless: \u003cstrong\u003edevice code phishing\u003c/strong\u003e.\u003c/p\u003e","title":"Device Code Phishing: Why Even Passkeys Won't Save Your Microsoft Tenant"},{"content":"On February 18, 2026, just after 4 p.m., Peter Wendel was looking forward to the end of his workday. Then his smartphone vibrated. An SMS, in the very chat thread where Trade Republic usually talks to him — login codes, security notices, the usual. This time it said a withdrawal from his account had been queued, one he hadn\u0026rsquo;t authorized. Right below it: an emergency hotline number. He called. Two hours later he had transferred 100,000 euros to a so-called \u0026ldquo;trust collection account\u0026rdquo; in Austria. It was the retirement savings he and his wife Nicole had built over more than 45 years.\nWendel, 63, reasonably tech-literate, briefly felt uneasy when an Austrian destination account was named — and let the voice on the hotline talk him into it anyway. Anyone accusing him of carelessness hasn\u0026rsquo;t yet understood how the attack was structured. The SMS wasn\u0026rsquo;t a suspicious fragment in clunky English. It was displayed in the same thread as the real codes from Trade Republic. That is exactly the problem I want to write about. And it\u0026rsquo;s one the German government has been ignoring for years.\nA sender ID anyone can write anything into If you receive an SMS today and your display reads \u0026ldquo;Trade Republic,\u0026rdquo; \u0026ldquo;DHL,\u0026rdquo; or \u0026ldquo;Sparkasse\u0026rdquo; at the top, that\u0026rsquo;s nothing more than a text field in a data packet. A field in a protocol designed in the eighties, when SMS still meant \u0026ldquo;Hi mom, almost there.\u0026rdquo; This text field is called the alphanumeric sender ID, and its central technical property is: it isn\u0026rsquo;t checked anywhere along the way.\nAnyone who sends SMS professionally — banks, parcel services, government agencies, but also marketing spammers and criminals — buys access to an SMS gateway. Such gateways are available across half of Europe for a few euros per thousand messages. On the order form you specify what should appear in the sender field. Up to eleven characters, anything you want. Nobody verifies whether \u0026ldquo;TradeRepubl\u0026rdquo; actually comes from Trade Republic Bank GmbH. The chain between client, gateway, and mobile carrier simply passes the ID through.\nThis isn\u0026rsquo;t a bug, it\u0026rsquo;s the specification. The SMS protocol was never designed for security-critical communication. Yet some banks have been using the channel for exactly that for decades — for TANs, verification codes, and status messages. Most German banks have moved on by now and rely on secure methods like app notifications. Trade Republic is one of the few remaining institutions that still uses SMS in a security context — and that is exactly what cultivates customer trust in a channel nobody authenticates.\nIn the same chat thread — and therefore granted the same trust The real lever of the attack on Wendel isn\u0026rsquo;t the SMS itself. It\u0026rsquo;s the display on the smartphone. Both iOS and Android group incoming messages by sender name into threads. If the real Trade Republic has been talking to you as \u0026ldquo;TradeRepubl\u0026rdquo; for months, and a phishing SMS suddenly arrives with the same sender ID, that phishing SMS lands in the same chat as all the real ones. Right below the last login code you received two weeks ago.\nImagine receiving an email from your bank — from the address the real confirmations come from — in the same mail thread, right below the last real replies. You wouldn\u0026rsquo;t doubt the content. That is exactly the configuration the alphanumeric sender ID creates for SMS, only without the protective layers email servers have built up against sender spoofing.\nThis exact scheme has been running against Trade Republic customers for months. BaFin (Germany\u0026rsquo;s Federal Financial Supervisory Authority) has been publicly warning since March 10, 2026; for one district alone, the Middle Franconia Police Headquarters reports financial losses in the multiple hundreds of thousands over recent weeks. When the SMS arrives in the real Trade Republic chat, victims call the number listed. The hit rate is high enough that it pays for the perpetrators to send another batch every hour.\nUK, Ireland, Singapore. And Germany. The technical problem has been known for years — and has been solved in several countries. The UK set up the SMS SenderID Protection Registry in 2018: banks, government agencies, and companies register their legitimate sender IDs there. Anyone trying to send an SMS under the name \u0026ldquo;Barclays\u0026rdquo; through a UK network without being authorized by Barclays gets blocked at the carrier level. More than 700 genuine sender IDs are currently protected, with over 3,750 spoofing variants on a shared blocklist — supported by BT/EE, O2, Three, and Vodafone together with the National Cyber Security Centre and UK Finance.\nIreland and Spain adopted the UK solution in 2021. Singapore went one step further: even under the voluntary registration introduced in 2022, SMS smishing cases dropped 64% between Q4 2021 and Q2 2022. Since January 31, 2023, the state regulator IMDA has been blocking every unregistered alphanumeric sender ID by default, replacing them with the label \u0026ldquo;Likely-SCAM.\u0026rdquo; France has required its mobile carriers since October 2024 to block unauthenticated foreign calls — regulation extending the same to SMS sender IDs is in preparation.\nIn Germany: nothing of the sort. The Bundesnetzagentur (Federal Network Agency) runs an SMS spam reporting service, but no authentication of sender IDs. The three major carriers — Deutsche Telekom, Vodafone, Telefónica/O2 — could start implementing a UK-style whitelist tomorrow. They don\u0026rsquo;t, because they don\u0026rsquo;t have to. As long as the risk sits with end customers, investing in sender ID filtering is, from a corporate perspective, a cost item with no return. That\u0026rsquo;s exactly the mechanism Singapore breaks by mandating filtering rather than recommending it.\nWhat needs to happen now German inaction isn\u0026rsquo;t an oversight, it\u0026rsquo;s a decision. The blueprints have been on the table for years — the UK does it voluntarily, Singapore by mandate. What\u0026rsquo;s missing is the political will to make them binding here too.\nTrade Republic needs to finally drop the SMS channel as a security channel. The web login does run primarily through app push — but after 30 seconds of waiting, the code can alternatively be sent via SMS. That leaves a direct SMS path into the account. Device pairing, PIN reset, and phone number verification all rely on the SMS channel anyway. As long as real Trade Republic SMS messages land in customers\u0026rsquo; inboxes, every phishing SMS has a ready-made foothold. That this trust anchor could also leave Trade Republic open to civil claims is now argued by an IT law specialist — alongside the absence of an emergency phone line. In-app verification is feasible and has long been in use at other banks. Trade Republic is a tech company with a full banking license; there are no technical reasons to stick with this.\nThe Bundesnetzagentur needs to mandate for German carriers what the UK has voluntarily upheld since 2018 and Singapore has enforced since 2023: a whitelist of approved sender IDs, with a blocklist for everything else. Until that happens, every new BaFin awareness campaign about helpfulness and trust is the tacit claim that smishing is a behavioral problem of the victims.\nFor Peter Wendel and his wife, tomorrow\u0026rsquo;s regulation changes nothing. The criminal investigation department had already told them on the day of the crime that the chances of getting the money back were slim. Anyone who wants to help them directly can do so through a donation. Anyone who has fallen for such an SMS themselves can find free template letters at JUN Legal for SEPA recall and GDPR data access requests — the first steps work without a lawyer.\nThe SMS Wendel received in February would never have reached his display in the UK. In Singapore it would have arrived with \u0026ldquo;Likely-SCAM\u0026rdquo; as the sender. In Germany it landed in the real chat thread. That isn\u0026rsquo;t a gap in the protection scheme — that is the protection scheme. As long as we stick with it, the next 100,000 euros are only a matter of time.\n","permalink":"https://lwst.io/en/posts/sms-phishing-alphanumeric-senderids/","summary":"\u003cp\u003eOn February 18, 2026, just after 4 p.m., Peter Wendel was looking forward to the end of his workday. Then his smartphone vibrated. An SMS, in the very chat thread where Trade Republic usually talks to him — login codes, security notices, the usual. This time it said a withdrawal from his account had been queued, one he hadn\u0026rsquo;t authorized. Right below it: an emergency hotline number. He called. Two hours later he had transferred 100,000 euros to a so-called \u0026ldquo;trust collection account\u0026rdquo; in Austria. It was the retirement savings he and his wife Nicole \u003ca href=\"https://www.gofundme.com/f/um-100000eur-betrogen-gesamte-private-altersvorsorge-weg\"\u003ehad built over more than 45 years\u003c/a\u003e.\u003c/p\u003e","title":"Eleven Characters, No Authentication"},{"content":"This site is live. Not a big occasion, but a start.\nI started this blog to write down my thoughts and findings from working in IT security — for myself, but perhaps also for others who have similar questions.\nWhat to expect here: practical topics from working in mid-sized organisations, insights from my Master\u0026rsquo;s studies, and the occasional crossover into student politics when the two worlds meet.\nAll posts reflect my personal views — not those of my employer or my university.\n","permalink":"https://lwst.io/en/posts/hallo-welt/","summary":"\u003cp\u003eThis site is live. Not a big occasion, but a start.\u003c/p\u003e\n\u003cp\u003eI started this blog to write down my thoughts and findings from working in IT security — for myself, but perhaps also for others who have similar questions.\u003c/p\u003e\n\u003cp\u003eWhat to expect here: practical topics from working in mid-sized organisations, insights from my Master\u0026rsquo;s studies, and the occasional crossover into student politics when the two worlds meet.\u003c/p\u003e\n\u003cp\u003eAll posts reflect my personal views — not those of my employer or my university.\u003c/p\u003e","title":"Hello World"},{"content":"Moin! I\u0026rsquo;m David Leeuwestein — IT Security lead, outdoor enthusiast, and proud northerner. By day I help protect the IT of mid-sized companies in the region; in parallel, I\u0026rsquo;m pursuing a Master\u0026rsquo;s in IT Security at the University of Lübeck. At night I get involved in student politics, advocating for students\u0026rsquo; interests at university level.\nOn this blog I share what I learn from working in IT security. All posts reflect my personal views — not those of my employer or my university.\nCurrently As of April 2026\nStudies: Master\u0026rsquo;s course \u0026ldquo;Threat Modeling\u0026rdquo; at the University of Lübeck — an interesting contrast between STRIDE methodology in the lecture hall and what actually holds up in day-to-day operations. Work: Refreshing the backup strategy for a mid-sized client — moving from daily full backups towards a combination of incremental, immutable, and offsite. Reading: Sandworm by Andy Greenberg — background on NotPetya and the Sandworm group. Student politics: Preparing for the next round of council meetings, focused on study-reform proposals and exam regulations. I update this list irregularly — if it hasn\u0026rsquo;t been touched in a while, my desk is probably busier than this page makes it look.\nContact Got a project I might be able to help with — or just want to get in touch? Drop me a line. I usually reply within a few working days. For confidential inquiries, you can also write to me encrypted (PGP key on request).\nEmail: blog@lwst.io LinkedIn: linkedin.com/in/david-leeuwestein-934725259 GitHub: github.com/cybertschunk Mastodon: @dd@digitalcourage.social ","permalink":"https://lwst.io/en/about/","summary":"About David Leeuwestein","title":"About"}]