Case Study · Incident Response
A typosquat domain — registered the same day its first email went out — cost a Las Vegas business’s customer over forty thousand dollars. Here is how it happened, what we did, and what every business should know.
On a Tuesday morning earlier this year, our phone rang. A long-time client — a Las Vegas business we’ve supported for years — had just gotten a panicked call from one of their own customers. The customer had paid an invoice for over forty thousand dollars. The money had gone to a bank account that wasn’t our client’s. And the emails the customer had been corresponding with for the past two months — the ones that gave them the new wire instructions — weren’t from our client at all.
We were on the case within minutes. By the end of the same afternoon, we had a working answer. By the next morning, we had a full report.
This is a story about how good security work looks when something goes wrong. It is also a story about a very modern kind of theft — one that doesn’t require breaking into anything at all.
Our client had a perfectly ordinary, perfectly authentic billing email thread going with their customer. A real outstanding invoice. A real billing contact at our client’s company. A real accounts payable contact at the customer’s company. Nothing exotic.
This is the most important thing to understand about modern email fraud: it does not need to forge a relationship. It only needs to insert itself into one that already exists.
A little over a week after the most recent legitimate email in that billing thread, an attacker registered a new domain. The new domain was identical to our client’s real billing domain except for a single letter swap — two characters traded places. Read it on a phone, in a hurry, with hundreds of other emails in your inbox: it looked exactly right.
Within hours of registering that domain, the attacker sent the first impersonation email. They used the right invoice number. They referenced the right people. They wrote in a tone that matched the real billing voice. And they introduced a small, plausible request: “we are doing a year-end audit, please redirect this payment to a secondary account.”
Two weeks later, when the customer had grown comfortable with the imposter, the attacker delivered the new bank details. The customer wired the money. Two months passed before anyone realized what had happened.
Here is where most security stories go wrong. When a client calls and says “money is missing and we don’t know how,” the temptation is to do something dramatic. Force a password reset on every account. Lock down every mailbox. Terminate every session. Make it look like you are fighting back.
We did none of that.
The reason is simple: those actions only make sense if someone is currently inside the system. We had no evidence of that yet. Acting first and asking questions later would have disrupted our client’s entire business, alarmed every other customer who saw the chaos, and worst of all, obscured the actual root cause. So we did the unglamorous thing. We investigated.
For each affected mailbox in our client’s environment, we pulled the full login audit log and checked every authentication event for the relevant time period. Where each login came from. Which device. Which browser. Whether multi-factor authentication was challenged. We pulled the OAuth grant log to see if any third-party application had been authorized to read mail. We pulled the rules and filters log to see if anyone had quietly added a forwarding rule or a delete-on-arrival filter. We pulled the user-account audit log to see if recovery contacts, recovery phone numbers, or two-step verification settings had been changed. We checked the security alert center for any anomaly the platform itself had flagged. And we tested whether the legitimate billing thread had been accessed by anyone outside the expected internal recipients.
The attacker had never been inside our client’s environment. They did not need to be.
The attack relied on something far simpler than a hack: a typosquat. The attacker registered a domain visually almost indistinguishable from our client’s real billing domain — close enough that nobody, on either side, noticed.
What is notable is which domain they chose to mimic. Our client uses two domains: a primary corporate domain that everyone knows, and a secondary, customer-facing billing domain that only their actual customers ever see. The attacker chose to typosquat the secondary one. That is not random. That is reconnaissance. Whoever did this knew exactly what address the customer was used to seeing in their inbox.
Public domain registration records confirm a chilling timeline: the attacker registered the lookalike domain in the morning and sent their first impersonation email that same evening. The infrastructure was bought, configured, and weaponized in a single business day.
Where did the reconnaissance come from? We were unable to determine the exact source from inside our client’s environment alone, because we ruled their environment out. There are several possible explanations, and the most common pattern in this kind of fraud is that someone with visibility into the legitimate billing thread — on either side — had a compromised mailbox somewhere in their broader email ecosystem. From inside any compromised mailbox in the conversation chain, an attacker would see the full thread: who emails whom, about what, in what tone, with what invoice numbers. Everything they needed.
That is not a comfortable conclusion. But it is an important one. Vendor-impersonation fraud is not always preventable on your side alone. Sometimes the leak is somewhere else in the supply chain entirely. The job is to make yourself a hard target, and to make sure that when something does happen, the answer comes back fast and clear.
Within the first afternoon, our client had:
By the next morning, they had a formal incident report they could hand to their customer’s leadership team — complete, professional, and factual. Not a hot take. Not a guess. A document that stood up to scrutiny.
You do not have to be a target to become one. These are the steps that meaningfully reduce the chance of being on the wrong side of this story.
One sentence in your invoice footer: “We will never request a change to payment instructions by email. Verify any redirect by phone to a known contact.” This single line protects every customer you have. It costs nothing.
Not optional. Not “available.” Required. Particularly on every mailbox in finance, accounting, and executive roles. For the highest-risk accounts, hardware security keys close the gap that authenticator apps leave open.
If a vendor or customer says their banking has changed, the verification needs to be a phone call to a number you already had on file — not a number from the email itself. Build the friction into your accounts payable process, not into the moment of the request.
If your domains do not have a DMARC policy of p=quarantine or p=reject, attackers can spoof you directly. The publishing fix is small. The protection it provides is enormous.
Free tools like dnstwist can generate every plausible look-alike of your domain in seconds. A periodic check for newly registered look-alikes is cheap insurance — and means you find the typosquat before the customer does.
The finance team needs targeted, specific training on vendor-impersonation patterns. Generic phishing training will not do it. They need to know the pretext words to watch for: year-end audit, secondary account, urgent change, treasurer’s instruction.
We are a Las Vegas veteran-owned, minority-owned MSP, and we have been doing this since 2002. When you call us, you reach a real person — not a phone tree, not a call center. If your business needs an IT partner who can investigate calmly when something goes wrong, let’s talk.
