Want Better Cloud Security? Make Your Detections Multi-Dimensional
How detection engineers are using data from other sources to secure their clouds
It took decades for the security community to get the upper hand against attacks on endpoints, and cloud environments pose an even bigger detection challenge. Where endpoint attacks often involve malware to package attacker capabilities, cloud attacks succeed through seemingly legitimate requests to the cloud provider. In the hustle and bustle of an enterprise cloud environment, atomic (one-dimensional) detections face a harsh tradeoff between low accuracy and overwhelming noise. Correlating between cloud and non-cloud activity can provide fidelity for effective detection coverage.
Most Cloud Detections Don’t Work
A recent study of cloud threat detection by Invictus IR should be a wake-up call for any SOC with a cloud footprint to secure. The researchers ran 32 well-known attack techniques in AWS, each leaving traces in the CloudTrail logs. Despite having access to evidence of the attack, the researchers found that “GuardDuty only triggered for just three of the simulated attacks, which is very limited. Especially because these attacks are all well-known.”
The built-in AWS threat detections were a no-show. Sigma, the leading open-source project for threat detection rules, also failed the test, with barely a third of attacks being detected. You can see how few of the well-known attack techniques were identified in the table below.
But wait! The results reflect only the disturbing proportion of false negative results (93% and 66% respectively). In a real deployment where detections feed a SOC’s alert backlog, detection rules must also demonstrate a low level of false positive results. Would the Sigma rules triggered in the study fire excessively in the real world?
On review, I believe many of the study’s successful detections would not have been enabled in a production environment. For example, IAM Backdoor Users Keys accounted for three of the eleven hits in the lab. This detection rule is designed to identify when an AWS API key is created for one user by another, which could indicate a backdoor being set up for persistent access to the AWS environment. The logic filters out cases where users create keys for their own account, aiming to reduce false positives. However, there are many legitimate cases in a real environment that meet this criteria- including developers and admins going about their daily duties.
Two successful detections were attributed to the rule AWS STS Assumerole Misuse, but the name is misleading. The rule triggers on the use of AssumeRole by an entity with the AssumedRole identity type, where the session issuer is also a role. The documentation warns that this activity is not necessarily misuse:
falsepositives:
AssumeRole may be done by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
AssumeRole from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
That sounds like a lot of work for the triage team. So much extra work that they’d probably shut the rule off entirely. How can a detection engineer reduce the noisiness so that rules stay enabled and ready to detect cloud attacks? And what about spotting attack techniques that seem to blend in with the normal activity of the cloud environment?
Bringing in Another Dimension
Like a detective collecting evidence, cloud threat detection should include more than one log source. An attack that is easy to miss when looked at only from the cloud perspective can become obvious when looking across cloud, endpoint, identity, and other types of activity. This turns the cloud’s unique properties (API-driven, all activity associated with a user) to the defender’s advantage.
Detection engineers can still start with basic detections like those from the study above. To improve their fidelity so that they become useful in a real-world environment, the rules can be expanded to account for the involved users, assets, and networks. Weak signals that would otherwise be ignored can amplify the detection such that when it alerts- the SOC does take notice.
Design decisions and tooling selection determine how easy it will be to create these high-fidelity detections. Because logs from different sources may arrive at different times, a log repository that depends on combining or enriching data at load time may struggle to support multi-dimensional detections. Data platforms that are good at join operations, on the other hand, make it easy to combine signals from different sources at query time. This is an area where the Splunk Effect pushes analysts to search for standalone indicators, while SQL-based analytics encourage analysts to combine dimensions like Lego blocks.
Getting Started
Building multi-dimensional detections is not rocket science. SOC analysts can start with threat modeling as described in The Detection Responsibility Handshake and consider the different areas where an attack would likely leave traces. Combining these areas into one detection can achieve the fidelity required for use in prod.
Once you have in mind the two or more activity types you want to combine, you’ll need to determine the field that they have in common. This is known as the join or pivot field. For example, to combine cloud and endpoint activity, you may join on the email address associated with the cloud user and the endpoint agent. Sometimes, this field is present in each of the logs, and sometimes, a lookup table is required. That table would be kept up to date with a mapping of computer names to email addresses, for example, based on data pulled from a CMDB.
The following three screenshots demonstrate a multi-dimensional detection implemented in SQL. This detection is designed to catch an attacker in the recon stage, early in the kill chain. A detection engineer may start by looking at AWS CloudTrail, where a bunch of enumeration events have taken place:
However, this logic on its own would be too noisy in production. Many legitimate use cases and tools run “describe” and “list” commands across AWS resources. Rather than giving up on detecting reconnaissance in the cloud, the detection engineer can add another dimension based on their threat modeling. They might reason that an attacker who compromises a cloud admin’s laptop would do a few things once they’ve established a foothold.
One of the attacker’s moves would be to enumerate the cloud resources that the compromised admin can access. Another would be to scan the local network to identify vulnerable hosts that would be more persistent and reliable than a laptop, such as local file servers or network devices. These scans could be identified by looking at network connections recorded by the EDR agent.
A user performing both scans around the same time is much less likely to happen during normal operations. To combine the two signals into one high-fidelity alert, the detection engineer would join the two logic blocks above into one query that can run against the aggregated datasets. In this example, a helper function resolves the user’s identity based on their hostname or cloud resource identifier. The function referenced below would reference the lookup table described above, where CMDB data is regularly pulled in to map hosts to users or cloud user accounts to email addresses.
The query above combines the two previous queries into multi-dimensional detection logic. A platform like Anvilogic that supports SQL JOIN operations could be used to operationalize these rules by automatically adding the necessary time windows, scheduled execution, and version control.
More Examples
Many cloud detections look for actions that are easy for attackers to bypass, such as root user activity in production, or logging being disabled. Multi-dimensional detections can help with more realistic attack techniques, such as stolen credentials used to tamper with a cloud environment. What might that look like?
An attacker that steals a user’s access token from a public code repository could limit their actions to blend in with the cloud environment, but they would need to use it from their own systems. A multi-dimensional detection could check for activity in the cloud control plane that doesn’t align with the corresponding activity on the user’s endpoint. The lack of network activity for a user supposedly interacting with the AWS console, for example, could be a dead giveaway.
A similar approach could amplify weak signals from a security agent on the endpoint. If a laptop or server triggers some low-severity endpoint detections, the SOC would likely not be notified. A report from Microsoft’s IR team describes how threat actors often deploy malware as a stepping stone toward more sensitive environments:
Tokens can also be stolen from endpoint devices themselves via credential-stealing malware. Microsoft IR has been engaged with organizations where credential-stealing malware was installed on an administrator’s endpoint device via an initial phishing email. While the admin used separate accounts for their day-to-day and administrative work, the Global Administrator had signed into both accounts from the same device. The malware had the capability to extract all the credentials and tokens on the device, eventually leading to tenant-level compromise.
Tokens on endpoints are typically stored as cookies, and theft can occur in several ways. Commodity malware such as Emotet, Redline, IcedID, and others have the capability to steal both credentials and tokens. Pirated or cracked software often has token and cookie stealing malware embedded within it as well.
Weak signals around malware activity or pirated software could serve as one detection dimension. When they happen in conjunction with cloud account role assumptions or privilege escalations for the host or associated users, a high-severity alert could be triggered for the SOC to investigate.
By all accounts, threat actors have become much more comfortable targeting cloud infrastructure. It’s now on security operations teams to keep up on the detection side. But as we saw in the Invictus report, relying on alerts from the cloud service provider is risky, and community-based content for cloud detection remains basic and noisy. Effective cloud threat detection takes a more advanced approach—with multi-dimensional threat detection providing an opportunity for defenders to gain the upper hand against attackers in the cloud.