Back to Intelligence

Kali365 Phishing Kit Weaponizes Microsoft Authentication: AiTM Detection and Defense Guide for Microsoft 365

SA
Security Arsenal Team
August 5, 2026
11 min read

The emergence of the Kali365 phishing kit marks another escalation in adversary-in-the-middle (AiTM) attacks against US enterprises — and this one goes straight at the heart of your identity perimeter: Microsoft authentication itself. Rather than simply harvesting credentials on a lookalike login page, Kali365 positions itself transparently between the victim and legitimate Microsoft sign-in infrastructure, proxying the real authentication flow in real time. The result is that even users who complete multi-factor authentication can have their session tokens stolen and replayed, granting attackers authenticated access to Microsoft 365 without ever needing the password or MFA device again.

For organizations running on Entra ID (Azure AD) and Microsoft 365 — which is to say, most US enterprises — this is a critical identity risk. MFA is no longer the finish line; it's a checkpoint attackers are actively routing around. Security teams need to shift detection focus from failed logins and credential submission to post-authentication anomalies: token issuance irregularities, session replay, impossible travel, and illicit OAuth consent.

This post breaks down how Kali365-style AiTM attacks work against Microsoft authentication, and provides field-tested detection rules, hunt queries, and hardening steps you can deploy this week.

Technical Analysis: How Kali365 Abuses Microsoft Authentication

Attack Chain Overview

Kali365 follows the mature AiTM phishing-as-a-service (PhaaS) model that has evolved significantly over the past two years:

  1. Delivery — Victims receive a lure (typically a themed business email: invoice, shared document, HR notice, or voicemail notification) containing a link to an attacker-controlled proxy domain. Delivery often abuses legitimate services (URL shorteners, open redirects, compromised sites) to survive secure email gateways.

  2. Transparent Reverse Proxy — The victim lands on a pixel-perfect Microsoft login page that is, in fact, a live proxy to login.microsoftonline.com. Every keystroke, challenge, and response flows through the attacker's infrastructure. Because the victim is interacting with the real Microsoft backend, conditional access branding, custom tenant logos, and even MFA prompts all render authentically.

  3. Credential + MFA Relay — The victim enters credentials and completes MFA (push approval, OTP, SMS). The proxy relays these to Microsoft in real time. Microsoft issues legitimate session artifacts — the primary refresh token (PRT) flow or web session cookies.

  4. Token Theft and Replay — The attacker captures the session cookie / refresh token and imports it into their own browser or tooling (often via token-replay frameworks), achieving authenticated access to Exchange Online, SharePoint, Teams, and OneDrive without triggering MFA again, because the session is already post-authentication.

  5. Persistence and Entrenchment — With mailbox access, attackers commonly create malicious inbox rules to hide replies, register rogue OAuth applications or consent grants for durable access, and in some cases register their own MFA methods or devices to survive password resets.

Why This Defeats Traditional MFA

SMS, TOTP, and even push-based MFA are phishable — the user interactively approves the prompt during a relayed session. The authentication is genuine; it's simply being proxied through hostile infrastructure. Only phishing-resistant MFA — FIDO2 security keys, Windows Hello for Business, or certificate-based authentication with token binding — cryptographically binds the authentication to the legitimate origin and breaks the relay.

Exploitation Status

  • Actively exploited in the wild: Kali365 is being used in live campaigns targeting US organizations across multiple sectors.
  • No CVE applies: This is not a software vulnerability in Microsoft products — it is abuse of legitimate, standards-based authentication flows. There is no patch; mitigation is architectural and procedural.
  • Delivery infrastructure rotates constantly: Indicator-based blocking (domains, IPs) has a short shelf life. Behavioral detection on the identity layer is the durable defense.

Detection & Response

The most reliable detection surface is Entra ID sign-in and audit telemetry, combined with endpoint signals for the delivery and post-compromise phases. The rules below target observable behaviors consistent with AiTM token theft and post-compromise activity — tuned to avoid drowning your SOC in noise.

YAML
---
title: Suspicious OAuth Consent Grant Following Anomalous Sign-In
id: 3f8a1b42-7c9d-4e51-a2b6-9d4e5f6a7b8c
status: experimental
description: Detects new OAuth application consent grants in Entra ID, a common persistence mechanism after AiTM session token theft. Correlate with sign-in anomalies and alert on grants to unverified publishers or broad mail/Graph scopes.
references:
  - https://attack.mitre.org/techniques/T1528/
  - https://attack.mitre.org/techniques/T1557/002/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.persistence
  - attack.credential_access
  - attack.t1557.002
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName:
      - 'Consent to application'
      - 'Add service principal'
      - 'Add app role assignment to service principal'
  filter_verified:
    # Reduce noise from well-known verified first-party/enterprise apps
    properties.TargetResources|contains: 'verified'
  condition: selection and not filter_verified
falsepositives:
  - Legitimate line-of-business app onboarding (maintain an allowlist of approved app display names)
  - Admin-initiated enterprise application registrations
level: high
---
title: Malicious Inbox Rule Creation for Email Concealment
id: 6e2d9c14-4a7f-4b83-91d5-2c8e3f5a6b7d
status: experimental
description: Detects Exchange Online inbox rule creation that hides or deletes messages, a hallmark of business email compromise and post-AiTM mailbox access. Rules moving messages to RSS/Archive/Junk or auto-deleting replies are frequently used to conceal attacker conversations from the victim.
references:
  - https://attack.mitre.org/techniques/T1098/002/
  - https://attack.mitre.org/techniques/T1557/002/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.persistence
  - attack.defense_evasion
  - attack.t1098.002
logsource:
  product: azure
  service: exchange
detection:
  selection:
    Operation:
      - 'New-InboxRule'
      - 'Set-InboxRule'
  suspicious_params:
    Parameters|contains:
      - 'DeleteMessage'
      - 'RSS Subscriptions'
      - 'Conversation History'
      - 'MoveToFolder'
  condition: selection and suspicious_params
falsepositives:
  - User-created organizational rules (tune by excluding known benign folder targets in your tenant)
level: medium
---
title: Browser-Spawning Script Interpreter After Phishing Link Click
id: 9c4e7a21-5d3b-48f2-b6a1-8e7d2c4f5a6b
status: experimental
description: Detects script interpreters (PowerShell, mshta, rundll32) spawned by a browser process, consistent with post-click phishing payload execution observed in some AiTM delivery chains (HTML smuggling, fake update lures). High-signal when combined with identity-layer detections.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1566/002/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.execution
  - attack.initial_access
  - attack.t1566.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\msedge.exe'
      - '\chrome.exe'
      - '\firefox.exe'
      - '\brave.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare browser extension or enterprise web-app integrations (baseline first)
level: high
KQL — Microsoft Sentinel / Defender
// Hunt: AiTM session token theft indicators — anomalous token replay and auth-method abuse
// Sentinel tables: SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs, OfficeActivity
// 1) Sign-ins where a session is reused from a new IP/ASN without fresh MFA,
//    followed by mailbox or OAuth activity within a short window
let lookback = 14d;
let suspicious_signins =
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| summarize arg_min(TimeGenerated, *) by UserPrincipalName, SessionId, IPAddress
| extend AuthMethods = tostring(AuthenticationDetails)
| project SignInTime=TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, UserAgent, SessionId, AuthMethods, AuthenticationRequirement;
// 2) Join to OAuth consent grants shortly after (persistence stage)
let consent_events =
AuditLogs
| where TimeGenerated > ago(lookback)
| where OperationName has_any ("Consent to application", "Add service principal")
| extend InitiatedByUPN = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetApp = tostring(TargetResources[0].displayName)
| project ConsentTime=TimeGenerated, InitiatedByUPN, TargetApp, OperationName;
suspicious_signins
| join kind=inner consent_events on $left.UserPrincipalName == $right.InitiatedByUPN
| where ConsentTime between (SignInTime .. SignInTime + 4h)
| project UserPrincipalName, SignInTime, IPAddress, Location, AppDisplayName, UserAgent, ConsentTime, TargetApp, OperationName
| order by SignInTime desc;
// 3) Standalone hunt: sign-ins from data-center/hosting ASNs or anonymizers against interactive apps
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where AppDisplayName has_any ("Office 365", "Microsoft Office", "SharePoint", "Exchange")
| extend NetworkDetails = tostring(NetworkLocationDetails)
| where NetworkDetails has_any ("hosting", "datacenter", "vpn", "proxy") or LocationDetails has "anonymous"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, UserAgent, NetworkDetails
| order by TimeGenerated desc
VQL — Velociraptor
-- Hunt for browser-spawned script interpreters consistent with phishing payload execution
-- Deploy across endpoints via Velociraptor hunt; enrich hits with sign-in telemetry in Sentinel
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       parent().Name AS ParentName, parent().Exe AS ParentExe, parent().CommandLine AS ParentCmd
FROM pslist()
WHERE (Name =~ '(?i)powershell|pwsh|mshta|rundll32|wscript|cscript')
  AND (parent().Name =~ '(?i)msedge|chrome|firefox|brave|outlook|teams')
ORDER BY CreateTime DESC
PowerShell
# Kali365 / AiTM Phishing Response & Hardening Script (Microsoft 365 / Entra ID)
# Requires: Microsoft.Graph PowerShell SDK with scopes:
#   AuditLog.Read.All, Directory.Read.All, Policy.ReadWrite.ConditionalAccess,
#   Application.Read.All, UserAuthenticationMethod.Read.All
# Run as a Global Admin / Cloud App Admin during investigation or scheduled audit.

Import-Module Microsoft.Graph.Identity.SignIns
Import-Module Microsoft.Graph.Identity.DirectoryManagement
Import-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All","Policy.ReadWrite.ConditionalAccess","Application.Read.All" -NoWelcome

# ---- 1. AUDIT: Find OAuth consent grants from the last 14 days (persistence check) ----
$since = (Get-Date).AddDays(-14).ToString("yyyy-MM-ddTHH:mm:ssZ")
$consents = Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $since" -All |
    Where-Object { $_.ActivityDisplayName -in @("Consent to application","Add service principal") }
$consents | Select-Object ActivityDateTime,
    @{N='InitiatedBy';E={$_.InitiatedBy.User.UserPrincipalName}},
    ActivityDisplayName,
    @{N='TargetApp';E={$_.TargetResources[0].DisplayName}} |
    Format-Table -AutoSize
Write-Host "[+] Review each consent above. Unknown/unverified publisher apps should be investigated and revoked." -ForegroundColor Yellow

# ---- 2. AUDIT: OAuth grants with high-risk Graph scopes (mail/offline access) ----
$riskyScopes = @("Mail.Read","Mail.ReadWrite","Mail.Send","Files.ReadWrite.All","offline_access","full_access_as_app")
$grants = Get-MgOauth2PermissionGrant -All
foreach ($g in $grants) {
    $matched = $riskyScopes | Where-Object { $g.Scope -match [regex]::Escape($_) }
    if ($matched) {
        $sp = Get-MgServicePrincipal -ServicePrincipalId $g.ClientId -ErrorAction SilentlyContinue
        Write-Host "[!] RISKY GRANT: $($sp.DisplayName) ($($g.ClientId)) scopes: $($g.Scope)" -ForegroundColor Red
    }
}

# ---- 3. RESPONSE: Revoke refresh tokens for a compromised user ----
# Usage: Revoke-UserSessions -Upn "victim@company.com"
function Revoke-UserSessions {
    param([Parameter(Mandatory=$true)][string]$Upn)
    $user = Get-MgUser -UserId $Upn
    Revoke-MgUserSignInSession -UserId $user.Id
    Write-Host "[+] Refresh tokens revoked for $Upn. Force password reset + re-register MFA." -ForegroundColor Green
    # List auth methods so you can spot attacker-registered MFA devices
    Get-MgUserAuthenticationMethod -UserId $user.Id | Select-Object Id, CreatedDateTime
}

# ---- 4. HARDEN: Verify Conditional Access baseline exists ----
$policies = Get-MgIdentityConditionalAccessPolicy -All
Write-Host "`n[+] Conditional Access Policies in tenant:" -ForegroundColor Cyan
$policies | Select-Object DisplayName, State, CreatedDateTime | Format-Table -AutoSize
Write-Host "[!] REQUIRED controls to deploy if missing:" -ForegroundColor Yellow
Write-Host "    - Phishing-resistant MFA (FIDO2/WHfB) for all users, enforced for admins"
Write-Host "    - Block legacy authentication (basic auth cannot complete modern MFA relay safely)"
Write-Host "    - Token Protection (session binding) CA policy for Exchange Online & SharePoint"
Write-Host "    - Block authentication transfer / device code flow where not required"
Write-Host "    - Restrict consent: disable user consent to apps; require admin consent workflow"

# ---- 5. HARDEN: Disable user app consent (stops illicit grant persistence) ----
$authPolicy = Get-MgPolicyAuthorizationPolicy
if ($authPolicy.DefaultUserRolePermissions.PermissionGrantPoliciesAssigned -notcontains "ManagePermissionGrantsForSelf.microsoft-user-default-legacy") {
    Write-Host "[+] User self-consent already restricted." -ForegroundColor Green
} else {
    Write-Host "[!] User consent to apps appears enabled. Recommended: set to 'Do not allow user consent'" -ForegroundColor Red
    Write-Host "    Portal: Entra ID > Enterprise applications > Consent and permissions > User consent settings"
}

# ---- 6. AUDIT: Flag users with recently added authentication methods ----
$report = Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $since" -All |
    Where-Object { $_.ActivityDisplayName -match "registered security info|Add authentication method|user registered security info" }
$report | Select-Object ActivityDateTime, ActivityDisplayName,
    @{N='Target';E={$_.TargetResources[0].UserPrincipalName}} | Format-Table -AutoSize

Remediation and Hardening Roadmap

Because Kali365 abuses legitimate authentication flows, there is no vendor patch. Your defense is configuration, policy, and identity-layer monitoring. Prioritize in this order:

1. Deploy Phishing-Resistant MFA (Highest Impact)

  • Roll out FIDO2 security keys or Windows Hello for Business for all users; mandate it immediately for admins, finance, and executives.
  • These methods cryptographically bind authentication to the genuine login.microsoftonline.com origin — a relayed session fails outright.
  • Reference: Microsoft phishing-resistant MFA guidance

2. Enable Conditional Access Token Protection

  • Microsoft's Token Protection (token binding) CA policy binds session tokens to the issuing device, making stolen tokens useless when replayed from attacker infrastructure. Enforce for Exchange Online and SharePoint Online first.
  • If not yet licensed/available in your tenant, use sign-in frequency + compliant device requirements as a compensating control.

3. Restrict Device Code and Authentication Transfer Flows

  • Block or tightly scope device code flow and authentication transfer via Conditional Access authentication context / authentication strengths — these flows are frequently abused by AiTM kits for MFA fatigue and session migration.

4. Kill Legacy Authentication and Lock Down Consent

  • Block legacy/basic authentication tenant-wide via CA policy.
  • Set user consent to applications: Do not allow and route approvals through the admin consent workflow. Audit existing grants (script above) for suspicious scopes like Mail.Read, offline_access, and full_access_as_app.

5. Post-Compromise Playbook (If You Suspect Token Theft)

  1. Revoke-MgUserSignInSession to invalidate refresh tokens immediately.
  2. Force password reset AND review/re-register MFA methods — attackers often add their own authenticator.
  3. Audit inbox rules for concealment rules (DeleteMessage, RSS folders).
  4. Audit OAuth grants and new service principals created within ±4 hours of the anomalous sign-in.
  5. Review audit logs for mailbox access patterns and external forwarding.
  6. Preserve sign-in/audit telemetry for the full retention window before triage — AiTM infrastructure rotates fast, and the identity timeline is your forensic backbone.

6. Continuous Monitoring

  • Deploy the Sigma rules and Sentinel queries above; alert on the join of anomalous sign-in + consent grant, which is the highest-fidelity Kali365 signal.
  • Feed Entra ID Protection risk detections into your SOAR for automated token revocation on high-risk sign-ins.

The lesson Kali365 reinforces is one we've been telling clients for years: identity is the perimeter, and tokens are the new credentials. Phishing-resistant MFA plus token binding closes the relay window that AiTM kits depend on. Everything else is detection depth.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.