Cyber Security News

Three PhaaS Kits Targeting US Organizations to Steal M65 Logins by Bypassing MFA

Three distinct Phishing-as-a-Service (PhaaS) platforms, Sneaky 2FA, EvilTokens, and EvilProxy, are actively targeting US organizations to steal Microsoft 365 (M365) credentials and session tokens, effectively neutralizing standard multi-factor authentication (MFA) protections.

Each kit uses a fundamentally different technical approach: Adversary-in-the-Middle (AiTM) session hijacking, OAuth device-code abuse, and real-time reverse-proxy credential relay, but all three converge on the same outcome: a fully authenticated M365 session or token in the attacker’s hands without ever “cracking” MFA itself.

For defenders, this represents a critical shift in the threat landscape. Traditional advice to “enable MFA” is no longer sufficient on its own, because these kits are purpose-built to make the victim complete real, legitimate MFA challenges while the attacker silently captures the resulting session artifact.

This article breaks down each kit’s infrastructure, attack chain, detection opportunities, MITRE ATT&CK mapping, and IOC data needed for defensive tooling.

Why MFA Alone No Longer Stops These Attacks

MFA Bypass Attack Paths (Image Source: Cybersecuritynews.com)

All three kits exploit the same structural weakness: MFA validates that a login event occurred, not where the resulting token or cookie ends up. Sneaky 2FA and EvilProxy sit as a live man-in-the-middle proxy between victim and Microsoft, relaying the real authentication flow and skimming the session cookie the moment it is issued.

EvilTokens goes a step further and doesn’t touch credentials or cookies at all; it abuses the OAuth 2.0 Device Authorization Grant, a flow Microsoft designed for keyboardless devices like smart TVs and IoT hardware, tricking the victim into authorizing the attacker’s client directly on Microsoft’s own infrastructure.

AttributeSneaky 2FAEvilTokensEvilProxy
Attack techniqueAiTM reverse-relay phishing pageOAuth 2.0 Device Code Grant abuseReverse-proxy AiTM
First observedOctober 2024 (Sekoia, Dec 2024)Mid-February 2026May 2022
Operator/brand“Sneaky Log” Telegram PhaaSEvilTokens PhaaS platformEvilProxy dark-web PhaaS
Credential theft methodRelays creds live to Microsoft API, captures session cookieNone victim authorizes attacker’s OAuth client; only tokens stolenReverse proxy relays creds + cookies in real time
MFA interactionVictim completes real MFA; cookie skimmed post-authVictim completes real MFA; token issued directly to attackerVictim completes real MFA; cookie/token intercepted mid-flight
Primary evasionCloudflare Turnstile/reCAPTCHA, IP/data-center filtering, Wikipedia redirects for botsMulti-redirect chains via trusted sites, bot-protection walls, AI-generated lure infrastructureVM/browser fingerprinting, random URLs, near-identical clone of real login page
Pricing (underground)~$200/month subscriptionNot publicly priced; sold as “complete BEC operations environment”Sold as PhaaS on dark web marketplaces since 2022
Scale observed~100 domains tracked by early Jan 2025; 61+ IOCs documented340+ M365 organizations compromised across 7+ countries since Feb 2026100+ organizations, executives/managers targeted in single 2023 wave

Sneaky 2FA is an Adversary-in-the-Middle phishing kit first identified by Sekoia’s Threat Detection & Research team in December 2024, though campaigns trace back to October 2024.

It is sold as a licensed, obfuscated PhaaS product through a fully automated Telegram bot called @SneakyLog_bot, operated by a cybercrime service known as “Sneaky Log,” which also sells a bulk email sender and redirect/attachment tooling.

Analysis of the leaked source code revealed it reuses components from the W3LL OV6 AiTM kit reported by Group-IB in 2023, including identical User-Agent handling logic and cookie-parsing functions.

Attack Chain

The kit’s defining evasion feature is a Cloudflare Turnstile (or reCAPTCHA) challenge gate placed in front of the fake login page this blocks automated scanners and sandboxes from ever reaching the phishing content, since bots typically fail or skip the CAPTCHA.

Victims who pass the human-verification check are shown a pixel-accurate cloned Microsoft authentication page, often using blurred screenshots of real M365 interfaces (Outlook, OneDrive, SharePoint) as visual bait.

  1. Victim clicks a phishing link/QR code (often embedded in a PDF titled something like “Final Lien Waiver.pdf”)
  2. Traffic passes an open-redirect step, then lands on a Cloudflare Turnstile gate disguised initially as a benign “Gourmet Delights” food page
  3. IP-based filtering silently redirects data-center, VPN, proxy, or known-abuse IPs to a Microsoft-related Wikipedia page via href.li
  4. Genuine victims are shown the fake M365 login; the server autofills the victim’s email from the URL parameter (autograb)
  5. Credentials are POSTed to /validate; the phishing server relays them live to Microsoft’s authentication API
  6. Victim completes real MFA (Authenticator push, OTP, or SMS) directly against Microsoft’s backend
  7. The resulting session cookie is captured server-side and handed to the attacker for account takeover

High-Fidelity Detection: “Impossible Device Shift”

Sekoia identified that Sneaky 2FA hardcodes a different User-Agent string for each step of the authentication flow it relays to Microsoft e.g., a Safari-on-iOS User-Agent for the login step, then a Chrome-on-Windows User-Agent for MFA resolution a pattern no real user’s browser would produce within the same session.

This “impossible device shift” is detectable via Sigma correlation rules against Entra ID/M365 audit logs, correlating Login:login and Login:resume events by correlation ID within a 10-minute window.

Sneaky 2FA IOCs

TypeIndicatorNotes
URL patternhttps://<domain>/[a-zA-Z0-9]{150}/index, /verify, /validate150-char alphanumeric path signature
Default repo path/auth/Common deployment directory
Operator domainsneakylog[.]storeLicense-check server, registered 3 Sep 2024
Operator IP185.125.100[.]81Hosts “Sneaky Log” HTTP service
Operator IP101.99.92[.]124Associated infrastructure
Sample domainhighnationservices[.]comActive phishing page
Sample domainmysilverfox.com[.]myActive phishing page
Sample domainkagumigroup[.]idHosted on /wp-content/plugins/well/auth/ (compromised WordPress)
Sample domaintesla-apply-job[.]comOperator-linked domain
Favicon hashSHA256 5d91563b6acd54468ae282083cf9ee3d2c9b2daa45a8de9cb661c2195b9f6cbfBase64-encoded Microsoft logo
Background image hashSHA256 8c4e78b1bc0a0923fccc0cd2d7ca06023b6ab15af079e6b19d7d5d2fddc5488dTransparent MSFT-color background
Redirect servicehref.liUsed to anonymize bot redirects to Wikipedia

Sekoia’s full IOC set spans roughly 61 indicators 57 domains, two IPs, and two subdomains publicly available in CSV form via the SEKOIA-IO Community GitHub repository.

Additional confirmed attacker-controlled domains include africanagrirnarket[.]com, allorganicitems[.]com, emailsay[.]com, files42[.]com, flonrenceorganics[.]us, guardiansresearch[.]org, intertrustsgroup[.]com, omnirayoprah[.]cfd, portalpowerfiles[.]top, reliant-rehabs[.]com, storageorder[.]sbs, and windstreaim[.]com.

Independent DNS analysis found average dwell time of 113 days between domain registration and threat-intel detection for Sneaky 2FA infrastructure, with roughly one-third of IOCs undetected for over 90 days.

Kit 2: EvilTokens OAuth Device Code Token Theft

EvilTokens is a PhaaS platform that emerged around mid-February 2026 and has already compromised over 340 Microsoft 365 organizations across at least seven countries.

Unlike traditional phishing kits, EvilTokens never presents a fake login page and never captures a password it weaponizes Microsoft’s legitimate OAuth 2.0 Device Authorization Grant, the flow built for keyboardless devices to authenticate via a short code entered at microsoft.com/devicelogin.

Attack Chain

The attacker’s client initiates a device authorization request against Microsoft’s API and receives a real, valid device code and user code indistinguishable from a legitimate Smart TV or printer authentication request.

The victim receives a lure (often disguised as a meeting invite, Adobe Sign, or DocuSign request) instructing them to enter this code at the genuine Microsoft URL.

When the victim authenticates including completing their real MFA challenge exactly as expected Microsoft’s backend issues valid access and refresh tokens directly to the attacker’s polling client, not the victim’s device.

  1. Attacker requests a device code/user code from Microsoft’s OAuth endpoint, often after first validating the target’s account existence via the GetCredentialType endpoint on login.microsoftonline.com
  2. Victim receives a lure with a verification code and a “Sign in” button pointing to the legitimate Microsoft device-login page
  3. Victim manually enters the code and completes normal sign-in, including TOTP, SMS, or push-based MFA
  4. Microsoft’s authorization server issues access and refresh tokens to the attacker’s already-polling client
  5. Attacker gains ongoing, silent API access to the victim’s Exchange, OneDrive, SharePoint, Teams, and calendar data with no phishing page, malicious login, or MFA alert ever triggered

The Register described the toolkit as functioning as a “complete business email compromise operations environment,” with Talos researchers noting its downstream use for business email compromise fraud, not just initial access.

Push Security and Sekoia have both confirmed a sharp spike in device-code phishing adoption throughout 2026, citing multiple shared backend IPs on the Railway cloud platform used for token replay.

EvilTokens IOCs

TypeIndicatorContext
Domaintechroboticslabmade.comCentral C2 / MailVault platform
Domainmacmamo.comSelf-hosted PHP backend
Domainbibf.ac.bwCompromised gate site
Domainacb.afRedirector
Domainadobe-lg7.emily-c57.workers.devCloudflare Worker Adobe/ACH lure
Domaindocusign-wz7.emily-c57.workers.devCloudflare Worker DocuSign lure
Domaindocusign-2vh.davidvallejo-tophattx-com-s-account.workers.devCloudflare Worker DocuSign lure
Domainms-teamsmeeting.topMicrosoft Teams impersonation
Domainmicrosoft365onlineoffice.comM365 impersonation
Domainmicrosoftonlineoffice365.comM365 impersonation
Domainmicrosoftofficeonline365.comM365 impersonation
Domainfilesharebysecureoffice365.comCredential harvesting
Domainoffice365documentbysecuredportal.comCredential harvesting
Domaindocumentsecuredbyoffice365.comM365 impersonation
IP216.126.227.101Self-hosted backend (Cloudzy, Tampa)
IP range162.220.232.0/22Token replay (Railway)
IP range162.220.234.0/22Token replay (Railway)
IP167.99.0.116DigitalOcean (ASN 14061), US
IP104.248.200.231DigitalOcean (ASN 14061), US
IP185.81.126.157PacketHub S.A. (ASN 136787), US
IP (IPv6)2606:4700:3037::6815:388bCloudflare-fronted infrastructure, US
User-Agentpython-requests/2.31.0Automated scripting agent
User-Agentkali365-live/1.0.0Custom M365 exploitation toolkit

Kit 3: EvilProxy Reverse-Proxy AiTM at Scale

EvilProxy has been operating since May 2022 and is one of the longest-running commercial AiTM PhaaS platforms, marketed on dark-web forums with turnkey targeting of Microsoft 365, Google Workspace, Dropbox, GitHub, and other major identity providers.

In August 2023, Proofpoint and Menlo Security tracked a large campaign that used EvilProxy to hijack M365 accounts of C-level executives and managers at over 100 organizations globally.

Attack Chain

EvilProxy operates as a genuine reverse proxy: victim traffic is routed through attacker-controlled infrastructure that fetches and displays the actual Microsoft login page content in real time, meaning the phishing page‘s source code closely mirrors the legitimate site a key reason automated scanners and casual visual inspection struggle to flag it.

Before serving any content, the kit performs extensive virtual-machine detection and browser fingerprinting to filter out security researchers and sandboxes.

  1. Victim receives a phishing email (often with a fake voicemail, DocuSign, or document-sharing lure) leading to an open-redirect chain
  2. Traffic lands on an EvilProxy phishing framework mimicking the target organization’s actual branding
  3. Credentials entered by the victim are passed through to the legitimate Microsoft or Google backend in real time
  4. If MFA is enabled, the real MFA prompt is proxied back to the victim, who completes it normally against the legitimate identity provider
  5. The reverse proxy harvests the resulting session cookie mid-transit, granting the attacker live, authenticated access without needing the password or MFA code again

Okta’s Threat Intelligence team confirmed an EvilProxy campaign active since at least March 2025, still evolving as of their advisory, describing it formally as threat actor O-TA-041.

A key detection tell flagged by Barracuda researchers: unusual MFA prompts arriving when the user is not actively logging in, and login page URLs that don’t match the organization’s usual authentication domain.

EvilProxy IOCs

TypeIndicatorNotes
Domainacrobatsign[.]esSuspicious landing page
Domainadobeacrobat[.]sa[.]comSuspicious landing page
Domainadobesign[.]ceelegal[.]comSuspicious landing page
Domainadobesign[.]plSuspicious landing page
Domainadobesign[.]us[.]comSuspicious landing page
Domainasir[.]co[.]comSuspicious landing page
Domainblue-styles[.]czSuspicious landing page
Login phishing URL patternlmo.msdnmail[.]net/common/oauth2/v2.0/authorize?client_id=...OAuth authorize endpoint abuse observed in 2022 campaign
Detection tell.ru TLD + Base64-encoded victim email in URLOften indicates Tycoon 2FA rather than EvilProxy; useful for differentiation

MITRE ATT&CK Mapping

Technique IDTechniqueApplies To
T1566.002Phishing: Spearphishing LinkAll three kits
T1566.001Phishing: Spearphishing Attachment (QR/PDF lures)Sneaky 2FA
T1539Steal Web Session CookieSneaky 2FA, EvilProxy
T1550.001Use Alternate Authentication Material: Application Access TokenEvilTokens
T1621Multi-Factor Authentication Request Generation (adjacent real MFA relayed, not generated)Sneaky 2FA, EvilProxy
T1557Adversary-in-the-MiddleSneaky 2FA, EvilProxy
T1078.004Valid Accounts: Cloud AccountsAll three (post-compromise)
T1114Email Collection (post-access BEC)EvilTokens

Detection and Mitigation Recommendations

Phishing-resistant MFA is the only control that structurally defeats all three kits, since TOTP, SMS, and standard push-based MFA are all relayed or redirected rather than broken FIDO2/WebAuthn passkeys and hardware certificate-based authentication cannot be proxied or device-code-hijacked in the same way.

Organizations should also restrict the OAuth Device Authorization Grant flow entirely for standard corporate users via Conditional Access policies in Microsoft Entra ID, since almost no typical employee legitimately needs keyboardless-device sign-in.

  • Block or tightly scope the Device Code authentication flow in Entra ID Conditional Access for users who do not operate keyboardless/IoT devices
  • Deploy Sigma/KQL correlation rules for “impossible device shift” inconsistent User-Agent strings across the same authentication correlation ID within a short time window
  • Monitor Entra ID Identity Protection alerts: Impossible Travel, Anonymized IP Sign-in, and Anomalous Token Detected, which flag geographically inconsistent or unusual token issuance patterns
  • Flag sign-ins from data-center/hosting-provider IP ranges (DigitalOcean, Railway, Cloudzy, PacketHub, OVH, Hetzner) tied to known EvilTokens and Sneaky 2FA backend infrastructure
  • Train users to never enter a Microsoft device-login verification code unless they personally initiated a device sign-in request
  • Inspect phishing URLs for the 150-character alphanumeric path pattern followed by /index, /verify, or /validate a high-fidelity Sneaky 2FA signature
  • Treat unexpected MFA prompts (arriving when the user is not actively logging in) and login-domain mismatches as high-priority indicators of EvilProxy activity
  • Enforce short session-token lifetimes and Continuous Access Evaluation (CAE) in Entra ID to reduce the value of a stolen cookie or OAuth token

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

Guru Baran

Gurubaran KS is a cybersecurity analyst, and Journalist with a strong focus on emerging threats and digital defense strategies. He is the Co-Founder and Editor-in-Chief of Cyber Security News, where he leads editorial coverage on global cybersecurity developments.

Recent Posts

Google Chrome 153 Update Fixes 42 Security Flaws, Including 3 Critical Ones

Google has released an important Chrome 153 security update that fixes 42 vulnerabilities across the…

4 hours ago

CISA and NIST Release Technical Checklist for Safeguarding Identity Tokens From Theft and Misuse

The Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology…

14 hours ago

CISA Shares 17 Techniques Used by Hackers to Compromise Active Directory Environments

CISA and five international cybersecurity agencies have released detailed guidance describing 17 common techniques hackers…

15 hours ago

Apple Rolls Out Massive Security Update Fixing 273 Vulnerabilities Across Its Devices

Apple has released one of its largest coordinated security rollouts, addressing 273 distinct critical vulnerabilities…

15 hours ago

How to Keep Malware’s Rotating Infrastructure From Becoming a Detection Gap

You can’t detect today's attacks with yesterday’s threat intelligence; that’s how you could briefly formulate…

16 hours ago

Microsoft Bans Its AI Models From Launching Cyberattacks or Escalating Their Own Access

Microsoft has published a draft Humanist AI Code of Conduct that would prohibit its in-house…

16 hours ago