Could an attacker create access that survives a password reset?¶
Yes. An attacker can create access that survives a password reset.
They may retain active sessions, refresh tokens, trusted devices, delegated applications, recovery methods, API keys, service accounts or newly created users.
What this means in practice¶
An attacker may deliberately create persistence before the account holder becomes aware of the compromise. They may add an application with long-term access, register a new authentication method, create a forwarding rule, add an administrator or issue a technical credential.
Investigators should build a timeline from the first suspicious access and examine every security or configuration change that followed.
Also check whether persistence exists outside the cloud account. The attacker may control the recovery email, linked device or identity provider.
Containment should be comprehensive. It may require revoking sessions and tokens, removing applications, resetting authentication methods, disabling additional users and reviewing organisational roles.
Those steps can change the evidential environment, so coordinate urgent security action with preservation and specialist support.
What this does not show on its own¶
The dangerous assumption is that changing the password returns the account to a clean state.
A password reset may stop future logins using the old password. It may not revoke credentials or permissions already issued through other mechanisms.
Continued activity after a password reset does not necessarily prove the attacker knew the new password. It may show that earlier persistence remained active.
What to do next¶
Check active sessions, token issue and refresh events, trusted devices, application consent, recovery details, administrator roles, service accounts, API keys and guest invitations.
Key takeaway
A password reset addresses only one access route, so identify and remove every session, token, application, recovery method and additional identity created during the compromise.