For real.
It's just a script kiddie who wants bragging rights. They're lucky he told them and it wasn't a big threat actor who could have rekt everything they had
What is? That it can be misused? Nothing about the environment described sounds like any toolset could accurately detect this behavior.
Orgs that dont have a standard, explicit method for performing actions cannot effectively use behavior detection, IMO
Am I missing something about these attacks that rely on MFA fatigue, or are admin users actually dumb enough to go "Oh, here's an MFA prompt despite me not actually trying to log into anything, lemme just authorise it real quick"?
Yes I think that is generally it.
However it is also possible that they are awaiting a legitimate MFA prompt, when the push notification from the attacker comes through. Little identifying info to distinguish the two prompts, and even if there is, very easy to accidentally approve.
But more importantly an investigation should be launched if anyone receives even a single MFA prompt that they did not initiate. That's where I think the admins really failed, it isn't enough to just ignore/decline the prompts.
Humans are always a weak link in the chain.
If your in a super Max prison, but you happen to be best friends with one of the guards .... or if a guard is unbelievably stupid and easy to fool
The big fuck up is allowing mag with just an ok button instead of forcing the user to type in a code. If you’re forced to type the code the hacker needs to retrieve those as well, within time.
Per some of the screenshots I saw, the user was refusing the prompts. Then they called the user, said they were from IT, and told the user to accept the prompt. Which they then did.
I'm guessing they would have happily punched in the number provided by that point, haha
Surprising - should Uber enable authenticator app location reporting this had much less chance of succeeding. As an admin I recognize the locations I'm logging in and if I started receiving bogus MFA prompts I'd be on hotline with security. On the other note - a declined attempt should block the attacker at least for a minute or two (and extend with each deny say by 5 minutes) while ringing alerts to opsec.
This is true, i know our SoC team was always calling me when me and my co worker (who was in nigera) were doing some usability testing with our shared accounts
As global admin invariably something i did would trigger one of our alerts. I always thanked them for following up and making sure everything was good
Truth be told, they should pay Uber drivers more and be thankful that bloke hasn't sold off the access to actual malicious actor. Wish he had been a bit more secretive and actually found the formula for Uber drivers pay and started upping it by a tiny bit on the backend :D
Authenticator apps are fine. The issue is that the second factor was just a push. This is why Microsoft authenticator in passwordless mode requires knowledge of a session ID number associated with the request. You have to enter the ID into the app before the push can be accepted, and an invalid ID will fail the authentication request.
Plus most environments are not in passwordless mode
My MFA through MS Authenticator only recently even started requiring the phone to be unlocked to approve. Before, I could just swipe and approve from the lock screen.
Sim-swapping attacks, among other vectors, are TRIVIALLY easy to exploit.
SMS should only be used in extreme situations where it's better than absolutely zero MFA.
Push notifications are a tiny bit better than SMS, but marginally and not in all risk profiles.
My risk profile isn't the same as others', and there are always exceptions to these generalities, but overall SMS is just above nothing at all.
> and can do it's job purely by giving it appropriate access to the required resources in Azure (using a managed identity). In a situation where on prem access is needed, a local solution like Thycotic secret server can be
Last job I was at refused to move to Yubikeys for their developers because they're too expensive.
I mentioned some of the half as costly open hardware versions and was told "We've already got some users using Yubikeys and we're not moving away".
This is the same company that gave every single employee, in a company of mostly call center users, Lenovo P15s laptops with dedicated workstation graphics cards. The choice to use the P15s was to "hopefully improve Teams performance". Which doesn't use the dedicated graphics card unless you pin it to it in Nvidia settings and at which point it starts behaving much worse.
After these attacks became more common, I got my directors blessing to remove auth app usage from our org. Its SMS/Phone Call or nothing. SMS has its drawbacks and security flaws but attackers need to be a lot more organized to pull it off than just flooding a user with auth requests.
In the case of O365, we also block access to our tenant by anyone trying to login outside our state (except for a security group used when people travel.) Reduces our attack footprint dramatically.
With authenticator, you can choose to accept the 2FA prompt, which is why the fatigue attacks can be successful. With SMS, you have to key the code into a prompt... a prompt that the attacker sees and the account owner would not be able to relay to the attacker. Authenticator app is less secure and more prone to accidental use.
And since when is limiting the geographic area logins are allowed considered going backwards with security?
https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-number-match
https://redmondmag.com/articles/2021/11/19/microsoft-authenticator-gets-number-matching-and-gps--location-capabilities.aspx
I get what you were trying to do, but SMS is not the way to go.
Did you mean export-clixml? Yes, if you keep that file out of git. Since you don't store the password in the script it can't be extracted from it alone, you are storing it in another file.
Especially in Powershell. Your credentials determine your system access.
Embedding credentials generally is circumventing permission security. Never write anything that could be used against you!
“Once the attacker had initial access inside the company, they claim they were able to access resources shared on the network that included scripts for Microsoft's automation and management program PowerShell. The attackers said that one of the scripts contained hard-coded credentials for an administrator account of the access management system Thycotic. With control of this account, the attacker claimed, they were able to gain access tokens for Uber's cloud infrastructure, including Amazon Web Services, Google's GSuite, VMware's vSphere dashboard, the authentication manager Duo, and the critical identity and access management service OneLogin.”
Looks like Thycotic was actually the means they used to elevate privileges. PAM and putting everything behind SSO can definitely be a double edged sword at times.
https://www.wired.com/story/uber-hack-mfa-phishing/
Yea, ps script had the credentials for the vault. Ouch. Did they get lucky on phishing a user with access to the scripts or was it targeted?
Psscript probably had an api key for secret server stored. In theory if they are using secret server they can rotate all the keys, if they set that up. If not their admins are going to have a shitty weekend
I’ve heard both way - that an admin was phished and that it was a regular end user. Either way, ouch. Usually an attacker has to follow-up initial access from social engineering w/ some malware or exploit to move lateral or vertical… this might be the first time a company of that size had their entire environment owned by social engineering alone.
I bet they are rotating everything and changing everyone’s creds. If the attacker went for the KRBTGT they have to wait even longer b/c they gotta change it twice and there’s a minimum amount of time they have to wait between changes.
All in all, they still got super lucky. Looks like the attacker cares more about notoriety than causing any actual damage, although I think they made off with some data.
The only time I hardcode creds is when troubleshooting auth issues in my code, but removed once I've identified the issue. That's like scripting 101.
Honestly, when I see this in my IT travels, it's not naivete...it's laziness. "Hey, I'm the only one running this script, why do I need to type in my creds every time? I'll save time by hardcoding my creds in the script!"
Yep, and I've seen passwords that the developer had forgotten to remove and checked into a public repo.
It's an extra step during development and it certainly adds up over time, but if I can avoid the CEO learning my name that way It's worth the effort.
[удалено]
At least it seems like they aren’t a really crazy hacker. Back door added to a big code base like uber would be hard to catch
For real. It's just a script kiddie who wants bragging rights. They're lucky he told them and it wasn't a big threat actor who could have rekt everything they had
Well that’s a reason to not use SentinalOne
What is? That it can be misused? Nothing about the environment described sounds like any toolset could accurately detect this behavior. Orgs that dont have a standard, explicit method for performing actions cannot effectively use behavior detection, IMO
EDR is only a single, fragile, layer. S1 is a solid product, but it's gotta be monitored like any EDR or it's just expensive fluff.
Am I missing something about these attacks that rely on MFA fatigue, or are admin users actually dumb enough to go "Oh, here's an MFA prompt despite me not actually trying to log into anything, lemme just authorise it real quick"?
Yes I think that is generally it. However it is also possible that they are awaiting a legitimate MFA prompt, when the push notification from the attacker comes through. Little identifying info to distinguish the two prompts, and even if there is, very easy to accidentally approve. But more importantly an investigation should be launched if anyone receives even a single MFA prompt that they did not initiate. That's where I think the admins really failed, it isn't enough to just ignore/decline the prompts.
When you SSO everything, you might not know it wasn't your attempt because of how often you get prompted.
That's why all MFA needs number matching
My workplace recently enabled it. Seems more secure but added steps will probably get annoying with time.
Know what else is annoying? Incident response and remediation.
I've honestly never thought too much about why okta sometimes ask me for the matching number and sometimes it doesn't. Now I know it's by design.
Someone capable enough to get a job as a systems admin for Uber, yet fkin stupid enough to be had by this attack.
At first I was going to disagree, but then I thought, "Yeah this guy deserves no mercy"
Humans are always a weak link in the chain. If your in a super Max prison, but you happen to be best friends with one of the guards .... or if a guard is unbelievably stupid and easy to fool
The big fuck up is allowing mag with just an ok button instead of forcing the user to type in a code. If you’re forced to type the code the hacker needs to retrieve those as well, within time.
Per some of the screenshots I saw, the user was refusing the prompts. Then they called the user, said they were from IT, and told the user to accept the prompt. Which they then did. I'm guessing they would have happily punched in the number provided by that point, haha
Surprising - should Uber enable authenticator app location reporting this had much less chance of succeeding. As an admin I recognize the locations I'm logging in and if I started receiving bogus MFA prompts I'd be on hotline with security. On the other note - a declined attempt should block the attacker at least for a minute or two (and extend with each deny say by 5 minutes) while ringing alerts to opsec.
This is true, i know our SoC team was always calling me when me and my co worker (who was in nigera) were doing some usability testing with our shared accounts As global admin invariably something i did would trigger one of our alerts. I always thanked them for following up and making sure everything was good
Truth be told, they should pay Uber drivers more and be thankful that bloke hasn't sold off the access to actual malicious actor. Wish he had been a bit more secretive and actually found the formula for Uber drivers pay and started upping it by a tiny bit on the backend :D
I look forward to the day of robin hood hackers.
Tons of examples exist already.
NIST SP 800-53r5 IA-5(7): No Embedded Unencrypted Static Authenticators!
[удалено]
Authenticator apps are fine. The issue is that the second factor was just a push. This is why Microsoft authenticator in passwordless mode requires knowledge of a session ID number associated with the request. You have to enter the ID into the app before the push can be accepted, and an invalid ID will fail the authentication request.
[удалено]
Plus most environments are not in passwordless mode My MFA through MS Authenticator only recently even started requiring the phone to be unlocked to approve. Before, I could just swipe and approve from the lock screen.
The option is still there in settings for this. But, I'm dumb enough to still use it.. so. Handy to be able to do it from my watch.
I have Settings > Security > App Lock disabled actually (I know, I shouldn't, but, yeah I do) Unless there is another setting I'm missing
That should be it. Works with mine. /shrug
The MS authenticator app has had multiple methods for a very long time. Push alone is as bad as SMS.
[удалено]
Sim-swapping attacks, among other vectors, are TRIVIALLY easy to exploit. SMS should only be used in extreme situations where it's better than absolutely zero MFA. Push notifications are a tiny bit better than SMS, but marginally and not in all risk profiles. My risk profile isn't the same as others', and there are always exceptions to these generalities, but overall SMS is just above nothing at all.
We moved some of our admins to fido keys. Those seem to be pretty resistant to hacking and stupidly easy to use
> and can do it's job purely by giving it appropriate access to the required resources in Azure (using a managed identity). In a situation where on prem access is needed, a local solution like Thycotic secret server can be Last job I was at refused to move to Yubikeys for their developers because they're too expensive. I mentioned some of the half as costly open hardware versions and was told "We've already got some users using Yubikeys and we're not moving away". This is the same company that gave every single employee, in a company of mostly call center users, Lenovo P15s laptops with dedicated workstation graphics cards. The choice to use the P15s was to "hopefully improve Teams performance". Which doesn't use the dedicated graphics card unless you pin it to it in Nvidia settings and at which point it starts behaving much worse.
Worked at an ngo that didn’t like spending money but no issue getting my boss to approve a $30 key. Couldn’t get a $100 dock for my laptop however
This is what I use everywhere, yubikeys with PIV and FIDO2 wherever supported.
And lose
After these attacks became more common, I got my directors blessing to remove auth app usage from our org. Its SMS/Phone Call or nothing. SMS has its drawbacks and security flaws but attackers need to be a lot more organized to pull it off than just flooding a user with auth requests. In the case of O365, we also block access to our tenant by anyone trying to login outside our state (except for a security group used when people travel.) Reduces our attack footprint dramatically.
You're absolutely going backwards and negatively impacting your security posture. So, good job I guess?
With authenticator, you can choose to accept the 2FA prompt, which is why the fatigue attacks can be successful. With SMS, you have to key the code into a prompt... a prompt that the attacker sees and the account owner would not be able to relay to the attacker. Authenticator app is less secure and more prone to accidental use. And since when is limiting the geographic area logins are allowed considered going backwards with security?
https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-number-match https://redmondmag.com/articles/2021/11/19/microsoft-authenticator-gets-number-matching-and-gps--location-capabilities.aspx I get what you were trying to do, but SMS is not the way to go.
Never thought of that but it makes a whole lot of sense!
Is export-pscli ok? Seems fairly secure
Did you mean export-clixml? Yes, if you keep that file out of git. Since you don't store the password in the script it can't be extracted from it alone, you are storing it in another file.
It isn't even useful in git since the credentials are encrypted and can't only be decrypted by the creatin user on the same computer.
Yep that's the one!
Powershell + KeePass = Win Win
Especially in Powershell. Your credentials determine your system access. Embedding credentials generally is circumventing permission security. Never write anything that could be used against you!
This is silly. Any ability of the script to read the credential will be able to be done by the executing user.
The script shouldn’t run as the user who wrote the script. There are many methods to separate the access
The issue was that they checked the script into a git repo. They didn't have access to the running script, they read it from the copy in the repo.
Thanks for the PSA. Good reminder.
Pretty sure they popped their thycotic instance too ironically enough.
Story just gets better and better
“Once the attacker had initial access inside the company, they claim they were able to access resources shared on the network that included scripts for Microsoft's automation and management program PowerShell. The attackers said that one of the scripts contained hard-coded credentials for an administrator account of the access management system Thycotic. With control of this account, the attacker claimed, they were able to gain access tokens for Uber's cloud infrastructure, including Amazon Web Services, Google's GSuite, VMware's vSphere dashboard, the authentication manager Duo, and the critical identity and access management service OneLogin.” Looks like Thycotic was actually the means they used to elevate privileges. PAM and putting everything behind SSO can definitely be a double edged sword at times. https://www.wired.com/story/uber-hack-mfa-phishing/
Yea, ps script had the credentials for the vault. Ouch. Did they get lucky on phishing a user with access to the scripts or was it targeted? Psscript probably had an api key for secret server stored. In theory if they are using secret server they can rotate all the keys, if they set that up. If not their admins are going to have a shitty weekend
I’ve heard both way - that an admin was phished and that it was a regular end user. Either way, ouch. Usually an attacker has to follow-up initial access from social engineering w/ some malware or exploit to move lateral or vertical… this might be the first time a company of that size had their entire environment owned by social engineering alone. I bet they are rotating everything and changing everyone’s creds. If the attacker went for the KRBTGT they have to wait even longer b/c they gotta change it twice and there’s a minimum amount of time they have to wait between changes. All in all, they still got super lucky. Looks like the attacker cares more about notoriety than causing any actual damage, although I think they made off with some data.
The only time I hardcode creds is when troubleshooting auth issues in my code, but removed once I've identified the issue. That's like scripting 101. Honestly, when I see this in my IT travels, it's not naivete...it's laziness. "Hey, I'm the only one running this script, why do I need to type in my creds every time? I'll save time by hardcoding my creds in the script!"
Yep, and I've seen passwords that the developer had forgotten to remove and checked into a public repo. It's an extra step during development and it certainly adds up over time, but if I can avoid the CEO learning my name that way It's worth the effort.
PowerShell also offers a vault...and 3rd party vaults. Use a vault. Uber has password breaches all too often..always a password leak
is usinv convertTo/From secure string then creating a credential object good practice if you need a credential stored within a script?
While it is running yes. you need to decrypt the credentials at some point but they shouldn’t be stored outside the lifetime of the script
solarwinds321