Account takeover
In application security, account takeover is the outcome where an attacker ends up in control of a legitimate user’s account. It is not a single technique but the result several techniques converge on, and it is the term a report uses when the business needs the impact rather than the mechanism.
How it works
There are four common routes and they arrive at the same place. Reusing credentials leaked elsewhere, which is credential stuffing. Guessing one weak password across many accounts, which is password spraying. Stealing an issued session instead of the password, which is session hijacking. Or abusing the recovery path, which is the route that needs no credential at all.
Recovery is where the interesting flaws live, because it is a deliberate bypass of authentication that has to be built into every application. If the reset link is derived from a predictable value, if the reset email destination can be influenced by a request header, if the token does not expire or is not invalidated on use, or if the one-time code can be attempted without limit, then the recovery flow is a second front door with weaker locks than the first.
What goes wrong
The defence is usually placed on the login form alone. We routinely find strong controls at login and none on the reset flow, the mobile endpoint, the legacy interface or the support tooling. Adding a second factor to the login while leaving recovery on a code sent by email means the account is protected by the email account, and the attacker knows it.
The second recurring failure is that takeover is not detectable after the fact. The application does not record which device or address changed the email address, does not notify the previous address, and does not end other sessions when the password changes. That combination means the victim cannot see it happened and the operator cannot reconstruct it. An infostealer log purchased for a few euro is enough to start, which is why this is a volume problem and not a targeted one.
Where this shows up in an audit
We test the whole set: login, second factor, recovery, email change, session termination, and the interaction between them. The report is written as the chain that reached control of the account, with the specific step that made it possible marked as the fix, and it records which of the events generated a log entry or a notification. Where takeover has business consequences beyond the account, such as stored payment instruments, we say so explicitly. This is part of how we test authentication and recovery flows.