Phishing: More Than a Fake Login Page

For years, phishing was fairly predictable. Attackers would create a webpage that looked almost identical to a popular service, wait for someone to enter their username and password, and collect those credentials. As organizations started adopting Multi-Factor Authentication (MFA), that approach became far less effective.

So, did phishing disappear? Not at all.

Instead, phishing kits evolved. Today’s phishing campaigns resemble lightweight web applications with multiple components working together. Rather than relying on a convincing fake page alone, they focus on capturing an authenticated session before security controls have a chance to react.

The Reverse Proxy Does the Heavy Lifting

Most current kits run on an Adversary-in-the-Middle (AiTM) setup. Instead of cloning a login page and hoping it looks convincing, the kit sits as a reverse proxy between the victim and the real service. The victim is genuinely talking to Microsoft 365 or Google Workspace; every request just happens to pass through the attacker’s infrastructure first.

Username, password, MFA code, all of it gets relayed to the real service in real time. Once the legitimate server issues a session cookie, the proxy grabs a copy on the way back. Kits like Tycoon2FA have made this almost turnkey: centralized panels, live campaign dashboards, and configuration options that read more like a SaaS product than malware. The attacker walks away with a valid, authenticated session, no password cracking, no MFA bypass exploit required, because nothing was technically bypassed.

A successful AiTM attack may capture:  • Session cookies  • OAuth access tokens  • Refresh tokens  • Browser fingerprint information  • IP address  • User-Agent  • Device identifiers

From a defender’s perspective, this is where traditional detections begin to fail. Authentication logs often show a completely successful login, correct password, valid MFA approval, and no obvious authentication errors. The compromise only becomes visible when the authenticated session starts behaving differently from the legitimate user’s normal activity.

Why Session Cookies Matter More Than Passwords

A password proves who you are.

A session cookie proves you’ve already authenticated.

That’s an important distinction.

Once a web application issues a session cookie after successful authentication, it assumes the browser has already passed every required security check. If an attacker steals that cookie before it expires, they may be able to inherit the authenticated session without repeatedly entering credentials or completing MFA.

CAPTCHA Is Guarding the Kit, Not the User

Here’s the part that throws people off. A CAPTCHA on a phishing page isn’t there to stop the victim. It’s there to stop you, the researcher, the crawler, the security scanner trying to fingerprint the domain before it gets flagged. Block the bots, and the page stays live longer. The same control we deploy to protect real users has quietly become an uptime feature for attackers.

An interesting side effect is that CAPTCHA also slows down automated threat intelligence platforms. Many URL scanners rely on headless browsers that struggle with interactive challenges, giving phishing infrastructure valuable extra time before it appears in public blocklists.

A headless browser is a browser that runs without a graphical interface and is commonly used by automated scanners, crawlers, and testing frameworks.

Telegram as the Notification Layer

Renting infrastructure and maintaining a command-and-control backend is effort. Increasingly, kits skip it entirely and just use the Telegram Bot API. The moment a session is captured, it’s pushed straight to the operator’s phone, credentials, cookies, IP, device metadata, timestamp, all of it. Recent PaaS families like Kratos and Bluekit lean on exactly this model, partly because it’s free and instant, but also because a Telegram bot token is far easier to rotate than a seized server. For defenders, that’s actually a usable signal: unexpected outbound traffic to Telegram’s API from a server that has no business talking to Telegram is worth a second look.

Phishing-as-a-Service (PhaaS) platforms provide ready-made phishing infrastructure that attackers can rent instead of building themselves.

Some phishing kits no longer wait until the victim finishes the entire authentication flow. They stream captured information as each step completes, meaning usernames, passwords, cookies, and browser metadata may all be transmitted independently. Even if the campaign fails midway, partial information may already have reached the operator.

Built to Slow You Down

Assume someone will eventually pull this kit apart because someone will. So, kits ship with their own defenses: blocking known cloud-provider and security-vendor IP ranges, single-use links that expire after one open, fingerprinting checks, obfuscated JavaScript. None of it is sophisticated on its own. Stacked together, it buys the campaign just enough runway.

What This Actually Changes for Defense

If the credentials and MFA were both valid, login monitoring alone won’t catch this. The shift has to be toward watching the session after authentication impossible travel, device changes mid-session, reuse patterns that don’t fit the user’s normal behavior. And phishing-resistant methods like FIDO2 or WebAuthn matter here in a way OTPs never could, because they’re cryptographically bound to the actual origin. An AiTM proxy has nothing to relay. (FIDO2 and WebAuthn authenticate users using cryptographic key pairs tied to the legitimate website’s domain, preventing attackers from replaying authentication through a phishing proxy.) 

The page being real doesn’t mean the visit was safe. As students heading into this field, that’s probably the single habit worth building early: stop asking whether the login page looked legitimate and start asking what happened to the session after it did.

The biggest realization is how operationally mature they have become. They borrow ideas from legitimate software engineering: modular components, dashboards, automation, APIs, and rapid deployment. Understanding that architecture makes it much easier to understand where defenders can actually disrupt the attack lifecycle.

Modern SOC platforms increasingly use AI to identify abnormal authenticated sessions by learning baseline user behavior instead of relying only on signatures. 

Examples include: 

• Unusual login sequence 

• Impossible travel prediction 

• Session anomaly detection 

• Cookie reuse detection 

• Risk-based authentication scoring