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.
curl- Sends web requests and prints the response. Built into Linux, macOS and Windows 10 and later.
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.
grep- Prints the lines of text that match a pattern. Built into Linux and macOS.
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.