Detect early signs of in-progress AWS attacks

Editor’s note: Last week we released composite alerts which automate the correlation of alerts across disparate sources – log based as well as runtime detections and telemetry – to surface a single, opinionated alert that precisely identifies complex exploits which may otherwise go unnoticed by SOC teams and analysts. This blog digs deeper into one of the use-cases so you can see how Lacework does the detective work for your cloud environment to deliver higher security efficacy.

Compromised credentials remain one of the most sought after pieces of information for hackers. According to a recently released study, over 80% of hacking-related breaches involved the use of lost or stolen credentials. Yet, AWS attacks involving illicitly obtained credentials (T1078.004) remain difficult to detect.

Over the past several years, Lacework Labs has combed through petabytes of cloud telemetry to compile a corpus of several hundred unique AWS attacks in the wild involving compromised credentials. Through analysis of this data we’ve identified common tactics and techniques that are most likely to occur in an AWS attack. With composite alerts, this human intelligence component has been combined with existing anomaly detection capabilities. The result is higher confidence alerts with context and supporting evidence – two things that are often manually compiled and which can be time-consuming for incident responders.

Here we will first examine actual tactics seen in the wild involving cloud attacks and the usage of compromised AWS credentials. Next, we’ll demonstrate how these tactics can then be used as inputs to composite alerting.

Tactics & Techniques

At a high level a cloud attack involving compromised credentials involves three phases: the acquisition of the credentials, usage of the credentials to enumerate and escalate privileges against the target, and subsequently the “actions on objectives” or tasks performed to achieve the attacker’s goal whatever it may be.

Let’s briefly look at each:

Credential Acquisition

There are several scenarios when it comes to the acquisition of credentials, the most commonly observed of these involve parsing exposed keys and secrets from public repositories, GitHub gists, or similar code-sharing platforms.  Another popular method that is commonly used by AWS spambots is scanning and parsing exposed Laravel application configs. Refer to our AndroxGh0st blog for more details on this. In many cases, exposed credentials can often be deduced from observing multiple entities testing the same creds.

Host-based data theft offers another credential supply chain for attackers. There are various info-stealers, offensive or enumeration tools that include AWS keys in their list of parsed credentials – for example, Metasploit, Winpeas, and Linpeas. Various threat actors targeting cloud infrastructure including Watchdog and TeamTNT have also been known to enumerate victim hosts for cloud credentials.

Figure 1. AWS creds stealer malware – TeamTNT

Identification of the credential acquisition method can be difficult to determine from CloudTrail logs alone. However, there are a couple of exceptions. The first of these are tests performed by Gitguardian which is a common tool that’s used for scanning public and private repositories. These tests will be seen as GetCallerIdentity API requests from Gitguardian hosts and with python-requests user agents. TruffleHog is a similar tool with a user agent of the same name which allows for CloudTrail identification of credential testing.

Regardless of the credential acquisition method, it usually only comes on the radar when they’re tested or used for enumeration.

Figure 2. Cloud attack phases

Enumeration and Escalation

Upon obtaining keys, the first step is to validate the credentials. As mentioned earlier GetCallerIdentity is a popular API for this because it will always work if used with valid credentials meaning if the API request is successful, one can deduce that the credentials are valid.

Frequently the testing of credentials and actions-on-objectives can overlap. For example with the AndroxGh0st spambot malware, Lacework observed requests to the AWS SES API – GetSendQuota. The result of this request can both validate the credentials as well as determine whether the account can be leveraged for spamming. An AccessDenied error indicates valid credentials because invalid credentials will return a token error – and are not even logged to CloudTrail. Another example includes DescribeInstances which can indicate an attempt to hijack infrastructure for mining cryptocurrency. The following charts show the most common APIs seen in attacks observed by Lacework Labs. The read-and-write APIs have been distinguished as these can give context on resource modifications versus recon and information gathering.

Figure 3. Top read and write APIs used in attacks (blue and black respectively)

Escalation often goes hand-in-hand with the environment enumeration. For example, an attacker may inspect the policies and permissions for various IAM identities that they have access to. Alternatively, they may attempt to create an admin user which is the most observed tactic. There are several techniques for this, however the most common is to create a new user, attach an admin policy, and then a login profile. This allows access to the AWS management console which enables the attacker to carry out their objective in a more interactive mode. A good distinction to make on whether something is enumeration or escalation is read/write status of the API. Enumeration will usually involve read-only APIs while write APIs are reserved for escalation and/or actions on objectives. Refer to the next section for common escalation APIs.

Actions on Objectives

Lacework Labs has observed hundreds of cloud attacks involving compromised credentials and among the cases where the attacker objective is known, the majority are for resource hijacking. Among this category, most are for cryptojacking however a very close second is for SES (Simple Email Service) abuse – whether that is for spamming or malicious email campaigns. Next is data theft and exploitation which represents the most severe category – this encompasses subcategories such as espionage and financially motivated objectives including ransom activities or selling the stolen data on the black market.

Responders may observe the following APIs for various actions on objectives. Escalation and persistence APIs have also been included as this may be a primary objective for initial access brokers:

 

Resource Hijacking (T1496):

• Cryptojacking
  • DescribeInstances
  • RunInstances
  • ListServiceQuota
• SES abuse
  • GetSendQuota
  • ListServiceQuota

Data theft (TA0010):

• ListBuckets
• DescribeDBInstances
• StartExportTask
• CreateKey

Cloud Initial access broker (escalation & persistence – TA0003)

• CreateUser
• CreateRole
• AttachUserPolicy, AttachRolePolicy, AttachGroupPolicy
• CreateLoginProfile

Bringing it together with Composite Alerts

In the previous section we outlined some profiles for AWS attacks and usage of valid accounts. In many cases one could write stand-alone detections to alert on these techniques, however, the challenge always comes with false positives and context. To complicate things further, an attacker may perform the same tasks as a legitimate user. For example, both may test their permissions, enumerate infrastructure, and create users, roles, keys, or policies. This means we need to ask follow-on questions about a potential incident, such as:

• Did the activity originate from outside the environment or outside of AWS infrastructure?
• Is there threat intelligence on the source IP?
  • Is the source host a TOR exit node, anonymizing VPN, or have an otherwise bad reputation?
• Are there indications of impossible travel?  For example, are there multiple entities from different countries that are leveraging the same user identity within a short time frame?
• Are there indications of enumeration?
  • Suspicious API behavior, error code spikes?
  • Usage of offensive tools such as ScoutSuite, Kali, or secret testers?

Figure 4. Example composite alert

This is where composite alerting offers value, especially when coupled with anomaly detections. Lacework also surfaces alerts using graph-based-modeling (GMB)/polygraph which detects behavioral anomalies such as new users, regions, and connections. This provides valuable intel on the novelty of an activity. By combining this anomaly detection with security context we can achieve a much higher signal. Figure 5 shows how these various data points, such as anomaly events, and attacker tactics can be evaluated as part of a composite and then alerted to a customer.

Figure 5. Composite alert logic

Mark Twain once said that “History never repeats itself, but it does often rhyme.” The same thing could be said for cloud-based attacks. While no two attacks are identical, we do often see the same tactics and similar anomalies. And by using these as inputs to composite alerting we can more effectively distinguish a likely incident from the abundance of noise in cloud environments.

Check out our announcement blog, watch our demo video, or see the guided tour to learn more about our new capability.

To see more content like this, follow Lacework Labs on LinkedIn, Twitter, and Youtube and stay up to date on our latest research.