Phish Tales #10 — Part 2
Following up on Part 1, where I dissected a targeted AiTM attack against my organization — seven redirect hops, a fake Microsoft Defender portal, and an ASP.NET Core reverse proxy of Microsoft 365 login — this part covers the attribution effort: a systematic elimination of known PhaaS kits against the Sekoia 2025 Global Analysis of Adversary-in-the-Middle Phishing Threats, and why attribution to any single documented kit ultimately was not possible.
Systematic Elimination Against Known Kits
I used Sekoia’s June 2025 Global Analysis of Adversary-in-the-Middle Phishing Threats as my primary reference. The report documents 11 kits with detailed cheat sheets covering backend technology, network, antibot page, URL patterns, infrastructure, main steps, indicators in code, authentication, and other indicators. I went through each one.
Step 1: Technology
The documented kits use these technology stacks:
- PHP: Storm-1167, Gabagool, CEPHAS
- Node.js: Mamba 2FA
- Go: Evilginx
- Python: Greatness
- Not explicitly documented: Tycoon 2FA, Sneaky 2FA, EvilProxy, Saiga 2FA, NakedPages
None of the documented kits use ASP.NET Core — and given how distinctive that stack is, it would have shown up in prior research if it had. That leaves three possibilities: a known kit with an undocumented backend, a known kit that underwent a full technology overhaul, or bespoke tooling built from scratch. I worked through the remaining indicators to see which, if any, of the known kits still matched.
Step 2: Network
The redirector and lure pages used Cloudflare IP addresses, which is common practice in phishing campaigns and provided nothing useful for attribution.
The login page cyberfy-login.quarantine-task-s4.live resolved to 91.92.242.194, hosted in AS202412 (Omegatech Ltd.), a Seychelles-registered hosting provider whose IP addresses have been flagged for abuse activity on [AbuseIPDB]. Because of its recent creation, AS202412 does not appear in the Sekoia report, suggesting either that a known kit has migrated to new infrastructure, or that this is tooling not yet publicly documented.
Step 3: Antibot Page
The antibot page was not covered in Part 1, as its relevance for attribution only became clear when preparing Part 2. Fortunately, the infrastructure was still online at that point, allowing a screenshot to be captured.
The challenge messages ‘Verify you are human by completing the action below’ and ‘We need to review the security of your connection before continuing’ do not appear in documentation for any of the known kits. The detailed message is documented for NakedPages: ‘We need to review the security of your connection before proceeding.’, but other kits use a similar technique: Tycoon 2FA, NakedPages, Saiga 2FA, Gabagool, and CEPHAS.
Step 4: URL Patterns
In the attack, long, descriptive, keyword-stuffed subdomains were observed, for example:
quaranda.com/e/a1?id=417ba11856d24822bbd4b9088ded09bb37da618d91405f2400d6cd36b6563230407a472cb781fd136e
drenchedinlove.com/e/a1?id=417ba11856d24822bbd4b9088ded09bb37da618d91405f2400d6cd36b6563230407a472cb781fd136e
www.quarantine-fix-30.com/r/r?rv=L2UvYTE_aWQ9NDE3YmExMTg1NmQyNDgyMmJiZDRiOTA4OGRlZDA5YmIzN2RhNjE4ZDkxNDA1ZjI0MDBkNmNkMzZiNjU2MzIzMDQwN2E0NzJjYj…
m365-securityportal-defender-online-windows-cyberfy.quarantine-fix-30.com/r/e/a1?_sd=1&id=417ba11856d24822bbd4b9088ded09bb37da618d91405f2400d6cd36b6563230407a472cb781fd136e&tk=5eae7f8a04ff7df791250102114716733e2661f236942471f2fb2c16bf47039e
quarantine-task-s4.live/application/rd/417ba11856d24822bbd4b9088ded09bb37da618d91405f2400d6cd36b6563230407a472cb781fd136e-f093c9b6
cyberfy-login.quarantine-task-s4.live/common/oauth2/v2.0/authorize?client_id=4765445b-32c6-49b0-83e6-1d93765276ca&redirect_uri=https%3A%2F%2Fm365.cloud.microsoft%2Flandingv2&response_type=code%20id_token&scope=openid%20profile%20https%3A%2F%2Fcyberfy-www.quarantine-task-s4.live%2Fv2%2FOfficeHome.All&response_mode=form_post&nonce=639059698621332650.YjViMjVhN2MtZGI3NS00M2U1LWJkMTgtM2UyNzA2Y2ZkMWNjZmVlYTg2MTQtMzcyOC00ODZkLTk2MWMtYWJlMWM1MTc0OTE3&ui_locales=en-US&mkt=en-US&client-request-id=7ec81683-9ee5-401f-abec-dafaf0746c66&state=uzjvKVjIM58CQ1kT-_MGFlGJgg1O2XmqImT_g3-rAe3iiL1aI5u_BgQLBh6uRtQyXAYks1QfZn2_C1xbSDOSO7_xZh8TdGu3K-FaUo8uZ62uULEVQRoO8ZG3tzypWTnNcIn6105bWg3MZt7yzsXRd3YlBp301ljbXbdBkrTGbbb74cImBlL8pXkPPb7A2yGskpy5j6Svso14DEVBDRQqEgIW4c8GNvpRqk0Ucqqr2nEhNQnSx-_vn3A3noRUfXyfR7kjmLBESclQVas2opuqCnU3g_-5SOd6WSL5HsopM4u1RIngsjmhvWYEcsKpk6ypoEqg6fXpfemHbeOhYz7gBGl2Fz4fVV_i0DyKy1zyAzmkenGlB0X3CyKqzm9x0aqVetM1r4MpH_C04P4poCrZvz4QA0LrW6bExIu5ofKSFW-GPDR5jkVdnyeLbNsygaul8r3SN9X1nvE30SYrc5QIOh6Av-c9LqR-s5vBbUVeo6g&x-client-SKU=ID_NET8_0&x-client-ver=8.5.0.0
The strongest match of the URL pattern is with EvilGinx. The URLs cyberfy-login.quarantine-task-s4.live/common/GetCredentialType?…
and https://cyberfy-login.quarantine-task-s4.live/common/oauth2/v2.0/authorize?… are the most significant find. EvilGinx’s documented pattern is identical to legitimate Microsoft endpoints but served from a malicious domain.
All other kits had weak or no matches.
Step 5: Infrastructure
In PhaaS operations, infrastructure is typically split between two layers. The operator controls the central backend — the servers that handle credential exfiltration, session hijacking, and antibot verification. Affiliates deploy their own disposable front-end infrastructure: phishing domains and lure pages themed around the target.
In this attack, the two layers are clearly distinguishable. The domain quarantine-fix-30.com served the lure pages, with keyword-stuffed subdomains such as m365-securityportal-defender-online-windows-cyberfy.quarantine-fix-30.com designed to appear legitimate at a glance. The domain quarantine-task-s4.live hosted the ASP.NET Core backend (confirmed by .AspNetCore.OpenIdConnect.Nonce, and .AspNetCore.Correlation cookies), handling both the authentication proxy and credential exfiltration — the functional equivalent of the central operator servers seen in many documented kits.
Step 6: Main Steps
The main steps observed in the attack were: Email → Anti-bot → 2 malicious redirectors → TinyURL → routing domain → fake Microsoft Defender “Quarantine Report” lure page → AiTM reverse proxy of Microsoft login.
A two-layer bot detection mechanism was observed, which is not documented for any of the known kits:
- Client-side (lure page, ui-form-security.js): mouse movement detection and a honeypot field validate human interaction before the form is submitted
- Server-side (POST /r/verify-redirect): a browser fingerprint token is validated server-side before the victim is routed onward to the Microsoft reverse proxy
The observed main steps only partially match the documented profiles of the known kits. A definitive attribution to any specific kit was therefore not possible.
Step 7: Indicators in Code
One remarkable indicator is the absence of obfuscation and encryption. Tools like Tycoon 2FA, Mamba 2FA, Sneaky 2FA, and Gabagool invest heavily in client-side obfuscation for hiding their phishing logic and evading signature-based detection.
Another remarkable detail is the verbose commenting in the code. These comments don’t just label what the code does — they explain why and give concrete examples. Giving a worked example inline in a comment is a very strong AI tell. It mirrors how AI models are trained to respond to prompts — showing their reasoning with examples.
However, there is a strong indicator for EvilGinx: malicious domains are included in Microsoft code. A relay of Microsoft’s legitimate Me.htm iframe endpoint had allowed origins rewritten to include cyberfy-login.quarantine-task-s4.live.
Step 8: Authentication
The authentication was performed against App ID 4765445b-32c6-49b0-83e6-1d93765276ca, which corresponds to Office Home. This endpoint is used by all documented kits except EvilProxy, which targets Office 365 (App ID 72782ba9-4490-4f03-8d82-562370ea3566). Since Office Home is effectively the default choice across the PhaaS ecosystem, this indicator does not narrow the field.
Conclusion
Attribution to a specific known PhaaS kit was not possible. Several kits were definitively ruled out based on the absence of documented code-level indicators: Tycoon 2FA, Mamba 2FA, Sneaky 2FA, and Gabagool. EvilGinx was ruled out on the basis of authentication flow indicators.
Of the remaining kits, NakedPages shows the closest alignment with the observed main steps and the server-side anti-bot mechanism. However, the additional client-side anti-bot layer extends the documented NakedPages mechanism to a multi-layer approach. The ASP.NET Core backend differs fundamentally from the technology stacks of all documented kits. The AI-generated lure page components are not characteristic of any known kit, but are to be expected as AI-assisted development becomes standard practice.
The most likely explanation is that this represents either a significantly evolved variant of NakedPages or a purpose-built kit drawing on techniques from multiple documented kits. The use of a newly registered hosting provider further suggests tooling that has not yet been publicly documented.
If you work in threat intelligence and track phishing kits, I would love to discuss my analysis. Maybe you can confirm my findings and finalize the attribution. If the kit was not documented before, I would like to propose the name Hopper — a nod to the seven redirect hops that brought my colleague to the fake Microsoft login page, and perhaps the most operationally distinctive characteristic of this kit.
In Part 3, I will show how a single JavaScript file name / hash unlocked a four-month campaign timeline.
References
- Sekoia TDR, “Global Analysis of Adversary in the Middle Phishing Threats”, June 2025, https://blog.sekoia.io/global-analysis-of-adversary-in-the-middle-phishing-threats
New or Evolved Phishing Kit: An AiTM Attribution Case Study was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.