Tracking Adversaries in AWS using Anomaly Detection, Part 1
Cyber criminals have evolved over the years to become extremely sophisticated. Major modern day breaches are usually not one-off events; rather, are lengthy campaigns in which attackers deploy their payload on their own terms to optimize the fruits of their efforts. In carrying out such campaigns, adversaries don’t just exploit a vulnerability. Instead, they perform several types of actions in which they gain and maintain more ground for a very long time while silently deploying their payloads.
To explore this type of threat activity, we tried out the Pacu open source exploitation framework developed by Rhino Security Labs. We used the framework to showcase the parts of such a cyber “kill chain.” We demonstrated how a campaign can evolve from a seemingly harmful third-party permission to fully controlling and moving laterally through an AWS account. We then examined how Ermetic anomaly detection picks up on such behavior, enabling an organization’s defenders to respond in time and rein in the damage from such a breach.
In a recent webinar, we presented the attacker’s thinking and our project’s results. We hope these serve as a useful introduction into the world of AWS penetration testing and potential phases of an attacker’s campaign, as well as mitigating steps that you can take.
The Attacker Mindset
Before you even start trying to offset an attack on an enterprise, you have to understand the attacker’s mindset. Some think that cybersecurity is based strictly on singular events. They have a mental image of “smash-and-grab” operations that they think they should try to prevent. Have no doubt: one-off events are important to consider. Yet when cyber criminals target the infrastructure of large organizations, more often than not, the attack will be in the form of a campaign – lengthy, patient, incremental and carefully timed.
Modern-day cyber criminals are extremely capable and intelligent, and wish to optimize the gain from their efforts by putting themselves in the best position possible to deploy their payload (or payloads) on their own terms. For example, before inflicting Denial of Service, they’ll wait until they have a substantial hold on the environment. Or, before taking down an eCommerce site, they’ll wait for the most opportune time rather than act on the first day they gained the ability to do so. Alternatively, they’ll aim to have silent control over various assets – control without the victims’ knowledge – and the ability to continuously manipulate the function of those assets and/or exfiltrate potentially useful data from them.
To have this sort of flexibility when conducting a cyber security campaign, an attacker needs to do more than just exploit a specific vulnerability to which an environment is exposed. The attacker needs to be able to implement several or all phases of a cyber “kill chain.” Lockheed Martin developed the cyber kill chain concept to describe the stages of a threat attack; the concept has since been adopted as the basis for the development of similar cyber frameworks. The central idea for a kill chain is that to get the most out of an attack and, as mentioned, deploy a payload at the optimal time, an attacker needs to exercise certain abilities, such as persistence, and conduct certain actions, such as reconnaissance and lateral movement.
This modus operandi by attackers managing their campaigns (or defenders analyzing adversary activity) is probably the greatest motivator for stakeholders to take an in-depth approach in securing cloud infrastructure. Attackers no longer exploit just the perimeter (if that term still applies). They are “everywhere,” so as your organization’s defender, you should be everywhere, too.
This “be everywhere” approach is a huge challenge for defenders, yet offers a great opportunity. Trying to prevent each exploitation puts a defender at considerable disadvantage: the attacker needs to find just one vulnerability, once, whereas the defender has to protect everything all the time and also keep the business running as usual. On the other hand, once the defenders learn the lay of the land, they can make it extremely difficult for the attacker to go unnoticed in the next events to unfold.
To conduct its business in different kill chain stages, the attacker is somewhat compelled to perform several actions that could be detected and alert the defenders as to its presence. This is especially true in the cloud, where the infrastructure is mostly provisioned and controlled by API calls that can be processed, analyzed and used to create insights for such anomalous behavior. The MITRE cloud matrix offers an interesting framework for examining the various stages of a campaign in the cloud.
The “be everywhere” approach, on top of the fact that permissions are mostly managed centrally, leads to the reality that securing cloud infrastructure involves fighting not one battle, but three.
Securing a Cloud Environment: Three Battles
While the focus of this post is on analyzing and detecting anomalous behavior, let’s look briefly at the three “battles” involved in securing cloud infrastructure. The fact that in the cloud, management of various types of configurations, permissions and activity logs are mostly centralized through similar services allows for a simpler abstraction of the different stages through which the adversary advances in executing a campaign. Fighting each battle will still be complex but the abstraction helps provide a simplified, high-level framework for looking at the big picture.
Configuring the Environment Correctly
Probably the most basic practice of securing a cloud environment is controlling its security posture, detecting and eliminating or replacing vulnerable configurations with a secure configuration to minimize exposure to threats. Most security professionals in charge of cloud environments today are familiar with this practice, which is why the cloud security posture management (CSPM) security category is overflowing with vendor solutions.
The cloud made it easy for third parties to aggregate an environment’s entire configuration information and present the misconfigurations in a single dashboard. Whether a misconfiguration is due to unsecured credentials, extreme network exposure, vulnerable workloads or other, the fact that all the configurations are coming from one place makes it easy to analyze and detect related vulnerabilities.
We often find people believing this is where the fight is over; that CSPM is enough. In fact, it’s just the beginning. The practice of “bulletproofing” an environment is near-impossible. This front line that CSPM provides will likely be breached and an attacker will likely gain a foothold on the environment – which leads us to the next two battles.
Managing Permissions Using the Principle of Least Privilege
In the cloud, permissions are incredibly fluid – and complex to manage. The availability of unified mechanisms for most types of permissions to resources in the environment is great for control. However if managed incorrectly these mechanisms can (and usually do) create huge attack surfaces that, once the first battle is lost, the attacker can use to gain more ground in the environment.
The second battle constantly being waged (consciously or not) is the attempt to limit the access that attackers can get from compromised identities. By the way, since the threat of malicious insiders should be always on the radar, the battle of limiting access can be seen, from a technical perspective, as the front line.
While most CSPM tools today can provide an analysis of configurations to find posture security issues, managing access risk is much more difficult. Understanding exactly what each identity can do with each resource and, more importantly, creating rightsized policies that provide the least privilege permissions needed for an identity’s business functions – is an incredibly complicated task. Today, this kind of capability is only accomplished by specific third party technologies called cloud infrastructure entitlements management (CIEM).
A true CIEM solution enables you to know what permissions exist in an environment and which are actually needed, and provide the resources needed to remediate any gaps automatically, with no queries or coding on your part.
Detecting and Responding to an Adversary’s Anomalous Behavior
Even if you do your best to configure your posture for optimal security and provide least privilege permissions, adversaries may break through and gain just enough access in your environment to start their campaign. Many practitioners take the fact of a breach as a sign that they’ve already lost – but this is not the case! You can still take action to isolate and minimize the damage.
To carry out a campaign, an attacker will be inclined, if not compelled, to perform certain actions. Here’s the win: When you know what these actions are and how to look for them and, just as importantly, when they are performed abnormally – you can detect the adversary, eliminate its presence in the environment and more easily identify damage carried out as part of the campaign. So the third battle you want to maintain is that of anomaly detection. At this point, discovering a malicious actor and the damage done won’t turn back time and prevent the breach. However, doing so is probably the best thing you can do to prevent further damage and remediate the damage already done.
Many miss out on the potential of such defensive activity because they’re not aware of how effective it can be. To help you understand its effectiveness, we’ve created a simulation of the steps a malicious actor may take to breach an environment – and how by using an activity analysis automation tool you can stop an adversary at its game and curb the damage done.
Summary
Today’s data breaches are typically lengthy campaigns that the perpetrator conducts over a period of time, stealthily at first. Common practices for securing one’s cloud infrastructure from such breaches is configuration – or more appropriately, misconfiguration – management. However, focusing on configurations misses identifying the hacked access to permissions that enables a campaign and to the resources that are targeted and affected by the breach. To rise up against the attacker mindset and modus operandi, defenders of cloud infrastructure need to do battle on three essential fronts: configurations, as well as permissions and anomalous activity. Operating on these three fronts not only can effectively prevent an attacker from doing damage and stop one in its tracks but also provide a mitigating response to damage already done.
See Part 2 to explore more deeply how, by automating anomalous behavior detection, you can help stop adversaries and limit their damage.
The post Tracking Adversaries in AWS using Anomaly Detection, Part 1 appeared first on Ermetic.
*** This is a Security Bloggers Network syndicated blog from Ermetic authored by Lior Zatlavi. Read the original post at: https://ermetic.com/blog/aws/tracking-adversaries-in-aws-using-anomaly-detection-part-1/