BlackApex, SPY, and Counting: The Emerging Wave of Vibe-Coded Phishing Kits

Anyone who has signed in to a streaming app on a smart TV by typing a short code into a phone has used a device code flow. Microsoft supports the same mechanism for Microsoft 365 accounts, and attackers have turned it against the people it was designed to help. Through 2026, ready-made Phishing-as-a-Service (PhaaS) kits such as EvilTokens, Kali365, and Tycoon2FA have put the technique within reach of almost anyone willing to pay for it.

While following this activity, we came across a family of phishing kits that does not match any publicly documented kit, operating under panel names such as BlackApex, DarkApex, SPY, and XXX101. More than 70 instances share the same backend and admin panel, and we believe they point to a growing wave rather than isolated cases.

The attack logic is familiar, but the code is not. Across all of its lures, the source shows traits we associate with AI-generated code, whether from direct prompts to a language model or from a person working alongside an AI coding assistant. This post walks through the lures, sets out the evidence for that assessment, and looks at how weak operational security exposed the kit’s infrastructure and what it means for defenders.

One Engine, Many Disguises

The first sample we analyzed was an HTML page styled like SharePoint. It pretends to load a document, stepping through messages about document access, session authentication, and file metadata. When the fake loading finishes, embedded JavaScript forwards the browser to a Cloudflare Workers URL.

Figure 1. SharePoint-themed lure page and its embedded JavaScript.

Several of the phishing domains turned out to share one backend. They respond on identical URL paths and return JSON replies with the same structure.

Figure 2. Observed phishing kit HTTP traffic sequence.

The Turnstile check and loader stage add a multi-stage redirection pipeline that helps the kit evade email gateways and automated scanners. In random mode, each victim receives a unique URL, which makes URL-based blocking harder.

Figure 3. Network activity of the phishing kit.

The campaign deploys a portfolio of distinct lures, each tailored to a specific application service. The landing-path management functionality supports configurable URL paths and two routing modes:

• Static: Directs all victims to the same configured URL (e.g., /documents/share/secure/).
• Random: Assigns a different unique URL to each victim (e.g., /documents/share/secure/c/uuid-here/).

Figure 4. Hardcoded URL path used in phishing campaigns.

The management interface identifies paths by Path Name and Path Value. The active configuration is retrieved through GET /api/landing-paths/active, which returns the selected path, its active status, and the configured mode.

Behind this page sits a simple mechanism that we later found in every lure. The page asks the attacker’s backend for a device code, then checks in repeatedly to learn whether the victim has finished signing in.

Figure 5. The /start and /state endpoints shared by all lures, used to request a device code and poll its status.

On top of this shared engine sits a set of lures, each dressed as a different everyday business task. They look different on the surface but behave identically underneath. Two of them stand out.

Figure 6. SharePoint and Zoom lures.

The Zoom lure copies Microsoft’s “Permissions requested” screen, familiar from third-party app sign-ins, so that entering a device code looks like approving an ordinary app. It also personalizes itself, swapping in the victim’s company logo and name based on their email domain.

Figure 7. The updateBranding() function changes the logo and company name to match the victim’s email domain, taking the logo from a third-party favicon service.

Figure 8. Adobe Acrobat Sign, Microsoft Excel, and OneDrive lures.

The OneDrive lure is the most carefully built of the set. It imitates a “Secure File Access” prompt that often serves as the first step of a two-stage operation, and it includes extensive error handling, steady polling logic, a full session ID system, and a fallback image if the logo cannot be fetched. That level of care matters for the AI-assistance assessment later in this post.

The Hand-off: Where MFA Works Against the Victim

In every variant, the main button opens Microsoft’s real microsoft.com/devicelogin page in a popup rather than a copied site. The device code is placed on the victim’s clipboard just before the popup opens, so the victim only needs to paste it. Everything they see on the Microsoft page is genuine.

Figure 9. The “Continue” button handler. The device code is copied to the clipboard just before the popup opens.

Meanwhile, the attacker’s server polls every five seconds to see whether sign-in has completed. When it has, the victim is redirected to a real Microsoft Word page, so the session looks normal from both sides.

Figure 10. The polling loop. On success, the victim is sent to a real Microsoft Word page.

By then the attacker’s server has redeemed the code and holds a live access token and refresh token for the victim’s Microsoft 365 account. The victim completed MFA themselves, so the control meant to stop the attacker was satisfied by the wrong person.

The kit also captures a Primary Refresh Token (PRT), which is displayed in its administrative panel and used to access the victim’s mailbox. In Microsoft Entra ID, a PRT supports single sign-on across integrated applications, so its compromise can extend beyond a single session and give persistent access to the victim’s identity and resources.

Figure 11. Phishing kit admin panel displaying captured PRTs used to access victims’ mailboxes.

The impact is comparable to a Golden Ticket attack against an on-premises Active Directory environment.

Reaching the Victim Through Trusted Services

The campaign spreads through spearphishing. The two delivery chains we collected both begin with a business-themed email and both pass the victim through a trusted cloud service before the device code lure appears. This helps the message and its links get past reputation-based filtering.

In the first chain, the email arrives as a forwarded message from an external address, with a highlighted “Google Share Link” as the only call to action. The link leads to a page imitating a document-opening prompt that presents an access code.

Figure 12. Spearphishing email with a Google share link and fake "Opening in Word for desktop" page presenting an access code.

The second chain uses a PDF attachment. The PDF contains a little more than a sentence asking the reader to use a link to view an “encrypted document”, and a highlighted “GO TO MESSAGE >>>” link. The link opens a shared copy of a Microsoft Forms page on forms.cloud.microsoft, where the attacker has embedded a link. Selecting it triggers Microsoft’s own “Open link to an external site” warning, which reveals the real destination.

Figure 13. Spearphishing email with a PDF lure leading to a Microsoft Forms page, which links to the device code lure.

Both chains end at the same sign-in page: login.microsoftonline.com/common/oauth2/deviceauth. That page tells the user they are signing in to “Microsoft Authentication Broker” on another device in the United States. The wording is the giveaway, because the sign-in was started elsewhere by the attacker’s backend and the victim is only asked to approve it.

The AI Fingerprint

The attack logic is conventional, but the way the kit was built is not. Several traits in the code, taken together, point to the heavy use of AI assistance.

Style.Hand-written phishing kits tend to be terse and often have no comments at all. This one is suspiciously noisy with emoticons, verbose console logs and structured documentation comments, in lures, configuration files and API functions alike. It reads like a tutorial, with a “// Helper:” label above nearly every function, however simple.

Figure 14. AI-assisted code annotations and verbose console logs.

Figure 15. Code snippets showing detailed comments with AI-assisted development.

Defensive engineering. The scripts use an isPolling flag to prevent duplicate polling timers in the same tab, a retry counter with separate “retry” and “restart” paths, and a timer that refreshes the device code after 14 minutes, which is just before Microsoft’s own 15-minute expiry. The code also opens the sign-in window differently on mobile and desktop. Throwaway phishing infrastructure rarely gets this much polish.

Figure 16. Separate window-opening strategies for mobile and desktop, selected by user agent and viewport width.

Consistency across lures. In our view, this is the strongest signal. All five lures share the same backend contract, the same getSessionId() pattern and the same retry logic yet look entirely different on the surface. That is what one would expect if a single specification had been used to generate several skins for different services. People who adapt a kit by hand tend to leave traces, such as inconsistent naming and leftover dead code. Here all variants are clean, and none of the code is obfuscated.

Figure 17. The updateCompanyInfo() function from the OneDrive lure, which personalizes the page for each victim.

Weighing all the signals together, we assess with high confidence that the codebase was produced largely through AI-assisted development.

OPSEC Failure: Analysis of Phishing Kit Portals

The kit’s operators also left a trail of their own. The site’s robots.txt file lists /admin and /api paths along with an administrative HTML file. Although robots.txt is guidance for crawlers rather than access control, here it publicly pointed to the kit’s management portal.

Figure 18. Infrastructure discovery through robots.txt (Source: Shodan).

We pivoted through Censys using the SHA-256 body hash of that robots.txt content to find other servers serving the same file:

web.endpoints.http.body_hash_sha256 = "5ec645bf49961d0f1b14e5ddc354e44df42b75b4451c19c6362e6a1d829a917f" or host.services.endpoints.http.body_hash_sha256 = "5ec645bf49961d0f1b14e5ddc354e44df42b75b4451c19c6362e6a1d829a917f"

The search identified more than 70 URLs hosting the same admin panel and HTML lure, each forwarding visitors to a device code phishing domain. Most exposed services run on ports 5000 and 443, spread across multiple hosting providers, some associated with bulletproof hosting. The same IP addresses appear in the panel’s own settings as VPS addresses.

Figure 19. Administrative system settings showing command-and-control (C2) configuration.

Figure 20. Distribution of identified hosts by Autonomous System Number (ASN).

The panels share the same authentication logic, which gave us a second reliable pivot. Once inside the panels, we found that they identify themselves with distinct names, at least eight in total, including BlackApex, DarkApex, SPY, XXX101-TOKEN, OGPARKER1, W1-TOKEN, ALIBOBO-TOKEN, and @globaltoken1.

The code, endpoints, and interface are the same across all of them. We cannot say whether these names reflect separate operators, resellers or customers of a single kit, but the pattern is consistent with a shared product being rebranded and redeployed.

Figure 21. Phishing kit administrative panel interface.

The panels exhibit consistent authentication logic, providing a correlation point for identifying additional instances of the kit. This enabled further analysis of multiple administrative portals, revealing their internal interfaces, available management features, and exposed API endpoints. These similarities extend the code-level observations discussed in The AI Fingerprint section to the kit's administrative interface.

Figure 22. Inside of phishing kits’ panels.

Once inside the administrative interface, a further operational security weakness was identified: multiple API paths were reportedly accessible without authentication.

Figure 23. API endpoint response from the phishing kit’s administrative panel.

These endpoints expose functionality for dashboard statistics, configuration management, messaging integrations, template and domain management, anti-bot controls, landing-path configuration, access logging, session management, and other integrations that support the operation of the phishing campaign.

What This Means for Defenders

If AI-assisted kit development becomes more common, tracking named kit families will cover a shrinking share of what is out there. Independently generated, one-off kits are likely to multiply faster than they can be catalogued. What AI changes is how quickly the tooling can be built, not how the attack begins: every chain we observed still started with a spearphishing email, and as attackers adopt AI tools, they continue to depend on human weakness to set the attack in motion. Three practical points follow.

• Static indicators age quickly. A new front end and fresh domains can be produced in minutes, so detection based on domains and page signatures will lag behind. Detection built on protocol behavior holds up better.
• Identity logs are the best place to catch this. Review Microsoft Entra ID (formerly Azure AD) sign-in logs for unusual deviceCodeFlow events, especially from unmanaged devices, unexpected IP ranges, or unfamiliar user agents.
• Restricting the flow is the most direct mitigation. Where practical, use Conditional Access to block device code authentication entirely. Where legitimate tools depend on it, limit it to compliant devices, named locations, or approved administrator groups.
• Awareness remains a key control. No technical control fully replaces a user who pauses before acting. Train users to treat any unexpected request to enter an access or device code as suspicious, even when the sign-in page is genuine Microsoft, and to question documents that arrive through unfamiliar shared links or forms. Make it easy to report suspicious messages, since early reports can reveal a campaign before any sign-in is abused.

Conclusion

Device code phishing gets around MFA by having the victim complete it. AI assistance changes who can build the tooling and how fast: a convincing multi-brand phishing kit no longer takes much development skill or time. Defenders who watch how sign-ins happen, rather than how lures look, will be in a better position to spot the next one.

Indicators of Compromise

Note: The indicators listed below were collected during the investigation, including VPS IP addresses and associated landing-page domains observed in the phishing kit's administrative panel. IP addresses and domain names are presented as observed at the time of analysis; infrastructure ownership, hosting assignments, and domain resolution may change over time.