The Call is Coming from Inside the House: Weaponizing Internal Trust

In the cat-and-mouse game of email security, the “mouse” has evolved. We are no longer dealing with simple credential harvesting pages hosted on WordPress sites. We are facing fully automated Adversary-in-the-Middle (AiTM) infrastructures that weaponize legitimate platforms to bypass MFA and deceive even the most paranoid users.

I recently dissected a live campaign targeting corporate environments. This operation wasn’t just technically sophisticated, it was a masterclass in social engineering and infrastructure obfuscation. Here is the forensic breakdown of how it works.

Phase 1: Silent Exfiltration & The “Internal Blast”

The most dangerous email in your inbox isn’t from a stranger, it’s from Dave in Accounting.

This campaign relies on a compromised internal identity. Once an attacker gains access to a legitimate mailbox (likely from a previous phish), they don’t immediately burn the access. They operate in two distinct sub-phases:

The Silent Siphon (Exfiltration) Before any phishing emails are sent, the attacker acts as a silent observer. They slowly and methodically exfiltrate sensitive data downloading contact lists, reading recent thread history, and hunting for high-value documents (contracts, invoices, internal directories). This establishes the “context” they need to make the subsequent phishing attacks look authentic.

The Blast (Weaponization) Once the intelligence is gathered, they move to the noisy phase. They don’t just send one email; they weaponize the victim’s entire contact list.

• The Technique: The attacker constructs a generic but urgent “Purchase Order” or “Agreement” lure.
• BCC & Chunking: To avoid triggering outbound spam filters (which would flag 500 emails sent instantly), they send the emails in chunks (e.g., 50–100 at a time). Crucially, they place the victims in the BCC field. This prevents recipients from “Reply-All” warning each other and keeps the attack stealthy until it’s too late.
• The Cycle: By the time the original victim realizes their account is sending spam, it’s game over. Dozens of trusted contacts have already received the link, and inevitably, someone else falls for it, restarting the cycle.

Evidence Exhibit A: The email uses a generic but urgent business hook — confirming a Purchase Order (PO). Notice the language: “Please confirm the attached PO… Document is too large.”

Security gateways (SEGs) typically trust this email because:

• Sender Reputation: It comes from a valid internal domain with a high trust score.
• Link Reputation: The link points to ‘onedrive.live.com’ or a similar trusted host initially or uses a high-reputation redirector.

Phase 2: The “Jumper” (PaaS Abuse)

When the victim clicks the link, they aren’t taken to the phishing site immediately. They are routed through a “Jumper” page hosted on a legitimate Platform-as-a-Service (PaaS) provider.

In this specific campaign, the attackers abused n8n.cloud a workflow automation tool.

Evidence Exhibit B: The victim lands on ‘gilberthorn157.app.n8n.cloud’. This is a legitimate subdomain, which helps bypass domain-age and reputation blocklists.

Why this matters:

• The “Loading” Trick: The page executes a script that displays a fake “Loading…” spinner for 4+ seconds. This isn’t just for aesthetics; it’s a Time-Based Evasion. Automated security sandboxes often have short timeout windows. By delaying the malicious redirect, the attacker waits for the sandbox to “give up” and mark the URL as safe before the real payload triggers.

Phase 3: The Gatekeeper (Anti-Analysis)

Once the Jumper releases the victim, they are redirected to the attacker’s primary infrastructure. But before they see the login page, they hit a hard wall.

Evidence Exhibit C: The attacker protects their infrastructure using Cloudflare Turnstile.

The Goal: This is not to stop DDoS attacks; it is to stop Security Crawlers.

• The Bypass: Microsoft Defender, urlscan.io, and Google Safe Browsing bots are “headless” (they don’t use a mouse). Turnstile detects this non-human behavior and blocks the connection. The phishing page never loads for the bot, so the domain remains “clean” for days longer than usual.

Phase 4: The Weapon (EvilProxy Node)

We have now arrived at the core of the attack. The victim is presented with a Microsoft 365 login page.

Evidence Exhibit D: This is not a clone. This is a Transparent Reverse Proxy (likely utilizing a customized EvilProxy or Tycoon 2FA kit). Notice the domain is ‘praksahchemicals.com’, a typosquat of a legitimate company.

The Mechanics of the Theft:

• Real-Time Relay: When the victim enters their email on ‘praksahchemicals.com’, the attacker's server immediately forwards that request to the real ‘login.microsoftonline.com’.
• MFA Interception: If the victim has MFA enabled, the real Microsoft server asks for the code. The Attacker’s proxy relays this request to the victim. The victim enters the code, and the proxy forwards it to Microsoft.
• The Kill Chain: Microsoft validates the login and issues a Session Cookie (ESTSAUTH). The attacker intercepts this cookie.

With this cookie, the attacker can inject it into their own browser and bypass the password and MFA entirely. They are the user.

Phase 5: Advanced Evasion (The “Hue” Trick)

While analyzing the source code of the landing page, I discovered a brilliant piece of anti-fingerprinting logic.

The Code: document.documentElement.style.filter="hue-rotate(4deg)";

The Effect: This CSS rule rotates the color palette of the entire page by 4 degrees.

• To the Human Eye: The “Microsoft Blue” looks exactly the same.
• To a Bot: The hex code of the branding is mathematically different from the official Microsoft assets. This breaks “Image Hashing” detection used by many brand-protection scanners.

Phase 6: Hunting the Infrastructure

As defenders, blocking the URL is a temporary fix. To stop the campaign, we must map the infrastructure.

Historical DNS Analysis Using passive DNS data, we can see the exact moment the domain was weaponized.

Evidence Exhibit E: The SecurityTrails history shows the domain was parked on a Hostinger IP (84.32.84.32) to "age" and gain reputation before switching to Cloudflare (104.21...) on Feb 11 to mask the backend server.

Certificate Pivoting By querying Certificate Transparency logs (crt.sh), we can find the specific SSL certificate issued for this domain.

Evidence Exhibit F: We can see the issuance of the Google Trust Services certificate, confirming the move to Cloudflare’s managed infrastructure.

The Hunter’s Pivot: We can’t ping the backend IP because it’s behind Cloudflare. However, we can search global internet scanners (like Censys or Shodan) for the unique signatures of this kit:

• Query: services.http.response.body: "hue-rotate(4deg)"
• Query: services.http.response.html_title: "Sign in to your account" AND services.port: 443

Finding servers that match these specific signatures reveals the Origin IP — the actual VPS hosting the EvilProxy node. From there, a reverse-IP lookup will typically reveal dozens of other domains targeting other organizations, allowing us to block the entire cluster at once.

Conclusion

This campaign demonstrates the dangerous reality of modern phishing: attackers are using our own trust models (Internal Email, OneDrive, Cloudflare) against us.

Defensive Takeaways:

• FIDO2 Keys: The only reliable defense against AiTM. A YubiKey would fail here because the domain ‘praksahchemicals.com’ does not match ‘microsoft.com’.
• Conditional Access: Restrict valid sessions to compliant devices only. Even if the attacker steals the cookie, they cannot use it from their own unmanaged machine.
• Hunt Forward: Don’t just delete the email. Analyze the headers, find the redirector, and block the kit’s signature at the edge.