The Anatomy of a Phishing Landing Page

The Trap: Familiar Portals Turned Against You

The anatomy of a phishing campaign often begins with something mundane. A user receives an enticing message, perhaps an email celebrating an "Employee of the Month" award. To claim the reward, the recipient is asked to click a link.

The destination is not Microsoft's generic login page, but rather a federated login portal that an organization uses to authenticate to Microsoft 365. These portals often carry the company's own branding, styling, and messaging. To an employee, they feel familiar and trustworthy, which is exactly why attackers target them.

This post examines how adversaries build these landing pages, why they are so convincing, and what defenders can do to reduce exposure.

Step One: Finding Organizations That Use Federated Login

Adversaries begin by determining whether an organization uses Microsoft federated authentication. This reconnaissance can be done in a number of ways:

Entering a target email address (for example, @example.com) at login.microsoftonline.com may reveal whether the organization redirects to a custom login page.
Automated tools can scale this discovery process, enumerating thousands of domains in bulk.

Such reconnaissance allows attackers to map which organizations rely on Microsoft federation, and therefore which login experiences can be imitated with high fidelity.

Note: Blog subscribers will receive a PoC tool for testing federation visibility inside their own environments.

Once identified, the organization's branded login portal can be viewed. For example, entering a Netflix email redirects users to the following federated login experience, which carries Netflix's own corporate branding:

This visibility allows attackers to focus on portals that employees already recognize and trust, making any replica they build far more convincing.

As the reconnaissance phase concludes, attackers transition seamlessly into the next step: replication.

Step Two: Capturing a Pixel Perfect Copy

Once a target organization is identified, adversaries seek to replicate its federated login portal with as much fidelity as possible. The closer the replica is to the genuine branded portal, the more likely users are to trust it.

Open source tools make this straightforward. For instance, extensions such as SingleFile allow the entire page to be saved into a single file, preserving structure, styling, and embedded assets.

Within moments, the attacker has a clone of the portal, complete with the organization's logos, colors, and layout.

From a user's perspective, the replica is nearly indistinguishable from the legitimate page. For defenders, this highlights how easy it is for attackers to mimic trusted brand identity at scale.

Step Three: Crafting a Convincing Domain

With a cloned portal in hand, adversaries still face an important challenge: where to host it. A perfect copy loses its power if the web address immediately looks suspicious. To overcome this, attackers register or compromise domains that appear trustworthy and aligned with the target's brand.

One common method is typosquatting, where attackers register domains with small spelling changes such as m1crosoft-login.com. Another is the use of homoglyphs, swapping characters with visually identical Unicode symbols so the difference is nearly invisible to the naked eye.

In other cases, attackers create legitimate-sounding subdomains on free hosting providers or compromised servers, producing URLs like company.example.com.secure-auth.org. To further reduce suspicion, some adversaries practice domain aging, registering domains months in advance and letting them sit idle so reputation checks treat them as benign.

These techniques give the cloned page a believable home. When paired with a carefully crafted phishing email, the entire experience feels seamless and trustworthy to the victim.

Step Four: Standing Up Cheap and Disposable Infrastructure

Attackers do not need enterprise infrastructure to run these campaigns. They often rely on:

Free hosting services
Budget virtual private servers (VPS)
Compromised websites

Most tradecraft observed involves purchasing a low-cost VPS from a provider such as OVH. Once online, the attacker deploys the cloned HTML page. However, a static replica is not enough. To actually capture credentials, adversaries typically set up a lightweight PHP application behind the page. This allows them to process submitted form data and forward credentials to attacker-controlled infrastructure.

In practice, this often looks like:

The attacker owns look-a-like.com, registered to resemble the target's brand. This domain hosts the cloned login page on the VPS.
DNS is routed through Cloudflare with proxying enabled, hiding the origin IP address from defenders.
Protections like Cloudflare Turnstile are enabled to block automated scanning or takedown bots.
A valid TLS certificate is issued, ensuring the page shows the reassuring HTTPS padlock in the browser.

When victims submit their credentials, the VPS-side PHP script captures them and either logs them locally or forwards them onward. This setup costs an adversary only a few dollars a month, yet it produces an infrastructure footprint that looks polished and secure to the average employee. The low barrier to entry also means phishing sites can appear and disappear rapidly, complicating takedown efforts.

Step Five: Relaying Credentials

After credentials are compromised from the previous steps, attackers commonly use a webhook flow to relay the credentials. Less sophisticated attackers might attempt to log in from their origin location (often overseas). However, more advanced attackers will purchase a VPN in the location of their victims. This serves two purposes:

SOC teams will be less suspicious if the origin is Arizona, and the company is based out of Arizona, for example.
Some companies apply Geo Fencing restrictions to specific states or countries.

One interesting tactic observed recently is Geo Fencing to allow 2FA bypass for large organizations. If your IP address is within 50 miles of an onsite location, your 2FA isn't required. It's quite surprising to think about!

At this point, with the credentials in hand, attackers aim to access Microsoft 365. They should use a VPN to get close to the origin location.

Step Six: Bypassing 2FA

Now that attackers have reached this stage, they face the final hurdle: bypassing 2FA. Almost every company nowadays has 2FA enabled. So, how do attackers go about doing this?

There are several tactics attackers use to bypass two-factor authentication (2FA):

2FA Fatigue Attack: This method involves bombarding the target with repeated 2FA requests, hoping to wear them down. The constant notifications can lead to frustration, causing the user to approve the request just to stop the interruptions.
Timing the Notification: Attackers may attempt to send a 2FA notification at a strategic time, such as 9 am, when employees are just starting their workday. The hope is that the recipient might mistake it for a legitimate request amidst the morning rush. Although this is a long shot, it only needs to succeed once.
Social Engineering: Attackers may impersonate IT support and contact the employee directly. They might claim there's an issue with the employee's account and that they need to verify it by sending a 2FA code. This approach requires more effort and targeting but exploits the human tendency to trust authority figures.

How Defenders Break the Chain

By this point in the chain, we have seen how attackers move from reconnaissance to replication, infrastructure setup, and finally credential harvesting. The good news is that defenders have proven ways to disrupt every stage of this process.

The challenge for defenders is that phishing relies on trust. Employees see a familiar logo or a convincing portal, and their instincts tell them it is safe. To counter this, security teams need layered controls that break the attack at multiple points.

Some of the most effective measures include:

Conditional Access Policies: Restrict access based on device health, geography, or user risk so that stolen credentials are far less useful.
Phishing Resistant MFA: Hardware keys (FIDO2) and passkeys prevent adversaries from reusing credentials even if they capture them.
Domain Monitoring and CT Logs: Watching for lookalike registrations and scanning certificate transparency logs provides an early warning when attackers attempt to stand up infrastructure.
Email Authentication Standards: SPF, DKIM, and DMARC reduce the chances that phishing lures are delivered to inboxes.
Awareness and Simulation: Training employees with realistic phishing campaigns helps them recognize even convincing replicas.
Federation Monitoring: Monitoring for abnormal login flows or suspicious federation redirects makes it possible to spot abuse before it becomes widespread.

Each of these measures on its own adds friction for the attacker. When combined, they create overlapping defenses that make phishing campaigns much harder to execute at scale.

Closing Thoughts: Awareness is the First Line of Defense

Phishing landing pages thrive on familiarity. They borrow the logos, flows, and design patterns employees see every day, turning trusted authentication experiences into weapons of deception.

The attacker's playbook is simple but effective: identify a federated login portal, clone it with precision, give it a believable home, host it cheaply, and harvest credentials as soon as they are entered. Every step is designed to exploit user trust while requiring minimal cost or skill.

For defenders, the takeaway is clear. The best countermeasure is preparation, which combines technical safeguards with user awareness. By understanding the exact methods adversaries use, security teams can anticipate their moves, recognize early warning signs, and strengthen defenses where they matter most.

Attackers rely on deception. Defenders can rely on preparation. In that preparation lies resilience.