FBI Alert: Kali365 Phishing-as-a-Service Hijacks M365 OAuth Tokens — Detection and Defense

The FBI has issued a warning regarding 'Kali365,' a sophisticated social engineering-as-a-service (SEaaS) platform specifically designed to hijack Microsoft 365 (M365) OAuth tokens. This kit represents a significant escalation in the Phishing-as-a-Service (PhaaS) ecosystem, lowering the barrier to entry for cybercriminals by automating Adversary-in-the-Middle (AiTM) attacks. Unlike standard credential phishing, Kali365 focuses on stealing session tokens, allowing attackers to bypass Multi-Factor Authentication (MFA) and maintain persistent access to corporate environments.

Introduction

Kali365 is not just another phishing template; it is a functional platform that facilitates AiTM attacks. By acting as a reverse proxy between the target user and the legitimate Microsoft 365 login page, the kit intercepts authentication traffic. When a user enters credentials and completes MFA challenges, the attacker relays the request to Microsoft, receives the valid OAuth session token, and captures it. The result is a fully authenticated session that the attacker can use from their own infrastructure, rendering MFA protections ineffective.

For defenders, this threat is urgent. If an actor successfully compromises a token, they gain the same privileges as the user without triggering traditional MFA alerts. This post provides a technical breakdown of the Kali365 threat and actionable detection logic to hunt for compromised tokens and adversary tooling.

Technical Analysis

Threat Type: Social Engineering-as-a-Service (PhaaS) / AiTM Attack Affected Products: Microsoft 365 (Azure AD / Entra ID) CVE Identifiers: N/A (Configuration/Abuse of protocol) Exploitation Status: Confirmed Active Exploitation (FBI Alert)

Attack Chain:

1. Initial Vector: Target receives a highly convincing phishing email (often leveraging legitimate-looking links via open redirector abuse or typosquatting).
2. Reverse Proxy Execution: Upon clicking, the user is directed to a threat-controlled server (Kali365 kit) which proxies the legitimate Microsoft login portal.
3. Credential Harvesting: The user enters their username and password. The Kali365 server forwards these to Microsoft.
4. MFA Bypass: Microsoft issues an MFA challenge (push notification, code, etc.). The user approves. The Kali365 server forwards the approval to Microsoft.
5. Token Theft: Microsoft issues a session token (Access Token, Refresh Token, ID Token) to the Kali365 server. The server captures this token and redirects the user to the legitimate site (or a fake success page).
6. Post-Exploitation: Attackers use the stolen token to authenticate to M365 services (Outlook, Teams, SharePoint) via tools like ROADtools or browser extensions, often bypassing Conditional Access policies that rely solely on user identity or location.

Why It Matters: This attack negates the security value of MFA. While the user's credentials are not technically stolen (the user logs in successfully), the session is hijacked. This is often followed by 'Business Email Compromise' (BEC) or lateral movement.

Detection & Response

Detecting the phishing email itself relies heavily on mail filters. However, detecting the successful compromise requires hunting for the usage of the stolen tokens or the tools used to manipulate them. The following queries focus on detecting the post-exploitation phase where attackers interact with the M365 environment using these hijacked tokens.

SIGMA Rules

---
title: Potential M365 OAuth Token Usage via ROADtools
id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects the execution of ROADtools Python scripts, commonly used to interact with Azure AD/Entra ID using stolen OAuth tokens.
references:
  - https://github.com/dirkjanm/ROADtools
author: Security Arsenal
date: 2025/04/04
tags:
  - attack.credential_access
  - attack.t1528
  - attack.t1552.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_python:
    Image|endswith: '\python.exe'
    CommandLine|contains:
      - 'roadrecon'
      - 'roadtx'
      - 'roadlib'
  selection_powershell:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'Get-AADIntToken'
      - 'Invoke-AADIntReconAsUser'
  condition: 1 of selection_
falsepositives:
  - Legitimate administration by security teams using ROADtools for auditing
level: high
---
title: Suspicious PowerShell Module Import for Azure AD
id: 2b3c4d5e-6f7a-8b9c-0d1e-2f3a4b5c6d7e
status: experimental
description: Detects loading of specific PowerShell modules often used to manipulate M365 tokens or sessions in a non-standard context.
references:
  - https://attack.mitre.org/techniques/T1059/001
author: Security Arsenal
date: 2025/04/04
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'Import-Module AADInternals'
      - 'Import-Module MSOnline'
      - 'Connect-MsolService'
  filter_admin:
    ParentImage|contains:
      - '\explorer.exe'
      - '\mmc.exe'
  condition: selection and not filter_admin
falsepositives:
  - Administrative automation scripts
level: medium

KQL (Microsoft Sentinel / Defender)

This query hunts for suspicious process executions on endpoints that indicate an attacker is utilizing a stolen token to access M365 APIs via command-line tools.

// Hunt for common Azure AD/M365 token manipulation tools
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in ("powershell.exe", "cmd.exe", "python.exe", "python3.exe")
| where ProcessCommandLine has_any ("roadtoken", "roadrecon", "AADInternals", "Get-AADInt", "msal", "oauth", "access_token")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine, FolderPath
| order by Timestamp desc

Velociraptor VQL

Hunt for processes and artifacts associated with token theft and Azure AD interaction.

-- Hunt for suspicious processes related to M365 token theft tools
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'python.*'
   AND CommandLine =~ 'road(recon|token|tx)'
   OR Name =~ 'powershell.*'
   AND CommandLine =~ 'AAD(Internals|Int)'

Remediation Script (PowerShell)

This script helps identify users who may have been impacted by looking for recent sign-ins that meet criteria consistent with AiTM attacks (e.g., successful MFA from an impossible travel context or non-compliant device). Note: Requires Microsoft Graph PowerShell module.

# Audit M365 Sign-ins for Potential AiTM / Token Theft Indicators
# Requires Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

$StartDate = (Get-Date).AddDays(-3)
$Filter = "createdDateTime gt $StartDate"

# Get Sign-in logs with failures or specific risk details
Write-Host "Fetching sign-in logs..."
$SignIns = Get-MgAuditLogSignIn -Filter $Filter -Top 1000 -All

# Filter for sign-ins that succeeded but have risk flags or originated from unknown device/resources
$RiskySignIns = $SignIns | Where-Object {
    $_.Status.ErrorCode -eq 0 -and 
    ($_.RiskDetail -ne 'none' -or $_.RiskLevelDuringSignIn -ne 'none' -or $_.DeviceDetail.IsCompliant -eq $false)
}

if ($RiskySignIns) {
    Write-Host "Found $($RiskySignIns.Count) potentially risky sign-ins." -ForegroundColor Yellow
    $RiskySignIns | Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, 
        @{N='RiskDetail';E={$_.RiskDetail}}, 
        @{N='RiskLevel';E={$_.RiskLevelDuringSignIn}},
        @{N='DeviceCompliant';E={$_.DeviceDetail.IsCompliant}},
        @{N='Location';E={$_.Location.City + ", " + $_.Location.CountryOrRegion}} | Format-Table -AutoSize
} else {
    Write-Host "No high-risk sign-ins detected in the last 3 days." -ForegroundColor Green
}

Remediation

1. Implement Conditional Access Policies (CAP) to Block Token Theft: Standard MFA is not enough against AiTM. You must enforce context-aware access.

• Require Compliant or Hybrid Azure AD Joined Devices: Create a CAP that requires devices to be marked as "Compliant" (Intune managed) or "Hybrid Azure AD Joined" for sensitive apps (Exchange, SharePoint). An attacker with a stolen token on a rogue device will not have a compliant device ID and will be blocked.
• Enforce 'Phishing-Resistant' MFA: Deploy FIDO2 security keys or Microsoft Authenticator with Number Matching. While AiTM bypasses the code, it cannot easily bypass the cryptographic proof of a FIDO2 key or the specific interaction of Number Matching in some flows.

2. Configure 'Token Protection' (Conditional Access Grant): Enable the "Sign-in frequency" and "Session constraints" controls. Specifically, look into the "Continuous Access Evaluation" (CAE) capabilities and ensure 'Insider Risk Management' policies are reviewed.

3. User Education and Reporting:

• Train users to recognize the subtle signs of AiTM, such as a URL that is slightly off (e.g., login.micros0ft.com vs login.microsoft.com).
• Encourage the use of the "Report Message" button in Outlook.

4. Vendor References:

• Microsoft Security: Resisting AiTM phishing attacks
• FBI Flash Alert (Search for Kali365)

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub