At 12:51 PM on a Thursday in August, a manufacturer sent 543 of its customers, suppliers and general contractors an invitation to bid on a materials package.
Except the company didn't send it. Someone in Virginia did, from the company's own mailbox, using the company's own signature block — right down to the notice about the office being closed for renovations that week.
By 2:27 PM that same afternoon, the intruder was locked out permanently. By 6:24 PM, all 543 recipients had been warned. Here is exactly how that happened, minute by minute, because the details are where the lessons live.
It started with an email from someone they knew
Seven days earlier, at 12:41 PM on a Thursday, the company's shared info@ mailbox received a message titled "Request For Bid." It came from a general contractor they had worked with — a real person, at a real company, from their real email address (d*******@a*********renovations.com). Nothing about the sender was forged.
The message contained a button: SUBMIT YOUR BID →. It led to a document-sharing page hosted on a free Webflow subdomain, which in turn presented a Google sign-in screen.
An employee clicked it, hit the sign-in page, and entered the mailbox password. We know this because that employee replied to the contractor the same day, in good faith: "we are trying to download the documents and are being redirected to google sign-in. Even after signing in, the documents do not appear to download."
They didn't download because there were no documents. The page existed to collect one thing, and it got it.
This is the part most security training gets wrong. The advice is "don't click links in suspicious emails." This email wasn't suspicious. It came from a known contact, at a known company, about a completely ordinary business activity, in an industry where unsolicited bid invitations arrive weekly. The contractor's own account had been compromised first, and the attacker was simply walking down that contact list — turning each victim into the next credible sender.
Seven days of nothing
At 8:28 PM that same evening, the attacker logged in from 45.58.218.205 — a residential Charter Communications address in Leesburg, Virginia. The password worked. There was no two-step verification on the account to stop them.
Then they waited.
They came back on Saturday the 23rd at 3:08 PM to re-authenticate, and did nothing else. No emails sent, no files touched, no settings changed. Seven days of a stranger reading a company's inbox — quotes, invoices, customer lists, pricing — with nobody aware.
Dormancy is deliberate. It builds a picture: who signs off on payments, how the company writes, which relationships are warm, when the office is quiet. The renovation notice in the signature block wasn't decoration; it was a detail that made the eventual fraud read as authentic.
Thursday, 12:46 PM
The attack ran on a schedule that looks a lot like a job.
- 12:46 PM — a single test message to one recipient. Confirm the send works, confirm it lands.
- 12:51 PM — the blast. 543 unique external recipients in two batches. 537 delivered.
- 12:52 PM — one minute later, they added a Gmail block on
[email protected].
That third step is the one to sit with. Bounce notifications are how an ordinary user discovers that their account has sent mail they don't recognize. By blocking the mail-delivery daemon, the attacker deleted the alarm — buying silence that held for roughly an hour.
- 12:54 PM to 1:06 PM — five recipients replied to the bid invitation. The attacker answered each of them personally, from the real mailbox, pushing the phishing link further. Real conversations, with real business partners, conducted by a stranger wearing the company's name.
The company found out the way most companies find out: a partner said something, and an employee noticed the account behaving strangely.
- 1:07:46 PM — staff changed the mailbox password.
- 1:08:11 PM — the attacker's next login attempt failed. Twenty-two seconds.
Why the password change wasn't the fix
It felt like the fix. It wasn't, and this is the single most valuable thing in this story for any business owner reading it.
Changing a password invalidates future logins. It does not, on its own, kill sessions that are already open, and it does not touch third-party applications that were authorized before the change. An attacker with a live browser session or a connected app keeps working straight through a password reset.
The incident reached our service desk at 1:38 PM. Investigation started immediately.
- 2:19 PM to 2:27 PM — containment. Every active sign-in session was force-terminated across all devices, and all five connected third-party OAuth applications were revoked. One of them had been authorized at 1:25 PM that day — 34 minutes after the blast — with access to mail, contacts, files and calendar. Whether it was attacker persistence or a staff member reconnecting Outlook after the reset, it didn't survive the review.
Attacker access was fully severed at 2:27 PM — 49 minutes after we were engaged.
- 2:47 PM to 2:48 PM — integrity sweep of the mailbox. No hidden forwarding rules. No unauthorized delegates. No malicious filters. No rogue "send mail as" identities. Clean.
- 3:46 PM to 3:55 PM — hardening. Two-step verification enrolled and enforced. Legacy POP access, enabled and unused since the account was created, switched off. The attacker's bounce-suppression block removed — the last artifact left behind. The workstation tied to the mailbox was independently verified clean by endpoint security.
The blast radius is your customers
Containment protects the account. It does nothing for the 543 companies now holding a credential-harvesting link that appears to have come from a trusted supplier.
A recipient notification was drafted, sent to the client's leadership for written approval, and approved that afternoon. Starting at 6:17 PM — the same day — it went out in six blind-copied batches, finishing at 6:24 PM. Every message was verified in the sent folder.
The next morning, two more things happened that we'd argue are the difference between closing a ticket and actually resolving an incident:
- We contacted the general contractor whose compromised account started this — a company that isn't our client, has no contract with us, and owed us nothing — to explain that their account was being used against their own contact list, and how to secure it.
- We wrote directly to the five recipients who had corresponded with the attacker, explaining that those replies weren't from the company they thought, and what to do if they'd entered a password.
What actually caused this
Not one thing. Four, stacked:
- A shared mailbox with a shared password. Multiple staff, one credential, no accountability trail. Nobody's account, so nobody's responsibility.
- No two-step verification. A stolen password was sufficient and complete.
- A trusted-sender lure. No spam filter flags a legitimate email from a legitimate contact.
- No detection layer. The only alarm was a bounce notification, and the attacker turned it off.
The remediation followed the same list: two-step verification enforced across every account, shared-password access replaced with proper mailbox delegation so each person signs in as themselves, and an advanced email security layer recommended and quoted.
One more thing surfaced during the audit that had nothing to do with the attack. A second company domain used as a sending identity had two SPF records published at once — a configuration error that invalidates both — no DKIM signing, and no DMARC policy at all. In practice, anyone on the internet could have sent email as that domain and had it delivered. We found it, published a DMARC policy, and put it under monitoring.
If you're reading this and recognizing your own setup
Ask three questions today:
- Does every mailbox in the business have two-step verification enforced — including the shared ones? The shared ones are the ones that don't.
- Do you know what "containment" means at your provider? If the answer to a compromise is "we reset the password," sessions and connected apps are still open.
- Can your IT partner produce a timeline? Not a summary — a timeline, with timestamps, source IPs, and what was done at each one. If they can't reconstruct it, they can't prove what the attacker did or didn't reach.
We contain first, then investigate, then notify, then harden — and we document all of it, because the report is what your customers, your insurer and your attorney will eventually ask for.
If you'd like us to review how your email is secured, get in touch: [email protected] or 772-254-7114.
Details in this article have been anonymized. Timestamps, actions and technical findings are drawn from the actual incident record.