You can spend lots of time meticulously hardening your network perimeter, adjusting firewalls, and making sure your infrastructure is pristine. But the second a user falls for a clever phishing trick, an attacker halfway across the world instantly gets a valid token to walk straight into your corporate cloud. In cybersecurity, we always talk about the importance of CYA—Covering Your Assets. But all the asset coverage in the world doesn’t matter if you leave the digital back door wide open for attackers to walk right through.
Historically, we told our teams to watch out for fake login pages that steal passwords. But the threat landscape has changed dramatically. A recent FBI Public Service Announcement (PSA260521) warned organizations about an emerging Phishing-as-a-Service platform called Kali365.
Distributed on Telegram channels, Kali365 allows even low-skill attackers to use AI-generated lures that perfectly mimic corporate jargon to bypass Multi-Factor Authentication (MFA) entirely. They don't want your password; they want your OAuth session tokens, and they are abusing a legitimate protocol called Device Code Flow to get them.
In the modern enterprise landscape, identity is your new perimeter. If you are your company’s cloud assets bouncer, you need a way to say: "Congratulations, you solved the password riddle. But you're on an unknown computer, outside our corporate network, in a country we've never operated in. You're not getting past the velvet rope."
That is where Microsoft Entra Conditional Access Policies come into play. It is Microsoft’s "if/then" engine for identity security. Let's look at how to architect these filters properly to stop bad actors in their tracks—without interrupting your users.
Visualizing Conditional Access: Like Water Filtration
Think of your corporate identity ecosystem as a stream of raw, incoming water. It contains essential resources your business needs to survive, but it also carries some dirty little debris, sediment, and microscopic pathogens.
If you try to stop everything with one single massive block, you’ll end up filtering out too much or not enough. Instead, layered purpose-built Conditional Access Policies function just like a multi-stage water filtration system.
This first layer catches the largest, most obvious debris. It represents your broad, sweeping organizational baselines.
As the water flows deeper, the pores get smaller. This stage inspects the contextual signals surrounding the login request to catch suspicious elements that slipped through the mesh.
This is the finest layer of defense, designed to trap microscopic pathogens—like session hijacking attempts or unauthorized device code flows—that look like clean water but carry hidden malicious payloads.
Let’s Talk About Device Code Flow, and Where is it Used?
Device Code Flow is like logging into Netflix on a smart TV. Because typing with a remote is difficult, the TV gives you a short code to enter into your phone's browser instead. There are plenty of IOT devices without a keyboard or browser, so this method gives us another way to authenticate.
The device displays a unique code (like B2C4D6F8) and directs the user to open a browser on a secondary device (like a smartphone) at https://microsoft.com/devicelogin. The user logs in on their phone, enters the code, and the session token is handed back to the original device.
Kali365 abuses this. The attacker triggers a device code flow, sends the code to your user via an AI-generated email lure, and tricks them into entering it onto the legitimate Microsoft page. Once the victim approves it, the attacker steals the session token and bypasses MFA completely.
We might not want to just disable it completely though. Device Code Flow can be a vital operational tool. It is commonly found in environments where traditional web-based sign-in forms can’t be used:
Staging a "Report-Only" Policy to Block Device Code Flow
Turning off an entire authentication protocol across an organization can feel like defusing a bomb. If you flip the switch too fast, you risk breaking vital business operations. To prevent these headaches, use Microsoft Entra ID's Report-only mode. This evaluates real-time sign-ins against your new rules and logs exactly what would have happened—without interrupting a single user.
Step-by-Step Configuration:
Checking on the Report-Only Policy
After creating your policy, you can go back to policies, select your device code blocking policy and click on “Policy impact” to see how many sign-ins would fail if the policy were on. That should help you decide if you need to add any exceptions or go talk to some people about what they’re doing.
Automatically Auditing Device Code Usage via PowerShell
Although you could check the portal daily to see who’s using device code flow, you can automate this discovery phase. Because authentication protocol tracking data resides in the advanced sign-in telemetry, you need to call the Microsoft Graph Beta endpoint.
The following PowerShell script leverages the Microsoft.Graph.Beta module to automatically look for any logins that utilized the devicecode protocol within your tenant:
powershell
# Install the required Beta module if you don't have it
# Install-Module Microsoft.Graph.Beta -Scope CurrentUser
# Connect to Microsoft Graph with the necessary audit log read permissions
Connect-MgGraph -Scopes "AuditLog.Read.All"
# Query the Beta Sign-in logs specifically for the Device Code protocol
Write-Host "Searching for Device Code Flow authentication events..." -ForegroundColor Cyan
$DeviceCodeSignIns = Get-MgBetaAuditLogSignin -Filter "AuthenticationProtocol eq 'devicecode'" -All
# Parse and display the results cleanly
if ($DeviceCodeSignIns) {
$DeviceCodeSignIns | Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, IPAddress, ClientAppUsed |
Out-Gridview -Title "Detected Device Code Flow Sign-ins"
} else {
Write-Host "No Device Code Flow authentication events detected in the log history." -ForegroundColor Green
}
By mapping out the users, applications, and IP addresses generated by this script, you can gather a complete list of legitimate devices that require a tailored policy exclusion group before flipping your policy toggle from Report-only to On.
Wrapping Up
Identity security is a continuous process, not a one-time project. Before you start turning things off, you need to understand who or what it will affect. Extra time in planning and testing will be worth it to keep your data safe while keeping your daily operations moving smoothly.
LookingPoint offers multiple IT services if you’re interested. Want more information, give us a call! Please reach out to us at sales@lookingpoint.com and we’ll be happy to help!