Contain Ava's account in order, then give it back with a passkey

Setup

1. Press Start on this page.

2. Give Ava the footholds of the exercise: in a private window, sign her in at $ISSUER/account and leave it open; run the lab-printer-app flow for her with offline_access and keep the tokens in your shell as TOKEN and REFRESH. Ava should still have her authenticator app and passkey from the earlier labs.

3. Store Ava's current password with read -rs OLD_PASSWORD. You will use it later to play the attacker's return.

4. In the incident record from the previous lab, write the containment plan in the lesson's order: block sign-in, end sessions, revoke app access and tokens, remove methods, check recovery settings, then give the account back.

Note: in a real incident, tell the owner in person before blocking sign-in, because the block locks them out too.

Walkthrough

1. Block new sign-ins first: lock Ava in Users. In the private window, refresh her account page. Then try to sign in as Ava with her password.

Why it matters: ending sessions while the attacker can still sign in only invites a new one. Locking first closes the door before the clean-up starts. The sign-in is refused, and Audit records why while the page shows the usual message.

2. Confirm each kind of access ended, one by one: introspect the access token as lab-photo-api, and try the refresh token.

btl-lab introspect "$TOKEN" --client-env API
curl -s -d grant_type=refresh_token -d client_id="$CLIENT_ID" --data-urlencode refresh_token="$REFRESH" "$ISSUER/oauth/token" | jq .

Why it matters: in your tenant a lock ends sessions, codes, tokens and remembered consent together. The lesson warns that each kind of access ends differently, so you verify each one instead of assuming.

3. Remove every way back: reset Ava's sign-in methods in Users, while she is still locked.

Why it matters: a password change leaves added methods in place, and a passkey an attacker registered would need no password at all. Removing every method means nothing is left that anyone has to reason about.

4. Check what else the account could change. In Audit, source User directory and Protocol activity, look for profile or email changes, management role assignments and app approvals involving Ava since the incident began. Write each one in the record and undo any you did not make.

Why it matters: some footholds are configuration, not credentials. A changed recovery address or a role assigned to the account outlives every reset.

5. Write down what you cannot reach: any application that signed Ava in and keeps its own session, such as lab-collage, and the absence of a tenant-wide block for an app nobody should approve again.

Why it matters: the lesson's cleanup includes sessions at each application and blocking the malicious app for everyone. Naming the gaps is part of the containment record.

6. Give the account back. Confirm it is Ava through a channel nobody could have taken over (in person, or a video call with someone who knows her). Then unlock Ava, set a new password in Users and share it with her that way.

Note: identity confirmation happens outside the tenant. Your tenant provides the unlock and the password; the help desk procedure from the recovery lab decides who receives them.

7. Sign in as Ava with the new password, skip any enrollment prompt, and add a passkey at $ISSUER/account/security.

Why it matters: the attack in the lesson relayed a password and a code. A passkey cannot be used on a look-alike page, so the account comes back stronger than it was.

8. Watch for a return: in another private window, sign in as Ava with $OLD_PASSWORD. It is refused. In Audit, source Protocol activity, find that refusal.

Why it matters: a rejected sign-in with the old password is useful news. The cleanup held, and someone still has the old credentials.

9. Write the post-incident review: what worked, what was slow, and each finding as a change with an owner and a date. Include at least one finding about your own response, such as how long it took to confirm each kind of access had ended.

Why it matters: the review is blameless and produces specific changes, then checks later that they happened.

Break it

1. Try the shortcut on Cora instead: set a new password for her in Users and do nothing else. Sign in as Cora with the new password. If she enrolled an authenticator app in the detection lab, it still asks for its code: a reset done alone left that method in place.

Restore: reset Cora's sign-in methods in Users, or keep the authenticator if you are sure it is hers.

Check your work

• Check my progress confirms the lock, the refused sign-in, the dead refresh token, the methods reset, the unlock and Ava's new passkey, in that order.

• In Audit, source User directory, the lock, methods reset, unlock and password change appear in the order you planned, all with you as actor and Ava as subject.

• Your incident record lists each kind of access with the step that ended it, and the review lists findings with owners.

Cleanup

1. Store Ava's new password with read -rs AVA_PASSWORD and clear the rest: unset OLD_PASSWORD TOKEN REFRESH.

2. Keep Ava's passkey; later labs assume she has one.

Missing infrastructure

• G30: there is no list of Ava's sessions, so you confirmed the session ended only by refreshing the one you knew about. Once it exists, the lab will read the session list before and after the lock.

• G40: there is no list of Ava's app grants and no tenant-wide block for an app. Once it exists, the lab will list Ava's grants before the lock and block lab-printer-app for every user during containment.

• G39: applications that signed Ava in are not told that her access ended. Once back-channel logout or shared signals exist, the lab will confirm lab-collage ends its session when Ava is locked.