An unexpected authenticator prompt can mean someone else knows a user’s password.
It is worth treating as a warning to check the account’s sign-in methods, because the methods are where persistence can hide.
Composite case study: based on patterns observed across incident response engagements; details are blended and illustrative.
The situation
Two separate things can happen in an account takeover, and they are easy to confuse. The first is a stray approval prompt. When a user is asked to approve a sign-in they did not start, it can mean someone tried to sign in with a password they obtained. The second is persistence. A phishing page that relays the real login can capture a session that has already satisfied MFA. That session can then be used to add sign-in methods, such as an authenticator app, a phone number or a passkey, to the account. A stolen password alone typically does not allow that on an account with MFA on, but a captured session often can.
Once an unknown method is registered, resetting the password may not end the access, and registered devices can matter as well, because they may be able to obtain tokens that keep working.
In a BEC scenario, the next moves are often familiar: reading invoice threads, creating mailbox rules that hide replies, and preparing a payment-instruction change email to a customer or vendor.
What investigators typically look at
A common complication is that a legitimate new phone or device is registered around the same period through a normal helpdesk request. The method list then contains a recent entry with an innocent explanation, and the whole list can start to look explained.
A common first wrong move is to remove the one entry that looks odd and close the ticket. If the other methods stay in place, the access may continue.
How this is usually confirmed
The useful question is not whether MFA is on. It is who added each method, and from where.
- Audit log entries for security info registration and authentication method updates can show additions from a network location the user cannot explain.
- Registrations close to a risky sign-in and outside any helpdesk ticket deserve attention.
- Registered or joined devices the user does not recognize belong in the review, not just the method list.
- Mailbox rules and sent items can show a payment fraud preparation pattern.
Each method is compared with what the user can explain, and a legitimate change is matched to its own ticket and kept apart from the rest.
What it can cost
The cost is often trust and time. Teams may need to re-check recent payment instructions, contact vendors and customers to confirm which messages were genuine, and rebuild a user’s confidence in their own account. Closing the matter early can extend the exposure.
Containment
Order matters, because someone holding a valid method or password can mint new tokens right after a revoke. Treat the steps below as one prompt action, with as little time as possible between them, not as separate phases.
1. Remove the unknown authentication methods and the unrecognized registered devices, reset the credential, and revoke the user’s sessions and refresh tokens in the same sitting.
2. Check again afterward that no new method or device has appeared.
3. Require re-registration from a trusted location using a temporary access pass, which an administrator issues only after the sessions have been revoked and the account is confirmed clean.
4. Remove malicious mailbox rules and forwarding, and review sent items.
5. Capture the audit log and mailbox evidence in parallel with these steps, not before them.
6. Verify payment-instruction changes by phone, using a number already on file.
A conditional access policy on security info registration can then be tightened so that changes require strong authentication and a trusted location or compliant device.
Lessons
- A new method is often the persistence step, so it is worth treating as a security event.
- Removing one method is rarely a complete cleanup. Review the full list, and the device registrations too.
- A legitimate change can make a malicious one look normal. Match each entry to its own ticket.
- Restrict where and how security info can be registered, and alert on new methods.
- Ask what the mailbox was used for, not only whether the account is now locked.
Checklist for your next incident
- List the authentication methods and registered devices on the account.
- Match each entry to a ticket or a person who can explain it.
- Remove unknown entries, reset the credential and revoke sessions together.
- Check again after revocation.
- Review mailbox rules, forwarding and sent items.
- Re-verify recent payment-instruction changes out of band.
- Re-register using a temporary access pass from a trusted location.
Message us to talk through your account takeover recovery plan.
Discover more from Core-Infosec
Subscribe to get the latest posts sent to your email.
