Real 84EM email is only @84em.com

The $45K RFP That Was Actually a Phishing Operation

A few months ago, someone sent a message through my contact form. Legit email address, legit website, and a legit-looking 12-page RFP with a $45K budget. A site build and performance project where the previous vendor had walked away, leaving $30K of budget on the table.

I looked into the company. Real overseas e-commerce operation, VAT registration and all. The RFP read like it was written by someone who knew what they were buying.

Fake RFPs come through my contact form regularly, so every inbound like this is unproven until it survives vetting. This one was surviving. I kept it moving because I wanted to see where it went.

The courtship

We exchanged several rounds of email clarifying points of the RFP. Every response was well written and professional. He’d gone through my case studies and called out specifics he was impressed by.

The one oddity was an outlook.com email address. Plausible, if he really was the marketing contractor he claimed to be. I noted it and kept the conversation going.

We agreed on next steps. A cursory look at the existing build to vet the project, then paid discovery.

The turn

Then came staging access. He said he’d need my Google email address to add me to their whitelist.

The phrasing was off, and it moved him from unproven to suspect. But he already had my email address, so confirming that [email protected] was my Google account gave him nothing. I wanted to see the next move.

The next move was a link to a WordPress staging site, with instructions to use the Google login button, not the WordPress login.

There it was. Nobody who runs a staging environment tells you which login button to click.

The catch

I wasn’t going to click that button, but I did want to see what they’d built. So I copied the Google login button’s link and opened it in an incognito window. This is what came up:

A fake Google sign-in window rendered inside the browser page. It imitates a Chrome popup, including a fake address bar showing accounts.google.com with a padlock icon, a Google logo, the heading Verify your identity, and a blue Next button.

Convincing, except Google sign-in doesn’t present itself as a browser window inside your browser window. That fake Chrome popup, complete with a fake address bar showing accounts.google.com and a fake padlock, is a technique called browser-in-the-browser phishing. The “window” is HTML. The padlock is a drawing of a padlock.

I viewed the frame source. The modal was hosted on a .click domain. Then I took a harder look at the staging URL itself: it was one character off from the company’s real domain. Someone had registered a typosquat of a real business and built a fake staging site on it.

Add it up. A real company used as cover. A professionally written 12-page RFP. Weeks of patient correspondence. Flattery calibrated to my own case studies. All of it engineered to get one developer to type his Google Workspace password into a fake modal.

I reported both domains to Google Safe Browsing and blocked the address. Their investment: weeks. Their payoff: nothing.

It wasn’t isolated

That was the most sophisticated attempt I’ve seen. It wasn’t the only one.

Four other fake RFPs have come through my contact form in recent months. Less effort behind those: the follow-up emails were fine, but a LinkedIn search showed no record of the sender working for the company they claimed to represent.

In late 2024, a hiring manager at WP Engine received a resume from someone claiming to own 84EM. He found the claim implausible, looked through this site, and reached out through my contact form to verify. Five minutes of checking on his end unraveled it.

And last week, someone impersonated 84EM directly, emailing one of our clients from a lookalike Gmail address with a pitch for WordPress maintenance work. The client caught it and flagged it. Full details, including the email itself, are on the security notice page.

The tells are gone

Notice what’s missing from every one of these: broken English, ugly design, implausible stories. The tells that used to filter scams out for you.

AI did that. The same tools I use every day to write code and draft documents also write clean follow-up emails and build pixel-perfect login pages. I’m not going to pretend AI is the villain. It’s a tool, and scammers upgraded their tooling like everyone else did.

What it means practically: instinct isn’t enough anymore. Instinct works on tells, and the tells are gone. What still works is verification, and verification is a habit, not a talent.

The habits

Here’s what caught these, and what’s worth making automatic:

  • Read the domain character by character. Typosquats survive a glance. They don’t survive a careful read.
  • Verify people through an independent channel. If someone claims to work for a company, check LinkedIn or call the number on the company’s website. Don’t use contact info they gave you.
  • Never authenticate through a link someone sent you. If a legitimate service needs you to sign in, go there yourself and sign in.
  • Know the browser-in-the-browser tell. A real sign-in popup is a real window you can drag around your screen. A “window” that’s stuck inside the page is HTML pretending.
  • Slow down the moment credentials or money enter the conversation. That’s the destination of every long con. Everything before it is setup.

None of this is sophisticated. That’s the point. The person behind that RFP spent weeks building the con, and it fell apart in about ninety seconds once the login ask arrived, because the checks are cheap and they don’t care how good the story is.

They’ll have to try harder next time.

Need some help?

Reach out and describe your project.

Folks We've Helped