Book a demo →
← All posts

What happens when the attacker hides the payload?

How AegisAgents follow phishing links through redirects, CAPTCHAs and cloaked decoy pages, and how attachments are unpacked in a proprietary sandbox.

What happens when the attacker hides the payload?

AegisAI Answers · Part 1

How AegisAgents investigate links and attachments that are built to evade sandboxes

Modern phishing is engineered to look harmless to a scanner. The link redirects four or five times. A CAPTCHA or a Cloudflare check sits in front of the credential page. The site serves a decoy to anything that looks like a sandbox. These are the questions security teams ask us most about how we deal with that.

Questions in this article

  • How do you follow a link through redirects, CAPTCHAs and Cloudflare gates?
  • What if the site detects your sandbox and shows a decoy?
  • When you hit a login page, whose credentials do you use?
  • What about links that are weaponized after delivery?
  • Do you scan attachments the same way?
  • Is the sandbox yours or licensed?

How do you follow a link through redirects, CAPTCHAs and Cloudflare gates?

We don't rely on a headless browser. Headless browsers are easy for attackers to fingerprint, and phishing kits cloak against them heavily. Instead, an AegisAgent navigates to the site the way a person would, interacting with the page and collecting telemetry at every hop.

Many filters stop after a hop or two, or stop at the first gate. When the visible page looks clean, the email is marked safe or handed to an analyst to detonate by hand. That is how attacks with five redirects and two gates reach inboxes.

Our engineering commitment is simple: the agents go as far as they need to in order to be certain of malicious intent. For most malicious email, surface analysis is already conclusive. The advanced attacks are where agents go deeper.

What if the site detects your sandbox and shows a decoy?

Cloaking is itself evidence. Agents look for signs that a site is trying to detect it is being analyzed, or that it is returning decoy content instead of what the email promised.

A concrete example: an email says "open this document," and the button lands on a social media home page. Nothing on that page is malicious. The mismatch between what the message claims and where the link goes is a strong red flag, and the agents weigh it with every other signal in the email.

When you hit a login page, whose credentials do you use?

Never yours. By the time an agent reaches a credential prompt, it usually already has its answer: a domain that isn't Google rendering a Google sign-in page is a fake.

Agents analyze the page for phishing-kit code. Where useful, they submit fake credentials to see which command-and-control server the kit reports to, so we can fingerprint the kit and the infrastructure behind it.

What about links that are weaponized after delivery?

We analyze URLs when the message is delivered. A time-bombed link is a gamble for the attacker: if the recipient clicks early, the attack fails. In practice we don't see it often.

When an attacker does serve a benign page at delivery, the rest of the email still has to make sense. Context, sender, intent and the link's behavior are judged together, so a harmless-looking destination does not clear a message that is otherwise out of place.

For click-time protection, AegisAI offers link wrapping and an in-browser isolated environment that lets users interact with suspicious links safely.

Do you scan attachments the same way?

Yes. Attachments of all kinds are pulled apart in secure, sandboxed environments. Analysis is recursive: archives such as ZIP and RAR are unpacked, links inside PDFs are followed, and redirects from those links are chased. Everything found feeds back to the agentic analysis of the email as a whole.

Is the sandbox yours or licensed?

It's ours. The sandbox is proprietary, built by the AegisAI team.

More from AegisAI Answers

  • Part 1: What happens when the attacker hides the payload? (this article)
  • Part 2: Can I trust AI agents inside my inbox? (coming soon)
  • Part 3: Wouldn't my current vendor catch what you catch? (coming soon)
  • Part 4: What happens to my mail flow if you go down? (coming soon)
  • Part 5: What happens to my data? (coming soon)
  • Part 6: Will outbound DLP drown my team in false positives? (coming soon)
  • Part 7: What if the attacker is already inside a trusted account? (coming soon)
  • Part 8: How realistic are your simulations, and what about attacks outside the inbox? (coming soon)
Newsletter

Don't miss the next big threat

New attack write-ups, product changes and practical defence notes, sent when there is something worth reading.