Microsoft 365 phishing failure chain: from Evilginx and public repos to device code abuse

An apparently trivial discovery - a public Python server with the list of directories activated and a legible .bash _ history - unravel the curtain over three phishing campaigns aimed at Microsoft 365 and allowed researchers to rebuild a complete chain of tools, operators and tactics. This small operational failure is the moral one: security is not usually broken by a single sophisticated explosion, but by a combination of publicly available code, poor operational hygiene and automation that lowers the entry barrier for unexperienced attackers.

In the cases analyzed, two technically different mechanisms were used to capture access to corporate accounts: on the one hand, proxies of adversary-in- the- middle built on forks of the Evilginx project (a proxy that preserves the real page to deceive the user and capture session cookies) and on the other, a legitimate abuse of the OAuth flow known as device code flow, which forces the victim to complete the start on microsoft.com / devicaluation and where the attacker "polling" takes the token when the user authorizes it. Both approaches are dangerous, but require different defenses: the first is mitigated with phishing-resistant MFA (FIDO2 / passkeys) and source binding; the second requires conditional access policies that block or limit the device code flow.

It is important that all the frames used by the operators were public or binary precompiled forks distributed in GitHub, some with improvements designed to evade detection and prolong the validity of cookies or tokens. This confirms a trend: the marketing of phishing as a service and the massive reuse of code available in public repositories make effective campaigns can be mounted at low cost and by actors who do not develop the infrastructure from scratch. The original repository of Evilginx remains a known and accessible resource: https: / / github.com / kgretzky / evilginx2.

The practical implications for a Microsoft 365 security team are clear and urgent. First, not having conditional access policies that restrict the device code flow leaves an open door that does not close with the mere implementation of FIDO2. Microsoft, for its part, documents the device code flow and its legitimate uses in developments: https: / / learn.microsoft.com / azure / active-directory / develop / v2-oauth2-device-code. To mitigate abuse, the operating lever is Conditional Access: invent which applications really need that flow, test a policy in just reporting mode and then ban the flow where it is not necessary. The general guide to Conditional Access and its capabilities is available here: https: / / learn.microsoft.com / azure / active-directory / conditional-access / overview.

In parallel, the AiTM proxies defence requires the deployment of phishing-resistant MFA and controls that validate the login origin. FIDO2 and passwords are effective in blocking the classic Evilginx because they associate authentication to a legitimate origin; however, they are not enough on their own to cover device code abuse. In addition, Microsoft recommends adding Continuous Access Evaluation to force session reassessments when a stolen token appears from abnormal locations or conditions: https: / / learn.microsoft.com / azure / active-directory / continuous-accesses-evaluation-overview.

From the detection and hunting of threats, there are specific signs to prioritize. Check the Entrance (Azure AD) login records for refresh token concessions associated with the Office desktop client's ID client d3590ed6-52b3-4102-aeff-aad2292ab01c when that client is not part of the normal use base. Crucially, track the field. Original transfer method and not just the current authentication event, because the sessions initiated by device code can keep that trail even though the later authentication no longer explicitly shows it.

In endpoints, seek persistent devices that operators leave behind their pivot, including RMM tools that are often deployed to maintain access. In the cases investigated, an agent called XEOX (e.g. C:\\ Program Files (x86)\\ XEOX\\ xeox-agent _ x64.exe) and programmed tasks with patterns that can be detectable. These prints vary, so combine telemetry EDR with signature searches and alert about unknown executables or new persistence watches.

There is also an operational lesson for developers and infrastructure managers: never expose directory lists or sensitive information on public servers, clean shell histories and not password stores in clear text on panels or versioned files. If a public repository contains pre-compiled secrets or binaries it exposes to the complete operation: learn to remove sensitive data from Git's history and turn committed credentials; GitHub explains how to treat repositories with sensitive information here: https: / / docs.github.com / en / authentication / keeping-your-account-and-data-secure / removing-sensitive-data-from-a-repository.

In immediate response to a suspicion: revoke tokens and affected sessions, force the expiry of compromising refresh tokens, implement the Conditional Access policy that blocks device code flow if it is not necessary, quarantine and forestall the endpoints detected with RMM, and notify Microsoft and the service providers committed to coordinate mitigation and rotary infrastructure blocks. Consider it a "containment + hardening" exercise; blocking PIs and domains is useful, but insufficient if the policies that allow the technique are not corrected.

The editorial conclusion is that effective protection against these campaigns requires two simultaneous layers: technical policies that close protocolary vectors (block device code where not needed and apply CAE) and operational improvements that close leaks and bad practices (repository control, record cleaning, secret rotation). As long as the phishing ecosystem remains commercial and modular - with polished forks, ready binaries and model-assisted generation - organizations that believe that deploying MFA and user treination is sufficient will be exposed. Defense Microsoft 365 today means combining resistant MFA, well-designed conditional Access, detection of tokens anomalies and good safety practices on servers and repositories.