Cloud Attack Emulation: Enhancing Cloud-Native Security With Threat-Informed Defense

Speed and agility are essential for effectively achieving cybersecurity goals in this cloud-native era. High-performing engineering teams leverage modern infrastructure and technology to increase deployment velocity and capability to react to adverse changes. Cyber security is no different; agility is even more critical since detection and response to adverse conditions are often time-sensitive, especially in the face of adversity. Accordingly, cloud security teams must leverage agile and proactive approaches and implement Threat-Informed Defense mechanisms. One of these approaches is cloud attack emulation, an emerging methodology that allows quick validation of security goals by mimicking adversarial behavior.

This article discusses cloud attack emulation and its advantages and demonstrates an actual use case scenario involving the AndroXGh0st malware.

Cloud-Native Security Is Hard

Modern security teams, charged with securing cloud infrastructure, often wear many hats based on job requirements. A recent Forrester report revealed that 52% of Security Operations Centers (SOCs) lack the needed technical skills; hence, systems that simplify security job functions and enhance agility are imperative. While most security professionals would love to learn a lot and be a jack of all trades, there is a chance for teams to burn out and become victims of their ambitions. An alternative approach is to acquire the services of cyber security specialists from internal or external resources. Specialists tend to have deep knowledge and skills in several cyber security domains, including penetration testing, red/blue teaming, detection engineering, threat hunting, etc. However, while the specialists' approach to achieving organizational security objectives adds immense value, it is not a one-fit-all solution and introduces some challenges. Let's expand on two of these challenges:

Risky Waiting Time

Windows of opportunity emerge due to the waiting time introduced in scouting for cyber security specialists. Attackers could take advantage of this gap to compromise cloud infrastructure. Unlike traditional setups, modern security teams do not have the luxury of time and avoid being blockers to the business. They aim to align with the business traction and move at the same speed; hence, security teams must limit technical obstacles.

Resource Constraints

Not all organizations are equal; only some have the budget to hire cybersecurity specialists to support security objectives. This indirectly ties to the first challenge: with insufficient security budgets, and organizations tend to implement inadequate security mechanisms and eventually become low-hanging fruits to attackers.

Cloud Attack Emulation: An Overview

Cloud attack emulation provides opportunities to address the challenges highlighted above. The basic idea of cloud attack emulation is to use adversarial tactics and techniques to emulate real-world attacker behavior against infrastructure. Security tools produce output due to emulated attacks, which can then be compared with the expected results to validate several security goals, e.g., detection efficiency and threat hunting hypothesis. Similarly, this approach validates several cloud security controls, e.g., CSPM, CNAPP, CIEM, and KSPM.

Cloud attack emulation is a subset of attack emulation (also called threat emulation or adversary emulation), focused on conveying the benefits of adversarial defense to cloud-native technologies. This shift is critical as traditional attack emulation techniques are unsuitable for cloud-native environments. Furthermore, adopting attack emulation mechanisms for cloud security brings several benefits, including overcoming the challenges discussed earlier.

Rethinking Cloud Security Operations

Measuring security is challenging, and even more difficult is cloud-native security, but this is an imperative activity for most security teams. The base metric for security teams' efficiency is outlined in the security policy or summarized as security objectives. Hence, security teams periodically make assessments, compare current outcomes with the security objectives, and hope to answer a bunch of important questions, including:

• How efficient are our security objectives?
• How reliable are the signals from our security tools?
• What could we be missing, i.e., unknown unknowns?
• Are we secure/insecure?

The easy way is to rely on gut feelings and signals provided by security tooling; however, what if gut feelings are flawed and security tools are inaccurate via misconfiguration or compromise? Security tools have recently become juicy targets; attackers understand the impact of nullifying security tools, as seen in the recent Azure storage ransomware, where the attackers breached the Sophos control panel before proceeding to the Azure cloud account.

Security Tool Testing - An Imperative for Cloud-Native Security

Total reliance on outcomes from security tools is trickier than ever; it often leads to adopting a false sense of security. For example, the absence of security alerts from a SIEM does not directly equate to a sound security posture. The SIEM (replace with your fancy tool) could be operating in error for several reasons, including misconfigurations, vendor updates, and attacker action. Therefore, continuous validation of security tools via attack emulation allows teams to test security tools to enhance accuracy. Consequently, accurate results from iterative validations allow teams to build true confidence in the overall security posture while fulfilling desired security objectives. Regardless of specific job functions (detection engineers, threat hunters, SOC teams, e.t.c), cloud attack emulation enables security teams to inject attacks that mimic real adversaries, collect and analyze outcomes, and make objective decisions rather than baseless assumptions.

Cloud Attack Emulation Example: AndroxGh0st Malware

The AndroxGh0st malware is notorious for scanning for and parsing Laveral applications for secrets from exposed .env files. Attackers commonly target the .env Lavarel files, widely used for storing configuration data, including AWS, SendGrid, and Twilio credentials. AndroxGh0st has “SMTP cracking” features and can generate keys to conduct limited brute-forcing attacks against AWS infrastructure. AndroxGh0st performs one of two further actions after stealing AWS credentials: abuse the SNS for spamming purposes or create a LoginProfile to allow easier access to the AWS account. This article provides a demo of the latter: creating a LoginProfile.

Emulating AndroxGh0st LoginConsole Attack

Understanding adversary behavior has been a critical aspect of humanity; success in military warfare depends on how much of the adversary is understood. Similarly, opponents study themselves intensely in sports to avoid going blind. In cyber security, malware analysts spend hours understudying malicious software

behavior, as this provides valuable insights for evolving effective countermeasures. Similarly, this approach can be adopted to enhance cloud security. However, the effort and resources required for emulating adversaries could be expensive; hence, most security teams tend to avoid it. Mitigant Cloud Immunity addresses this challenge by simplifying and automating cloud attack emulation. Consequently, cloud security engineers can get up to speed with a few button clicks. The following example shows how easy it is to emulate the AndroxGh0st malware attack in an AWS cloud infrastructure. The attack is roughly summarized into six steps, as follows:

Step 1: The attacker steals the AWS credentials from a .env file.

Step 2: The attacker uses the stolen credentials to create a new IAM user.

Step 3: Attaching a managed IAM policy, the attacker elevates the new IAM user's privileges. In the demo, the AWSS3FullAccess policy is attached; however, it could even be a more permissive policy, e.g., the AdministratorAcccess policy.

Step 4: The attacker creates a LoginProfile to allow access to the compromised account via the AWS web browser portal.

Step 5: The attacker deletes the initially compromised key. This step is not implemented in the emulation since all resources created during the attack process would be automatically cleaned up afterward.

Step 6: The final attack step is not definite as it depends on the intentions of the attack. It could be to move laterally into the compromised account in search of specific targets or lucrative resources.

Validating Attack Detection

One crucial motive for emulating attacks is to create validation opportunities, and realism plays a massive role in the quality of the learning gained. The attack validation process allows defenders to analyze the output extracted from security controls by comparing it with the expected behavior. In this demo, we validated the attacks conducted by AndroxGh0st using DataDog Cloud SIEM , similar to other SIEMs, DataDog Cloud SIEM collects CloudTrail events from the protected AWS account. The screenshot below shows that the LoginProfile event created via the Attack Step 4 is captured, including other helpful information for investigations, e.g., source IP address and MITRE ATT&CK tactics mapped to this attack.

It is important to note that the attacker made several API calls during the compromise. In the screenshot below, 12 different CloudTrail events are reported. These events are vital as detection engineers can use them to create more accurate detection rules and automated incident response strategies. The last step is part of a SOC team's responsibility. Similarly, the output from the emulated attacks allows cloud security engineers to validate the performance of other tools, e.g., CSPMs.

Emulating Cloud Attacks with Mitigant Cloud Immunity

Modern security teams can enable agility by using tools to validate cloud security posture quickly. This approach is rare because of the time and effort required to construct attacks that run safely, gather evidence for analysis, and clean up the test environment. Mitigant Cloud Immunity takes away these pain points with its powerful cloud attack emulation approach. There is no need to invest time in attack construction, attack analysis, environment clean-up, evidence collection, etc. These requirements are available as features in a SaaS model. Furthermore, all the attacks are aligned with the MITRE ATT&CK framework and enable Threat-Informed Defense.

Mitigant Cloud Immunity implements over 40 cloud attacks for several AWS services. The attacks can be launched independently or combined to emulate multi-step attack scenarios. Furthermore, managed attacks are designed to emulate specific attacks, e.g., AWS S3 Bucket ransomware. The Mitigant Cloud Immunity is implemented based on the innovative Security Chaos Engineering approach; it allows enterprises to fast-track cyber resilience. You can quickly onboard by signing up for a 30-day free trial.