Mamba 2FA: Emerging Player in the AiTM Phishing Landscape

Sekoia TDR identified Mamba 2FA, an AiTM phishing kit sold as PhaaS that delivers Microsoft 365-like login pages via HTML attachments and link domains to capture passwords, cookies, and MFA inputs. The kit uses Socket.IO to relay user actions to backend relay servers (now often proxied via IPRoyal), which then perform authentication requests to Microsoft services. #Mamba2FA #Microsoft365

Keypoints

  • Mamba 2FA is an adversary-in-the-middle phishing kit sold as phishing-as-a-service (PhaaS) on Telegram.
  • Phishing delivery uses HTML attachments or link domains that require a valid Base64 parameter to render the page and can pre-fill targeted email addresses.
  • Pages load template scripts and the Socket.IO library to establish bidirectional (WebSocket) connections to relay servers.
  • Template scripts send events (new-session, password_command, otp_command) to relay servers; relay servers reply with s2c events to drive page state, capture cookies, and redirect victims.
  • The relay servers use stolen credentials to perform authentication requests to Microsoft (Entra ID/M365) on behalf of attackers; proxies (IPRoyal) have been added to hide relay IPs.
  • HTML attachment files are often obfuscated with benign filler content and a small JavaScript snippet that decodes a Base64 URL and redirects the browser to the phishing page.
  • Infrastructure is split into short-lived link domains (antibot checks) and less-exposed relay domains/servers that handle core AiTM operations.

MITRE Techniques

  • [T1566] Phishing – Use of phishing emails with HTML attachments and crafted web pages to steal credentials. [β€˜HTML attachments that mimicked Microsoft 365 login pages.’]
  • [T1003] Credential Dumping – Capturing user passwords, cookies and MFA inputs through the phishing page and exfiltrating them to the attacker. [β€˜capturing user credentials and MFA inputs through phishing pages.’]
  • [T1210] Exploitation of Remote Services – Relay servers perform authentication requests to Microsoft services to sign in as victims using stolen credentials. [β€˜perform requests to the Microsoft authentication servers to sign in as the victim.’]

Indicators of Compromise

  • [IP address] Relay/proxy IPs involved in Entra/M365 sign-ins – 23.26.35[.]67, 45.61.130[.]11, and 10+ other addresses cited
  • [Domain] Relay server domains used for backend authentication – ccokies1cakes[.]com, m1tis-apicookies[.]com, and many other ccokies*/ apicookies* domains
  • [Domain] Link domains hosting phishing pages / antibot checks – tubope[.]com (example link domain), and numerous short-lived link domains
  • [URL pattern] Phishing URLs requiring Base64 parameter – example: https://tubope[.]com/n/?c3Y9bzM2NV8x… (Base64 query string required to display page)
  • [File name] Template JavaScript files injected into pages – jsdrive.js, jsnom.js (OneDrive/generic templates)
  • [File content] HTML attachment redirect pattern – files containing window.location.href = atob(β€œaHR0cHM6Ly…”) + β€œ#” + β€œ[EMail]” (filler content made invisible via CSS)

Mamba 2FA serves phishing pages only when a valid Base64 query parameter is present in URLs of the form https://{link-domain}/{path}/?{Base64}. The decoded parameter contains fields (sv, rand, uid) that select the visual template (sv=o365_#_one/nom/sp/voice), a pseudo-random value, and a customer UID. Targeted email addresses can be appended after the Base64 string (using N0123N or a URL fragment) and may be Base64-encoded; if provided the login form is pre-filled. Link domains implement antibot detection (redirect to https://google.com/404/ for suspected scanners) and return a minimal HTML document that embeds Socket.IO and a template script instead of static content.

When loaded, the template script (examples: jsdrive.js, jsnom.js, jssp.js, jsv.js) injects the phishing UI and contains the relay server domain. It uses Socket.IO to open a bidirectional channel (WebSocket/long-polling) to the relay server and emits events such as new-session (uid, email, ua, timeZone, browserLanguage), password_command (password), and otp_command (phish_otp). The relay replies with s2c events to update phish_state (RQ_EMAIL, RQ_PASSWORD, RQ_OTP_*), branding fields, OTP expectations, and ultimately s2c_cookies when cookies are captured; s2c_cookies includes an endUrl to which the victim is redirected after session capture.

The relay servers perform the AiTM function by taking captured credentials/cookies and executing authentication requests against Microsoft authentication endpoints to sign in as the victim; captured cookies and session data are exfiltrated to the attacker (notifications are also sent via a Telegram bot). To reduce exposure of relay server IPs in tenant logs, operators began routing relay traffic through commercial datacenter proxies (IPRoyal), making detection in auth logs show proxy IPs instead of the relay hosts. Operators rotate short-lived link domains weekly while relay domains persist longer, and HTML attachments are commonly used to deliver Base64-encoded redirectors that resolve to the active link domain.

Read more: https://blog.sekoia.io/mamba-2fa-a-new-contender-in-the-aitm-phishing-ecosystem/