AI-Augmented PhaaS and the Machine-Speed Threat

This is Part 3 of a three-part series researching how malicious actors are using readily available artificial intelligence tools to make their attacks faster, cheaper, and more convincing.

In Part 1, we traced how AI moved from conference demos to a subscription feature of real criminal platforms, and why that shift has left many security teams defending at human speed against attacks running at machine speed. In Part 2, we looked at the Phishing as a Service (PhaaS) economy, where MFA-bypassing kits rent for a few hundred dollars a month and increasingly use large language models to mine compromised mailboxes and automatically compose and send phishing emails.

Modern Phishing as a Service (PhaaS) kits don't execute phishing campaigns. They execute automated, multi-phase workflows that run from initial access through post-compromise exploitation with minimal operator intervention. Part 3 is for the practitioners: the analysts, detection engineers, and incident responders who need to understand what the tooling does, how to spot it, and where it maps in MITRE ATT&CK.

Phase 1: Initial Access (TA0001)

Two dominant techniques power the current generation of PhaaS for gaining an initial foothold, both centered on abusing legitimate authentication processes rather than exploiting vulnerabilities. The first is AiTM reverse proxy activity (T1557), where the kit acts as a real-time man-in-the-middle between the victim and a legitimate authentication service. Credentials and MFA tokens are relayed live, the authenticated session cookie is captured, and the attacker walks away with a fully valid session. The victim successfully logs in, MFA is completed, and from both perspectives the transaction appears legitimate yet the attacker now holds an authenticated session indistinguishable from the user. This technique underpins platforms such as EvilProxy and Tycoon 2FA. Alongside this, OAuth device code phishing (T1528 / T1566.002) has emerged as a more subtle and resilient alternative. Instead of presenting a phishing page, the attacker generates a legitimate device code and convinces the user to authenticate on the real provider’s device-login page. No proxy is required and no credentials are captured directly. Instead, the attacker receives a long-lived OAuth refresh token that enables persistent access. Because authentication occurs entirely on legitimate infrastructure, these events appear valid from the provider’s perspective, making traditional phishing detection and blocking mechanisms largely ineffective.

Phase 2: Reconnaissance (TA0043)

Once access is established, modern PhaaS kits immediately execute automated reconnaissance routines, particularly in Microsoft 365 environments, where structured enumeration of Graph API endpoints provides rapid situational awareness. This activity includes account and identity discovery (T1087.004), group and permission mapping through membership queries (T1069.003), and broader identity enrichment (T1589) such as calendar harvesting and contact resolution. At the same time, the kit performs cloud service discovery (T1526), identifying license assignments, tenant relationships, and service principals to understand both privilege boundaries, blast radius, and lateral movement opportunities. The distinguishing characteristic of this phase is not simply the data accessed, but the pattern of access. Unlike a human operator who navigates unpredictably, a PhaaS kit follows a deterministic playbook, issuing API calls in a specific sequence and at a speed that reflects automation rather than manual interaction. This high-volume, ordered enumeration occurring in a compressed timeframe creates a detectable signature within Graph API and audit logs. More advanced kits extend this phase using AI-augmented email collection (T1114), where embedded language models scan the compromised mailbox for high-value keywords such as “invoice,” “wire,” and “approval,” automatically surfacing active financial conversations to the operator via external channels like Telegram. In these cases, the attacker is no longer manually exploring the environment, the system identifies and prioritizes opportunities autonomously, including the creation or abuse of email forwarding mechanisms (T1114.003) as part of ongoing data collection.

Phase 3: Stealth (TA0005)

Before executing primary objectives, mature PhaaS kits implement a series of defense evasion measures designed to suppress visibility and maintain operational control of the compromised account. A common first step is the creation of hidden inbox rules (T1564.008), typically named using obfuscated or minimal character strings, which automatically move inbound replies to archive folders, mark them as read, and halt further rule processing. This effectively intercepts responses to phishing messages before the legitimate account owner becomes aware of them, allowing the attacker to control the entire communication loop. Many kits deploy these rules prior to campaign execution, reflecting a scripted pre-attack workflow rather than ad hoc configuration. At the same time, attackers leverage valid account access (T1078), operating entirely within legitimate authentication flows using captured session tokens. This removes the need for malware or exploit weaponization, eliminating many traditional detection opportunities tied to process or file-based indicators. Beyond account-level activity, attackers employ infrastructure-level evasion techniques, including rotating VPN exit nodes across geographies, leveraging legitimate CDN services as proxy layers, and generating unique phishing URLs per target. More recent iterations of PhaaS kits have integrated AI-generated decoy content, automatically serving benign or unrelated pages when a visitor is identified as a scanner or analyst, further complicating takedown and investigative efforts.

Phase 4: Execution (TA0002) and Impact (TA0040)

With access established, reconnaissance completed, and defenses suppressed, the attacker executes the primary objective, most commonly Business Email Compromise through internal spearphishing (T1534). Using the compromised account, the kit sends bulk outbound messages to internal users and external contacts identified during earlier enumeration, leveraging established trust relationships to increase engagement rates. In traditional campaigns, this might involve templated phishing lures, but AI-augmented PhaaS kits have significantly increased effectiveness by dynamically generating content based on data harvested from the victim’s mailbox. Large language models are used to craft emails that reference real vendors, active transactions, payment workflows, and authentic communication styles observed in prior threads. Rather than appearing as generic phishing attempts, these messages align closely with legitimate business context, making them far more convincing and difficult to detect. The result is a shift from broad opportunistic phishing to highly targeted and context-aware social engineering, where the attacker leverages the organization’s own data to improve success rates.

Phase 5: Persistence (TA0003) and Secondary Objectives

Following initial execution, capable PhaaS kits continue operating within the compromised environment to maintain access and identify additional opportunities for exploitation. This phase often involves further reconnaissance to map tenant relationships, identify service principal ownership, and enumerate cloud storage resources, building a broader understanding of interconnected systems and potential downstream targets, including partner organizations and higher-privileged accounts. Persistence is commonly maintained through token-based mechanisms rather than credentials alone, including OAuth consent grants and cached refresh tokens that can survive password resets if not explicitly revoked. This creates a critical gap in many incident response workflows, where remediation actions focus solely on credential reset without addressing active session state or token validity. In these scenarios, attackers may retain uninterrupted access even after the user’s password has been changed. As a result, effective containment requires both credential rotation and explicit session/token revocation; anything less leaves residual access paths available to the adversary and enables continued exploitation beyond the initial compromise.

It is worth noting that the techniques in commercial PhaaS kits don't exist in isolation from state-sponsored activity. Nation-state groups have been documented using the same underlying techniques typically as a precursor to espionage campaigns rather than financial fraud. The initial access stage of a financially motivated BEC attempt and a state-sponsored intrusion can look identical in telemetry. Don't assume financial motive just because the tooling is a commodity kit.

State-aligned actors have also been confirmed using publicly available AI models for reconnaissance planning, vulnerability research, and social engineering content generation which is the same task automation that commercial PhaaS kits have built into their execution pipelines. The capability sets are coming together and advanced kits are available for a few hundred dollars a month. Nation-state actors have considerably larger budgets.

AI in adversary tooling is the current operational baseline for the most capable PhaaS kits in active use today. The attack flows are well-documented, the ATT&CK mappings are clear, and the detection opportunities are real but they require detection logic calibrated for machine-speed attacks, not the human-paced intrusions most runbooks were designed around.

The kits execute in minutes. Calibrate your detection posture to the actual speed of these attacks, deploy phishing-resistant MFA where it matters most, and close the Conditional Access gaps that these kits are specifically engineered to find.

The attacker's workflow is automated, yours should be too.

MITRE ATT&CK Summary

Detections

To make the above actionable, below are five Microsoft Sentinel rules that operationalize the techniques described in this blog. Several incorporate potential tuning areas that can be customized based on your specific environment for known false positives we encountered while testing.

Detection 1: OAuth Device Code Sign-In from Uncommon Client

The OAuth 2.0 device code flow mechanism is behind a wave of recent phishing campaigns that skip the fake-login-page step entirely and instead trick a victim into approving a real Microsoft device login on the attacker's behalf. Device code auth is legitimate for a narrow set of scenarios, so the signal that matters is an app using it that has no business doing so in your environment. KnownDeviceCodeApps can be adjusted accordingly for authorized automation within your environment.

Detection 2: Suspected AiTM - MFA Sign-In Followed by Rapid Cross-Country Reuse

Detects a successful MFA sign-in immediately followed by another successful sign-in for the same user from a different country, within a tight window. This is a more targeted variant of the well-known “impossible travel” pattern where a live Adversary-in-the-Middle proxy captures a valid post-MFA session token and replays it from attacker infrastructure while the victim's own session stays active, so both sign-ins look fully legitimate to the identity provider. KnownCorporateEgressIPs can be adjusted to account for shared corporate infrastructure such as VPN, proxies or cloud backends that can create known false positives.

Detection 3: Unconditional Hidden Inbox Rule Created to Conceal Reply Traffic

Detects a newly created or modified inbox rule that applies to all mail (no sender, subject, or date condition) and either hides its own presence with a blank or meaningless name, routes mail to a low-visibility folder, or deletes it outright. This is the staging step attackers take before sending internal spearphishing or BEC follow-up messages, so replies from would-be victims never reach the compromised mailbox's owner.

Detection 4: Burst Directory Enumeration by New Application

Detects an application making a high volume of Microsoft Graph directory calls (user, group, service principal, and role lookups) across many distinct endpoints in a short window, where that application has no history of this behavior in your tenant. A human operator explores a directory unpredictably; an automated recon module runs a fixed, exhaustive playbook at machine speed. Requiring the app to be new to this pattern, not just high-volume, is what separates that from your everyday SaaS integrations doing the same kind of bulk lookup as their normal job. KnownDirectoryEnumerationApps can be adjusted to account for known apps that run on a wider cadence (ie. quarterly, annually).

Detection 5: Mailbox Send Volume Burst Consistent with Internal Spearphishing

Detects a mailbox sending an unusually high volume of messages in a short window. Once an attacker has staged reconnaissance and a concealment rule, the actual internal spearphishing or BEC send typically goes out in a burst rather than a natural, spread-out sending pattern. KnownBulkSenderMailboxescan be adjusted to account for high volume shared and automated mailboxes such as helpdesk/ticketing integrations or bulk marketing campaigns.

Putting It Together

None of these rules are a silver bullet on their own. What makes them effective is the sequence they describe: a device code or AiTM sign-in, followed by burst enumeration, a hidden inbox rule, and a send spike, all tied to the same identity within minutes.

Also note that not all five are ready for alerting immediately. Rules 3 and 4 ran clean across every environment we tested and should be safe to enable as alerting analytics rules as published. Rules 1, 2, and 5 depend on environment specific context. Run those three as hunting queries first, adopt the tuning notes above, and only then promote them to alerting.

https://securesky.com/contact-us/

info@securesky.com

+1 833.473.2759  (+1 833.4SecSky)