Meridian: 62-message credential phish, three compromised accounts, and a manual pull decision

14:45–14:50 - stop the bleeding at the edge before touching mailboxes.

1. Block the phishing domain and URL in URL Defense so any not-yet-clicked message is neutralised at click time, and add the sender domain to the inbound block. Do this before pulling, because pull takes minutes and clicks take seconds.
2. Record the indicators in the incident ticket: sender address and domain, subject, URL, registration date, first and last delivery timestamps.

14:50–14:55 - scope before you purge. Query message tracking for the sender domain and the exact subject across the full window, sender and recipient side, and reconcile the count against the reported 62. You need the true recipient list to pull correctly and to know whether the campaign went beyond the 41 already identified. Do not purge on the assumption of 62.

14:55–15:05 - contain identities, which outranks message cleanup. 3. Reset the three passwords and revoke active sessions and refresh tokens; a password reset that leaves the attacker's session alive is theatre. 4. Remove the forwarding rule on the affected mailbox and capture it as evidence first (screenshot/export). 5. Check the three mailboxes for the classic post-compromise markers: new inbox rules, mailbox delegation, MFA method changes, OAuth application consent, sent items, and any mail sent to the Gmail forward address.

15:05–15:15 - pull the campaign. 6. Execute the TRAP pull for the confirmed indicator set across all recipients found in step 2. This is a good case for pull: the campaign is confirmed malicious, indicators are unique, volume is small, and leaving messages lets more users click. 7. Notify recipients: a short, specific message - what arrived, what to do if they clicked, how to reach the SOC.

Throughout: timestamp every action in the ticket; the timeline is the deliverable if this becomes a reportable incident.

Why manual was chosen, and its cost. Auto-pull is irreversible from the user's perspective: messages vanish from mailboxes, including from users who had already acted on them and from anyone who legitimately received a similar-looking message. If the indicator set is wrong - a shared sender domain, a subject line reused by a real supplier, a URL that later turns out to be a marketing redirect - the pull becomes the incident. Manual mode also preserves evidence in place while an analyst confirms scope.

Why manual is the wrong default for this class of campaign. A credential phish has a click window measured in minutes. Between the 14:40 report and the 14:45 SOC start, the attacker already had the credentials. Every minute a confirmed-bad message sits in an inbox is additional exposure, and a human in the loop at 02:00 on a weekend is a bottleneck, not a control.

Bounded operating model:

1. Automatic pull for high-confidence, machine-derived indicators only - URL Defense and attachment sandbox verdicts at the malicious end, confirmed sender-domain blocks, and TRAP campaigns the SOC has explicitly marked 'auto'.
2. Manual for anything analyst-derived - subject-line matches, display-name impersonation, user reports, and any indicator that could plausibly cover legitimate mail.
3. Pre-pull guardrails: a domain allowlist that can never be pulled, an automatic exclusion for internal senders, a size cap that escalates to a human above, say, 500 messages, and a second-approver requirement for org-wide scope.
4. Evidence preservation: pulls remove the message from the mailbox but must not remove it from logs. Verify retention before enabling auto, and export the message list to the ticket automatically.
5. Reversibility: document how to restore a pulled message, and test it. Restores are rare but their absence turns a false positive into a data-loss event.

Review the auto-pull log monthly against user reports to check that automatic pulls are not quietly deleting legitimate mail.

The MFA prompt storm. After revocation and reset, legitimate clients will re-prompt - some of that is expected. What matters is whether the prompts are unexpected:

• Check MFA registration state on the account. If a new authenticator or phone number was added during the compromise window, the attacker may be attempting to re-enrol after the reset. Compare the registered methods against the pre-incident record.
• Check sign-in logs for successful authentications from the same IP ranges or user agents as the phishing session, especially any that succeeded after the reset. A successful post-reset sign-in from those IPs means either revocation did not cover a token type or there is a second entry point.
• Check for OAuth consent grants issued to any application in the compromise window. An illicit consent grant survives a password reset entirely, and the symptom the user notices may be prompts from the attacker's own attempt to re-consent.

The second email to a colleague. This is the more important finding, because it says the campaign is still live or was re-launched:

• Compare the new message to the original: same sender domain, same URL, or a new-but-similar domain? If the domain changed, the block did not cover it and you need registration-monitoring or a lookalike rule rather than another one-off block.
• Check whether the message arrived from an internal account (i.e., sent from a compromised mailbox) - that changes the scope from 'phishing campaign' to 'active intrusion with internal sender'.
• Re-run the message-tracking query for the full window and both indicators to confirm no additional deliveries were missed on day one, and to check whether the second wave was delivered before or after the block was applied.

Implication either way: the incident is not closed. Keep it open until at least 24 hours pass with no new deliveries and all three mailboxes have a clean post-reset sign-in review.