ORAX is a previously undocumented phishing-as-a-service (PhaaS) platform that reaches the familiar adversary-in-the-middle (AiTM) objective through a different architecture. Rather than acting as a reverse proxy, ORAX presents its own sign-in experience and coordinates each target interaction through a persistent WebSocket connection to its backend, ultimately capturing the authenticated session after MFA succeeds.
What makes ORAX notable is not a new attack objective, but a different way of reaching it. Rather than relying on the reverse-proxy model used by most AiTM kits, the platform coordinates authentication through an attacker-controlled phishing page and application-layer control plane.
Abnormal Intelligence observed one ORAX voicemail campaign in which approximately 12,846 messages were sent from a compromised nonprofit bulk-mail account to 675 organizations. Fresh deployments remained active into mid-August 2026, and a shared access-key registry is consistent with a multi-tenant service. Based on evidence from ORAX’s associated Telegram ecosystem and regional indicators, we assess with moderate confidence that an Iran-nexus developer operates ORAX.
That architecture becomes clearest when following the observed campaign from initial delivery through the live authentication flow.
How the ORAX Attack Works
ORAX delivers a voicemail-themed phishing chain that funnels targets through multiple filtering layers before reaching a WebSocket-driven AiTM harvester. The delivery and ultimate objective resemble other AiTM campaigns; what distinguishes ORAX is what happens once the target reaches the harvester.
The Lure
The campaign begins with a fake voicemail notification using the subject New VM Received and originating from a compromised legitimate sender. Clicking the link routes the target through a Mailchimp click tracker to a Brevo/Convrrt “Listen To Message” landing page on *.sibpages[.]com.
This delivery chain relies on abused legitimate services rather than custom infrastructure. ORAX’s bespoke engineering begins after the click.
Stage 1: Filtering Out Automated Analysis
From the landing page, the target is directed to a per-visit wildcard subdomain hosting ORAX’s first filtering layer. The platform uses one of two interchangeable gate designs:
- A server-side emoji CAPTCHA, built as a PHP page that generates a random set of emojis for each request and prompts the visitor to “Select the 3 matching icons to continue.” (Fig. 1)
- A client-side self-decrypting page that uses AES-128-GCM and redirects to about:blank when it detects WebDriver, a headless browser, or a proxy. It also blocks developer tools.
Both gates serve the same purpose: to keep automated crawlers and mail-provider URL-detonation sandboxes from reaching the harvester while allowing a real human browser through. The gate fleet spans at least six domains deployed across two shared Google Cloud Platform (GCP)/Plesk origin servers.
Fig. 1: ORAX’s emoji-CAPTCHA gate rotates the five emojis on every request, while the underlying page template remains byte-identical across the fleet once the emojis are normalized.
Targets that pass the first gate are routed using a one-time handoff token through a Cloudflare-managed challenge before reaching the harvester (Fig. 2).
Fig. 2: The Cloudflare-managed challenge, served on a per-deployment wildcard subdomain
Stage 2: The WebSocket-Driven AiTM Harvester
The recovered harvester presents a Google sign-in page built and controlled by ORAX rather than Google’s live site proxied through attacker-controlled infrastructure.
Each deployment has its own keyed entry path, which ORAX binds to an access key and session. The target’s browser then remains connected to the ORAX backend, allowing the platform to change what appears on the page as the real authentication process advances behind the scenes.
Three technologies work together to support that process:
GraphQL provides the command interface. GraphQL is a widely used method for applications to exchange structured requests with a backend. ORAX uses it for attacker-defined commands such as Init, Input, Submit, Challenge, MirrorChallenge, and Reset. These are ORAX operations, not Google authentication commands.
SignalR manages live target sessions. ORAX uses the legitimate Microsoft real-time framework and its /hubs/session channel to associate each browser with the correct session and deliver updates.
WebSockets maintain the persistent connection. This allows the browser and backend to exchange data in either direction without requiring a page reload. SignalR commonly uses WebSockets as its underlying transport.
Same AiTM Objective, Different Architecture
Conventional Reverse-Proxy AiTM | ORAX | |
Target-facing Page | Provider pages forwarded and rewritten by the proxy | A phishing page built and controlled by the platform |
Communication | A sequence of provider web requests and responses passing through the proxy | A persistent connection between the target’s browser and the platform |
Authentication State | Inferred from provider traffic passing through the proxy | Tracked through platform-specific commands such as Input, Submit, Challenge, and Reset |
Challenge Handling | Provider response is proxied back through the phishing domain | The platform’s MirrorChallenge command updates the target’s active session |
Operator Workflow | Commonly managed through a campaign or session panel attached to the proxy | Branded OraxManage/OraxRDP control plane centered on live session groups |
Final Objective | Capture an MFA-authenticated session | Capture an MFA-authenticated session |
When a target enters an email address, password, or challenge response, the phishing page sends an ORAX command such as Input or Submit to the backend. The backend advances the real authentication workflow and uses Challenge or the distinctive MirrorChallenge command to instruct the phishing page what to display next. SignalR delivers those updates to the correct target’s browser in real time, while the associated OraxRDP console organizes the connections as live sessions for the operator. Authentication therefore becomes a synchronized sequence of attacker-controlled instructions and responses rather than a transparent relay of Google pages through a reverse proxy.
ORAX demonstrates that the defining AiTM outcome—capturing an MFA-authenticated session—does not require a traditional reverse proxy. Instead of transparently forwarding identity-provider pages, ORAX synchronizes its attacker-controlled phishing page with the real authentication process through platform-specific commands and a persistent connection to the target’s browser. The attack reaches the same destination through a fundamentally different control model.
Broad Targeting, Broader Reach
In the campaign we observed, targeting was broad and opportunistic rather than sector-selective. A single compromised nonprofit account served as the measurable delivery vector, and the recipient set tracked the hijacked contact list. Approximately 12,846 voicemail lure messages reached employee mailboxes at 675 US organizations spanning software, technology, education, business services, media, finance, retail, and manufacturing.
The objective is reusable access, not credentials alone. ORAX harvests live Google Workspace sessions for downstream business email compromise, mailbox rule abuse, internal phishing, and financial fraud.
The observed campaign represents only a floor for ORAX’s total reach. Its shared access-key registry is consistent with a multi-tenant service, while the separation between disposable campaign infrastructure and the persistent OraxManage/OraxRDP control layer suggests continued domain and sender rotation across tenants and lures. Other apparent platform customers may therefore use different lures and senders beyond what this campaign reveals.
Inside the ORAX Operation
The ORAX name appears throughout the platform’s codebase and operator tooling. The harvester bundle contains the strings OraxManage and OraxRDP, and the same branding appears on the operator control panel.
The OraxManage panel provides a central view of the platform’s supporting services (Fig. 3). OraxRDP, running on port 5050, serves as the SignalR-based session console for managing live target interactions. Alongside OraxRDP, the panel exposes Dozzle, Uptime Kuma, and Dockge—off-the-shelf tools used for container logs, service monitoring, and Docker stack management.
Fig. 3: The OraxManage operator panel, showing the OraxRDP session console alongside supporting infrastructure tools.
The recovered GraphQL and SignalR API surface also exposed how OraxRDP organizes those live sessions. ORAX’s schema includes fields for the target, authentication stage, session state, source IP, and Seen, with a MirrorChallenge stage label corresponding to the ORAX command used to synchronize the phishing page with the real authentication process.
Because Abnormal Intelligence did not obtain authenticated access to the live OraxRDP console, the interface shown below is a reconstruction based on that recovered API surface (Fig. 4). Its column layout, session states, and MirrorChallenge stage label reflect ORAX’s schema, while all sessions, addresses, and access keys shown are synthetic.
Fig. 4: Abnormal Intelligence reconstruction of the OraxRDP live-session view based on ORAX’s recovered GraphQL and SignalR API surface. All displayed session data are synthetic.
The branding extends into an associated Telegram ecosystem that includes a service bot (@oraxbot) and an Arabic-branded storefront (@oraxstore). The ecosystem also includes a channel whose bio explicitly references Iran ("Connect to Internet In Critical Situations For IRAN") and a developer persona with a Persian-language support contact and an `ir`-suffixed handle. The operator panel is hosted in Saudi Arabia, while the observed harvester uses gotech-ae[.]com, a .com domain with UAE-themed branding.
Based on the Telegram ecosystem’s explicit Iran reference, Persian-language persona indicators, and Gulf-region infrastructure, we assess with moderate confidence that an Iran-nexus developer operates ORAX.
The platform itself reflects substantial custom development. ORAX combines a WebSocket-driven relay architecture, per-deployment access keys, two interchangeable gate designs—including an anti-analysis self-decrypting page—and shared infrastructure. Together, those features indicate a capable developer. That sophistication is concentrated in the platform itself; by contrast, the delivery layer relies heavily on abused legitimate services, including a hijacked Mailchimp account, a Brevo/Convrrt landing page, and Cloudflare fronting.
We observed ORAX infrastructure from approximately February through mid-August 2026, but its target-facing infrastructure turns over much more quickly. One harvester domain expired only a day after its associated lure was sent. Across that short-lived infrastructure, the same emoji CAPTCHA gate appeared on six domain apexes from April through August, while the OraxManage panel and OraxRDP session console remained the central control layer.
Defending Against ORAX
Because ORAX captures an authenticated session after MFA succeeds, a password reset alone is not sufficient. Defenders should revoke active sessions and refresh tokens, audit for persistence, and prioritize higher-specificity ORAX artifacts over domains that operators can readily rotate.
Prevention
Require phishing-resistant authentication for all users, not just administrators. Properly deployed FIDO2 security keys and passkeys are cryptographically bound to the legitimate relying party, making them resistant to AiTM relay. By contrast, one-time codes and phone-based factors remain relayable, while push-based MFA can be defeated when a victim approves a request initiated through an attacker-controlled session.
Harden authenticated sessions. Shorter session lifetimes reduce how long a stolen session remains usable. Token binding can restrict reuse from an attacker-controlled environment, while continuous access evaluation can trigger re-authentication when session context changes.
Response
Treat a successful ORAX attack as a session compromise, not just a credential compromise. Revoke all refresh tokens and active sessions, force re-authentication, and audit for attacker-installed persistence, including new or altered MFA methods, new OAuth application grants, mailbox forwarding, or inbox rules.
What ORAX Changes About the AiTM Playbook
ORAX underscores why defenders cannot anchor their understanding of AiTM to a single implementation. Target-facing domains can be short-lived, and campaign infrastructure can turn over while the persistent platform behind them continues to coordinate authentication and translate successful interactions into reusable access. That makes the behaviors closest to the authentication process and resulting session more durable defensive signals than any individual lure or domain.
The broader lesson is to treat AiTM as a class of authentication abuse rather than a single technical pattern. Defensive strategies built around the outcome attackers are trying to achieve—not assumptions about the architecture they will use to achieve it—are better positioned to remain effective when that implementation changes.
For additional insight into the attack landscape and analyses of other dark web tools, visit Abnormal Intelligence, our threat intelligence data and research hub.
Visit Abnormal Intelligence
