r/EmailSecurity

Spent time researching a Sneaky 2FA-style campaign that was interesting because the email delivery and the phishing kit both showed meaningful evolution.

The initial message was not sent from a random throwaway account. It came through a compromised trusted SaaS sender account and targeted enterprise IT users. The lure was a Microsoft sign-in activity alert, but it was placed inside a business-thread chain, which made the message look more like part of an existing operational conversation than a standalone phishing email.

The web flow was also more interesting than a basic Microsoft credential clone. From the samples I reversed, the kit supported:

• identity-check gating before exposing the Microsoft page
• session-mutated routes, loader names, validation paths, and tokens
• tenant-branded Microsoft 365 rendering using Microsoft tenant branding assets
• signed resource URLs with hashed IP and user-agent values
• password collection
• verification code collection
• SMS code collection
• Microsoft Authenticator approval and number matching flows
• final redirect back to Outlook

The strongest evidence came from controlled testing with non-valid credentials. After submitting them to the phishing page, Microsoft Entra ID recorded near-real-time OfficeHome sign-in attempts from external infrastructure. The attempts failed with error 50126, which confirms the credentials were replayed against Microsoft rather than only stored by the page.

The observed asset set, MFA workflow, href[.]li decoy behavior, and Sneaky/WikiKit-style page structure make Sneaky 2FA a strong match for this case.

An end user was bombarded yesterday by emails from herself that she did not send. I've had Proofpoint on their domain for over a year (on their MX records) with very few issues. The emails she received bypassed the MX records, sample header properties below. Both Microsoft and Proofpoint have writeups on this very issue, but I'm having a brainfart as to how to proceed. Stephanie@mydomain.com is using M365 Business Premium.

Received: from CO1PR05MB7879.namprd05.prod.outlook.com (::1) by
 IA3PR05MB10713.namprd05.prod.outlook.com with HTTPS; Thu, 25 Jun 2026
 14:37:05 +0000
Received: from DS7P220CA0008.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:1ca::15) by
 CO1PR05MB7879.namprd05.prod.outlook.com (2603:10b6:303:f3::17) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.181.7; Thu, 25 Jun 2026 14:32:24 +0000
Received: from DS1PEPF00017099.namprd05.prod.outlook.com
 (2603:10b6:8:1ca:cafe::60) by DS7P220CA0008.outlook.office365.com
 (2603:10b6:8:1ca::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.159.17 via Frontend Transport; Thu,
 25 Jun 2026 14:32:23 +0000
Authentication-Results: spf=none (sender IP is 108.175.8.93)
 smtp.helo=mta-80-125.sparkpostmail.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine
 header.from=mydomain.com;compauth=none reason=451
Received-SPF: None (protection.outlook.com: mta-80-125.sparkpostmail.com does
 not designate permitted sender hosts)
Received: from mta-80-125.sparkpostmail.com (108.175.8.93) by
 DS1PEPF00017099.mail.protection.outlook.com (10.167.18.103) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.181.6
 via Frontend Transport; Thu, 25 Jun 2026 14:32:23 +0000
Return-Path: <>
From: stephanie@mydomain.com
To: stephanie <stephanie@mydomain.com>
Subject: mCaller left stephanie - 34s  Preview vHC- June 25, 2026
 3517286943
Message-ID:
 <[1782397942584.17a9c193f74e0b73-JFZGS42DN5WW25LONFRWC5DJN5XFA3DBORTG64TNFVIHE33EFVGVOMKQPREUCTKTKNIFE7CTKNIFERLNMFUWY7CFPBXVG3LUOA======@mydomain.com]>
Date: Thu, 25 Jun 2026 14:32:22 +0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--_NmP-289a666a40f8f530-Part_1"
X-MS-Exchange-Organization-ExpirationStartTime: 25 Jun 2026 14:32:23.4717
 (UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
 b48d577c-0b2c-4399-3061-08ded2c69266
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 220a3ae7-e220-4b76-abb2-d1cefeba692f:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
 DS1PEPF00017099:EE_|CO1PR05MB7879:EE_|IA3PR05MB10713:EE_
X-MS-Exchange-Organization-AuthSource:
 DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: b48d577c-0b2c-4399-3061-08ded2c69266
X-MS-Exchange-AtpMessageProperties: SA|SL
X-MS-Exchange-Organization-SCL: 1
X-Microsoft-Antispam:
 BCL:0;ARA:13230040|29132699027|5009299003|6049299003|57112099003|55112099003|18002099003|19002099009|17002299006|4053099003|5063699009;
X-Forefront-Antispam-Report:
 CIP:108.175.8.93;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mta-80-125.sparkpostmail.com;PTR:ip108-175-8-93.pbiaas.com;CAT:NONE;SFS:(13230040)(29132699027)(5009299003)(6049299003)(57112099003)(55112099003)(18002099003)(19002099009)(17002299006)(4053099003)(5063699009);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2026 14:32:23.1133
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b48d577c-0b2c-4399-3061-08ded2c69266
X-MS-Exchange-CrossTenant-Id: 220a3ae7-e220-4b76-abb2-d1cefeba692f
X-MS-Exchange-CrossTenant-AuthSource:
 DS1PEPF00017099.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB7879
X-MS-Exchange-Transport-EndToEndLatency: 00:04:42.5262254
X-MS-Exchange-Processed-By-BccFoldering: 15.21.0159.007
X-MS-Exchange-ExternalInOutlookResult: NotEnabled
X-Microsoft-Antispam-Mailbox-Delivery:
ucf:0;jmr:0;auth:0;dest:I;ENG:(910005)(944506478)(944626604)(920097)(930201)(20251009189)(140003)(1310096);
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?n+j9JsLrhwvRb6OmvBUb3zljh6lgyFRYEtg3psgCsmqnGcQ/8jBmnCrECPJg?=

Cofense has a writeup here on polymorphic phishing: rotating URLs, sender identities, subjects, and body copy until old-school detection loses the plot.

The board angle is fine, but the fix is still boring work: DMARC enforcement, tight OAuth/app controls, mailbox monitoring, and testing against real phish instead of pretty dashboards.

Anyone else seeing World Cup 2026 lures that are personalized enough to get past normal user skepticism?

https://cofense.com/blog/world-cup-themed-phishing-campaign-delivers-voidrift-malware-with-highly-personalized-lures

This is the kind of campaign where training feels thin unless auth, attachment handling, and post-click controls are actually wired up.

INTERPOL says phishing is the most widespread problem across Asia-Pacific, which tracks.

Everyone wants to talk AI scams, but most breaches still start with someone typing creds into a fake login page.

https://thehackernews.com/2026/06/interpol-warns-phishing-ransomware-and.html

I spent some time reversing a CodeStorm Microsoft 365 phishing flow that looked like a basic voicemail lure at first, but the deeper chain was more interesting.

The visible email was short:

missed call
date received
duration
reference number
open voicemail portal

Nothing too special on the surface.

The strange part was the full message body. Far below the visible lure, after a lot of whitespace, there was a full unrelated historical email thread with reply headers, signatures, disclaimers, addresses, and phone numbers.

I saw the same buried thread reused across unrelated victim environments.

That feels intentional. To the user, it is a short voicemail email. To a filter, it is a much longer business-looking message. That can change things like URL-to-text ratio, body length scoring, reply-chain heuristics, keyword density, and normal-business-language signals.

The rough flow I observed:

email lure
→ trusted redirectors
→ adservice hops
→ randomized landing domain
→ Cloudflare Turnstile
→ anti-analysis JavaScript
→ second-stage JavaScript
→ POST /google.php

The landing pages accepted the victim identity in multiple formats:

#<email>
?e=<email>
#?<random_param>=<base64_email>

The first-stage JavaScript included a few analyst-friction checks:

if (
  navigator.webdriver ||
  window.callPhantom ||
  window._phantom ||
  navigator.userAgent.includes("Burp")
) {
  window.location = "about:blank";
}

It also blocked common DevTools shortcuts, right-click, and used a debugger timing trap. If debugging was detected, it redirected to what looked like a legitimate Outlook encrypted-message URL.

The second stage used a backend controller pattern:

var file = "<base64 encoded URL>";
const controller = atob(file);

// decoded to:
// https://<backend-domain>/google.php

The backend actions I observed included:

do=check
do=login
do=verify
checkVerify

do=check appeared to perform Microsoft identity discovery. In controlled testing, managed M365 users, nonexistent users, and federated tenants received different responses.

Examples of the behavior:

managed M365 existing user
→ status=success
→ type=office
→ federationLogin=""
→ canary returned

managed M365 nonexistent user
→ status=error
→ "We couldn't find an account with that username. Try another account."

federated M365 tenant
→ status=success
→ federationLogin=<tenant federation route>
→ branding returned

provider-labeled federation example
→ type=godaddy
→ federationLogin=sso.godaddy.com/?domain=...&realm=pass&app=o365...

I would not treat GoDaddy as a separate authentication category. It is still a federated M365 path. The interesting part is that the backend can label some provider-backed federation routes.

For do=login, I only used fake credentials against a controlled tenant. The backend returned a Microsoft-style error:

{"status":"error","message":"Your account or password is incorrect"}

Immediately after, Entra sign-in logs showed failed OfficeHome sign-ins for the same account:

Application: OfficeHome
Client app: Browser
Status: Failure
Error: 50126
Failure reason: invalid username or password
Authentication requirement: single-factor authentication
Source IPs: external IPs

So this did not behave like a simple credential collection form. It attempted to validate or replay the submitted credentials against Microsoft.

I also saw the same /google.php controller model across rotating infrastructure. The visible frontend domains changed, but the protocol stayed consistent:

victim identity in URL
→ POST /google.php
→ do=check
→ do=login
→ do=verify / checkVerify

Static strings in the second-stage JavaScript showed support for multiple MFA-related paths, including authenticator app, OTP, SMS, phone call, and Hotmail-style recovery/OTP flows.

Some detection ideas from this analysis:

- short visible lure + very long unrelated buried thread
- voicemail-themed M365 lure with organization-specific subject
- self-addressed sender/recipient pattern
- Google redirector → adservice hop → S3 or randomized landing
- victim identity carried as email or base64 email in URL
- Turnstile gate before content
- anti-analysis checks for webdriver, Phantom, Burp, DevTools shortcuts
- browser POST to cross-site /google.php
- Entra OfficeHome failures with 50126 from external replay IPs after a phishing click

Main takeaway: the lure was basic, but the backend was not. The flow behaved like a tenant-aware M365 authentication relay, with identity discovery before credential replay.