Cthullu, BlueHammer, NK, CUPs, Axios, Fortinet, Cognitive Surrender, Aaran Leyland – SWN #570

Doug White

1. Device code phishing attacks surge 37x as new kits spread online
2. Disgruntled researcher leaks “BlueHammer” Windows zero-day exploit
3. North Korea recruits Iranian workers for IT job fraud
4. Axios maintainer’s post mortem confirms social engineering by UNC1069
5. AI agents found vulns in this Linux and Unix print server
6. Fortinet Rushes Emergency Fixes for Exploited Zero-Day
7. China is winning one AI race, the US another – but either might pull ahead
8. “Cognitive surrender” leads AI users to abandon logical thinking, research finds

Aaran Leyland

1. Device code phishing attacks surge 37x as new kits spread online

   First, if you have Entra P1 or above, audit device code usage and get as close as you can to a default block. Microsoft now explicitly recommends that, and it has rolled out managed policies to limit device code flow. Second, if you are on the free tier, be honest about the gap. Security Defaults is better than nothing, but it does not give you this granular block. In that case, use the cheap friction controls as well. Where your mail stack allows it, flag or block direct Microsoft device-login links in mail and chat, be suspicious of QR-code document lures, and teach users one simple rule: nobody legitimate should be sending them a short code and telling them to enter it into Microsoft to read a file or join a meeting.

   Blocking direct Microsoft device-login links is worth doing, but it is only a speed bump, because newer campaigns often use intermediate pages on Cloudflare Workers, Vercel or similar services before handing the user to the real Microsoft page.

   Then monitor logs for unexpected device code authentication events [because the login page is real, your best evidence is usually identity telemetry: device-code sign-ins where you do not use them, odd IPs, fast mailbox or OneDrive access, suspicious inbox rules, or new device registrations]. Microsoft, Huntress and Push all point defenders back to anomalous IPs and follow-on session behaviour. And if you think a user has been hit, do not just reset the password and walk away. Revoke sign-in sessions, review device registrations, mailbox rules and recent Graph access, and assume the attacker may still have usable tokens until you explicitly kill the session. The forward point is simple. As passkeys kill more old credential phishing, more attackers will move into approval and authorisation abuse like this. So yes, deploy phishing-resistant auth. But do not kid yourself that it closes this gap by itself.