AI phishing panels are industrialising browser-based identity theft

At a glance

What this is: This is Push Security’s analysis of phishing panels that gate malicious content in the browser and use live operator control to harvest credentials, MFA approvals and sessions at scale.

Why it matters: It matters because IAM and PAM programmes built around email filtering, static indicators and post-login assumptions will miss browser-mediated identity theft that is deliberately hidden from automated scanners and then used to reach SaaS estates.

By the numbers:

• Push Security identified over 400 domains linked to the attacks, giving an indication of the scale.

Context

Browser-gated phishing panels are criminal infrastructure that only shows the malicious content to a live target after the operator approves the visit. That matters for identity governance because the attack chain is designed to bypass the controls most organisations still associate with phishing, including email gateways, static takedown workflows and simple indicator-based detection.

Push Security traced the activity to hybrid social engineering campaigns linked to ShinyHunters and BlackFile-style operations, where voice phishing and adversary-in-the-middle techniques are used to steal credentials, MFA responses and authenticated sessions. The governance gap is not just phishing awareness, but the assumption that access abuse can be discovered after the fact from infrastructure alone.

Once the attacker holds a valid session, the problem moves into connected SaaS platforms such as SharePoint, Salesforce, DocuSign and Slack. For IAM teams, that shifts the centre of gravity from login prevention to session trust, support-desk deception, and the abuse of browser-mediated identity flows.

Key questions

Q: What breaks when phishing panels only show malicious content to live targets?

A: Infrastructure scanning breaks first, because the malicious page is hidden behind a browser gate until an operator approves the victim. That means crawlers, blocklists and takedown feeds may never observe the payload in time. Teams need controls that inspect the rendered page and session behaviour at the moment of interaction.

Q: Why do AiTM phishing kits still succeed against MFA?

A: AiTM kits succeed because they capture the authenticated session, not just the password. If the attacker can intercept the one-time code and the session cookie during login, MFA has already done its job and the cookie becomes the reusable credential. Defenders therefore need controls that watch for session replay and token abuse after sign-in.

Q: How should security teams detect and respond to browser-based identity attacks before attackers turn stolen credentials into account takeover?

A: Teams should treat the browser as an identity control point, not just a user interface. Detection works best when it combines session telemetry, token theft indicators, and behavioural signals that reveal abnormal login or replay patterns. The goal is to spot compromise early enough to block access, contain the session, and investigate the affected accounts before lateral movement starts.

Q: How should IAM teams respond when SaaS abuse happens through the browser?

A: They should treat the browser as part of the identity control plane and align app access governance, session monitoring, and response workflows around it. That means reviewing permissions, extension risk, and session behaviour together instead of separating browser threats from identity governance.

Technical breakdown

How browser-gated phishing panels control victim traffic

The panels described by Push use client-side JavaScript and server-side handlers to create a live feedback loop between the operator and the victim’s browser. A landing page first checks whether the operator has approved the visitor, then redirects the target to a cloned login flow only after that gate is cleared. This means the malicious page is not broadly exposed to scanners or crawlers, which is why infrastructure-based detection struggles. The important architectural point is that the browser becomes the delivery environment, the control plane and the evidence source all at once.

Practical implication: detect rendered-page behaviour in the browser, not just known-bad infrastructure.

Why AiTM phishing defeats MFA assumptions

Adversary-in-the-middle phishing sits between the victim and the legitimate identity provider, relaying the user’s credentials and MFA response in real time. The attacker does not need to defeat MFA cryptographically if the user willingly completes the second factor inside the attacker’s session. That is why passcodes, push approvals and OTP prompts remain exposed when the user is manipulated into approving a login that appears normal. In these campaigns, the panel can forward the credentials, relay the MFA step and capture the resulting authenticated session for later reuse.

Practical implication: treat MFA as one layer of resistance, not proof against active session capture.

How stolen browser sessions become SaaS compromise

Once the attacker has an authenticated session, the identity provider is no longer the only target. The session token becomes a launch point into adjacent SaaS services where data can be exfiltrated, collaboration channels can be abused and further social engineering can be staged using real account context. Push’s analysis shows that the same stolen identity can support access to cloud productivity tools, CRM systems and support workflows. This is a classic identity escalation path: the compromise starts as browser theft and ends as enterprise-wide trust abuse.

Practical implication: monitor post-login session behaviour and connected-app access, not only authentication events.

Threat narrative

Attacker objective: The objective is to obtain authenticated browser sessions that can be reused to access enterprise identity providers and downstream SaaS accounts for theft and extortion.

1. Entry occurs when the operator uses vishing to direct the target to a gated phishing page that only serves malicious content after manual approval.
2. Credential access follows when the victim enters their email, password and MFA response into a cloned login flow that relays the data to the attacker in real time.
3. Escalation occurs when the attacker uses the stolen authenticated session to reach the identity provider and pivot into connected SaaS platforms.
4. Impact is realised when the attacker exfiltrates data, enables extortion and extends access across the victim’s collaboration and business systems.

Breaches seen in the wild

• ShinyHunters Salesforce data theft campaign 2025: Vishing calls got staff to approve malicious Salesforce connected apps that bulk-exported CRM data from Qantas, Allianz Life, Google and dozens more.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-gated phishing creates an identity theft model that static controls cannot see. The malicious page is hidden until a real target arrives, which means infrastructure scanning, reputation feeds and bulk takedown logic arrive too late to matter. This is not just a delivery refinement, it is a shift in how attack evidence exists. Practitioners should treat browser rendering as the detection boundary, not the domain name.

Ephemeral session capture is now the decisive control failure. The panel’s real purpose is to convert a one-time interaction into a reusable authenticated session that survives the original login step. That makes post-login governance, session binding and step-up logic more important than the initial password prompt. The practical conclusion is that identity assurance has to extend past authentication into session continuity.

Human-assisted social engineering has become part of the machine-readable attack surface. Voice calls, support-ticket references and IT-helpdesk impersonation are not separate from browser security anymore; they are the mechanism that drives the browser compromise. This collapses the boundary between human trust abuse and technical identity theft. IAM teams should assume the helpdesk is now part of the authentication attack path.

Identity theft is being industrialised through reusable phishing infrastructure. The panel forks, operator branding and commodity distribution show a market for off-the-shelf browser theft tooling that can be reshipped by multiple crews. That widens the population of actors capable of running high-fidelity session theft without building their own stack. Security programmes should plan for repeatable abuse, not isolated campaigns.

Browser-layer telemetry is becoming a governance control, not just a detection tool. If the browser is where the attacker gates delivery, captures MFA and redirects the victim, then that is also where defenders gain the best chance of observing the fraud in real time. This pushes identity security toward session-level inspection and away from reliance on known-bad indicators alone.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.

What this signals

Browser-gated phishing is a session-trust problem, not a domain-blocking problem. The attacker can hide the malicious page until a live target is present, which means the security programme has to move closer to the browser and the authenticated session. Controls that only see infrastructure will always arrive after the operator has already captured the identity.

Human-assisted phishing now sits inside the identity control plane. The voice call is not a side channel, it is the mechanism that gets the user into the browser flow and into the attacker’s prompt sequence. That makes helpdesk procedures, support verification and MFA fatigue resilience part of identity governance rather than separate awareness concerns.

Ephemeral session abuse is the most relevant concept here: the attacker only needs one successful browser interaction to turn a live login into downstream SaaS access. That means IAM teams should measure whether they can observe, bind and revoke sessions fast enough to stop the pivot before it reaches collaboration and CRM systems.

For practitioners

• Strengthen browser-layer detection Instrument the rendered page and client-side behaviour so that gated phishing flows, redirects and credential capture logic can be detected where the user actually sees them.
• Harden helpdesk-assisted recovery paths Review support workflows that can be used to establish trust, reset credentials or trigger MFA enrolment, because the attacks described rely on human confirmation before browser compromise.
• Reduce dependence on OTP and push approvals Limit where one-time codes and approval prompts are accepted, especially for high-risk sign-ins and sensitive SaaS access that can be hijacked in real time.
• Monitor session reuse across connected apps Correlate identity provider sign-ins with downstream SaaS activity so that a valid session used to pivot into SharePoint, Salesforce or Slack is visible as an abnormal trust change.
• Prepare for fast-changing phishing infrastructure Assume domains, hosting and page variants will rotate quickly, so detection and response should key off behaviour and session abuse rather than static indicators.

Key takeaways

• Browser-gated phishing changes the detection problem by hiding malicious content until a live target is present.
• The campaign shows how vishing, AiTM phishing and session capture combine to defeat assumptions built around email-first controls.
• IAM teams need browser-level visibility and stronger session governance because the stolen login is only the start of the compromise.

Key terms

• Browser-based phishing: Browser-based phishing is phishing that executes through the web browser rather than the inbox, often using redirects, malicious sites, consent prompts, or extensions. It matters because the browser is where identity, application access, and session state intersect.
• AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• Help Desk Social Engineering: Help desk social engineering is the manipulation of support staff into approving or performing an access action without proper verification. Password resets are a common target because attackers exploit urgency, confusion, and inconsistent procedures to bypass stronger controls elsewhere in the identity stack.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.