Microsoft Logs Missing for Hours After Attack
Detecting a compromise minutes after it happened without a complete record of how the attacker got in
An Incomplete Attack Timeline from Microsoft
We recently detected an adversary-in-the-middle (AitM) phishing attack where Microsoft published the audit logs 6 minutes after the attacker got in, Petra ingested the logs 24 seconds later, and alerted 2 seconds after that (curious about Microsoft’s 6 minute delay? Here are the numbers).
However, Microsoft’s logs didn’t give us the full picture until nearly 20 hours later.
What Actually Happened
Here’s the timeline:
2025-02-25 6:34:50 PM: Attacker got password wrong
2025-02-25 6:36:01 PM: Attacker got password right, was prompted to input MFA code
2025-02-25 6:36:35 PM: Attacker entered correct MFA code
What We Saw a Few Minutes After the Attack
Microsoft published the first sign-in related to this attack about 6 minutes after it happened. At first, we didn’t see any of the failed sign-ins, and only saw the single successful sign-in:
What We Saw a Few Hours After the Attack
About 2 hours after the attack occurred, the sign-in labeled UserStrongAuthClientAuthNRequiredInterrupt was finally emitted by the API.
Note: Microsoft’s docs on UserStrongAuthClientAuthNRequiredInterrupt are not super clear, but this code is emitted when an MFA challenge is issued.
What We Saw 20 Hours After the Attack
It was almost 20 hours after the attack that the log labeled InvalidUserNameOrPassword came in:
Takeaway: Logs are Often Missing In the Minutes After an Attack
If you’re triaging alerts or doing forensic work for M365 environments, beware that you may not have the whole picture for up to a day after an attack.
Logs are often delayed and arrive out-of-order. If something’s not quite adding up, these delays are likely why.
This makes it even more important to comprehensively analyze all the telemetry that is available to you in a timely manner. The more context you gather, the better you can spot missing pieces and form a complete understanding of the incident.
If you're ever brainstorming how to strengthen your processes to better handle these delays, you can find me at [first name] [at] petrasecurity.com.