How attackers exploit non-human identities: Workshop recap

“Identity is the new perimeter.” This catch phrase is present in almost every website of identity security vendors, and for a good reason. Human access, more commonly referred to as user access, is an established security program in most organizations – big or small. The realization that user identities and login credentials need to be vigorously protected with IAM policies and security tools like MFA or IP restrictions or via SSO happened long ago. However, when it comes to non-human access like API keys, OAuth tokens, service accounts, secrets and other programmable access credentials, the situation is very different. Lack of visibility, monitoring and governance to this permissive access is everywhere, and attackers have figured it out.

In this last part of our Technical guide to non-human identity security, we will recap our live workshop. 

How we performed a supply chain attack through NHIs

In the workshop we demonstrated a full attack path exploiting non-human identities, starting with initial access to AWS through an exposed secret in a public GitHub repo. We then continued to privilege escalation through a service account, gained access to source code, and managed to steal customer details and perform a supply chain attack. 

In this quick recap, we will cover the highlights of the workshop. 

Watch the on-demand workshop: How attackers exploit non-human identities

Phase 1: Initial access 

We started by following a company’s (SquareCD) users on Github, as users are always public. We found that one of them created a new public repository. We then cloned it and ran GitLeaks (an open source secret detection for git repos), and found some secrets. 

The most interesting one was an AWS access key. We knew it’s an AWS access key because of two reasons: the rule ID, and the prefix of the token (AKIA). Attackers use such “magic” prefixes extensively to quickly search and identify secrets they can abuse. But, the same method can also help security practitioners to better protect their environment, especially when it comes to SaaS tools. 

We used our AWS access key to configure our AWS profile, and used a special API to realize that the key belongs to a special service account, and eventually gained initial access to SquareCD’s production AWS environment.

For the full initial access process, watch the workshop recording. 

Phase 2: Performing privilege escalation in AWS 

To escalate our privilege, we continued in the unmonitored non-human identity route to try and remain undetected from security tools. Since AWS allows you to view what secrets exist even with low privileges like our service account gave us, we could see a list of all the secrets that exist in SquareCD’s AWS environment. So we went ahead and tried to find if we could see the actual secret value of any of the secrets in the list. We chose to try a SlackBot secret because it looked like it’s related to the CI/CD process. 

We found two access keys related to Slack, one belonging to a bot and the other to a user. We again started by using Slack’s auth.test API to test if the secrets are active and who they belong to.

Using the user token, we searched what channels we have access to. We found interesting channels like devchannel, sequarecd-talk, and even a customer-shared channel! Definitely a good start. We then used the search.messages function in Slack to find more tokens, using the token prefixes we already know. We searched for an AWS key by using the AKIA prefix. And we got a hit! A user shared an AWS key and forgot to delete it. This will allow us to escalate our privileges in SquareCD’s production AWS environment. 

Seeing that the AWS access key is different to the one we previously used, we tested who it belongs to and found that we’ve hit the jackpot and managed to escalate our privilege to an AWS administrator – completely owning SquareCD’s production AWS. 

Quick tip: It’s common for attackers to use prior knowledge about the magic prefix secrets start with in order to identify which service they belong to. Examples: AWS: AKIA, Slack: xoxp/xoxb. 

To continue understanding how we escalated our privileges, watch the on-demand workshop. 

Phase 3: Stealing SquareCD’s source code

Having full access to SquareCD’s AWS, we could go a few ways. We recalled seeing a secret with a name related to Github which we didn’t have access to with the low-privileged user, and decided to go for it.

Indeed, it was a personal access token of a SquareCD developer! Listing the Github repositories we found, we have access to some private repository alongside a public repository – the same one we began infiltrating into the organization with. 

That private repository seemed promising, so we searched for files and folders that would be indicative of repositories containing sensitive source code. A folder named src piqued our interest, and immediately after going into it, we saw many files associated with source code, we knew we found what we aimed for!

To see us stealing the source of SquareCD production, watch the on-demand workshop.

Phase 4: Diverting to supply chain attack

When we accessed SquareCD’s AWS, we did so using a compromised admin account. This most likely led to our efforts being exposed and our access being revoked.

To combat this, we decided to quickly utilize our entire scope of access to try and use SquareCD as a “jumping pad” to one of their customers, converting this to a supply chain attack. We divert our attention to other sensitive AWS services, starting with S3. We immediately saw some very interesting buckets:

Looking at the company-customers-data bucket, we see some files and folders that can cause some serious damage – customer agreement and payment methods.

However, when we listed the files within the employee-backup-do-not-delete bucket it looked like one of SquareCD’s employee had dumped their desktop and uploaded it to S3. Within, we noticed a directory which contained a few .json files. Downloading one, the format resembles a GCP service account public key.

Putting our sights on the most important-customer, we authenticated to GCP with their key and found that we have access! We have access as editor to the customer’s GCP project, which means full read and write access, completing our supply chain attack.

As a final step, assuming the customer will try and rotate SquareCD-associated keys after they report the breach, we decided to leave a little surprise – a backdoor key to the same compromised service account, which should stay active even under a breach investigation.

Quick tip: Many attackers gaining privileged access to an environment will utilize several tools to persist their access even under active investigation. Some of these methods include creating new users, service accounts or access keys, and generation of tokens using attacker-controlled OAuth apps mimicking common services.

Just one attack path of many 

The attack path we demonstrated in our live workshop brings to light the tactics and techniques attackers commonly use with NHIs. Clearly, there are many different attack paths through different environments and SaaS tools, but the bottom line remains the same – attackers opt to exploit NHIs not only because they are the path of least resistance, but also because NHIs allow attackers to remain under the radar while performing complex exploits. To stay ahead, we need to get inside their heads. See you at the next live workshop!