Sneaky 2FA

Sneaky 2FA is an adversary-in-the-middle phishing-as-a-service kit targeting Microsoft 365 accounts, first observed in late 2024 and also tracked as Sneaky Log and WikiKit. Randomized URL structures and honeypot form fields keep it ahead of automated scanners, and it has been one of the most consistently detected tools in the browser since Push began tracking it.

URL patterns

The Sneaky 2FA family of phishing kits has evolved and possibly forked since its emergence in late 2024. The earliest versions had distinctive paths containing a segement of 150 random alphanumeric characters followed by /index or /verify:

1. /[a-zA-Z0-9]{150}/index - Blank page that simply redirects to /verify using JavaScript.
2. /[a-zA-Z0-9]{150}/verify - Fake Microsoft login form.

Starting in April 2025, further obfuscation was added to the URLs by randomizing the /verify path segment as well as randomizing the length of the large alphanumeric segment. For example, a /verify URL was now accessed using a path such as:

/QxJhREchBx4hjgckrIPkBit6besHMCKSo20supU8gXXT7efkYG3Iyr26A9dE9nnRMr5XsZL8JuAnmaovCRAqbpFVyWNDwfKWoZoOjod8iiqBmJHyvQSC62Nwtjmg5OU443oaEGFv3lOtwecGVTzL5xDlMNVZ97Pzl7dUWF1/m82scyq1KOFa

By late 2025, a variant had appeared that prepended the long random token with mixed case shorthand referencing various Microsoft products - for example Ms36-DoC-..., AzRe-sHaRe-..., OuTl-DoWnLoAd-... and ExCl-PrEvIeW-.... These URLs also randomised the /index path segment:

/TeMs-ViEw-kopXHsYcSep_ZEnh09BdhviGsdlrlQN668vpHNghwd96LDsMKhqUKzfmLGwR7vo7ffItrMK4vTkPWVVsGeQL1uegBSFROt-FSP2i6Q4QbHd6Bys9sEsTRbFA2n6J2b4qztag6JEmrs_R7n8L6pPKNF9TXk3N-XemEclqw95V6ZYJCYAQt4Q7qnaCFfjb0r4xxLmVaMQuZFG/2TjgfU4HQdDZF

Over the course of 2026, this became the dominant URL structure observed by Push for detections associated with the Sneaky 2FA family.

Network traffic

The background traffic sent by Sneaky 2FA during credential relay has used a consistent base set of parameters that are POSTed to the /validate endpoint (randomised since mid-2025). The example below shows three different POST bodies for the three main steps:

1. Email address validation
2. Password submission
3. Second factor authentication

POST /OuTl-DoWnLoAd-...dvWCr9/dfYA9ZWlUIW
Content-Type: application/x-www-form-urlencoded; charset=UTF-8

em=<email>&security_token=<hex>&timestamp=<ts>&email_hp=&username_hp=&password_hp=

em=<email>&pa=<password>&security_token=<hex>&timestamp=<ts>&email_hp=&username_hp=&password_hp=

em=<email>&auth=verify_code&code=<otp>&security_token=<hex>&timestamp=<ts>&email_hp=&username_hp=&password_hp=

The 2FA step auth value is typically one of verify_code (OTP), verify_sms (SMS) or verify_app (push). The email_hp / username_hp / password_hp fields appear to be honeypots for bot detection.