The message came from a real company. The sign-in that followed did not.

What happened

A member of the office staff at a small organization we protect received an email from a firm their business had worked with for years. It said a protected message was waiting, with a button to view it. Notifications like this arrive from legitimate services every day, and this one carried a real name, a real relationship, and no spelling mistakes.

The button led to a convincing sign-in page. It was not the real one.

What gave it away

Not the email. The email passed every surface test, because it came from the trusted firm's genuinely compromised account. What gave it away was what happened next: a sign-in attempt on the staff member's account that did not look like the staff member. Wrong place, wrong device, wrong pattern. The layer that checks every sign-in, around the clock, raised its hand.

What we checked

• Sign-in history for the account: where from, what device, what time, and whether the attempts matched the person's normal pattern
• Mailbox rules, because attackers who get in quietly add rules that forward or hide mail
• Registered authentication methods, to confirm nothing new had been added to keep a door open
• The original message's routing headers, to establish whether the sender was spoofed or genuinely compromised
• Whether the same lure had reached anyone else in the organization
• Account activity logs for the window in question, to establish what, if anything, was touched

What we found

The password had been captured by the fake page. The attempt to use it came quickly, from infrastructure with no relationship to the staff member. The extra verification on the account did its job, the attempt failed, and the monitoring flagged it. No mailbox rules had been planted, no new sign-in methods had been added, and the activity logs showed nothing was reached.

The sender was not spoofed. A real firm's real account had been compromised, which is why every authentication check on the email passed. That detail matters: it is the version of this attack that filters alone cannot stop.

What we did

• Locked the account, reset the credential, and ended every active session
• Verified, rather than assumed, that no persistence was left behind
• Told the staff member plainly what had happened, without blame
• Checked every other account in the organization for the same lure and the same sign-in pattern
• Let the compromised firm know through a known-good channel, so their other contacts were not next
• Kept a closer watch on the organization's sign-ins in the days that followed

What changed afterward

Sign-in protections were strengthened across every account in the organization, not just the one involved. Sign-in policies were tightened against the specific pattern used. And the incident, anonymized, became part of how staff there are trained: the next suspicious message at that organization was forwarded to us before anyone clicked it.

What another business can learn

• "Protected message" is the costume of the moment. Document-share and secure-message notifications are the current favorite disguise, because real ones look almost identical. Verify by a channel you already trust before signing in anywhere.
• A password alone should never be enough. Extra verification turned a stolen password into a failed attempt. Without it, this note would be much longer.
• The email that passes every check can still be hostile. When a real partner's account is compromised, sender checks all pass. The tell is behavioral: an unexpected message type, an unfamiliar sign-in page, a request that breaks routine.
• Detection speed is a property of the system, not luck. Someone has to be checking sign-ins at the moment a stolen password is used. Hours matter. Ask whoever protects you who is checking, and when.