Cover Your Assets: How Microsoft Entra Conditional Access Stops AI-Driven Device Code Phishing

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.

Filter 1: The Coarse Mesh (Global Authentication & Basics)

This first layer catches the largest, most obvious debris. It represents your broad, sweeping organizational baselines.

• The Policy: A global policy requiring MFA for all standard users and blocking legacy authentication protocols completely.
  
  
• The Result: It lets the vast majority of legitimate user traffic pass through while instantly screening out simple, automated credential-stuffing attacks and brute-force attempts. This is your largest net.

Filter 2: The Medium Sediment Filter (Context & Location)

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.

• The Policy: Policies restricted by group membership, trusted networks, or geographic location. For example, if a user successfully inputs their password and MFA but the request originates from outside your defined "Named Locations," this filter catches it.
  
  
• The Result: The pool of allowed traffic shrinks further, ensuring only users operating within defined compliance boundaries move forward.

Filter 3: The Micro-Filter (Device Health & Flow Controls)

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.

• The Policy: High-security policies that demand specific device states (like requiring an Intune-compliant workstation) and explicitly block specific authentication mechanisms like Device Code Flow.
  
  
• The Result: Only completely verified, trusted identities operating on authorized, healthy machines are permitted through to your crown-jewel data applications.
  
  

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:

• Conference Room Technology: Smart TVs and Microsoft Teams Rooms (MTR) consoles use it to link hardware to resource mailboxes.
  
  
• Command Line Interfaces (CLI): Network engineers and cloud architects use az login --use-device-code to connect to developer toolkits or headless servers.
  
  
• Printers and Multi-Function Devices: Enterprise copiers use this flow to safely bind hardware to cloud print-queues like SharePoint and OneDrive.
  
  

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:

• Go to the Microsoft Entra admin center.
  
  
• Search for Conditional Access and go to Policies.
  
  
• Click New policy and name it something like Global - Block Device Code Flow.
  
  
• Under Assignments, select All Users (but always exclude your emergency break-glass accounts).
  
  
• Under Target Resources, choose All Resources.
  
  
• Go to Conditions > Authentication Flows, toggle Configure to Yes, check Device code flow, and click Save.
  
  
• Under Access Controls > Grant, select Block access.
  
  
• Under Enable policy, select the toggle for Report-only and click Create.
  

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!