Unit 10: Capstone: review the shop · Lesson 4 of 4 · 18 min
Case file: when the password and MFA were not enough
A stolen browser session skips both. Check whether the shop asks again before sensitive changes.
case file
Linus Tech Tips session token hijack
Linus Media Group · 2023
On 23 March 2023 attackers took over Linus Media Group's YouTube channels, renaming them and streaming scam content. A team member had opened a malicious file disguised as a sponsorship PDF, and malware stole browser session tokens, which bypassed both the password and two-factor sign-in.
What went wrong
Malware on a staff machine exported browser session cookies, which stayed valid when replayed from another device.
What would have stopped it
- Treat unexpected attachments as untrusted and block executables disguised as documents.
- Platforms binding sessions to devices and asking again before sensitive actions such as renaming or mass deletion.
- Short session lifetimes and least privilege for admin roles.
What defenders could have seen
- The same session cookie used from a new address or device.
- Bulk changes that do not match normal work.
sourceswepc.comdeployflow.co
mission
- You are
- The reviewer adding one more check to the shop report.
- Situation
- Infostealer malware copies session cookies straight out of browsers. Whoever replays one is signed in, with MFA already passed.
- Goal
- Find out whether the shop asks for the password again before changing the account email.
- Hand in
- A finding with evidence and a recommended fix.
Step-up before sensitive changes
Press play or step through.
Sign in and change the email
curl -s -o /dev/null -c jar.txt -d @shop-account.txt http://127.0.0.1:8000/login && curl -s -b jar.txt -d 'email=new@example.net' http://127.0.0.1:8000/account/email
{"email": "new@example.net", "changed": true}
you should see The change succeeds with nothing but the cookie. Changing the email is usually the first step to taking an account over for good.
How long does the session last?
grep shop_session jar.txt
#HttpOnly_127.0.0.1 FALSE / FALSE 0 shop_session 7f3a9c2e41d8b6a5
you should see The expiry column is 0: a browser session cookie, but the server never expires it, as the earlier sign-out lesson showed.
Does the CSRF check help?
curl -s -b jar.txt -H 'Origin: https://other.example' -d 'email=x@example.net' http://127.0.0.1:8000/account/email
{"error": "cross-site request refused"}
you should see Refused, because the request says it comes from another site. Someone replaying a stolen cookie from their own tools sends no such header, so only a step-up check stops them.
Changing the account email
POST /account/email Cookie: shop_session=... -> 200 changed
A copied cookie is enough.
POST /account/email Cookie: shop_session=... -> 401 confirm with password or passkey email sent to the old address
The thief is stopped and the owner is told.
What a defender takes away
- 1A stolen session has already passed MFA.
- 2Ask again before email, password, payout or MFA changes.
- 3Notify the old address whenever contact details change.
Questions
0 of 2 solved
Answer each one from what you find on your lab machine.