Threat reportPhishingTL-2026-3036
Google Phishing Kit Uses Real-Time Browser-in-the-Middle (Socket.IO) Remote Browser Relay
Google Phishing Kit Uses Real-Time Browser-in-the-Middle (TL-2026-3036) is a medium-severity phishing campaign, first published 2026-08-11. It has no confirmed attribution, affects Google Google Account sign-in (impersonated brand; no product, maps to 6 MITRE ATT&CK techniques (T1027, T1056, T1071.001), and is covered by 9 detection rules and 9 indicators of compromise.
- Severity
- MEDIUMAssessed severity
- CVEs
- 0None referenced
- Techniques
- 6MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 9Indicators of compromise
Key facts for TL-2026-3036
- Threat ID
- TL-2026-3036
- Severity
- MEDIUM
- Status
- ACTIVE
- Category
- PHISHING
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- technology, general-consumer, enterprise
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 9
Malware and tooling in Google Phishing Kit Uses Real-Time Browser-in-the-Middle
Malware and tooling: Google BitM phishing kit (Socket.IO/diffDOM), Socket.IO, diffDOM
How Google Phishing Kit Uses Real-Time Browser-in-the-Middle works
Joe Security analyzed a Google sign-in phishing kit that implements a Browser-in-the-Middle (BitM) architecture: the victim's page relays every keystroke, click and selection to a backend browser over Socket.IO and applies the backend's DOM changes (via diffDOM) in return. The kit is gated by Cloudflare Turnstile and delivers an encrypted self-decrypting loader; no attribution or CVE is reported.
Joe Security (blog post dated 11.08.2026, parsed as 2026-08-11) documents a phishing kit that mimics the Google authentication flow but is not a static clone. It is a Browser-in-the-Middle / adversary-in-the-middle design in which the victim-facing page is only a thin client for a browser session running on the attacker's backend. The backend streams complete Google authentication views and subsequent DOM updates to the victim over Socket.IO, while the victim's browser sends full field state and user interactions in the opposite direction. The backend can therefore drive a multi-step authentication flow while the victim stays on the malicious origin.
Delivery and gating: the first request to the phishing origin returns a Cloudflare Turnstile challenge. After the challenge is completed the server sets three cookies with a 3-minute lifetime, one of which is viewer_session_id, and redirects to an encrypted application loader that carries its own self-decryption material. The decrypted loader pulls three JavaScript components from the phishing origin: socket.io-client.js (Socket.IO transport), domdiffer.js (a reformatted browser build of the open-source fiduswriter/diffDOM library) and index.js (custom relay and control logic).
Relay protocol: the client emits inputchange (full input value, CSS path, selectionStart/selectionEnd and element metadata), selectionchange (caret movement) and click events, capturing normal input, paste, IME composition and change events, and calling preventDefault/stopPropagation on user interactions. The server emits domchanges (diff arrays applied to head, body and nested iframes through diffDOM), inputchange (server-directed field updates with selection restoration), navigation commands with URL rewriting that keeps the victim on the malicious origin, and flow-control signals (document reset, pause, completion redirect). A client-side inputTracker suppresses outbound events that match server-supplied values to avoid feedback loops. Because authentication evolves through continuous state exchange rather than a form POST and reload, there is no conventional credential submission for network tooling to key on; pre-rendered elements such as a hiddenPassword field reference were seen in the patches delivered after the email step.
Evidence: Joe Sandbox reproduced a live session (analysis 1951180) showing a pixel-faithful Google sign-in UI. TLS inspection exposed plaintext Engine.IO/Socket.IO framing: 90 protocol records with 74 application events, most after the HTTP-to-WebSocket upgrade. A Joe Reverser expert-mode analysis recovered the decryption mechanism and JavaScript components. Only one network indicator is published, the domain salemilaw[.]com. The analyst did not state the delivery vector (lure), the victim set, the actor, or whether the domain is attacker-registered or a compromised legitimate site; none is asserted here. A BeaconBeagle config search for the domain returned no records, and open web search found no other reporting on it.
Analyst note: the report states the kit relays the full authentication flow, which is the property that makes BitM effective against password-plus-MFA sign-ins (the same mechanism described for the public CuddlePhish BitM tool), but the Joe write-up does not itself show MFA or session-cookie theft, so those capabilities are treated as a risk, not an observed behavior. A separate, apparently unrelated Google credential kit reported by cside (July 2026) uses image-streamed remote-browser rendering over encrypted WebSockets rather than Socket.IO/diffDOM and is cited for context only; its indicators are not merged into this record.
MITRE ATT&CK techniques used in TL-2026-3036
Defense Evasion
T1027 Obfuscated Files or Information; T1480 Execution Guardrails; T1684.001 Impersonation
Collection
Command and Control
Credential Access
Affected products and versions in Google Phishing Kit Uses Real-Time Browser-in-the-Middle
- Google — Google Account sign-in (impersonated brand; no product vulnerability)
Remediation for Google Phishing Kit Uses Real-Time Browser-in-the-Middle
Immediate actions
- Block and sinkhole salemilaw[.]com (as salemilaw.com) at DNS, proxy and email gateway; hunt historical proxy/DNS logs for it
- Alert on Google sign-in lookalike pages served from non-Google origins that load socket.io-client, domdiffer.js and a custom index.js
- For any user who interacted with the page, revoke all active Google sessions and tokens, reset the password and re-enroll MFA; a password reset alone is not sufficient if a live session was relayed
Workarounds
- Detect Cloudflare Turnstile challenges on untrusted or newly registered origins that precede a credential prompt
- Flag short-lifetime (about 3-minute) session cookies such as viewer_session_id set by unfamiliar origins
- Monitor for DOM-diff payloads applied to credential input fields and for per-keystroke email input relays during authentication flows
Longer-term hardening
- Move high-risk users to phishing-resistant authentication (FIDO2/WebAuthn security keys or passkeys), which are bound to the real origin and break BitM relays
- Deploy browser or secure-web-gateway controls that detect credential-page lookalikes and WebSocket/Socket.IO sessions to newly seen domains following a login-like page
- Train users that a sign-in page reached through a link, even one behind a Cloudflare Turnstile check, is not evidence of legitimacy
Timeline of Google Phishing Kit Uses Real-Time Browser-in-the-Middle
- Context only: cside investigates a separate Google credential phishing kit (image-streamed remote browser over encrypted WebSockets, not Socket.IO/diffDOM), showing the remote-browser phishing pattern is in active use.
- Report recommends detections for Turnstile gates on untrusted origins, Socket.IO connections to non-legitimate domains, socket.io-client/domdiffer/relay JS, viewer_session_id cookies and DOM diffs on credential inputs.
- Report discloses salemilaw[.]com as the phishing infrastructure hosting the Socket.IO relay and encrypted loader; no actor attribution is given.
- Joe Reverser expert-mode analysis recovers the encrypted loader's self-decryption and the three JS components (socket.io-client.js, domdiffer.js, index.js).
- Joe Sandbox reproduces a live session (analysis 1951180) and, through TLS inspection, captures 90 Engine.IO/Socket.IO protocol records with 74 application events.
- Joe Security publishes its analysis of the Google phishing kit (blog date 11.08.2026, parsed as DD.MM.YYYY). The sample first-seen date is not disclosed.
Sources cited for Google Phishing Kit Uses Real-Time Browser-in-the-Middle
- Google Phishing Kit: When Phishing Becomes a Real-Time Remote Browser (Joe Security)
- Joe Sandbox Analysis 1951180 (live phishing session)
- Joe Sandbox TLS-inspected capture for analysis 1951180
- Joe Reverser expert-mode report (loader decryption and JS components)
- Socket.IO conversation extraction script (Appendix A of the Joe post)
- fiduswriter/diffDOM (library reused in domdiffer.js)
- SpecterOps CuddlePhish docs: Browser-in-the-Middle overview
- cside: Inside a live Google credential phishing kit (related, distinct kit)
- MITRE ATT&CK T1557 Adversary-in-the-Middle
Detection coverage for TL-2026-3036
As of 2026-08-11, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-3036 across Splunk SPL, Microsoft KQL and Sigma, covering 9 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.