Attacks on recovery and the help desk
The other way in
Every account needs a way back in for the day its owner loses a phone, forgets a password, or both. Recovery has to work without the methods the person normally uses. That makes it a sign-in path of its own, and often the most powerful one, because it ends with someone able to set new credentials.
Enrollment, replacement, and recovery explains how to design recovery for the people who genuinely need it. An attacker looks at the same design from the other side and asks what recovery accepts in place of the usual methods, and whether they can supply it. There are two broad routes. Automated recovery sends a link or code to a channel on record, such as an email address or a phone number. Assisted recovery puts a person, usually on the help desk, between the request and the reset. Each has its own weak point.
At Cedar Inc., an attacker took over the account of Riley, who works in the finance team, at 09:14 one morning. Less than an hour later, at 10:05, the attacker tried the second route and called the help desk.
Taking over the reset channel
A reset link sent by email is only as safe as the mailbox it goes to. For customers of the photo application, that mailbox is usually a personal account, which may have a reused password, no MFA, or a weak recovery path of its own. Whoever controls the mailbox can reset the photo account, and the photo application has no way to tell that it is not the owner.
Channels also change hands without being attacked directly. Phone numbers are reassigned to new customers some time after an old contract ends, and they can be moved by the number transfer fraud described in Getting around MFA. A recovery address at a small company's domain becomes someone else's if the domain lapses and another person registers it. An old address the person no longer reads may still be on record, quietly receiving reset links.
The most direct attack is to change the channel itself. An attacker who already holds a session can try to add their own email address or phone number for recovery, so they can return after being thrown out, a foothold How attackers stay in covers in detail. Changing a recovery channel should therefore need the same fresh, strong check as adding a sign-in method. Recovery should also replace what was lost rather than everything at once. A reset link that sets a new password should not switch off the second factor in the same step.
A convincing call to the help desk
A help desk exists to get people working again, and it is often measured on how quickly it does so. That makes it a target. A caller does not need to defeat any technology, only to persuade one person that they are who they claim to be and that the request cannot wait.
Callers come prepared. Names, job titles and reporting lines are on company websites and professional profiles. An attacker who already controls one mailbox has far more. At Cedar, Riley's mail showed the names of the IT administrators, that an outside contractor was working on a mail migration, and how Cedar's change tickets are numbered. Details like these sound like inside knowledge, but they prove only that the caller has read them somewhere.
The call itself leans on pressure. Urgency: a deadline that will be missed, a system that will fail. Authority: an executive, or someone working on behalf of IT. Sympathy: a stressed person who has lost everything just before a big meeting. The request is chosen for its value as well. A password reset on an ordinary account is useful to an attacker, but an MFA reset on an administrator's account can be worth more than a hundred ordinary ones.
That is the request Rowan, on Cedar's help desk, received at 10:05. The caller said they were an IT contractor working on the mail migration, named an administrator's account, and asked Rowan to reset its MFA so that the administrator could enroll again before that afternoon's cutover.
Verifying someone who has lost everything
The help desk's hardest case is not the attacker. It is the genuine employee who has lost their phone and their backup key and needs to work today. Verification has to let that person through while refusing someone who knows all about them.
Several approaches do that far better than questions. If the person still has any enrolled method, such as a backup key or recovery codes, they can use it to recover through self-service, and the help desk only needs to point the way. Otherwise the agent can end the call and call back the number on the employee's record, never a number the caller provides. A second person can confirm: the employee's manager, reached through their own signed-in channel, or a second agent who must approve resets on sensitive accounts. For the most valuable accounts, the person can be re-proofed: checked again against their identity record in person, or on a video call with an identity document, using the methods in Proofing methods.
Knowledge questions do poorly. An employee ID, a manager's name, a birth date or a home town can be found or guessed, and an attacker inside a mailbox may know more about the account than its owner remembers. The help desk also never handles secrets. It does not ask for a password or a current code, and it never reads out, sends or forwards a code or link to an address the caller supplies. When a reset is approved, the person receives a one-time link to enroll a new method through the channel that was just verified, not a temporary password spoken over the phone.
How much of this to require depends on what the account can reach. A mistake that restores an attacker to an ordinary account costs far less than one that hands over an administrator, so the checks rise with privilege. If the number on record belongs to the very phone that was lost, the callback reaches nobody, which is why the flow keeps an in-person route open rather than falling back to easier checks.
Now take Rowan's place for the 10:05 call.
Take the call
Simulation. This help-desk call is made up for practice. You choose Rowan's response at each turn, and checking an answer happens only in your browser and sends nothing.
Making recovery visible
Rowan called the administrator back on the number in Cedar's directory. The administrator answered at their desk, had lost nothing and had made no request. Rowan refused the request and recorded it: the time, the account the caller asked about, the role they claimed and why the request was refused. The next day, when Quinn, on Cedar's security team, investigated Riley's account, that record stood out. The caller had known about the migration from Riley's mail, so the attacker had also been reaching for administrator access, and the record named the administrator to warn.
A recovery that succeeds should be just as visible. When a recovery channel or sign-in method changes, the service notifies the old channels as well as the new one: the previous email address, the enrolled devices, the phone that was replaced. An attacker can change where future messages go, but cannot recall the message to the old address saying that the change happened. The real owner gets a chance to say "this wasn't me" while it still matters.
A waiting period gives that notice time to work. A recovery that replaces every method at once can take effect only after a delay, with notices sent at the start, unless stronger verification shortens it. For the first hours after a recovery, the account can be limited too: no new recovery channels, no methods beyond the one just enrolled, no large payments or data exports. A genuine person rarely needs those in the first hour, while an attacker almost always does.
Resets done by support need their own review. Each one should record who asked, which agent acted, what verification was used and which account changed, without any secret values. Looking through those records for resets of privileged accounts, runs of resets by one agent, or requests from unfamiliar numbers catches both social engineering that succeeded and procedures that have quietly drifted.