Written by Mitigant (Kennedy Torkura) and Sekoia.io Threat Detection and Research (TDR) team (Erwan Chevalier and Guillaume Couchard).

Introduction

Enterprises are increasingly using cloud infrastructure to take advantage of its underlying benefits. Unlike traditional data centres, cloud infrastructure affords business agility at a cheaper cost. Consequently, several organisations are migrating workloads to the cloud. However, cybercriminals have also noticed this trend and have started targeting cloud workloads. 

Defending cloud infrastructure is more complex than defending on-premises infrastructure. Enterprises often need support with interpreting and implementing the appropriate security controls that align with the shared security responsibility model, significantly for threat detection and response. One approach to address this gap is to leverage third-party products that provide effective cloud threat detection and response.

Aim of This Article

This article provides a use-case scenario demonstrating how defenders can address detection gaps in AWS environments. This will be achieved by combining Mitigant Cloud Attack Emulation and the Sekoia Security Operations Center (SOC) Platform. Furthermore, this article discusses how organisations can adopt a Threat-Informed Defense strategy by combining security measures, Cyber Threat Intelligence, and evaluation/testing. This strategy enables organisations to detect and respond effectively to threats lurking in their AWS infrastructure. We provide details of how Extended Detection and Response (XDR) and adversary emulation can be synergized to defend against malicious threat actors.

Threat Scenario

To demonstrate the importance of using a combined approach of a SOC Platform and adversary emulation, a threat scenario has been formulated based on a real-life attack observed by the Sekoia platform. The scenario is based on real events that emulate the Scattered Spider threat actor. It also demonstrates the effectiveness of leveraging a Threat-Informed Defense Strategy (TIDS).

The Scattered Spider threat actor is a cyber-criminal gang that has become notorious recently. Scattered Spider targets financial institutions, telecommunication organisations, and technology companies. The Sekoia Threat Detection and Research (TDR) team wrote a comprehensive blog post about Scattered Spider; you can find a detailed description of it at this link.

Threat Model

The threat model illustrates Acme, a fictitious Fintech that hosts its sophisticated banking system on AWS cloud infrastructure. John Doe, Acme’s CISO, has been bothered about the increasing popularity of the Scattered Spider Threat actor and wants to ensure that Acme is not the next victim of this notorious threat actor. He recently attended the MITRE ATT&CK Workshop in Brussels, where he learned about Threat-Informed Defense Strategy (TIDS). Consequently, he applied TIDS to enable a cyber-resilient cloud posture by adopting the three pillars: security measures, Cyber Threat Intelligence (CTI), and Security evaluation/testing.

John uses several AWS security services; however, he wants to leave no stone unturned; therefore, he adds the following cyber security products to align with TIDS:

1. Defensive Measures: Sekoia Defend is a leading SOC platform that provides threat detection and incident response capabilities offered by Sekoia.io
2. Cyber Threat Intelligence: Sekoia Intelligence, a highly structured, contextualised, and actionable CTI service offered by Sekoia.io
3. Testing & Evaluation: Mitigant Cloud Attack Emulation, the most comprehensive cloud-native adversary emulation platform, provides over 100 attacks that align with MITRE ATT&CK and MITRE ATLAS. 

 Threat Informed Defense Triad

Cloud Attack Emulation

Mitigant Cloud Attack Emulation implements several MITRE ATT&CK TTPS used by Scattered Spider. These attacks were orchestrated against Acme’s AWS environment to mimic Scattered Spider, and the Sekoia SOC Platform is used to detect these attacks. To better understand the detection, it is essential to note that Sekoia provides rules for all its customers. Therefore, sometimes fine-tuning is impossible, which explains how Sekoia builds detection rules. To compensate for that, Sekoia triages these rules by effort level (from intermediate to master). The higher the effort, the harder it is to activate the rule without false positives in a classic corporate network. However, when thousands of events sometimes raise alerts, creating a commensurate rule is non-optimal, even with a master effort. Indeed, activating the rule by mistake can be painful, and it is usually tough to filter the rule to exclude false positives in these cases. Consequently, it is much easier actually to create a specific rule instead.

A great example is the “CreateUser” event generated by AWS. Sekoia, as an editor, can’t filter out users (except maybe generic AWS service users), and the rule will just spam end customers. However, organisations can create rules with this event if they really master their environment or just perform regular hunting queries instead.

The Mitigant Cloud Attack Emulation provides a means to document the emulation’s aim and observations. It can also reverse attacks by cleaning up the environments used for them, thereby eliminating the maintenance overhead and the possibility of leaving the cloud account vulnerable. Cloud resources can be exempted from being attacked by Mitigant via the use of tags and reports containing the detailed attack steps, attack telemetry, mitigation steps, and Sigma detection rules are provided on attack completion.

Mitigant Cloud Attack Emulation Provides No-Code Interface For Executing Attacks 

Cloud Attack Phases and Detection

The threat scenario earlier described is emulated to illustrate real attacks. Adversaries tend to attack organisations using multi-step attacks captured via attack kill chains. The MITRE ATT&CK framework groups these attacks into Tactics and Techniques. Consequently, these attacks against Acme have been categorised into the following:

1. Initial Access: The attacker gains access to Acme’s corporate AWS account using stolen credentials obtained through phishing.
2. Execution: The attacker enables serial console access to EC2 instances to bypass network security controls.
3. Persistence: The attacker creates new IAM users and backdoors existing IAM users.
4. Privilege Escalation: The attacker weakens IAM password policies to facilitate further attacks.
5. Defense Evasion: The attacker deletes VPC subnets and disables domain transfer locks to hide their activities.
6. Credential Access: The attacker compromises Lambda credentials and retrieves secrets from AWS Secrets Manager.
7. Collection: The attacker replicates S3 buckets and exfiltrates sensitive data.

The following paragraphs describe how the Sekoia platform detects the emulated attacks, including the interaction between Sekoia Defend and Sekoia Intelligence. The attacks are emulated from Mitigant Cloud Attack Emulation, thus clearly demonstrating how security operation teams can practically implement a Threat-Informed Defense strategy in cloud environments like AWS.

Initial Access

At this step, the attacker uses stolen AWS credentials obtained via phishing. Bob from Acme’s finance department receives a malicious email. It contains a link to a fake corporate website hosted on the IP 149[.]248[.]8[.]85, associated with Scattered Spider. The user’s workstation, configured to use a corporate web proxy solution hosted on AWS, logs this activity. Sekoia.io’s Intelligence Feed rule detects this suspicious IP access. This is made possible because this kind of attacker’s infrastructure is continuously tracked to add the relevant indicator of compromise (IOC) daily, with the most accurate date to avoid false positives.

The “Serial Console Access” attack Implemented in Mitigant is a Common Technique Used By Scattered Spider.

Execution

At this step, the attacker enables serial console access to EC2 instances, bypassing network security measures and triggering the event “EnableSerialConsoleAccess.” This allows the attacker to directly connect to the interesting EC2 instance from the AWS console, thwarting the other security protection. The Sekoia.io rule “AWS CloudTrail EC2 Enable Serial Console Access” detects this action.

Persistence 

At this step, the attacker creates backdoor IAM users, raising the “CreateAccessKey” and “CreateUser” events to secure future access to the tenant. While these events are noisy, creating specific detection rules tailored to the environment can help identify these activities. Indeed, as explained earlier, sometimes Sekoia does not have rules for highly noisy events. In this case, it is better if the customers create their own rules since they know which user is suspicious and can build quality rules that trigger fewer false positives.

Privilege Escalation

At this step, the attacker degrades the account password policy, triggering the “UpdateAccountPasswordPolicy” event. This step can also be used to break into other accounts in the future. The Sekoia.io rule “AWS CloudTrail IAM Password Policy Updated” effectively monitors this less frequent event. Mitigant implements this attack by degrading the password policy to the lowest possible pattern, i.e., six characters, no special character.

Defense Evasion 

At this step, the attacker deletes VPC subnets, triggering the “DeleteSubnet” event and disables domain transfer locks, triggering the “DisableDomainTransferLock” event. The subnet modification could help the attacker bypass some network segmentation. Disabling the domain transfer protection mechanism could allow the attacker to attempt the next step of hijacking the target domain name. These actions are detected by the Sekoia.io rules “AWS CloudTrail EC2 Subnet Deleted” and “AWS CloudTrail Route 53 Domain Transfer Lock Disabled.”

Credential Access 

At this step, the attacker compromises Lambda credentials, raising the “ListFunctions20150331” event. This and subsequent “Decrypt” events can be monitored, but creating effective detection rules can be challenging. Since both events are raised several times, it is best to create tailored rules for each environment, where there are only a few accesses to Lambda, and therefore, legitimate activities can be easily excluded.

“Malicious Bucket Replication” Attack Launched from Mitigant Showing the Corresponding MITRE Tactic & Techniques

Collection and Data Theft

At this final step, the attacker configures malicious S3 bucket replication, triggering the “PutBucketReplication” event. This is quite effective for the attacker to automatically collect and exfiltrate every data from the target’s tenant without using any specific tool. This action is detected by the Sekoia.io rule “AWS CloudTrail S3 Bucket Replication“

Lessons Learnt

• CTI helps in detection but also in contextualising attacks to have a better understanding and perform further investigation.
• Alert fatigue is one of the most complex problems in SOC teams. Triaging rules by effort level and fine-tuning the highest-effort (master-level) rules is great. Sometimes, however, it is better to let the customers create the rules if they require too specific tuning. The Sekoia AI assistant can help create the rules.
• Sometimes, the events are insufficient to perform an excellent detection rule that does not raise thousands of false positives. Correlation might be the key in some cases.
• Attack emulation helps test the rules and ensure you have great coverage.
• Context is crucial, and even when security measures are implemented with detection rules and CTI, security teams need to add their context to reduce false positives. Emulating attacks in the environment provides an excellent approach for deriving the precise context.

Conclusion

Threat actors are increasingly targeting cloud infrastructure due to the increasing adoption of cloud infrastructure. While the business needs to push for agile product development and deployment, security teams constantly battle the rapidly increasing security risks that appear alongside business agility. Security teams must adopt approaches that allow precise threat optimizations with minimal alert fatigue and false positives. Threat-Informed Defense strategy provides a meaningful approach given its empirical alignment with real attacks. This post provides an instructive scenario based on the Scattered Spider, a notorious threat actor that recently gained traction through involvement in several high-profile attacks. Organisations can derive many lessons from the attack used in this scenario and the detection approaches to improve the cloud security posture.

Take charge of your cloud security posture today by adopting a Threat-Informed Defense Strategy. Get in touch with Sekoia.io at https://www.sekoia.io/en/contact/ and sign-up for a FREE trial of the Mitigant Cloud Security Platform at https://www.mitigant.io/en/sign-up.

Sigma Rules

• AWS CloudTrail S3 Bucket Replication
• AWS CloudTrail EC2 Enable Serial Console Access
• AWS CloudTrail IAM Password Policy Updated
• AWS CloudTrail EC2 Subnet Deleted
• AWS CloudTrail Route 53 Domain Transfer Lock Disabled

Feel free to read other Sekoia.io TDR (Threat Detection & Research) analysis here :

Share this post: