Kali365 Phishing-as-a-Service Expands to Target AWS and Okta

Overview of the Kali365 Platform

The landscape of Phishing has shifted significantly with the rise of automated toolkits. According to Dark Reading, the FBI-flagged toolkit known as Kali365 has significantly broadened its operational scope. Originally designed to target Microsoft 365 users, this Phishing-as-a-service platform has evolved to facilitate credential and session theft across a wider array of cloud services, including Amazon Web Services (AWS) and Okta, as well as Russian-based platforms like Yandex and Mail.ru.

The Kali365 phishing-as-a-service expansion highlights a growing trend where threat actors move away from simple credential harvesting toward sophisticated session hijacking. By utilizing the OAuth 2.0 device authorization flow—commonly known as device code phishing—the kit allows attackers to gain persistent access to enterprise environments without ever needing the victim’s password or second-factor token directly. This transition makes the kit a potent threat to organizations relying on traditional multi-factor authentication (MFA) methods that do not specifically account for device-based authorization vulnerabilities.

Technical Analysis: Device Code Phishing

The core of the Kali365 attack involves the abuse of the Device Authorization Grant. This protocol was originally designed for devices that lack an easy input interface, such as smart TVs or IoT devices, allowing them to sign into a service by displaying a code that the user enters on a separate device (like a smartphone or laptop).

In a Kali365 campaign, the attacker sends a lure that triggers this flow. The victim is directed to a legitimate login page—such as microsoft.com/devicelogin—and prompted to enter a code provided by the attacker. Because the user is interacting with the official domain of the service provider, traditional EDR and email security filters often fail to flag the activity as malicious. Once the victim enters the code and authenticates, the service issues an access token and a refresh token directly to the attacker’s C2 infrastructure.

How to Detect Device Code Phishing Attacks

Security teams must adapt their monitoring strategies to identify this specific TTP. Within the MITRE ATT&CK framework, this falls under Adversary-in-the-Middle (AiTM) and Steal Web Session Cookie techniques. Detection hinges on auditing sign-in logs for the ‘Device Code’ grant type. A SOC analyst should look for instances where a device code flow is initiated from an IP address or geographic location that deviates from the user’s typical behavior. Furthermore, monitoring for the creation of new OAuth applications or the granting of high-privilege permissions to existing ones can provide early warning of a compromise.

Impact on AWS and Okta Environments

The expansion into Okta and AWS represents a significant escalation. Okta serves as the primary identity provider for thousands of enterprises; a compromised Okta session can lead to Lateral Movement across the entire corporate application stack. Similarly, gaining access to AWS via session tokens can allow an attacker to bypass Privilege Escalation checks if the hijacked identity has administrative roles, potentially leading to data exfiltration or the deployment of Ransomware in cloud environments.

Recommendations and Mitigation

To address the risks posed by Kali365, organizations must implement specific Okta and AWS phishing mitigation strategies. The following steps are recommended for immediate defense:

• Disable Device Code Flow: If your organization does not use devices that require the device code flow (e.g., smart conference room hardware), disable this feature entirely within Microsoft 365 and Okta settings.
• Enforce FIDO2-Based MFA: Transition away from push notifications or SMS codes toward phishing-resistant hardware keys. FIDO2/WebAuthn binds the authentication to the specific origin, preventing session theft through AiTM or device code flows.
• Conditional Access Policies: Implement strict Conditional Access policies that require managed, compliant devices for all administrative logins. This ensures that even if a token is stolen, it cannot be used from an unmanaged attacker-controlled machine.
• Log Correlation: Configure your SIEM to alert on successful logins using the device code flow that occur within a short window of a failed login or from a non-standard browser agent.