Business email compromiseIdentityEmailMid-size company · Microsoft 365 · 2 accounts · resolved
The inbox rule named "."
An attacker working from a commercial VPN exit spent two days turning one weak password into tenant-wide persistence. The rule that gave them away had a single-character name and no conditions. It deleted every incoming message to the admin mailbox, silently.
36 minEscalation to contained2Accounts, 1 rule, 1 app secretRestoredEvery deleted message
Read the timeline
Day 1 · 18:11A password attack against a staff mailbox succeeds. Guard logs the pattern, the lead stays open.
Day 2 · 22:43The same address sends mail from that mailbox and reads existing threads. Foothold confirmed on the lead.
Day 3 · 15:07The address fails, then succeeds, against the tenant admin mailbox. The lead escalates.
Day 3 · 15:08An inbox rule named "." is created: delete every message, stop processing further rules, no filter. Guard fires on rule creation. A case opens.
Day 3 · 15:22The same session rotates secrets on a service principal. Query ties the session, both mailboxes and the VPN address together in one place.
Day 3 · 15:43Both accounts disabled, sessions revoked, the rule deleted, the address blocked, app secrets rotated, deleted mail restored. Comms to the customer with the full chain.
What changed after. The customer's conditional access now blocks commercial VPN ranges outright, and inbox-rule creation on privileged mailboxes is a confirmation event, not a log line.
Account takeoverIdentityHealthcare provider · Microsoft 365 · 1 account · resolved
MFA passed. The token was stolen anyway.
A sign-in that looked legitimate on every checkbox: right user, MFA satisfied, familiar app. What didn't fit was everything around it. The session token had been lifted from the user's browser by a look-alike sign-in page, so the attacker never needed the password or the second factor.
24 minFirst flag to disabledMFA passedToken stolen anywayRe-enabledNext morning, fresh credential
Read the timeline
00:09Guard flags a Microsoft 365 sign-in: new device fingerprint, new network, hours outside the user's pattern, on an account with access to patient scheduling.
00:13A case opens as "Confirmation needed." The record already holds the sign-in, the user's 30-day baseline and the token issue time.
00:21The token's issue time predates the sign-in by hours and matches a visit to a lookalike login page in the proxy logs. Determination: stolen session token.
00:24Account disabled, sessions revoked, device unregistered. Comms sent to the customer's IT lead with what to tell the user.
Next morningThe customer confirms the user never authorized the device. Account re-enabled with a fresh credential and a new phone enrollment. Case resolved.
What changed after. Token-theft indicators now carry extra weight on this tenant's identity rules, and the BAA-covered accounts get a tighter sign-in baseline.
Social engineeringEndpointConvoy AgentMid-size company · Windows · 1 host · resolved in 35 minutes
A fake prompt and a pasted command.
A fake "verify you are human" page told a user to press Windows+R and paste a command. They did. The command pulled down a second program through a built-in Windows tool. The whole thing is designed to look like the user's own action, because it is.
35 minPaste to resolved1 host0 second stage2 rulesFired on the same paste
Read the timeline
18:36Convoy Agent records a shell launched from the Run dialog with download and pipe content in the command line. Two rules fire: one on the Run dialog history, one on the download through a built-in tool.
18:37Two leads, one case. The host is isolated. The user's account stays enabled pending a human read of the record.
18:44Query finds the referring page in the proxy logs and no other host with the same Run dialog history entry. Nothing else ran after the download.
19:12Download removed, isolation lifted, case resolved. Comms to the customer with the page URL to block and a two-line note for the user.
What changed after. Nothing on the platform side. The rules were already there. The customer added the lookalike page's domain pattern to their web filter the same afternoon.
The one we got wrong firstEndpointJudgmentDemo environment · Windows RD Web server · 1 admin account · closed, no action
A remote admin tool, as SYSTEM, on a production server. Twice. By the right person.
An admin-companion account ran a remote admin tool as SYSTEM from a Downloads folder on a remote-access server. Two earlier leads had escalated the same pattern on the strength of one claim: that the account did not exist in the directory. The third investigation checked the claim instead of inheriting it.
No actionThe right call, the third time2Prior escalations overturned68 minOf telemetry read before deciding
Read the timeline
19:08:21Guard fires on a remote admin tool starting cmd.exe as SYSTEM from a user profile on an RD Web Access server. The lead inherits two prior escalations on the same host and account.
19:17Case opens. The prior determination says the account is not in Active Directory, therefore forged.
19:40The claim is re-tested. The base user exists. The ".adm" suffix is the customer's standard admin-companion convention. Thirty days of baseline show the same profile installing ordinary software and running a daily scheduled cleanup.
20:1568 minutes of post-detection telemetry on the host: five process creations, no remote targets, no credential tooling, no persistence. Self-elevation, not lateral movement.
OutcomeDo not isolate. Comms to the customer asking whether running admin utilities from a Downloads folder on that server is sanctioned. Two prior escalations annotated as a self-reinforcing chain built on one unverified claim.
What changed after. "Account not found" from a single enrichment lookup is no longer treated as proof of a forged account anywhere on the platform. It is now a prompt to look again.
EDR tamperEndpointThird-party EDRPayments company · third-party EDR · 1 admin · closed, authorized
Someone pulled the EDR uninstall token.
Convoy watches the other EDRs too. Revealing an uninstall token is the step before removing an agent from a host, which is the step before the host goes dark. It is also what an admin does before a planned migration. The record has to tell the two apart quickly.
4 minTo the questionAuthorizedClosed next morningCoveredConvoy Agent on the host either way
Read the timeline
00:02Guard flags a protection-tamper event from the third-party EDR: an uninstall token revealed through the console, overnight, for a host in the payments segment.
00:04Case opens as "Confirmation needed." The record pairs the console action with the admin's own sign-in, device and a change ticket referenced in the customer's knowledge base.
00:06Comms to the customer's on-call: who did this, from where, and the question. No action taken, because the host is covered by Convoy Agent either way.
MorningCustomer confirms a scheduled agent migration. Case closed as authorized, with the confirmation on the record for the next audit.
What changed after. The customer's migration runbook now opens a Convoy case first, so the question is already answered when the token is revealed.
Timelines are taken from case records and condensed. Organizations, people, hosts and addresses are altered. Durations are real.