Why Does Phishing Still Get Through When It Looks Like Work?

A project inquiry comes through your website, and it looks like the fifty inquiries before it. You reply, because that is what a real lead gets. 

The prospect says he would rather use his own scheduler instead of yours, which happens often enough that nobody thinks twice. The scheduler asks for a Google login. That feels a little strange, but not impossible; plenty of legitimate tools gate access behind an existing account. 

The page looks real, the lock icon looks right, and the certificate information checks out when you glance at it.

That is the design of the attack, not a flaw in it. 

Modern phishing does not need to look perfect. It needs to look normal long enough for one more person to keep moving through a workflow they were already in, and for agencies, software companies, and service businesses, the attacker is not interrupting the work. 

He is imitating it, inside the same channels you depend on to grow.

‍

Who Actually Falls for This?

The people who fall for this are usually the ones who already know the rules: they read URLs out of habit and check a certificate before they trust one. 

They get pulled in anyway because the request arrives exactly where a real one would, at the tail end of a normal lead conversation, after several legitimate-sounding questions, from someone who has already earned a little trust. 

If a person who knows the rules can still get two steps into a credential-harvesting flow before something catches it, individual carefulness was never going to be the whole plan.

At a growing agency or software company, that is not a hypothetical. 

You are usually running lean, without a security team to catch what a person misses, while holding a dozen clients' logins across email, file storage, a CRM, and a code repository. 

There is rarely a clean line between "our risk" and "their risk" at that size. 

One compromised login is not a line item. 

It is the trust a client handed you along with their data, and the account you cannot promise to protect if you cannot say with certainty who else has access to it.

‍

What Is a Browser-in-the-Browser Attack?

A browser-in-the-browser attack is a fake login window drawn entirely inside a webpage, styled to match a real pop-up from Google, Microsoft, or whatever brand a workflow calls for, complete with an address bar and lock icon that no actual browser ever generated. 

The scheduler in a scenario like the one above runs exactly this. 

There is no browser chrome behind it. It is a picture of one, built to fool the person checking for the picture.

Silent Push documented an active version of the technique in March 2025, run against Counter-Strike 2 players through fake pop-ups spoofing Steam and the eSports brand Navi. The tell was not visual, it was structural: the windows could not be dragged outside the page, maximized, or minimized, because they were never separate windows to begin with. 

Menlo Security's 2025 State of Browser Security report found a 140 percent surge in browser-based phishing over the prior year, with roughly 75 percent of phishing links now hosted on trusted domains like AWS and Cloudflare instead of the sketchy ones people learned to spot. 

The attack does not ask you to ignore a warning sign. It hands you a fake one and lets you check it yourself.

‍

Why Are Agencies and Service Businesses the Target?

Agencies and service businesses run on inbound trust: a contact form, an RFP, a scheduler link, a shared Drive file, a DocuSign envelope, an invoice, a calendar invite, a job applicant's portfolio. 

Each one is a point where someone on your team is trained to respond fast and stay easy to work with, and each one is a point an attacker can occupy without building anything that looks like malware.

A lead becomes an email. 

The email becomes a scheduling link. 

The scheduling link becomes a login prompt. Each step inherits the trust of the one before it, and by the third or fourth handoff nobody is evaluating the request fresh, because momentum has replaced judgment and nobody wants to be the one slowing down a real prospect. 

The handoff is where these attacks land, not the first email, and it is also where the decision gets made without anyone feeling like they made one.

‍

Why Doesn't Security Awareness Training Stop This?

Security awareness training does not stop this because the attacks are built for people who already follow it. 

The standard advice still holds: watch senders, question urgency, avoid unexpected login prompts, turn on MFA. 

None of it stops a password from landing in a fake window when the attack arrives inside a normal workflow, wearing a familiar brand, showing the exact signs people were taught to trust.

Awareness is a real layer. It is just not the whole plan. 

A process that depends on every employee catching every convincing fake, every time, is one distracted afternoon away from failing, and growing companies run on distracted afternoons.

‍

How Do You Build the Safe Path Into the Workflow?

The more durable fix is structural: make the safe option the default, not the one that requires a judgment call under time pressure.

• Route unknown prospects to your own scheduler instead of theirs.
• Open Google, Microsoft, or Dropbox directly in a new tab instead of through a link someone else sent.
• Confirm anything unusual through a second channel.
• Name one person or role who reviews a request that feels off, instead of leaving that call to whoever happened to open the email.

The systems underneath those workflows carry less of that risk by design, not more. 

We saw the same idea from a different angle when we rebuilt the operations platform for Witherspoon Rose Culture, a wholesale rose grower running orders, inventory, spray mix tracking, and month-end financials across a stack of disconnected tools. 

A single purpose-built system with defined roles for field staff, office admin, and finance means fewer standing logins scattered across e-commerce, spreadsheets, and email, and fewer places where one compromised password reaches further than it should. 

We believe that business is built on transparency and trust, and that good software is built the same way, and a system with too many unnecessary doors is not one you can call trustworthy, no matter how careful the people using it are.

‍

What Does MFA Actually Stop, and Where Does It Stop Working?

MFA does exactly what it is supposed to do: it stops a correctly entered password from becoming account access on its own. 

It has a limit too, and the phishing-as-a-service kit Tycoon2FA shows exactly where. Microsoft's security team reported in March 2026 that Tycoon2FA has powered campaigns sending tens of millions of phishing messages to more than 500,000 organizations a month, sold to attackers for as little as $120 for ten days of access. 

It works by sitting between the victim and the real login page, capturing the password and the MFA code in the same pass, then stealing the session token that comes back, which hands the attacker a live, authenticated session that survives a password reset unless someone explicitly revokes it.

When MFA is simply missing, the downside compounds fast. In February 2024, attackers used compromised credentials to reach a Change Healthcare remote-access portal with no MFA enabled at all. 

Ransomware followed nine days later, claims processing for a company that touches roughly one in three American patient records went dark for over a month, and providers were left struggling to make payroll while the industry waited for systems to come back online. MFA earns its place as the baseline. 

The sessions, the recovery settings, and the stale admin accounts sitting behind it still need someone paying attention.

‍

What Do You Audit After a Phishing Attempt?

A phishing scare should trigger a full operational review, and that review has a shape.

• Accounts. Change the password through a trusted path, revoke active sessions, and check recent login activity and recovery settings.
• Email. Review forwarding rules, filters, and delegated access for anything added without your knowledge.
• Connected apps. Check third-party OAuth grants tied to Google Workspace, Microsoft 365, the CRM, and the website platform.
• Admin access. Confirm who still has rights across file storage, the CMS, code repositories, and billing, and remove former employees and shared logins while you are in there.

None of that happens if the person who clicked stays quiet out of embarrassment, and the delay is what turns a near miss into an incident. 

Treat a fast report as good judgment every time, not a mistake to manage, because the people who report fast are the ones protecting the company.

‍

What Should You Change This Week?

• Route unknown prospects to your own scheduler, and tell the team not to log into anything through a scheduling link a prospect sent.
• Turn on MFA everywhere it matters, then check whether any one account has more access than its role requires.
• Review recent Google or Microsoft admin activity and audit connected third-party apps.
• Remove stale users and permissions tied to former employees or old vendors.
• Name the person or role who reviews suspicious inbound requests, and write down what happens in the first hour after someone clicks.

Phishing arrives now as a lead, a meeting request, a shared file, or the next normal step in a deal you actually want to close, which is exactly why it works. 

For a growing agency or software company, the cost of getting this wrong is not abstract. It is the client conversation you do not want to have, the access you cannot fully account for, the trust that took eighteen months to build and one login to put at risk. 

The companies that handle it well build the safer option into the workflow itself, ahead of the moment anyone needs vigilance to save them: fewer standing logins, clearer ownership of access, a fast path for reporting instead of a slow one built on fear of blame. 

The click was never the real vulnerability. 

The workflow around it was, and that is the part you can actually fix.