A misconfigured server in Budapest left an open directory accessible, exposing the Evilginx‑based phishing infrastructure of three operators and showing that more than 218 Microsoft 365 accounts had been compromised, according to Lexfo’s research. The leak revealed the operators’ aliases, codemado, mail‑argenta and saroula01, and gave defenders a rare view into the tools and logs they used.
Evilginx works as a reverse proxy that sits between the user and the legitimate Microsoft login page, capturing session cookies and authentication tokens to bypass multi‑factor authentication, and no CVE identifiers are associated with this exposure because the flaw is a server misconfiguration rather than a software vulnerability. The open directory contained configuration files, scripts and credential logs that allowed anyone who discovered it to reconstruct the phishing campaign.
Among the exposed files were templates for spoofed Microsoft domains, scripts that abuse the Device Code Flow to obtain tokens, and logs documenting successful token harvesting from victims across multiple sectors. The operators identified as codemado, mail‑argenta and saroula01 used utilities such as ScreenConnect for remote administration and relied on legitimate Microsoft features to stay hidden from casual detection.
Activity was observed between 13 and 17 July 2026, with victims spread across twelve countries and spanning corporate offices and cryptocurrency platforms. While no named threat actor group has been linked to the effort, the financially motivated behaviour of the three individuals matches patterns seen in credential‑theft campaigns that aim to resell access or fund further intrusions.
Defenders should begin by auditing web server settings to disable directory listing and ensure that any test or red‑team tooling is not left publicly reachable. Enforce phishing‑resistant multi‑factor authentication, preferably based on FIDO2 security keys, and tighten Conditional Access policies to block legacy authentication protocols and restrict device‑code‑flow requests. Monitor sign‑in logs for anomalous patterns such as impossible travel, repeated token use or logins from unfamiliar IP ranges, and alert on any successful authentication that follows a device‑code‑flow request.
Conduct regular asset discovery and vulnerability scans to spot exposed directories before attackers do. Apply least‑privilege principles to service accounts and review third‑party tools for unnecessary exposure. Educate users to scrutinise login prompts for subtle visual discrepancies and to report any request that asks for a device code outside of expected workflows. Consider deploying network‑level inspection that can detect TLS traffic patterns typical of man‑in‑the‑middle proxies and keep incident response playbooks updated to handle credential‑theft incidents swiftly.