According to JFrog, the information stealer “scrapes every secret it can find on a developer’s machine, hides behind an eBPF kernel rootkit, and
The Slovakian cybersecurity company said it first detected the malware spread via multiple campaigns in early 2025, with each attack wave making use of distinct websites mimicking utilities, war-related updates, and a government news source:
govlens[.]net, which
ReliaQuest has assessed with moderate to high confidence that the espionage-focused activity is linked to China.
“OP-512 was highly likely conducting espionage through a
You click a link, sign in, approve the MFA prompt, and get on with your day. Completely unaware that someone else just logged into your account at the same moment.
That scenario surprises many businesses, particularly those that rely on multi-factor authentication (MFA) to protect cloud accounts. But this is exactly how Adversary-in-the-Middle (AiTM) phishing attacks work.
Rather than stealing passwords for later use, these attacks silently hijack an already-authenticated session in real time.
MFA remains a core control, and getting it implemented correctly is still a critical first step for any business.
But AiTM attacks exploit something MFA was never designed to protect: the trusted session that exists after authentication has already completed.
Phishing remains the most common starting point for account compromise, but the objective has changed.
Traditional phishing collected usernames and passwords. Modern phishing is after something more immediately useful: the authenticated session itself.
Security researchers have documented a significant shift toward session and token theft, where attackers intercept the authentication process as it happens.
Rather than reusing stolen credentials, which MFA typically blocks, they wait until the user successfully completes login, then steal the session token that proves it already occurred.
The technique has matured quickly. Phishing-as-a-Service (PhaaS) platforms now supply ready-made proxy toolkits that let even low-skilled attackers run AiTM campaigns targeting Microsoft 365 and Google Workspace.
An AiTM phishing site is not a basic replica of a login page. It is a live reverse proxy.
The attacker’s infrastructure sits between the user and the real authentication service. Every keystroke, redirect, and server response flows through the attacker’s system in real time. From the user’s perspective, nothing looks wrong.
The page behaves exactly like the real service, with correct branding, working redirects, and a functioning MFA prompt. In most cases, the only clue is a slightly altered URL that goes unnoticed on a mobile screen or when someone is under time pressure.
This is where many security assumptions fall apart.
MFA protects the moment of authentication, not what comes after it.
Once a user successfully completes MFA, the service issues a session cookie. What this means is that the cookie signals to the application that the user is already verified. From that point, no password or MFA prompt is required. The system trusts the token. Whoever holds the cookie holds the access.
AiTM attacks simply wait for that cookie to be issued then steal it.
Microsoft tracked a 146% rise in AiTM attacks over the past year, as cybercriminals increasingly shift focus to accounts already protected by MFA.
Much of this increase is driven by PhaaS platforms like Evilginx that allow even low-skilled attackers to run convincing reverse-proxy campaigns at scale, targeting major cloud identity providers with minimal setup.
Session tokens act as bearer credentials. So, whoever possesses the token can access the account, with no password or MFA challenge required.
Once the cookie is stolen, the attacker imports it into their own browser and immediately resumes the session.
This is a session replay attack. The attacker does not log in. They pick up where the legitimate user left off, inside a fully trusted, already-verified session.
The aftermath of an AiTM attack tends to be quiet, which is precisely what makes it dangerous.
The attacker is operating inside a legitimate, authenticated session. There are no failed MFA attempts, no unusual login alerts, and nothing in standard sign-in logs to signal a problem.
Research from Proofpoint shows that attackers who gain access through session hijacking commonly create hidden inbox rules to redirect mail, register additional MFA methods to lock in persistent access, monitor email threads for financial conversations, and use the trusted account to launch phishing campaigns against internal colleagues or finance teams.
These follow-on actions are a key reason AiTM attacks are frequently uncovered late, after financial fraud, data exposure, or wider network compromise has already begun.
MFA is still essential. Building strong authentication practices remains the starting baseline. But reducing AiTM risk requires controls that extend beyond the login event itself.
Methods like FIDO2 hardware keys and passkeys bind authentication to the specific device and the legitimate domain. A proxy in the middle cannot relay them: the process fails if the URL is not the real one.
The Canadian Centre for Cyber Security analyzed over 100 AiTM campaigns targeting Microsoft Entra ID accounts. It found that phishing-resistant MFA consistently blocked session theft where standard MFA methods (including push notifications and one-time passcodes) did not.
Risk-based access controls evaluate additional signals, including device compliance, IP location, and session behavior, rather than treating every authenticated session as permanently trusted.
Configured correctly, these policies can detect and block anomalous access even when a stolen session token appears valid.
Detecting AiTM compromise typically means watching for activity after login: new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations, or unusual data activity.
Authentication logs alone will not surface the problem.
Employees who understand that a working MFA prompt on an unfamiliar-looking page still represents a risk are better positioned to pause, check the URL, and report before a session is compromised. A brief team walkthrough of what AiTM lures look like in Microsoft 365 contexts can meaningfully reduce exposure.
MFA is a baseline, not a finish line. The businesses that reduce AiTM risk are the ones that understand how sessions, tokens, and identity trust actually work . And they build controls around each layer, not just the login screen.
Want to review your identity security controls?
Contact us or schedule a consultation to identify the gaps that matter most before an incident does it for you.
—
This Article has been Republished with Permission from The Technology Press.
The vulnerability in question is CVE-2026-3300 (CVSS score: 9.8), a remote code execution bug impacting all versions of the plugin up to, and including, 1.9.12. A patch for the flaw was
Recent reports describe thousands of lookalike FIFA domains, banking malware hidden inside pirate streaming apps, and at least one operation that copies FIFA’s login page well enough to take over real accounts.
It is an obvious target. More than
“Compromised business servers across the U.S., Europe, and Asia were quietly converted into SMTP proxies, verified for mail relay capability, and synced to a downstream consumer every five minutes,” Hunt.io said in
It is tracked as CVE-2026-20230, and proof-of-concept exploit code is already public. Cisco’s PSIRT says it has not seen the flaw used in attacks yet. The PoC shortens that runway.
The flaw is a server-side request forgery.
RyotaK of GMO