Linus Tech Tips - That's gotta hurt...

...but it can happen to anyone.

This week, I've been working on buffing up our security at the college - getting users skippy with MFA and Windows Hello. It's been a busy week for me, for sure.

And then one of my techs sends this one to me - hadn't heard of it, but then, that's why CASP+, CySA+, and Security+ bring up topics like CSRF and such - doesn't take much to overcome MFA, even if you know what you're doing.

So, since we're always down for a good conversation (and a deliberate opportunity to poke at @Lee McWhorter to see if he's still watching CIN) - how about we start a conversation about this.

Ever had an issue with a hijacked session token? What did that look like for you?

It wasn't too kind to Linus over at Linus Tech Tips. Poor guy - having to troubleshoot a problem like that...in the buff, even...

/r

 
The attack vector was a malicious PDF attachment that was targeted to LTT via spear phishing. It stole the session cookies from the browser and sent them to the attacker's server, so the email with the PDF attachment was clearly opened from within the browser (Linus mentioned it was the LTT Gmail account using Chrome). Otherwise the malicious PDF would have been identified by Microsoft Defender (or whatever AV software they use). It also means that an AV scan wouldn't have detected this particular attack afterwards because it took place in the few seconds the PDF was opened by Chrome and left nothing persistent on the machine itself.

So, the easiest way to prevent this would have been to identify the spear phish attempt and not open the PDF attachment. But another method that would have prevented this would be to use Microsoft Edge (=Chromium) on Windows 10/11 with core isolation and hardware-assisted security enabled in Defender. With these features enabled, each tab and process you open in Edge runs in a separate isolated sandbox - in this case, when the PDF was opened in Edge it wouldn't have been able to steal the session cookies.

Of course, a better solution (that Linus noted) would be if Google/YouTube didn't allow such long-lived session cookies in the first place, and required additional verification for things such as deleting videos or changing certain content.
 
So, the easiest way to prevent this would have been to identify the spear phish attempt and not open the PDF attachment. But another method that would have prevented this would be to use Microsoft Edge (=Chromium) on Windows 10/11 with core isolation and hardware-assisted security enabled in Defender. With these features enabled, each tab and process you open in Edge runs in a separate isolated sandbox - in this case, when the PDF was opened in Edge it wouldn't have been able to steal the session cookies.
That is, if it was opened on a Windows machine, yeah?