A single misconfiguration exposed three separate phishing operations built to steal Microsoft 365 sessions. An operator running a live attack server left a Python web server (python3 -m http.server 8080) listening on a public port with directory listing enabled, and the command was still readable in the .bash_history. French security firm Lexfo found the open directory during a routine internet scan in late April 2026 and pulled the operator's full toolkit off the host. (Source: The Hacker News)

From that one host, cataloged at an address in Budapest, Lexfo pivoted to two more operators. The result is three campaigns, each running a custom fork of the open-source Evilginx adversary-in-the-middle proxy, cloned from public GitHub. The operators are tracked as codemado (an Egyptian actor), mail-argenta (Nigerian, behind the fork called red-queen), and saroula01 (behind the fork called black-queen). The exposed server also held a SimpleHelp remote console, a Kraken panel, and a bulk mailer codemado wrote called MaDoO Blaster, which surfaces separately inside a phishing-as-a-service ecosystem named The Quarry, run by a developer called RockyBelling.

Why this matters for your firm: these operators target corporate mailboxes. The largest campaign ran for more than a year, and Lexfo counted 218 distinct captured accounts across a dozen countries, around 94 percent of them corporate mailboxes.

The firm counted 218 distinct captured accounts in the campaign's Telegram bot logs across a dozen countries between June 2025 and July 2026, around 94 percent of them corporate mailboxes.

The two techniques in play get past MFA in mechanically different ways — one by proxying the live login, one by abusing Microsoft's legitimate device code sign-in flow. A stolen session gives an attacker access with the victim's own permissions, which means mailbox contents, documents, and any downstream systems tied to that account are reachable without further credential theft. That exposes customer records, internal communications, and the compliance obligations attached to them.

How Evilginx2 Reverse Proxy Phishing Works Against Microsoft 365

The reverse-proxy variant of this operation works by sitting between the victim and Microsoft's real login page. When a target clicks a phishing link, Evilginx2 serves a pixel-perfect copy of the Microsoft 365 sign-in flow while transparently relaying every request to the genuine login.microsoftonline.com backend. The victim sees a real login, enters real credentials, and completes a real MFA challenge — and the proxy captures all of it in transit.

This is the mechanism that defeats most MFA. The proxy is not stealing a static password to replay later; it is intercepting the authenticated session cookie Microsoft issues after MFA succeeds. Once the attacker holds that cookie, they replay it into their own browser and inherit the victim's session without ever facing the MFA prompt themselves.

For the operators mapped here, the attack chain ran roughly in this order:

• Initial exposure and recon: The public directory listing on the attack host handed investigators phishing configs, credential-harvesting logs, combolists, and backup archives — the same reconnaissance and staging material the operator used to run the campaign.
• Infrastructure setup: Custom Evilginx forks were stood up behind operator-controlled domains, paired with wildcard certificates and rotating subdomains to keep lures live as older ones were flagged.
• Delivery and interception: Targets were funneled to the proxy, which pre-filled the victim's email address to reduce abandonment and relayed the live login to Microsoft.
• Credential and token harvesting: Captured sessions were logged to a Telegram bot and management panels for the operator to work.

The engineering added to the public framework is what makes these forks harder to catch. One fork renamed the crossorigin and integrity HTML attributes to defeat Subresource Integrity checks, and added a URL-rewriting engine to http_proxy.go to evade path-based detection. Another point matters for incident responders: the same fork set a one-year TTL of 31536000 seconds on captured Microsoft session cookies.

An intercepted login can then outlast a password reset and, without a CAE-capable Conditional Access policy, stay usable for months. One captured M365 cookie sitting in the repo carried an expiration date of June 30, 2027.

They remain inside the mailbox and connected services until the token is explicitly revoked or reevaluated.

Post-compromise, the toolkit extended well past email access. One operator's backend was built on a Kraken panel, with a MySQL password hardcoded into it — the same password later found reused across the operator's own accounts in infostealer logs. Stolen access was monetized through the MaDoO Blaster bulk mailer, turning compromised mailboxes into launch points for further phishing.

For persistence and hands-on control, the operators dropped remote management tooling on the same host or on victim endpoints. A SimpleHelp remote console ran alongside the proxy on the primary attack server, and one kit reached for the XEOX RMM agent. RMM software gives an attacker a legitimate-looking remote channel that blends into normal IT administration, which lets them return to a host, run commands, and move deeper without redeploying custom malware.

On the indicator side, the primary attack host was cataloged at 185.163.204[.]7, running the proxy and remote console together. The operation also showed repeated captures of the same corporate accounts from different source IPs — behavior consistent with an operator refreshing stolen tokens as they aged out, and a useful signal when correlating sign-in logs. Because this infrastructure rotates quickly, IP and domain indicators are best treated as short-lived leads rather than durable signatures.

Business and Compliance Impact of Compromised Microsoft 365 Credentials

When one of these operators captures a Microsoft 365 session, they inherit whatever that account can reach. In this operation, the captured mailboxes were overwhelmingly corporate — the Lexfo team counted 218 distinct compromised accounts across a dozen countries in a single campaign, roughly 94 percent of them corporate rather than personal. That mix tells you the targeting is deliberate: business accounts hold the data and the relationships worth monetizing.

A stolen session gives an attacker your inbox as you see it. That means reading current and archived mail, searching for wire instructions, contract terms, credentials sent over email, and internal discussions that reveal how your finance and approval processes work.

From there, business email compromise follows a familiar path. The attacker replies from inside a legitimate thread, redirects a payment, or asks a colleague to release funds — and because the message comes from your real account, your usual signals of fraud are gone.

The exposure does not stop at mail. A Microsoft 365 session commonly carries access to the wider workload tied to that identity:

• SharePoint and OneDrive — shared drives holding contracts, financial records, HR files, and intellectual property.
• Teams — chat histories and channels where sensitive decisions and credentials get passed around.
• Directory and address data — the org chart an attacker uses to pick the next target and craft convincing internal requests.

If you run hybrid identity — Entra ID synced with on-premises Active Directory — a compromised cloud account can become a foothold toward internal systems. The stolen identity is legitimate, so activity blends with normal use and takes longer to surface.

The persistence built into these kits changes the timeline you are working against. In one fork, captured session cookies were set with a one-year time-to-live, and the token file found in the repository showed sessions set to auto-refresh, some renewed as many as 25 times. A single interception can outlast a password reset and keep an attacker in your tenant for months without asking the victim to do anything again.

The compliance consequences depend on what data sat in those mailboxes and drives. If the compromised account handled personal data of EU residents, GDPR breach-notification obligations apply, with regulator notification generally required within 72 hours of becoming aware. Healthcare data brings HIPAA notification duties; accounts touching financial reporting raise SOX and internal-controls questions.

Because the attacker used your legitimate credentials and session, you also face a governance problem: proving what was accessed, exfiltrated, or altered. Auditors and regulators will ask for that scope, and a legitimate session leaves fewer of the obvious markers that make forensic reconstruction straightforward.

The repeated captures of the same French and North American corporate accounts from different IPs point to a longer-term intent than a one-time smash-and-grab. An operator refreshing stolen tokens as they age out is holding access, not just harvesting a login — which means the window for data exposure and downstream fraud stays open until you force the sessions closed.

The two techniques at play here reach different accounts by different means, but the business outcome converges: unauthorized, hard-to-detect access to high-value corporate identities and everything those identities can open.

Immediate Detection and Response Actions for Evilginx Phishing

Start with the sign-in logs. In Entra ID (Azure AD), pull the sign-in logs for any account you suspect and filter on the Microsoft Office desktop client ID d3590ed6-52b3-4102-aeff-aad2292ab01c. Refresh-token grants from that client ID, in environments where that desktop client is not in normal use, are the artifact Lexfo flags as worth watching. Cross-check each one against the source IP; a token from outside your known ranges is your first sign someone else is riding the session.

Because a session that began through device code flow keeps that tag on later refreshes, hunt on the sign-in's Original transfer method field, not just the live authentication protocol. The current event may show a normal refresh while the original grant was device-code abuse. In environments Capstone manages, Adlumin correlates these authentication anomalies against source geography and client behavior, surfacing the repeated captures of one account from rotating IPs that indicate an operator refreshing aged tokens.

Once you confirm a compromised account, containment order matters:

• Revoke active sessions and reset the password — but understand a reset alone does not evict an intercepted session, because captured cookies carry long TTLs and refresh on their own.
• Revoke refresh tokens explicitly in Entra ID so the autoRefresh tokens Lexfo found still alive in the operators' repos stop renewing.
• Disable the account if you cannot confirm the session is dead, then re-enable after re-enrolling MFA credentials.

Inside the next 24 to 48 hours, audit what the attacker set up while they had access. Review inbox rules and mailbox delegates for auto-forwarding or hidden rules that quietly copy mail out. Audit Entra ID application consent grants and OAuth permissions for apps the user does not recognize. Block legacy authentication protocols through Conditional Access, since they bypass the modern controls you rely on.

On endpoints, hunt for the remote console persistence these operators drop. One kit reaches for XEOX, so check for the agent at C:\Program Files (x86)\XEOX\xeox-agent_x64.exe and scheduled tasks matching *XEOX*Agent*Watchdog*.

Revoking the token, not just the password, is what stops that.

For longer-term hardening, the two techniques need two different levers. Enforce phishing-resistant sign-in — FIDO2 keys or Windows Hello for Business — to bind authentication to the real Microsoft domain and shut the reverse-proxy path. That does not touch device code abuse, so block device code flow through Conditional Access everywhere it is not needed.

Inventory legitimate device-code use from the sign-in logs first — mostly Teams room hardware and some command-line tools — then test the block in report-only mode before you enforce it. Layer IP-based location policies and Continuous Access Evaluation on supported Microsoft 365 workloads so a token seen from outside your allowed ranges gets reevaluated rather than running out its lifetime.

Add DNS filtering to block outbound calls to attacker infrastructure, and treat the domains and IPs in the Lexfo report as containment, not a permanent fix, since that infrastructure rotates. Finally, audit your own public-facing hosts for the exposure that started this case: no directory listing on internet-reachable servers, no readable shell history, and no ad-hoc Python web servers left running on open ports.

Hardening Against Server Misconfiguration and Post-Compromise Lateral Movement

The root cause here was not the phishing kit. It was a working attack server left exposed by an operator who ran python3 -m http.server 8080 with directory listing on. The same class of misconfiguration that gave researchers a full toolkit is the one that lets an intruder pivot through your network once they get a foothold, so treat configuration hardening and post-compromise detection as the two controls that limit what a session theft turns into.

Start with a configuration baseline. Apply CIS Benchmarks or DISA STIGs to your servers and endpoints, and run automated compliance scanning against that baseline on a schedule rather than a one-time audit. Directory listing on a public port, open remote-management consoles, and readable shell history are exactly the deviations a compliance scan surfaces before an attacker finds them.

Enforce least-privilege access on every host that touches the internet. No service should run with broader rights than it needs, and administrative interfaces should never be reachable from the open internet. Regular penetration testing validates that these controls hold under pressure instead of only on paper.

Block the tools these operators drop

Once an operator has a session, the persistence layer comes next. These campaigns pair remote-management software with bulk-mailing and phishing-as-a-service tooling, and every one of those can be denied execution before it runs.

• Use AppLocker or Microsoft Intune application control to allow only signed, approved executables. Unknown remote-access agents and mailer binaries get blocked by default under allowlisting.
• Restrict remote-console software your organization does not sanction, including SimpleHelp and any RMM agent not in your approved inventory.
• Deny execution of bulk-mailer and phishing-panel tooling such as MaDoO Blaster and kits distributed through The Quarry marketplace, and alert on any attempt.

Watch for lateral movement

Session theft on one host becomes a network problem when an attacker moves sideways. The signals to hunt for are well understood, and an EDR/XDR agent on every endpoint is what turns them into alerts instead of log entries no one reads.

• Credential dumping — process access against LSASS memory and Mimikatz-style behavior, the step attackers take to harvest cached credentials for reuse.
• Admin share access — connections to C$, ADMIN$, and IPC$ from hosts that have no business touching them, a common path for spreading tooling.
• Kerberos delegation abuse — unusual ticket requests and impersonation attempts that let an attacker act as other users without a password prompt.

SentinelOne catches this post-compromise activity across managed environments, flagging LSASS access and unapproved remote-management binaries at the point of execution rather than after the operator has already established persistence.

Two housekeeping controls close the remaining gaps. Disable remote-access tools your teams do not actively use, since every enabled console is another door an operator can open with a stolen session. And enforce phishing-resistant MFA on every remote-access point, not just email, so a captured credential does not translate directly into VPN or RMM access.

The report reads that the barrier to a working campaign has fallen to near zero, and the Lexfo CTI team expects this class of attack to become significantly more common over the coming months.

Configuration baselines and application allowlisting are inexpensive relative to what an unbounded intrusion costs in downtime and cleanup. Put the baseline in place first, then layer detection on top so a single compromised account stays a single compromised account.

Key Takeaway: Credential Compromise Is Your Highest Risk

What these three operations have in common is not a shared toolkit or a common author — it is that all of them target the authenticated session, not the password. Whether the operator proxied the live login or wrapped a genuine device code in a fake Authenticator page, the artifact they walked away with was a valid Microsoft 365 token. That token grants the same access your user has, and it does not trip a failed-login alert.

The economics are the reason this keeps happening. Lexfo describes forks that sell for a few hundred dollars, cloned from public GitHub, with AI filling in the custom glue code around them. The barrier to standing up a working campaign against your mailboxes has dropped to near zero, and Lexfo expects this class of attack to grow more common over the coming months.

One cheap ecosystem now supplies two ways around MFA — a shop hardened against reverse-proxy phishing is still open to device-code abuse.

The practical consequence for you is that MFA alone no longer proves an active session is legitimate. A captured token set to autoRefresh can outlive a password reset, and some in this campaign were renewed dozens of times without the victim ever seeing another prompt. Your existing account may already be the one holding the session an attacker is quietly keeping alive.

The one takeaway worth acting on: treat token theft, not password theft, as your primary Microsoft 365 risk, and assume any account touched by a phishing lure has a live session you need to account for. A password change does not close that door — only session revocation and phishing-resistant sign-in do. The specific auditing and Conditional Access steps that accomplish this are covered in the detection and response guidance.