Device Code Phishing Gets a Voice: Why Microsoft Entra Users Are Getting Unexpected Phone Calls
Device Code Phishing Gets a Voice: Why Microsoft Entra Users Are Getting Unexpected Phone Calls
I’ve been tracking an interesting evolution in phishing tactics lately, and frankly, it’s got me concerned about how attackers are getting more sophisticated with their social engineering. We’re seeing threat actors combine device code phishing with old-school voice calls to compromise Microsoft Entra accounts, and it’s working disturbingly well.
The New Hybrid Attack
Here’s what’s happening: attackers are targeting organizations in tech, manufacturing, and finance with a clever two-step process. First, they send the typical device code phishing email asking users to authenticate via a device code. But here’s the twist – they’re following up with actual phone calls (vishing) to walk victims through the process.
Hackers are exploiting the OAuth 2.0 Device Authorization flow in ways that feel legitimate to users. The device code flow was designed for legitimate scenarios where you need to authenticate on devices without easy input methods – think smart TVs or IoT devices. But attackers have figured out how to abuse this trust relationship.
What makes this particularly effective is the human element. When someone gets confused by the email (which is natural – device codes aren’t something most users encounter daily), they’re more likely to pick up the phone when “helpful IT support” calls to guide them through it. The voice component adds credibility that pure email phishing often lacks.
Why This Works So Well
I’ve been thinking about why this hybrid approach is so successful, and it comes down to exploiting our users’ desire to do the right thing. Most security-aware employees know they should be cautious about suspicious emails. But when someone calls claiming to be from IT and references the email they just received? That feels like confirmation rather than a red flag.
The OAuth flow itself also creates a false sense of security. Users see Microsoft’s legitimate authentication pages, which look exactly like what they’d expect during a real IT support interaction. The attackers aren’t hosting fake login pages – they’re using Microsoft’s own infrastructure against us.
The Patching Problem Continues
Speaking of infrastructure being used against us, CISA just added another vulnerability to their Known Exploited Vulnerabilities catalog. This time it’s affecting TeamT5’s ThreatSonar Anti-Ransomware product – yes, a security tool with an exploitable vulnerability. The irony isn’t lost on me.
The vulnerability was actually patched back in 2024, but CISA’s decision to add it to the KEV catalog now suggests they’re seeing active exploitation in the wild. This is exactly why we need to treat security tool updates with the same urgency as any other critical system.
Getting Creative with Incident Reports
On the phishing front, I came across another interesting tactic this week. Security researchers are reporting phishing campaigns that use fake incident reports as bait. The attackers are essentially weaponizing our own incident response processes against us.
These fake incident report emails are particularly insidious because they target the very people most likely to respond quickly to security incidents – our fellow security professionals. It’s a reminder that we need to verify incident reports through established channels, even when they look legitimate.
The Automation Reality Check
While we’re dealing with increasingly sophisticated attacks, there’s also some sobering news about our defensive capabilities. New research shows that 88% of AI proof-of-concept projects never make it to production, despite 70% of workers wanting AI to free up time for high-value work.
This gap between promise and reality in security automation is something we need to address. We’re facing more complex threats while struggling to implement the tools that could help us scale our response. The disconnect suggests we need to focus more on practical implementation and less on flashy demos.
What We Should Do
For the device code vishing attacks, user education needs to evolve beyond “be suspicious of emails.” We need to teach people that legitimate IT support will never cold-call about authentication issues. If someone receives an unexpected device code request, the response should be to contact IT through established channels, not to follow phone instructions from unknown callers.
On the technical side, we should review our conditional access policies for device code flows. Can we restrict which applications can use device codes? Can we require additional verification for device code authentication from new or unusual locations?
For the broader patching issue, this TeamT5 situation reinforces why we need comprehensive asset inventories that include security tools. These systems often get overlooked in patch management processes because teams assume security vendors are more diligent about updates.
The reality is that attackers are getting more creative while our defensive automation still has a long way to go. That means we need to double down on the fundamentals: user education, asset management, and verification processes that work even when the technology fails us.