Today’s cybercriminals understand how email gateways work. They know that gateways analyze message headers, inspect the message body, and scrutinize attachments. And when something appears suspicious, the email gateway will sandbox attachments and URLs to observe their behavior.
Because attackers know all this, they’ve shifted their attack methodology. While they have historically favored malicious attachments, increasingly they’re using malicious URLs. According to the most recent Proofpoint Human Factor Report Vol. 2: Phishing and URL-based Threats, URLs are now used 4x more often in malicious emails than attachments.
To evade detection, threat actors often hide the malicious components of a URL behind authentication barriers or conditional logic to get them past security. A sandbox can't easily emulate genuine user behavior. So, without that authentic user interaction, the sandbox may never reach the malicious portion of the attack. And threat actors aren’t stopping at manipulating URLs. They're also finding ways to bypass email security infrastructure entirely by exploiting trusted relationships in collaboration platforms.
Below are three real-world use cases that we've observed where threat actors intentionally engineer their attacks to circumvent existing protection. Each demonstrates a different evasion strategy.
Use case 1: the link verification exploit—hiding behind authentication
In this first use case, a threat actor includes a link in their email that looks legitimate. For example, it might be a shared document on OneDrive, a Dropbox file, or a DocuSign request.
How it works
When the email gateway's sandbox analyzes the URL, it encounters only an authentication page that requires users to verify their identity. Users are asked to enter an email address, provide a password, or complete a CAPTCHA or other “prove you are human” verification.
The critical evasion: this initial URL contains no malicious code whatsoever.
From the security system's perspective, this page looks like a standard verification page for a legitimate file-sharing service. The sandbox determines the URL is safe, and the email is delivered to the recipient's inbox.
It’s only after the user clicks the link and enters their authentication data that the web server grants access to the malicious page. That page might be a credential harvesting form, a malware download, or a sophisticated phishing site. The attack exists behind the authentication requirement. It’s invisible to the automated scanning that already cleared the email as safe.
Figure 1. Example of a link verification exploit.
The implication
Even if the gateway can detect the known malicious URL behind the authentication page, it will never be able to analyze the page. The initial URL is genuinely clean, so the gateway will not rewrite the URL for future analysis, and it will deliver the message. The threat only reveals itself after the security analysis has concluded and the user has been convinced to authenticate. This technique effectively turns legitimate security features (authentication pages) into an evasion mechanism.
Use case 2: the sandbox mirage—detecting the detector
In this more sophisticated attack, the cybercriminal’s web infrastructure is specifically designed to detect whether a visitor is human or an automated security system.
How it works
When an email that contains a malicious URL reaches the gateway, the security system opens it in a sandboxed environment so that it can analyze its behavior before delivery.
However, the attacker's web server analyzes incoming HTTP requests to differentiate between sandboxes and real users. Web servers can examine:
- User-agent strings. Sandboxes often use identifiable user agents that reveal they're automated security tools.
- IP addresses. This tells them if a request originates from known security vendor IP ranges or a data center network.
- HTTP headers. Patterns in headers like Referer, Accept-Language, and other request attributes differ between automated tools and genuine browsers.
- JavaScript execution. This tells them whether the client fully executes JavaScript, as some sandboxes may load pages without complete script execution.
- Access patterns. They’re looking for whether it’s a direct URL access versus natural navigation patterns from search or email clients.
Figure 2. Workflow of a webpage request.
Based on this analysis, if the request appears to come from a sandbox, the attacker’s server redirects to or serves a completely benign webpage.
As a result, when the security system analyzes the URL, it determines the content is safe, and the email is delivered. Meanwhile, when a user clicks that same link from their corporate device with standard browser characteristics, the attacker’s server redirects to or serves the actual malicious content.
The implication
When threat actors use server-side logic to differentiate between security scanners and human targets, static or single-pass URL analysis isn’t enough. The very act of automated inspection can be detected and exploited. This creates a cat-and-mouse game that defenders are currently losing.
Use case 3: the Google Calendar backdoor—exploiting trusted ecosystems
This attack vector is particularly insidious because it doesn't involve sending an email at all. So, it can completely bypass email security gateways.
How it works
The process unfolds as follows:
1. Initial reconnaissance. The threat actor identifies that Company XYZ uses Google Workspace.
2. Account creation. The attacker creates a free Gmail account: badguy@gmail.com.
3. Target identification. They obtain a list of email addresses for employees at Company XYZ.
4. Calendar event creation. In their @gmail.com account, the attacker creates a calendar invitation that includes:
- The target employees’ email addresses
- A phishing URL embedded in the event details
- A malicious PDF attachment (disguised as meeting materials)
5. The critical step. Instead of clicking "Send Invite," the attacker simply saves the calendar event as a draft.
Within seconds, the calendar invitation appears on the calendars of all targeted Company XYZ employees. It’s complete with the phishing URL and malicious attachment. Because no email was sent, the email security gateway never sees the threat. It never has an opportunity to scan the URL or analyze the attachment.
Figure 3. Example of a Google calendar exploit.
This attack exploits the inherent trust relationship within Google Workspace. When calendar invitations are created within the Google ecosystem, they synchronize directly between accounts without triggering traditional email delivery mechanisms.
The security controls designed to inspect email traffic are completely circumvented because the threat operates at the application layer, not the email transport layer.
From the user's perspective, all they see is a legitimate calendar invitation—perhaps for a “Quarterly Business Review” or a “Vendor Meeting”—that has professional formatting and attached documents. Because it arrived through a trusted application, there's no reason for them to suspect it bypassed any security screening.
The implication
This use case reveals a critical gap: organizations that rely solely on email gateway protection are blind to threats delivered through collaboration tools.
As work becomes increasingly collaborative and cloud-based, attackers are adapting their techniques to exploit trust relationships between integrated applications.
The path forward
To defend against these evasion tactics, you need to fundamentally shift your approach to security. Rather than having a single-point-of-inspection, you need comprehensive, defense-in-depth protection. Here’s what to look for:
1: Advanced email protection with continuous analysis
You need a security system that goes beyond initial page inspection and provides ongoing monitoring and post-delivery analysis. This includes:
- Continuous re-evaluation of URLs even after email delivery
- Behavioral analysis that detects anomalies in user interaction patterns
- Time-of-click protection that analyzes URLs at the moment users access them, not just when emails arrive
2: Native browser-based collaboration protection
Threats are increasingly arriving through collaboration platforms rather than email. That’s why you need security controls that operate where users interact with content—in the browser. Native browser protection can:
- Analyze redirects and multi-nested URLs in real-time, regardless of how they were delivered
- Inspect threats on every page of a user's journey, not just the initial landing page
- Detect malicious behavior in calendar invitations, shared documents, and messaging platforms
3: Human-centric defense
No amount of technology can replace security awareness. You need to educate your users to understand:
- Why they should be suspicious of URLs that require immediate authentication—especially when credentials are provided in the message.
- How to recognize and report unusual calendar invitations from external parties.
- Security controls aren't infallible, and their judgment remains a critical defense layer.
Conclusion
The use cases detailed above aren't theoretical—they're active attack patterns observed in real enterprise environments. If you assume that your email gateway provides comprehensive protection, you’re operating with a dangerous blind spot.
Learn how Proofpoint Prime Threat Protection delivers comprehensive, layered protection against these intentional evasion tactics.
