r/threatintel

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.

The SOCRadar Threat Research team just uncovered a staggering, active hacking campaign exposing over 30,000 verified Fortinet firewall credentials.

Here is the damage report:

🌍 Global Reach: 194 countries affected, with the US sitting at the #2 most targeted spot.

🏦 High-Value Targets: The victim roster includes major banks, telecom giants, and government agencies.

🛠️Full Visibility: We tracked the entire operation—the attacker infrastructure, the tools, and the complete victim list.

⚠️ Status: STILL active as of this publication.

Don't wait for an incident to react. Dive into the full discovery, grab the IoCs, and take immediate steps to mitigate the risk and strengthen your posture.

Read the full FortiBleed breakdown here: https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/

#ThreatIntelligence #Fortinet #CyberSecurity #InfoSec #SOCRadar

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.

5⁄3 Oc. Not Q., C. S. Lou.