Thanks, bitcoin.
If I open a pdf in chrome for example am I opening myself up to this kind of attack?
From what I understand, it was an executable inside a zip attachment to an email disguising itself as a partnership proposal from a reputable source.
The file inside the zip probably had a .pdf.exe extension. By default, Windows Explorer would show it as a .pdf, making it easy to run by mistake.
Is there a link to the sample on VirusTotal?
Looking at how I can prevent this from happening to myself, am I missing something? Why didn't their email-service's anti-virus pick up on virus?
In the case that it was in a zip, why didn't said anti-virus extract the zip & scan?
In the case of a password-protected zip, why didn't the computer scan the file upon extraction?
In the case of a scan upon extraction, why was it missed? Outdated definitions or zero day?
Linus also spoke about invalidating sessions. This is something that requires careful planning. We can't do it due to our teams switching VPNs so often.We do enable Impossible Travel in Okta by default for our clients.
From the perspective of a browser, it seems like a better mitigation would be to make it harder to steal these tokens in the first place. Cookies have to be persisted to disk in order to survive browser restarts, but maybe some cookies could be identified as password-equivalents and get stored in the system's keyring.
And of course, from the perspective of a server, they could probably be more credulous when they see a session token trying to make account management actions from a new IP.
I blame Windows hiding the extension of known files by default.
`anything.pdf.exe` would show as `anything.pdf`
Can't blame people from thinking it's a PDF.
Otherwise, I use SumatraPDF as a viewer. Small, no frills, probably less of a vulnerability target than Adobe Acrobat.
It allows creating granular permissions and you can see its interface around 08:15.