We have been closely monitoring the situation this week of a potential compromise of a cloud identity provider. It is important to note that neither SecureAuth nor most of the blogs, tweets, and other information coming from those outside of the impacted organization have all the information, and there is some conjecture that has been occurring.
We are not addressing the specifics of this event; however, based on the tactics, techniques, and processes (TTP) used by the suspect threat actor (TA) we want to provide organizations overall good practices to protect your organization from these types of attacks.
Overall, most of the TTPs used by the TA are not unique or novel, with one exception. This TA publicly announced that it is looking to purchase credentials from employees, contractors or users of companies. These, and many other TAs are primarily financially motivated, using various techniques to extort money from the compromised organizations.
To bypass multi-factor authentication (MFA) they are either adding a new MFA factor to a user whose credentials they have stolen, or targeting users through social engineering to accept a push notification to their MFA device. The threat actors are relying on a user to blindly accept a push notification. This is possible because users are inundated with push notifications and many accept a notification without reviewing the request.
In one of their public announcements, the threat actors indicated they breached an identity provider and could subsequently access internal environments in order to gather information or gain access to customer data, modify customer environments, obtain passwords, and other potential impacts to customers. Looking at this situation through the lens of security best practices.
- User credentials should be stored within the customer’s directory store and not stored within the platform’s environment; therefore, no one within the platform can obtain any specific credentials or change them within the customer’s environment
- Customer data should be securely sent and stored within the platform environment – username, email, source IP address, in some cases device location, and device information. It’s also a good idea to limit the amount of data stored on the platform. Customer information should be considered sensitive, with appropriate precautions to protect that information – in transit and at rest, with active monitoring of the environment for attacks, reconnaissance, et
The following techniques can help detect potential attacks or compromises – and these are not unique to just this threat actor but should be used in general to monitor attacks.
Auditing
- Investigate any new or unexpected MFA factors registered for users
- Monitor environment for multiple MFA attempts and failures
- Watch for logins for users from abnormal IP addresses or locations – be aware that some geo-location mismatches will just prompt the user for MFA, which could also be compromised, so having an alert on geo-location mismatching or more than normal number of different IPs for a single user or a single IP (non-NAT address) being used for multiple users
- Monitor for abnormal SMS transactions – accounts where SMS may not have previously been used
- Monitor individual application or SaaS providers for access by users that normally do not access the environment, attempts to log into multiple different systems in a short period of time (this could indicate the threat actors are trying to determine what the user they have compromised has access to).
- New users, especially administrative users, created in the directory store or individual applications
- Modification of permissions for non-administrative users
Proactive Measures
- Do not use known weak MFA methods such as SMS or email. If using these methods is absolutely necessary, monitor closely for potential compromises of these factors – monitor IP addresses that are attempting to use these methods
- As much as possible (and especially for administrators or users with access to customer data or environment) use hardware keys (FIDO, WebAuthn, etc) for MFA authentication
- Implement additional checks – source IP location, device information, mutual certificates, etc. – to provide another level of protection against stolen or intercepted MFA requests
- Monitor your identity provider, directory store, remote access (VPN, RDP) for abnormal activities – brute force, multiple MFA failures in rapid succession, credential stuff and other automated attempts to access user accounts.
