3 ms·

How did you determine that the attacker hijacked the existing O365 session rather than logging in with the phished username and password? For an app like O365,

How did you determine that the attacker hijacked the existing O365 session rather than logging in with the phished username and password? For an app like O365, usually that kind of cookie-stealing doesn't happen without malware on a user's computer.

cdolan 6y ago
This was about 6-9 months ago and I didn’t lead the postmortem, so to be honest I don’t recall how we determined that. However anecdotal, the user who was compromised is aware enough not to re-enter their credentials outside URL schemes that match our password manager database, and they wouldnt have entered anything. “Oh but how can you trust the user, they clicked a bad link?!”... again this email came from a very reputable vendor who we email with regularly, and the link would have been completely normal for a Monday morning in Q1 2020. I also think part of our reasoning for why the credentials were not re-used was because all the sessions seemed to be headless chrome sessions, but no logins. I’m not a data security expert, but in my best summary, it seemed they: - Had a “virus” that spread really well. I’m assuming they had two kinds of users. Spreaders, and targets. Our employee was a spreader, sending this bug out to his/our network. Once the targets were hit, they’d be selected out of the spreader pool (so the hackers could remain undetected). - The hack relied upon identifying ,mutually high volume (trusted) email senders. - The hack had something to do with leveraging the platform of Notion.io. Unsure if there is a bug on that platform which was also being abused, or if they just have a good system for hosting phishing pages. - The user’s authenticated sessions seemed to be hijacked and replicated across the globe in headless chrome browsers, which appeared to renew the session until the hack ended.
- resfirestar 6y ago
  I sympathize, it's difficult to get a satisfying answer in a situation where you trust the user to accurately remember and own up to a mistake. You need both good logs (Microsoft's default logging and retention usually don't cut it) and a security vendor that knows O365, AAD, and the attacks on them well enough to make useful conclusions. Notion.so is popular for phishing pages because it's a "reputable" "enterprise" application that doesn't raise the spam score when it's linked to in an email, can require signing in to view the page which further deters spam filters that actually check the links, and has less robust anti-phishing systems than Google Docs and Sharepoint (which are still used for the same purpose but require more tweaking of the template to avoid being auto-flagged).

cdolan 6y ago

This was about 6-9 months ago and I didn’t lead the postmortem, so to be honest I don’t recall how we determined that. However anecdotal, the user who was compromised is aware enough not to re-enter their credentials outside URL schemes that match our password manager database, and they wouldnt have entered anything. “Oh but how can you trust the user, they clicked a bad link?!”... again this email came from a very reputable vendor who we email with regularly, and the link would have been completely normal for a Monday morning in Q1 2020. I also think part of our reasoning for why the credentials were not re-used was because all the sessions seemed to be headless chrome sessions, but no logins. I’m not a data security expert, but in my best summary, it seemed they: - Had a “virus” that spread really well. I’m assuming they had two kinds of users. Spreaders, and targets. Our employee was a spreader, sending this bug out to his/our network. Once the targets were hit, they’d be selected out of the spreader pool (so the hackers could remain undetected). - The hack relied upon identifying ,mutually high volume (trusted) email senders. - The hack had something to do with leveraging the platform of Notion.io. Unsure if there is a bug on that platform which was also being abused, or if they just have a good system for hosting phishing pages. - The user’s authenticated sessions seemed to be hijacked and replicated across the globe in headless chrome browsers, which appeared to renew the session until the hack ended.

resfirestar 6y ago
I sympathize, it's difficult to get a satisfying answer in a situation where you trust the user to accurately remember and own up to a mistake. You need both good logs (Microsoft's default logging and retention usually don't cut it) and a security vendor that knows O365, AAD, and the attacks on them well enough to make useful conclusions. Notion.so is popular for phishing pages because it's a "reputable" "enterprise" application that doesn't raise the spam score when it's linked to in an email, can require signing in to view the page which further deters spam filters that actually check the links, and has less robust anti-phishing systems than Google Docs and Sharepoint (which are still used for the same purpose but require more tweaking of the template to avoid being auto-flagged).