4 ms·
They could be fake, of course, but this thread[1] of screenshots is pretty bad... internal tools, Slack Admin, Google Workspace admin, an AWS account showing ad
by cddotdotslash 4y ago
They could be fake, of course, but this thread[1] of screenshots is pretty bad... internal tools, Slack Admin, Google Workspace admin, an AWS account showing admin permissions.
[1] https://twitter.com/Savitar0x01/status/1570580235716014081 https://twitter.com/Savitar0x01/status/1570580235716014081
- bombcar 4y agoThis is where all the secondary hackers will come into play - I expect to get “new uber signup” random texts later tonight.
- jtchang 4y agoThose screenshots look pretty convincing to me.
- dx034 4y agoAnd as other people have already written, that's the main issue. Not that someone got compromised, but that passwords for admin accounts to all those services were stored on a network share.
- lbriner 4y agoWhat happens is that as a company scales to this sort of size, all kinds of shortcuts are made, all kinds of compromise decisions are made because there is still little non-financial cost for getting it wrong. Imagine deciding to add some extra floors to your office made from cardboard because, "we are scaling too quickly to build them out of concrete". Wouldn't happen. Why? The legal and marketing fallout would be fatal. In the corporate world, especially in ones at the extreme levels of inefficiency/size/etc. it is easy just to blame the previous job holder, the previous culture, "we have made improvements since then" etc. as if that makes it alright. tbf, we also see this in Healthcare and Government so I think it is Human Nature rather than corporate greed.
- marcinzm 4y agoSecurity is like an onion and in this case every layer was rotten. * Social engineering successfully got someone * MFA approach did not protect from a simple fake webpage tunneling hack * VPN was based on a password rather than a certificate * Network scan was not detected and stopped * High level credentials were stored in a public file and not detected * Abnormal credential usage was not detected and stopped I probably missed a few but point there were many ways to stop this hack and all of them were broken. This wasn't some highly funded government operation that bypassed layers through clever approaches and expensive zero-day exploits.
- twistedpair 4y agoI'm still confused. Why did people have username/password logins to the AWS console? Either require SSO login, or require HW tokens to get in as an AWS user. Then it doesn't matter if someone finds the password file, it's useless.
- aeyes 4y agoFrom information floating around on Twitter it looks like they had the password to the SSO account of an employee and then social engineered their way to get the employee to accept the push MFA prompt to add a new device. At this point it appears that they found more credentials on the internal network and owned SSO, MFA and AD giving admin access to everything.
- twistedpair 4y ago> found more credentials on the internal network ... giving admin access to everything That's my hangup. The fact that admin/root level accounts can be accessed with "credentials" alone, rather than only via SSO/MFA/Yubikey. Were these service accounts, what happened to least privilege?
- aeyes 4y agoIt depends on the employee you target. If it is someone working on internal IT systems, chances are high that you gain pretty wide access after owning their SSO. SSO can go down or get owned so having break glass credentials isn't unheard of. The last place I worked at had them on paper in a safe in their headquarters. The Twitter threads show that they were stored in a password manager but the hacker was able to find credentials to access it which could have been one of the responsiblities of the employee which was targeted. If you have your password manager on SSO it will be even easier.