How to Spot a Fake Sign-In Page or Approval Prompt Flood

TL;DR — A fake sign-in page usually gives itself away by the address bar, the timing, or the path that led you there. A flood of approval prompts is often an attacker trying to wear you down into tapping "Approve"; the safest response is to deny every prompt you did not start, stop signing in, and report it through your IT or identity provider admin path immediately. Reading time: ~7 min

What it is and where it sits

Two common account-takeover tricks are:

• Fake sign-in page: a web page that looks like your Microsoft, Google, Okta, or company login page but is hosted somewhere else so it can steal your password or session.
• Approval prompt flood: repeated MFA (multi-factor authentication) push notifications sent to your phone or authenticator app until you get tired and approve one.

These attacks sit at the front door of your systems: the sign-in step. They do not usually attack your laptop first. They attack the moment where your browser talks to your company's identity provider (the service that verifies who you are), and where that identity provider talks to your apps.

In a normal setup, the flow looks roughly like this:

You -> App or company portal -> Identity provider login page -> MFA check -> App access granted
                    ^                     |
                    |                     v
               Browser address bar   Password / passkey / code

A fake sign-in page inserts itself before the real identity provider:

You -> Link in email/chat -> Fake login page -> Attacker collects password -> Real login page or error page

An approval flood usually happens after the attacker already knows your password. They try to log in to the real identity provider, which then sends MFA prompts to your device over and over:

Attacker -> Real login page -> Enters your password -> MFA prompts sent to your phone -> hopes you tap Approve

What it replaces in the flow

A fake page replaces the real login screen you should have reached from your normal app or bookmarked company portal. An approval flood does not replace anything; it abuses the real MFA step.

Where it lives

• Fake sign-in pages live on attacker-controlled websites, often with lookalike domain names.
• Approval floods live in the real authentication system, but the login attempt was started by someone else.
• Your browser, email client, chat app, and authenticator app are the places where you will notice the symptoms.

How it actually works

Let’s walk one realistic example end to end.

Example: fake Microsoft 365 page followed by MFA spam

1. You receive an email saying, "Your shared document is waiting," with a button.
2. You click it and land on a page that looks like Microsoft 365.
3. The page asks for your email and password. The logo looks right, but the browser address bar says something like microsoft-login-docs.example-login.co, not a domain you recognize from your company.
4. You type your password.
5. The attacker immediately tries that password on the real Microsoft sign-in page.
6. Because your account has MFA enabled, your phone starts receiving approval prompts.
7. The attacker hopes you think, "This must be part of the document login," and tap Approve.
8. If you approve, the attacker gets into your mailbox or other apps and may set up forwarding rules, reset passwords elsewhere, or send more phishing from your account.

What you can observe at each step

• Before entering anything: the strongest signal is the address bar. The page design can be copied almost perfectly; the domain is harder to hide.
• During the prompt flood: the strongest signal is that you did not start a login yourself. A real MFA prompt should match an action you just took.
• After a mistaken approval: you may see new inbox rules, sign-in alerts, password reset emails, or colleagues asking about strange messages from you.

The simple rule that catches most cases

If you did not just go to your company portal or app and start a login, any MFA prompt is suspicious. If a page asks you to sign in after arriving from an email or chat link, stop and open the service the normal way instead: use your bookmark, your company portal, or type the known address yourself.

When to use it (and when not to)

This is less about buying a tool and more about deciding when to treat something as an incident versus normal sign-in friction.

You probably do not need to overthink it if...

• You opened your normal bookmarked company portal yourself.
• The domain is the one your organization always uses.
• The MFA prompt appears immediately after you entered your password on that known site.
• The prompt includes a number or location that matches what you are doing.

Even then, if anything feels off, stop and restart from the known portal rather than trying to reason through a weird screen.

Trade-offs

There is no free security win here. The safer habits and controls reduce risk, but they cost convenience.

The big decision

For most organizations, the best practical move is not "train people harder" by itself. It is a combination of:

• a known sign-in path (bookmark or company portal),
• stronger MFA such as number matching or passkeys,
• and a simple reporting path for suspicious prompts and pages.

In practice

Below are concrete things a user or admin can do today.

Example 1: What to send your IT team after a suspicious page

If you are a user, the most useful report includes the full page address, time, and what happened before the prompt. You can paste something like this into email, chat, or your ticket system.

Subject: Suspicious sign-in page / unexpected MFA prompt

Time noticed: 2026-08-05 10:14 local time
What I was doing: Opened a link from an email about a shared file
Page address shown in browser: https://microsoft-login-docs.example-login.co/auth
My email entered?: Yes
My password entered?: No
Unexpected MFA prompts received?: Yes, 3 prompts on my phone
Did I approve any prompt?: No
Screenshot attached?: Yes

What it does: gives responders the minimum facts they need to check sign-in logs and block the campaign. Gotcha: include the exact address from the browser bar, not just "looked like Microsoft."

Example 2: Microsoft Entra admin action to revoke sessions after a mistaken approval

If your organization uses Microsoft Entra ID, an admin can revoke active sessions from the Entra admin center. In your provider's dashboard, go to the affected user account and use the revoke sessions option; in Microsoft Entra this is typically under Users → select user → Authentication methods or Sessions-related actions depending on the current UI.

CLI option with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "User.ReadWrite.All Directory.ReadWrite.All"
Revoke-MgUserSignInSession -UserId "user@company.com"

What it does: forces the user to sign in again so stolen sessions are less useful. Gotcha: this can interrupt the user's work immediately, so tell them before you run it.

⚠️ If you believe the attacker got in, revoke sessions before spending time on cleanup. Otherwise the attacker may stay active while you investigate.

Example 3: Google Workspace admin action to review recent sign-ins

In your provider's dashboard, open your identity admin console and review the user's recent login events. In Google Admin, this is commonly under Admin console → Directory → Users → select user → Security and the reporting/audit sections under Reporting.

If you use the Google Workspace Admin SDK from a scriptable admin workstation:

gam info user user@company.com

What it does: shows account details and can help you pivot to login and security review in environments that use GAM. Gotcha: GAM is a community admin tool, not a built-in shell command; if you do not already use it, use the dashboard first.

Example 4: Nginx redirect to a single known login portal URL

If you run an internal portal or app, reduce confusion by redirecting old login paths to one known place.

server {
    listen 443 ssl;
    server_name portal.company.com;

    location /login {
        return 302 https://auth.company.com/;
    }
}

What it does: sends users to one canonical login page so they learn the expected sign-in path. Gotcha: use 302 while testing; a 301 can be cached by browsers and make rollback annoying.

Further reading

• NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management
• Microsoft Entra documentation, the MFA and sign-in logs sections
• Google Workspace Admin Help, the login audit and security investigation sections
• MDN Web Docs, the "URI" and "HTTP authentication" sections
• CISA guidance on phishing-resistant MFA

This article was written by an AI system and published pending human review. Verify anything you intend to act on.