The SOC escalates: a finance team member's account authenticated successfully from an IP in a country the company has no presence in, at 03:00 local time. MFA was satisfied. No alerts have fired since. What do you do, and what do you tell the SOC lead?

I would resist both the instinct to dismiss it and the instinct to declare an incident, and spend twenty minutes establishing which it is.

Hypotheses first, and I would write them down because the benign ones are the ones that get skipped: the user is travelling or using a personal VPN; a mobile carrier is routing traffic through an unexpected egress; the company has a roaming or cloud egress in that region that nobody documented; the account is compromised via stolen session token; or the account is compromised via credential theft with MFA defeated.

The MFA point matters and I would raise it explicitly with the SOC lead, because "MFA was satisfied" is often treated as exculpatory and should not be. Session token theft bypasses MFA entirely — the attacker replays a valid session and never re-authenticates. Adversary-in-the-middle phishing kits proxy the MFA challenge in real time. MFA fatigue and SIM swap are also live. So satisfied MFA lowers the probability of a simple credential stuffing case; it does not lower the probability of account takeover much at all.

Then evidence, in this order. The account baseline — where does this user normally sign in from, on what devices, at what hours. A single anomalous location for a user who never travels is very different from one for a user who signs in from four countries a month. The device and user agent: is it a known enrolled device or something new? The authentication detail: was this a fresh interactive sign-in or a token replay, and was the MFA satisfied by the user's registered method or by a newly registered one?

That last point is the one I would chase hardest. Registration of a new MFA method around the time of an unusual sign-in is close to a definitive account takeover signal, and it is also the persistence mechanism, so it changes what containment has to do.

Post-authentication activity next: mailbox rules created — especially forwarding or auto-delete rules, which are the classic business email compromise move — OAuth application consents granted, unusual file or SharePoint access, group membership or privilege changes, and any password or recovery method change. The absence of alerts since is not reassuring; most of these actions do not alert by default.

Then breadth: did any other account authenticate from that address or that ASN, in this window or historically? And characterise the source — is it a hosting provider, a commercial VPN exit, a residential proxy service, or a normal consumer ISP? A residential proxy is meaningfully more concerning because that is what is used to defeat impossible-travel and geo-based detection.

Role changes the priority. This is a finance user, so business email compromise and payment redirection are the specific risks, and I would check for any in-flight payment or invoice changes rather than treating it as a generic account.

What I would tell the SOC lead: what we observed, what we do not yet know, and a recommendation with a confidence level attached — for example, "this is possibly a legitimate sign-in but I cannot rule out token theft; I recommend we revoke sessions and require re-authentication now, which is low cost and reversible, while I check the mailbox rules and MFA registration history". I would also make sure we preserve the sign-in and mailbox audit logs before anyone starts resetting things, because containment destroys evidence.

Escalation to a declared incident depends on what the post-authentication check finds, and I would say when I will come back with that.