The Perfect Phishing ⚔️

First of all, hello everyone. I am a researcher with little experience, but I often find myself daydreaming about exploits and exploit chains in my spare time — while taking a hot shower, during the quiet moments of a public transit commute, or simply when my mind is drifting somewhere else. Honestly, I think that is one of the most interesting parts of offensive security. It is not necessarily about finding one crazy vulnerability, but rather about finding two completely boring vulnerabilities and asking what happens if we put them together.

I started studying offensive security seriously a little over two years ago, and during that time, as most people here already know, we encounter many vulnerabilities that fall outside the scope or outside the paradigm for which companies actually pay. A user enumeration issue, an open redirect, a dangling DNS record, a strange email configuration, or a cookie with an unexpectedly broad scope can individually look almost boring. However, a well-structured attack that chains together every notable misconfiguration, weaving everything together like a spiderweb, never fails to fascinate me. That is exactly what I am presenting today: the Perfect Phishing hypothesis.

To get started, we need a target, and for demonstration purposes, our target will be example.com. The second step is choosing the objective, which could mean getting a user to perform an action or exfiltrate their data, but for this hypothesis, I am going to focus on Account Takeover, specifically a one-click path. Once we have the target and the objective, we need to look at the pieces, starting with the victim. The ideal scenario would be an information-disclosure vulnerability yielding unique identifiers, but realistically, authentication behavior where applications respond differently to existing versus unknown email addresses provides a reliable starting point.

When dealing with large companies possessing millions of accounts, identifying a subset of legitimate addresses through an authorized test or public information gives us our potential victims. Next comes email configuration, which is one of my favorite parts of this hypothesis. I often see discussions treating DMARC with $p=none$ as a green light for domain spoofing, but it is not that simple. DMARC is a policy and reporting mechanism built around SPF, DKIM, and domain alignment, requiring a comprehensive view of how receiving mail infrastructure actually processes failed authentication.

When we map the public DNS footprint of example.com, we look at the domain, known subdomains, MX records, TXT records, and CNAMEs. MX records reveal mail reception infrastructure, while complex SPF records across marketing, support, CRM, and cloud platforms frequently introduce configuration inconsistencies. Large organizations also maintain numerous subdomains inherited from legacy products or acquisitions, creating opportunities to find domains whose email trust model differs from the primary apex domain.

Beyond email, suppose our target has an abandoned subdomain like old-app.example.com containing a CNAME pointing to an external cloud provider that no longer hosts the application. If that external resource can be legitimately claimed, we face a potential subdomain takeover. When this compromised hostname is trusted by other systems or shared via authentication boundaries like cookies scoped to .example.com, the security model depends entirely on every subdomain remaining secure. If a cookie is broadly scoped rather than strictly isolated, a compromised origin within that boundary can interact directly with the user's active session context.

We can further integrate an open redirect from the official application, such as an endpoint redirecting browsers to supplied destinations, to create a seamless user journey. The victim receives an official-looking notification email from a trusted organizational subdomain, clicks the link, gets redirected through the official domain to the compromised subdomain, and inadvertently exposes their authenticated state if boundary isolation fails. That is the theoretical one-click ATO, driven not by a magical bypass, but by the simultaneous failure of multiple security assumptions.

The complete chain flows from reconnaissance and user identification to email trust analysis, DNS discovery, dangling CNAMEs, subdomain takeover, authentication boundary weaknesses, trusted open redirects, and finally, authenticated victim compromise. However, there is always a catch, because every link must be rigorously proven. A weak DMARC policy or a dangling CNAME does not automatically grant arbitrary access without thorough verification of underlying mechanics.

What fascinates me about this attack model is that while individual components like user enumeration, open redirects, dangling DNS records, and broad cookie scopes look mundane on their own, combining them builds a much stronger and more dangerous structure. That is the essence of offensive security that I truly enjoy — discovering relationships between bugs, uncovering shared security boundaries, and exploring what happens when we stop looking at vulnerabilities separately.

For those who were curious about my journey, yes, my first bounty on HackerOne was indeed for a client-side RCE.

$2,500.

Hahaha.

Best Regards, @scrutalis