How Phishing Sites Work and How They’re Conducted

A phishing site looks simple from the outside — a login page that isn’t what it claims to be. But underneath, there’s a small, fairly consistent technical architecture that shows up across the vast majority of phishing campaigns, whether they’re built by a lone opportunist or bought as a kit from an underground marketplace. Understanding that architecture — not to build one, but to recognize and defend against it — is what this article covers.

The Core Architecture of a Phishing Site

flowchart TD
    A[Victim clicks link from email/SMS/social] --> B[Lookalike Domain]
    B --> C[Front-End: Cloned Login Page]
    C --> D{Victim Submits Credentials}
    D --> E[Collection Endpoint / Backend Script]
    E --> F[Exfiltration Channel]
    F --> G[Telegram Bot / Email / C2 Server / Log File]
    D --> H[Redirect to Real Site]
    H --> I[Victim Believes They Mistyped Password]

Component 1: The Delivery Layer

This is everything that gets the victim to click: the email, SMS, or social media message containing the malicious link. Modern phishing kits increasingly use link redirection chains — the initial link points to a legitimate-looking intermediate service (URL shorteners, cloud storage sharing links, or open redirects on trusted domains) before finally landing on the phishing page. This technique specifically targets automated security scanners that only inspect the first-hop URL, a well-documented evasion pattern in phishing kit analyses.

Component 2: The Lookalike Domain and Hosting

Domains are chosen to visually resemble the legitimate target through several established techniques:

Hosting is typically cheap, disposable infrastructure — free-tier cloud hosting, compromised WordPress sites, or bulletproof hosting providers that ignore abuse takedown requests. Because campaigns are designed to be short-lived, attackers optimize for speed of deployment over durability.

Component 3: The Cloned Front-End

The visual layer is usually a near-pixel-perfect copy of the target’s real login page, achieved by directly copying publicly viewable HTML/CSS/JS assets from the legitimate site — this is trivial because browsers expose all front-end code by design. Sophistication varies:

• Static clones — simple HTML forms that just look like the real page.
• Dynamic/interactive clones — replicate multi-step login flows (password, then MFA prompt) to capture one-time codes in real time.
• Adversary-in-the-Middle (AiTM) proxies — the most advanced and increasingly common pattern, where the phishing site acts as a live reverse proxy between the victim and the real service. The victim interacts with the actual legitimate site’s content in real time, while the proxy silently captures the session cookie issued after successful login — including after MFA. This technique, used by phishing kits tracked under names like “Evilginx” in security research, defeats traditional (non-phishing-resistant) MFA entirely because it steals the authenticated session token rather than just the password.

sequenceDiagram
    participant Victim
    participant Proxy as AiTM Phishing Proxy
    participant RealSite as Legitimate Service
    Victim->>Proxy: Visits phishing link
    Proxy->>RealSite: Forwards request transparently
    RealSite-->>Proxy: Real login page content
    Proxy-->>Victim: Displays real content (looks 100% legitimate)
    Victim->>Proxy: Enters password + MFA code
    Proxy->>RealSite: Forwards credentials + MFA in real time
    RealSite-->>Proxy: Issues authenticated session cookie
    Proxy-->>Victim: Logs victim into real site (no visible error)
    Proxy->>Proxy: Silently stores stolen session cookie

Component 4: The Collection and Exfiltration Backend

For simpler (non-AiTM) kits, submitted credentials are sent to a lightweight backend script that logs them somewhere the attacker can retrieve them quickly — commonly a Telegram bot API, a plain text file on the same server, or an email sent to an anonymous inbox. Security researchers analyzing leaked phishing kit source code have repeatedly found Telegram bot integration as the dominant exfiltration method in commodity kits, because it’s free, fast, and doesn’t require the attacker to maintain their own receiving infrastructure.

Component 5: The Redirect

After capturing input, most phishing pages redirect the victim to the real service — sometimes with a fake “invalid password, try again” error first, which conveniently causes the victim to simply retype what they believe was a typo, occasionally handing over a second, more carefully typed credential. This redirect is a deliberate design choice to delay victim suspicion, giving the attacker a longer window to use the stolen credentials before the victim reports anything.

Table: Phishing Site Sophistication Tiers

Why AiTM Phishing Is a Turning Point for Defenders

The rise of Adversary-in-the-Middle phishing kits is arguably the most significant recent shift in the phishing threat landscape, because it directly neutralizes the value of traditional MFA (SMS codes, authenticator app codes, push approvals) — all of which can be relayed through a live proxy sitting between victim and real service. Microsoft’s threat intelligence research on large-scale AiTM phishing campaigns (including the “DEV-1101” and related tracked activity) documented this shift affecting hundreds of thousands of organizations. The only authentication method structurally immune to this technique is phishing-resistant MFA built on FIDO2/WebAuthn or passkeys, because the cryptographic challenge-response is bound to the legitimate origin domain and simply cannot be relayed through a proxy sitting on a different domain.

Defensive Recommendations Mapped to Sophistication Tier

Common Mistakes

• Believing “we have MFA” fully solves phishing risk — AiTM kits specifically defeat non-phishing-resistant MFA.
• Relying only on blocklists, which lag behind the speed of disposable phishing infrastructure.
• Not training users to recognize that a correct-looking password error after login is itself sometimes a phishing artifact.
• Ignoring conditional access and session risk policies that could detect and revoke sessions issued from anomalous locations or devices even after a successful phishing login.

FAQs

Q: Can a phishing site steal a session even if I use an authenticator app? Yes, if it’s an Adversary-in-the-Middle (AiTM) proxy kit — it can relay the code you enter to the real site in real time and steal the resulting session cookie.

Q: What is the one technology that actually stops AiTM phishing? Phishing-resistant MFA — specifically FIDO2/WebAuthn hardware security keys or platform passkeys — because the cryptographic proof is bound to the real origin and cannot be relayed by a proxy on a different domain.

Q: Why do phishing sites redirect victims to the real login page afterward? To delay detection — the victim assumes they mistyped their password rather than realizing they were just phished, buying the attacker more time to use the stolen credentials.

Summary and Recommendations

A phishing site’s architecture — delivery, lookalike domain, cloned front-end, collection backend, and redirect — has stayed remarkably consistent, but the sophistication of the front-end layer has evolved sharply with the rise of Adversary-in-the-Middle proxy kits, which can defeat traditional MFA outright. Defense needs to evolve with it: phishing-resistant authentication is no longer optional hardening, it’s the baseline for any organization serious about stopping this attack class.

Further reading:

• Microsoft Security Blog — Adversary-in-the-Middle phishing campaign research
• MITRE ATT&CK — T1557 (Adversary-in-the-Middle), T1566 (Phishing)
• NIST SP 800-63B — Digital Identity Guidelines
• FIDO Alliance — FIDO2/WebAuthn specifications
• APWG — Phishing Activity Trends Reports