A report by Luke Richards, Dmitriy Beryoza & Kat Traxler.
The recent security incident at Okta represents yet another view of a supply chain compromise. While this attack appears to not have been fully realized, resulting in an apparently limited number of businesses affected, it poses an interesting set of questions to think about in terms of what a supply chain attack against an IDP would look like when fully realized. The result of any IDP compromise, or that of any similar pervasive use technology could be an attack group with access to millions of users and thousands of businesses.
The tactic of a supply chain compromise itself is not novel with recent high-profile breaches like Kaseya and SolarWinds coming to mind. But the idea of something like a supply chain attack focused on accounts management is scary when you work through the paper exercise of what a security team would need to do.
Account access has played a role in 85% of recent compromises. Accounts provide attackers access to nearly everything in an organization ranging from cloud-managed resources in public cloud SaaS applications to network assets, without the need for any payloads or contact with monitored endpoints.
Given the questions posed about what could have happened, we outline below recommendations for security teams to take in the event of an IDP or other identity focused software being involved in a supply chain compromise. These recommendations also apply to the compromise of accounts resulting from tactics other than supply chain attacks. In the view of an attacker, the supply chain is just one of many methods to compromise an account. How attackers leverage compromised accounts to complete their goals within a target environment, and how defenders can detect and respond to those actions, are essentially the same, regardless of the initial method of compromise.
Evaluate the current situation
Acquire as much information about the breach as possible
When a compromise involves a third party, the controlled information released by the impacted organization and the statements made by attackers, the full picture of what is occurring may be hard to put together. Factor multiple information sources into your analysis, including commentary from independent security researchers, to estimate the extent of the incident.
Determine the rough timeframe for the breach
News of the security event sometimes breaks weeks or even months after the attack. To find as many IoCs as possible, cast a wide net and define a realistic timeframe within which malicious activity could have occurred.
Take inventory of everything your Identity Provider touches
Modern enterprises use hundreds of different services and applications, and sometimes even the SOCs have trouble tracking the accurate picture of the inventory. One cannot adequately protect what one does not know, so it is crucial to acquire complete knowledge of all entities the provider services to cover all consequences of the breach.
Review the recent activity in the logs and any alerts that were triggered
Established providers should have good logs of all critical activity within the environment. Armed with the timeline estimate, review all relevant changes in the system configuration to spot anything that could give attackers a foothold into your enterprise: new admin users, elevated permissions, redundant access credentials, newly installed applications, enrolled devices, and so on. Any logged security alerts should also be evaluated.
Investigate any other changes that may provide redundant access
Sometimes available logging may not be enabled or adequate. It will be worth your time to review the current security settings to see if something was changed that is out of the ordinary.
Mitigate malicious changes
Roll back malicious setting changes
This step is self-explanatory - any detected malicious changes should be rolled back. Their full details should be recorded to put together the complete picture of the compromise and aid in further forensic activities.
Reset user passwords
When you suspect that individual user accounts may be compromised, forcing user credential rollover may be a necessary step. While this step will be unpopular with your user base, it is easy to perform and is a practical step in dealing with possible account compromise.
Rotate keys and certificates
Resetting credentials of applications and services is usually a much more complex and labor-intensive activity. While it may be unavoidable if the relevant secrets are leaked, make sure it is necessary before you embark on it.
Revoke all excessive 3rd party permissions
Some Identity Providers (including Okta) can request customer permission to access and modify tenant settings or perform system debugging. In the face of provider compromise, it would be prudent to revoke any such access that has already been given.
Shore up defenses
Review current security settings
This is another obvious step. A security incident is a great opportunity to review your current security settings and tighten them up. Security posture management products like Siriux, which can scan and identify gaps in configurations in Azure AD and M365 controls, can be of significant help.
Install a monitoring solution
Even the most well-configured security solution is not immune to breaches. Human factor or supply chain attacks (like an IdP breach) can bypass external defenses. To address when incidents occur, you need an effective detection and response solution like the Vectra Platform to monitor malicious activity and stop attacker progression.
Review incident response playbooks
Ideally, you already have a plan for an incident at your Identity Provider, and you are executing it right now. Those who find themselves with gaps in preparedness should take this opportunity to implement a plan to deal with the fallout from a breach at a critical infrastructure provider that your enterprise depends on.
Consider a 3rd party audit
When the dust settles, it is good to schedule a third-party audit by a respectable security provider to verify that your security posture is well designed and does not contain apparent holes.
What are the signs of a compromised account?
When one or more accounts are compromised, the impact is not always immediately apparent. Because of the variety of actions an account can perform and how assets are managed, the signal for a compromised account is most generally characterized as anomalous activity related to accessing valuable services, functionality, hosts, or data. Defining what is abnormal and even what is valuable is obviously no simple task.
While teams can hunt through network Active Directory logs and review the actions logged by a cloud service, the scale and ambiguous nature of the problem is best handled using AI solutions to make sense of what is anomalous and aligned to the objective of an attacker. This is especially important when faced with scenarios where the alternative to not knowing precisely who is compromised is to reroll credentials, access tokens, and potentially private keys.
Vectra applies security-led AI to monitor and respond to attackers’ actions with compromised accounts spanning your business across hybrid-cloud, SaaS, and AWS. Alerts are focused not just on what is anomalous but on the behavior of attackers. Techniques like Vectra’s Privilege Analytics that automatically understands the value of accounts and assets in both the hybrid-cloud and pure SaaS environments can make sense of the abnormal by understanding the value of assets based on their historical activity.
Manually investigating compromised and high-risk accounts
For those without the benefit of a platform like Vectra’s, threat hunters will have to assess the incident specifics and how the IDP interacts with their environment to determine potential accounts that are suspected of compromise. In the Okta case, this may be done by looking at account changes during the disclosed period of attacker control within the IDP infrastructure as one example.
During normal operations Security Operations, analysts may expend extra effort on monitoring high profile accounts such as domain administrators and service accounts. These tend to be robust and stable accounts, with little change in how they operate on a day to day-to-day basis. When we are forced to consider a supply chain type attack, the focus shifts beyond the scope of those high privilege accounts, to almost every account on the network. Rerolling credentials, access tokens, and potentially private keys, is a task which is not only complicated and time consuming, but sometimes untenable.
If an account is suspected compromised or tagged as high risk, the best place to look outside of detections is the Active Directory Security logs and, in particular, the following event IDs
· 4624 (An account successfully logged on) this account produces two logon types of note.
- Logon Type 10
§ Remote interactive logon – This is related to RDP, remote assistance or shadow connection. This type of logon would also logon the remote IP address.
- Logon Type 3
§ Network Logon – This would indicate an authenticated user connecting to a service on the remote host.
· 4768 A Kerberos authentication (TGT) ticket was generated this event indicates a user account being authenticated on the network. The TGT is given to a valid account with a valid password. Again, this would generate an IP address to track potential anomalous behavior.
Following these logs could reveal activity on potentially compromised accounts. Applications and service accounts tend to be very stable, which is why Vectra learns the normal behavior for these accounts and can provide a Privilege Anomaly Detection when they start acting outside of their established patterns. The same is also true of more ephemeral accounts, or those which have a broad scope, such as operator accounts, or normal user accounts. These accounts are less likely to interact with the services which are stable and business critical, enabling Vectra’s approach to monitoring identities for anomalous behavior to generate detections and guide your team’s focus accordingly.
To learn more about Vectra, please feel free to contact us or try our demo!