We infiltrated a criminal phishing panel: here’s what we found

When Push detects and blocks a phishing attack, we take the opportunity to do some additional digging to see what we can find. One recent detection caught our attention due to overlapping indicators linking it to the ShinyHunters campaign combining a real-time operated phishing panel with an AITM payload first reported in January 2026. Recent reporting has also highlighted the BlackFile hacking group using heavily overlapping TTPs that track with our data.

Through a bit of digging, we’ve directly accessed active deployments of the operator panels driving these campaigns, observed what happens in real-time when a victim is targeted, and analyzed multiple variants and forks of the tooling. 

We’re highlighting four distinct infrastructure clusters associated with this tooling, with each deployment having its own panel implementation. While the panels share common heritage, the operators deploying them appear to be separate groups with different infrastructure preferences and operational patterns.

The existence of these independently branded forks indicates that the tooling has entered a phase of wider distribution — operators who obtained the original panel source are now customizing and reshipping it for their own purposes. As a result, the tooling is now most likely accessible to a broad population of financially motivated threat actors. In total, we’ve identified over 400 domains linked to the attacks. 

Background

Since at least August 2025, attackers have been running hybrid social engineering campaigns targeting hundreds of organizations across financial services, technology, cryptocurrency, healthcare, hospitality, and private aviation. 

• August 2025: Tooling made available, used in crypto-focused attacks

• November 2025: Major attacks on enterprise identity platforms begin

• January 2026: Public breaches reported

• March 2026: Activity spikes again

The attacks combine voice phishing with MFA-bypassing adversary-in-the-middle (AiTM) phishing mechanisms that allow the attacker to steal authenticated sessions for target applications — typically enterprise identity providers and cryptocurrency exchanges. Once an identity provider account is compromised, the attackers pivot across connected SaaS platforms — SharePoint, Salesforce, DocuSign, Slack — exfiltrates data, and attempts to extort the victim organization. 

Inside the panels: what Push found

Push detected an active Okta phishing site with TTPs aligned to the tooling used by SLH and affiliated groups. Through analysis of the phishing infrastructure, we gained direct access to Doko’s Panel and variants, and were able to observe how these attacks unfold from the operator's perspective — including real victim submission logs from the current week confirming ongoing active operations.

How the attack works

The general sequence of steps is the same across the panels:

• The operator calls the target spoofing the organization's IT helpdesk number, often referencing real employee names or internal ticket numbers to establish trust. The target is directed to a phishing domain — usually following a combosquatting pattern like my<target>internal[.]com or <target>sso[.]com — under the pretext of a mandatory security update, passkey enrollment, or support ticket resolution. 

• The victim lands on the phishing domain and is presented with a loading spinner — the anti-bot gate that prevents unauthorized access to the phishing pages.

• The operator accepts the visitor from the admin panel and the victim is redirected to the cloned login page (e.g. Google, Microsoft, Okta).

• The victim enters their email address and password, which is forwarded to the operator's Telegram channel. The victim sees a processing spinner on the branded login form.

• The operator relays the credentials to the real identity provider. If they're valid, the attack proceeds. If they're invalid, the operator can redirect the victim back to the credential entry pages. Assuming MFA is required, the operator issues a redirect to an appropriate MFA capture page — "Submit SMS OTP," "Submit Gauth OTP," or "Approve [XX] Prompt," depending on what the legitimate IdP is presenting.

• The victim submits their OTP or approves the push notification and the operator relays the OTP in their own login session, completes authentication, and captures the session. 

• The victim is redirected to a benign page (e.g., Google Drive) or to a support ticket closure screen displaying a fabricated ticket number.

Doko’s Panel

Let’s take a closer look at the panels themselves. We'll start with the default version of Doko's Panel since it’s the most established. It provides a multi-functional framework targeting users of Google, Microsoft Entra, Okta, and popular cryptocurrency exchanges including Abra, Coinbase, Gemini, and Kraken. Its core functionality resides in a client-side JavaScript file (client.js) that establishes the real-time feedback loop between the victim's browser and the operator's C2.

The technical indicators that characterize Doko's Panel in its standard form include:

• client.js containing a pingServer() function that sends a JSON POST request to /backend.php every second with the structure { action: 'ping', token, window_id, page, os, browser }. If the response contains a redirect key, the victim's browser navigates to that path. 

• sendTelegramMessage() (aliased to sendtg()), a function for relaying real-time credential submissions and session updates to the operator's Telegram channel.

• backend.php as the primary server-side handler for both victim ping actions and admin panel operations (retrieving connected victim information, sending redirect instructions).

• j.php as the endpoint for sending Telegram messages, relaying captured credentials and session logs.

Push found that deployments of Doko's Panel had minimal security by default — anyone was able to view the admin panel and manage visitors' connections without authentication.

Panel proliferation and remixes

Access to Doko's Panel has clearly proliferated beyond its original developers, resulting in remixes and variants being distributed across the ecosystem. Push identified a variant titled "Lord Mensius's Panel" targeting Koinly (a cryptocurrency tax platform), and another titled "$$$" using a template impersonating the Australian Tax Office, also targeting cryptocurrency tax filing. 

The existence of these independently branded forks indicates that the tooling has entered a phase of wider distribution — operators who obtained the original panel source are now customizing and reshipping it for their own purposes. As a result, the tooling is now accessible to a broad population of financially motivated threat actors. 

heartbeat/check_redirect variant

In addition to Doko’s Panel and its forks, the site initially detected by Push used a modified variant of Doko's Panel with a different C2 protocol. Rather than the standard ping action, this variant sent two types of regular requests from client.js to the backend:

• Heartbeat — POST to backend.php with action=heartbeat along with page, token, and window_id.

• Check Redirect — GET to backend.php with parameters action=check_redirect along with token and window_id.

A redirect instruction in response to either request causes the victim's browser to navigate to the specified page. The variant compounds this with a separate inline script embedded in the landing gate HTML — in addition to client.js — that schedules its own sendHeartbeat() and checkRedirect() functions on regular intervals. 

Additional technical differentiators for this variant include:

• UUID generation using Math.random() to replace x in the template xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, rather than the original Doko's Panel method of constructing a template from [1e7]+-1e3+-4e3+-8e3+-1e11 and replacing [018].

• No central Telegram sending function, though j.php still exists and is called from inline scripts on individual phishing pages.

• No use of FNV-1a to hash-generate the window ID.

Push also found sub-variants hosting Okta phishing pages with additional modifications: a minified client.js script, and a renamed backend endpoint (api_FyekIDWY.php replacing backend.php).

Revamped admin panel

Push also found examples of a significantly revamped admin panel, including a version from April 2026 specifically targeting Microsoft as an enterprise identity provider. 

This panel featured a more sophisticated operator interface with an updated look, quick action buttons, and sound notifications.

In addition to the standard compromise flow for acquiring email, password, and OTP, this panel provided operator actions for sending Microsoft Teams call instructions to the victim — a Meeting ID and Passcode rendered on a branded page. This capability likely enables further interaction through a channel that supports screensharing, extending the attacker's reach beyond credential theft into live session manipulation. It also has the potential to make the scenario more believable for the victim.

Other capabilities were referenced in the panel's source code but did not appear active in the observed deployment:

• Additional MFA approval pages for Duo and Okta, with the operator providing a code to display to the victim.

• A code execution prompt to instruct the victim to run a command — the placeholder example being mshta to execute a remote HTA file, suggesting a potential bridge from identity compromise into malware delivery.

The admin panel also included settings for restricting access to specific geographic locations and device types, allowing operators to refine their campaign targeting and also avoid detection from unusual devices (often an indicator that the visitor is not a real human and is actually a security tool or bot).

LLM-generated tells: vibe-coded phishing infrastructure

Evidence of extensive LLM use is extremely prevalent in attacks detected by Push, from LLM-generated phishing kits and tools to vibe-coded cloned pages. Attackers have also been observed leveraging AI–assisted capabilities in SaaS platforms to automate and scale-up their campaigns from an infrastructure and operations perspective. 

The ‘heartbeat’ variant in particular has significant tells of heavy use of LLMs to modify the phishing panel for the operator’s needs. The fact that these are so blatant increases the belief that these tools are being vibe-coded by relatively inexperienced developers with limited regard for operational security.

Some versions of client.js begin with verbose header comments that no human developer would write:

The "NOTES FOR NEXT SESSION" header is particularly telling — it's a pattern generated by LLMs that maintain context between chat sessions, not a convention any human developer would adopt in production code, let alone in a phishing kit where operational security should discourage self-documenting infrastructure.

The admin panel HTML contains similarly over-documented opening comments:

One of the Okta cloned login pages observed by Push contained the following comments suggesting the use of an LLM to create the clone:

The cloned Microsoft login pages displayed previously contain terser comments, but still typical of useless comments that are included by an LLM rather than a human author, especially a malware/phishing author:

The broken duplication in the heartbeat variant — where an inline script and client.js independently schedule the same backend requests using slightly different data formats — is consistent with an operator pasting requirements into an LLM and accepting the output without understanding the existing codebase well enough to recognize the redundancy.

Clearly, the barrier to entry for building (or forking) and operating a real-time vishing phishing panel is lower than the effectiveness of the tooling might suggest.

Infrastructure clustering and attribution

Through analysis of phishing domains, hosting infrastructure, and technical indicators in the panel source code, we’re highlighting four distinct infrastructure clusters associated with this tooling. While the panels share common heritage, the operators deploying them appear to be separate groups with different infrastructure preferences and operational patterns.

Cluster A

The indicators for Cluster A overlap with Mandiant’s reporting on UNC6661. Mandiant also attributes the extortion activity following UNC6661 intrusions to UNC6240, aka ShinyHunters.

Cluster B

The indicators for Cluster B overlap with Mandiant’s reporting on UNC6671. Other external reporting has linked this group to BlackFile-branded extortion and leaks.

Cluster C

Cluster C is likely an evolution of Cluster B. Some evidence has been observed tying the backend hosting to Njalla behind the Cloudflare CDN further solidifying the link. The shift to Cloudflare Turnstile protection and subdomain-based targeting represents an operational refinement — moving away from the distinctive [target]internal[.]com pattern that had become a well-known campaign indicator.

Cluster D

Detection considerations

For Push, the detection approach to these panels is fundamentally the same as for any other phishing kit — behavioral analysis of the rendered page in the browser, regardless of the C2 protocol running underneath. 

The main operational difference is on the operator end, where the human-in-the-loop interaction replaces fully automated credential harvesting. This has implications for defenders relying on proactive infrastructure scanning: the gated landing pages, anti-bot checks, and operator-approval requirements mean the malicious content is only served to active targets, making it significantly harder for automated scanners to discover and flag these domains before they're used against a victim.

The phone call as delivery vector eliminates the email-based detection surface that most organizations rely on as their primary phishing defense. Combined with the operator-gated payload delivery, this means that unless you are detecting the phishing page at the point where it renders in the victim's browser — analyzing page structure, credential entry behavior, and phishing kit signatures in real time — these attacks will reach their targets unimpeded.

Indicators of compromise

Short-lived IoCs are of limited value when tackling modern phishing attacks due to the rate at which attackers are able to quickly spin up and rotate the sites used in the attack chain, often dynamically serving different URLs to site visitors.

Bulk list of domains to be follow, check back later.

Push customers do not need to take any further action.

Learn more about Push

Push Security is the most powerful AI-native security tool in the browser. Think EDR, but for the browser — high-fidelity telemetry and real-time control across every session, on every device, with no browser migration required. Security teams use Push to detect and stop advanced browser-based attacks like AiTM phishing, ClickFix, and session hijacking; gain visibility and control over AI tool usage across their workforce; harden identities by surfacing credential reuse, SSO gaps, and shadow IT; and support data loss and insider investigations with browser-layer telemetry that other tools can't see. Book a live demo to learn more.