Fueled by several NHI-related breaches, NHI security companies (SlashID included) are everywhere these days - but, what are the core issues, and what’s causing them?

In this blog post, we seek to map out the problem and draw some lessons from application security, endpoint, and other areas of security to reason about the problem.

Attack patterns against NHI

The MITRE ATT&CK framework is very useful for mapping attack patterns against NHIs:

Several of the techniques discussed here apply to NHIs - in particular, limiting this to Initial Access and Credential Access:

1. Trusted relationships
2. Credentials from password stores
3. Exploitation for Credential Access
4. Steal application access token
5. Steal or Forge Authentication Certificates
6. Steal Web Session Cookies
7. Unsecured Credentials

In practice, looking at historical data we see adversaries perform the following techniques to gain access via NHIs:

1. OAuth social engineering (notable adversary: APT28/GRU)
2. Stolen, lost, or forged credentials (notable adversary: APT29/SVR)
3. An important sub-category of (2) is Kerberos/Active Directory-related token forging or stealing (notable adversary: Turla/FSB)
4. Exploitation of federation trust relationships (notable adversary: Scattered Spider)

In this article we are not going to focus on OAuth social engineering and the exploitation of federation trust relationships for two reasons:

1. OAuth social engineering is a broader problem that applies to user accounts as well. Similarly, federated trusts relationships broadly apply to user identities. We are going to cover both in separate posts
2. While both techniques are dangerous, stolen, forged and lost credentials represent the bulk of real-world intrusions by a significant margin

What is unique about NHIs?

With a taxonomy of attacks under our belt, we can reason about the unique challenges associated with NHIs. At a high level, we see 5:

1. You can’t enforce Multi-Factor Authentication (MFA)
2. Their credentials can’t be rotated easily
3. Lifecycle management is lacking: it is hard to know who has access to them, and how and when they should be de-provisioned. Further, there’s no source of truth/” known good” for them
4. There are too many of them and their usage is not self-explanatory
5. They are often over-privileged

The result is that, as an industry, we face the following:

1. Attackers target NHIs because they can log into a system and move laterally much more easily
2. If there is a breach or suspected breach, the time to remediate is extremely long
3. It’s hard to stay compliant
4. Because NHIs are so often overprivileged, privilege escalation and lateral movement are much easier to achieve

Analyzing the problem 

In summary, we are facing two core issues.

One is that NHIs make for perfect candidates for credential-based attacks, and the second is that governance of these identities is too hard due to sprawl and lack of granular visibility.

When we talk about governance in this context we mean both lifecycle management as well as entitlement management.

Dissecting the problem further leads us to several questions.

Are NHI issues a misnomer? Are they credential issues?

While not all NHI issues are credentials-related, without credentials, we could be way less concerned about the remaining NHI attack vectors.

Specifically, without credentials, NHIs would be a significantly less popular attack vector because there would be a lot fewer ways to impersonate an NHI - in particular, phishing, endpoint/workload breach, and trusted relationships exploitation.

As we can see from past breaches the bulk of identity attacks are credential-related, just a few examples:

1. The recently branded UnOAuthorized attack against Microsoft apps involves credentials attached to service principals and then misusing these credentials for persistence and privilege escalation
2. The AWS credential leak campaign reported by Palo Alto Unit 42 is another example of NHI credentials abused
3. One of the most infamous attack vectors for AWS historically were Server-Side Request Forgery (SSRF) attacks to steal EC2 metadata credentials.

So yes, many NHI concerns are credential concerns in disguise.

While it’s not feasible to get rid of credentials altogether, short-lived credentials can greatly reduce risk and increase the ability to generate high signal detections.

Would workload-bound credentials solve the problem?

As we have discovered, one of the central issues with NHIs is that they are privileged, and impersonating one by stealing credentials is relatively easy.

Workload-bound credentials would significantly reduce the number of attacks you could carry via an NHI. If you can safely attest a device or a workload and protect its identity we would make the value of an NHI limited in that it could only be misused while maintaining persistence on the workload using it.

However, as we’ve seen in application security, even the most locked-down applications still get compromised. Locking down credentials increases the complexity of the attack but by no means solves the problem entirely.

When it comes to governance, are lifecycle management and over-privileged identities a solvable problem?

In a perfect world access issuance would be significantly down-scoped to just the number of permissions necessary for that NHI to perform its role. A good parallel to think about is sandboxing applications on desktops.

Sandboxing has been incredibly useful in reducing the odds of privilege escalation once an attacker has compromised the application. However, it is also incredibly difficult to apply in real life.

Most applications are still far from being sandboxed and it took Chrome several years and an inordinate amount of engineering effort.

If the parallel holds we can then conclude that achieving perfect least privilege won’t be feasible and we’ll have to accept a trade-off, however, it is equally true that the current state of NHI privilege management is similar to applications before sandboxing was widely used.

Is this an identity, engineering, or SOC issue?

We believe the answer is all of the above and a unified approach decreases the odds of a successful breach.

The ideal solution

The NHI problem is not fundamentally new - in fact, as an industry, we’ve had many similar challenges in the past and, as usual in security, a layered approach is the right way to think about it. In particular:

1. Short-lived credentials
2. Device/workload-bound identities
3. Down-scoped privileges for each identity
4. Governance around provisioning, de-provisioning, and federated trust
5. A detection and response framework to stop the remaining potential breaches

It is key to remember that even if 1-4 are in place, the fundamental threat still exists and is unavoidable. When we think about it:

1. Breaching a workload or a user will still happen and it will likely still result in the loss of key material later leveraged for lateral movement
2. Phishing via OAuth apps and federation can be abused to pivot from a user account to an NHI

So it’s clear that the three pillars to solve this problem are engineering, governance, and detection and response.

How close are we to that?

While there are several standards out there and, to some degree, practical implementations of device-bound tokens and ephemeral credentials, in practice, several problems emerge:

1. Most applications don’t support ephemeral credentials or even multiple credentials per tenant/account. As a result, credential rotation and revocation are risky and could result in downtime. Furthermore, several applications require a user to login through the UI to generate a new set of credentials making automation harder
2. Workload/device attestation is feasible but not trivial to solve at scale
3. Least privilege, as we discussed, is hard to achieve. For instance, AWS has 15,561 API methods and 17,181 permissions
4. Sometimes NHIs are used outside of workloads so attestation is not an option to begin with
5. Lastly a number of attack paths are not easily addressable and have never been historically, e.g.: phishing and exploitation of application vulnerabilities

So what can we practically do today?

Even though we can’t easily get to the ideal solution, several practical improvements are feasible today:

1. Use a vaulting solution to reduce the risk of credential sprawl
2. Adopt a secret scanner to reduce the risk of accidental credential leaks
3. Tokenize credentials/adopt a secret-less posture. The basic premise is to minimize the surface-touching key material to make it easier to perform rotation, reduce the odds of needing to rotate credentials in the first place and generate an audit trail on usage
4. Implement and enforce conditional access for NHIs
5. Unify observability and inventory of the various NHIs present across your environments
6. Detect and automatically respond - put a strong detection and response framework in place to reduce the risk of a lost or stolen credential or a compromised identity. According to CrowdStrike, attackers break out in approximately 30 minutes - it’s important to react automatically to reduce the blast radius of the incident.

How can SlashID help?

SlashID can help in three ways:

1. You can adopt our platform to observe, detect, and automatically respond to NHI breaches. You can read more about our approach here based on the Palo Alto Unit 42 report of the latest AWS credential theft campaign
2. You can adopt our Gate module to implement credential tokenization and conditional access for NHIs. This is an overview of how we approach tokenization
3. Provide visibility over trust relationships, privileges, and remediation capabilities to help solve the governance issue

Conclusion

We hope this blog post helped frame the issues surrounding NHIs and some of the approaches to solving them.

Ultimately the perfect solution requires a significant engineering effort from both vendors and consumers of a service, making it hard to achieve in the real world in the short term.

Until then, we believe that security teams should put in place a credential minimization strategy and a detection and response framework.

Reach out to us to let us know how you are approaching the problem or to schedule a free Identity Security Assessment!