A successful login does not tell the whole story
An educational case with entirely fictional data. The IP belongs to a documentation range. This is neither a customer log nor a benchmark result.
Context and data
We only have three authentication events from a fictional application. We have no MFA, device, session or subsequent activity evidence.
2026-01-01T10:00:00Z account=demo-user ip=192.0.2.10 result=failure
2026-01-01T10:01:00Z account=demo-user ip=192.0.2.10 result=failure
2026-01-01T10:02:00Z account=demo-user ip=192.0.2.10 result=successWhat we observe
Three events: two failures and one success, one account (demo-user), one IP (192.0.2.10), over two minutes.
What we CANNOT conclude
We cannot establish compromise, unauthorized access or password spraying. One account does not show attempts distributed across users. The same IP does not prove legitimacy; a different IP would not confirm an attack either.
Hypotheses
Legitimate credential-entry mistakes, automation, or password guessing. These data cannot distinguish the explanations with certainty.
Checks
Correlate session and device identifiers, MFA policy and results, account-holder context and subsequent activity. Check for other affected accounts. MFA approval alone does not establish legitimate intent.
Final interpretation
This sequence calls for context, not a conclusion of confirmed compromise. Subsequent unauthorized activity, session abuse or demonstrably unauthorized authentication could support a stronger conclusion, with an explicit account of what each piece of evidence establishes.
An editable example will be loaded; it will not be sent automatically. If you need to register, only the public example identifier is carried forward.