Executive Summary

SRA identified an active adversary-in-the-middle (AiTM) phishing campaign propagating across healthcare and healthcare-education organizations by chaining compromised accounts. SRA reconstructed one chain across a university and two health systems, where a single compromised account phished recipients at more than 90 distinct .edu domains in roughly 13 minutes. Open-source analysis shows the observed chain is a part of a broader operation that pairs credential and session theft with a parallel malware delivery track, masking its infrastructure so effectively it scores clean on public reputation tools. Organizations in healthcare and higher education should hunt for the redirect and inbox-rule patterns detailed below, confirm session-token revocation on any affected account, and prioritize phishing-resistant MFA.

Background

During the investigation, email security tooling flagged a phishing link as the Sneaky 2FA kit. The infrastructure patterns SRA observed across the campaign, Google Sites staging in front of rotating harvester domains, Microsoft 365 session theft to bypass MFA, and aggressive cloaking against scanners, align with public reporting on that kit. SRA assesses with moderate confidence that this activity is Sneaky 2FA or a closely related AiTM kit. Because phishing-as-a-service kits are sold broadly, this is a kit assessment, not attribution to a specific operator; infrastructure overlap does not indicate a single actor.

Sneaky 2FA, operated under the “Sneaky Log” PhaaS brand and active since late 2024, targets Microsoft 365 by sitting as a reverse proxy between the victim and the legitimate sign-in flow. Like EvilProxy and Tycoon 2FA, it relays credentials and MFA prompts in real time and captures the resulting authenticated session cookie. The attacker then replays the stolen session token rather than the password, so the second factor is never re-challenged and a password reset alone does not evict them.

Two tradecraft trends documented across 2025 and 2026 converge in this campaign. First, AiTM kits increasingly stage their lures on trusted cloud services such as Google Sites, Google Cloud Storage, and Adobe to defeat domain-reputation filtering: the victim’s first click lands on legitimate Google infrastructure, and only a subsequent redirect reaches the attacker-controlled harvester. Second, multiple 2026 campaigns have paired AiTM credential theft with delivery of ConnectWise ScreenConnect as a remote-access foothold. ScreenConnect is legitimate IT software, so its install often evades suspicion absent application allow-listing or behavioral monitoring.

Activity Observed

• Organization A: A compromised account at a university sent the initial lure, a shared “Print_Scanned” document notification, to a small set of recipients at Organization B. The lure linked to a Google Sites staging page named after Organization A.
• Organization B: A user clicked through the staging page to the harvester domain technoserveinckkkmozambique[.]vu and was harvested. Anomalous sign-ins from unusual ISPs began within minutes. Roughly seven hours later, the actor used the account to send approximately 47 internal and 1,000 external phishing messages under an organization-branded “Secure” message subject. Email telemetry shows the external burst reached more than 90 distinct .edu recipient domains in a window of roughly 13 minutes, with recipient volume concentrated in academic medical centers, university health systems, and medical schools. The send rate and breadth are consistent with automated bulk distribution from a harvested address book or scraped directory rather than manual targeting.
• Organization C: Recipients at a second monitored health system received the onward phish from the compromised Organization B account. One link was flagged by client tooling as the Sneaky 2FA kit, redirecting through a Google Sites page to a second harvester, royalswazilaknwndsugarcorporation[.]vu. A second link delivered ConnectWise ScreenConnect.

Victimology

Analysis of the outbound burst shows the account sent phishing to 1,454 unique recipients across 565 distinct domains.

Healthcare provider organizations accounted for roughly 47% of unique recipients and higher-education institutions another 13%; together they represent about 63% of all recipients, and roughly 83% once consumer webmail addresses are excluded. The remainder spans the periphery of the healthcare ecosystem: insurance and financial services, malpractice and risk insurers, government, and professional and licensing bodies.

Infrastructure Analysis

Google Sites as a trusted redirect layer. The staging pages sit on legitimate Google infrastructure under sites.google.com/view/ paths, so they clear domain-reputation filters and lend the lure credibility. They function as a gatekeeper and then redirect to the .vu harvester. The operator names each staging page after the targeted organization, and observed page names include hand-typed misspellings of the impersonated institution. Any Google Sites page bearing an organization’s name that the organization did not create is high-fidelity.

Persistent harvesters, rotating staging pages. Initial triage suggested the operator burned one harvester domain per target. Open-source sandbox data contradicts this. A public Triage analysis dated June 26-27 shows royalswazilaknwndsugarcorporation[.]vu, the domain observed in the second monitored environment on July 2, already in use against an unrelated organization days earlier. The harvester domain therefore has an operational lifespan of at least six days and is reused across multiple unrelated victims. What rotates is the Google Sites staging page, renamed per target, while the backend harvester persists. The assessment that the two .vu harvesters belong to one operation rests on shared TTPs (identical staging pattern, naming convention, sector, and timeframe) and is held at high but not confirmed confidence.

Harvester naming pattern. The domain strings impersonate real organizations with junk-character padding inserted to make an otherwise-registered string available: technoserveinc + kkk + mozambique (TechnoServe Inc, a US nonprofit with a Mozambique country program) and royalswazila + knwnd + sugarcorporation (Royal Swaziland Sugar Corporation, Eswatini’s largest agribusiness). Both are African development and agribusiness organizations with no relation to the healthcare targets, indicating the string is disposable filler the victim never reads. The operator used “Swaziland,” a name obsolete since the country’s 2018 rename to Eswatini, suggesting generation from a stale scraped dataset. This is a reproducible pattern and a candidate for proactive hunting in newly-registered-domain and certificate-transparency feeds.

A second delivery track: Windows malware via ardecim[.]com. The same June 26-27 sandbox runs surface ardecim[.]com, a previously unreported domain feeding the same DocuSign and Microsoft-themed operation. One capture records the redirect chain from a staging page into a credential-harvesting path at ardecim[.]com/request/mirrosoft/ndocusign/index[.]php. A second capture resolves the chain one step further and shows the domain delivering a 13 MB Windows PE executable from a parallel download path (T1105). The domain was registered June 16 and first observed in the wild June 26, a ten-day-old single-purpose domain, exactly the profile newly-registered-domain blocking is designed to catch. It is Cloudflare-fronted with a PHP backend. The DocuSign lure theme and the ScreenConnect second stage observed at Organization C suggest the PE may be a ScreenConnect installer or similar RMM loader, but this is unconfirmed.

Active cloaking. Every public sandbox scored this infrastructure at or near zero: 0% on urlscan, 0/10 on Triage, zero across all urlquery detection categories, and the delivered PE is absent from VirusTotal by hash. This is not evidence the infrastructure is benign. It is consistent with active cloaking: the kit fingerprints scanners, VPNs, and datacenter egress and serves benign decoy content to them while delivering the phishing page and payload only to plausible real victims. Independent abuse reporting on the same Cloudflare edge documents an unrelated phishing operation exhibiting the same crawler-versus-victim content split. The practical implication is that reputation scores and IOC feeds will lag this operator; behavioral detection carries the load.

A note on shared infrastructure. The harvester and malware domains resolve to Cloudflare anycast edges, and the staging pages resolve to Google CDN. Those IPs are shared by millions of legitimate sites. Block on the domains and full staging-page paths, not on resolved IPs, and do not block sites.google.com wholesale. Because the origin hosts sit behind Cloudflare, the actor’s true infrastructure is not recoverable via DNS or passive-DNS pivoting.

Detection Opportunities

• Web proxy or DNS sessions where a request to sites.google.com is immediately followed by a request to a .vu domain, or any newly registered low-reputation TLD, from the same user and source within a short window (under 60 seconds). The staging page and harvester are separate hostnames, so correlate on user and timestamp rather than expecting one URL to contain both.
• Google Sites paths of the form sites.google.com/view/<string> where the string matches or typosquats your organization’s name. Match on fuzzy or partial strings, since the actor generates these by hand and introduces spelling errors.
• New-InboxRule or UpdateInboxRules operations creating rules that mark inbound mail as read and move it to Conversation History or another low-visibility folder (OfficeActivity / CloudAppEvents logs).
• Outbound email bursts: a single internal sender reaching an anomalously high count of distinct external recipient domains within a short window (EmailEvents logs).
• Non-interactive sign-ins from unmanaged, device-less sessions presenting previously issued tokens, particularly from residential ISP space inconsistent with the user’s baseline (Entra ID sign-in logs).
• Unauthorized ConnectWise ScreenConnect installation or outbound relay beaconing on hosts where a suspect link executed.

Defense Recommendations

• Confirm session-token revocation, not just password resets, on affected accounts. Against AiTM, a password reset alone does not evict an actor holding a live session cookie. Force sign-out and revoke refresh tokens on all impacted identities, then verify with post-remediation sign-in review.
• Alert on inbox-rule creation and hunt retroactively for rules diverting mail to Conversation History or other low-visibility folders. In this campaign the rule pattern recurred across incidents in the same tenant, making it one of the highest-fidelity signals available.
• Block the harvester and malware domains and the specific Google Sites staging paths by full path across proxy and DNS. Consider blocking the .vu TLD where no legitimate business need exists.
• Consider enabling Newly Registered Domain and newly-seen-domain blocking in your web proxy.
• Prioritize phishing-resistant MFA (FIDO2/passkeys) enforced through Conditional Access authentication strength. AiTM defeats push and OTP factors but not hardware-bound credentials. This is the control that actually breaks the attack chain; everything else is downstream of the session token already being stolen.
• Enforce Conditional Access requiring compliant or managed devices and enable continuous access evaluation to blunt session replay from unmanaged infrastructure.
• Inspect hosts tied to suspect links for RMM footholds. Treat any host where a second-stage link executed as potentially having an active ScreenConnect foothold, independent of the credential-theft remediation.
• SRA published related research on AiTM session theft in Defending and Hunting AiTM Attacks, which can be leveraged to harden against this campaign and similar token-replay activity.

Indicators of Compromise

All indicators are defanged. Likely-malicious indicators only; shared Cloudflare and Google CDN IPs behind this infrastructure are intentionally excluded and should not be blocked.

Behavioral indicators:

• Google Sites staging pages at sites[.]google[.]com/view/<target-organization-name>, renamed per victim and often containing hand-typed misspellings.
• Auto-created inbox rule marking inbound mail read and moving it to the Conversation History folder.
• Anomalous Microsoft 365 sign-ins from residential ISP space inconsistent with the user’s baseline.
• ScreenConnect client install or outbound relay beacon on hosts where a second-stage link executed.