SECURITY

Detecting Cloud Account Takeover Attacks: Threat Research Release, October 2022

The Splunk Threat Research Team (STRT) recently released three new analytic stories, Azure Active Directory Account Takeover, AWS Identity and Access Management Account Takeover and GCP Account Takeover, to help security analysts detect adversaries engaging in cloud account takeover attacks against some of the largest public cloud service providers. In this blog, we describe the telemetry available in each of the cloud providers and the options teams have to ingest this data into Splunk. Finally, we highlight some of the detection opportunities available to cyber defenders in the released analytic stories.

Watch the video below to learn more about some of the attacks we simulated against cloud lab environments and how security teams can detect them using Splunk.

Introduction

Account Takeover (ATO) is an identity attack whereby cybercriminals gain unauthorized access to online accounts by using different methods like password spraying, social engineering, malware infections and credential stuffing. This access can then be abused to pose as a real user and perform malicious actions like changing account details or stealing sensitive information. In some scenarios, the compromise of a single employee’s online account can lead to an attacker expanding their access within the target organization and taking control of sensitive internal systems or applications. 

Throughout 2022, we have seen this threat materialize across several breaches performed by the Lapsus$ group. Rather than utilizing traditional methods like deploying malware and compromising victim networks through command and control channels, this actor has been able to obtain access to sensitive information and privileged access to large enterprises by using a combination of social engineering and stolen credentials. 

Monitoring For Cloud Account Takeover

Effective monitoring for cloud account takeover accounts requires the ingesting and indexing of  authentication and account activity telemetry. This telemetry is typically available within the identity provider leveraged by the particular cloud provider. An identity provider is a system entity that creates, maintains and manages identity information for principals and also provides authentication services to relying applications.

In this section, we will provide a high-level overview of the native identity providers leveraged by Amazon Web Services, Microsoft Azure and Google Cloud Platform. We will also cover the telemetry made available by these identity providers and the options security teams have to ingest this data into a Splunk stack.

Azure Active Directory

Azure Active Directory (Azure AD) is Microsoft's enterprise cloud-based identity and access management (IAM) service. Azure AD is the authentication backbone of services like Microsoft 365 (previously Office 365), the Azure portal, as well as thousands of other cloud-based applications via the OAuth protocol. Azure AD can also sync with on-premises Active Directory environments and provide authentication to internal resources like applications on a corporate intranet. According to Microsoft, Azure AD manages more than 1.2 billion identities and processes over 8 billion authentications per day.

Telemetry and Logging

Azure AD provides three activity log categories. For the account takeover use case, we mostly leveraged the Sign-ins and Audit log categories. 

Name

Description

Sign-ins

Information about authentication attempts.

Audit

Information about changes applied to a tenant such as user modification and group management.

  Provisioning  

Activities performed by the provisioning service, such as the creation of a group in ServiceNow.

Ingesting Azure AD logs into Splunk can be done leveraging the Splunk Add-on for Microsoft Cloud Services, available for download in Splunkbase. The Splunk Threat Research Team followed the official documentation to set up the integration with an Attack Range environment in a few steps. Splunk Cloud users can also leverage Data Manager, which recently announced support to onboard Microsoft Azure data sources.

AWS Identity and Access Management

Amazon Web Services (AWS) Identity and Access Management (IAM) is a service that facilitates the identity and authorization between users, AWS resources and other AWS services. For example, if an AWS user wants to access, update or delete some files on Amazon Simple Storage (S3), the user request will be examined by default IAM, which will identify the user making the request and allow or deny the request based on the permissions granted to the user in attached IAM policy. These policies are an integral part of IAM and are attached to all users and groups of users which articulately describes what resources they can access.

Telemetry and Logging

There are 3 major ways to monitor AWS IAM logs: 

Name

Description

AWS Cloudtrail

This service has information about any activities taken by a user, role or an AWS. Services are recorded as events in Cloudtrail.

AWS Identity and Access Management Access Analyzer

This service is provided by AWS and it helps identify how accounts and users are utilizing the AWS resources, and validates IAM policies against policy grammar and best practices. 

Amazon CloudWatch Logs

This centralizes logs from various Amazon services (EC2, S3, Route53, Lambda, etc) and AWS Cloudtrail to help monitor, store and query from a single console.

For the account takeover use case, we will focus on AWS Cloudtrail logs. It is a very rich data source and well explained logging format. Cloudtrail service logs everything security teams would need to investigate threats. These logs also help with risk auditing, governance and compliance of your AWS Account.

Essentially, Cloudtrail records all API activity and interaction with the AWS Console, which is very useful for hunting adversaries and finding misconfigurations in your AWS account to help secure your AWS environment.

Ingesting AWS logs into Splunk can be done by leveraging the Splunk Add-on for Amazon Web Services, which is available for download from Splunkbase. The Splunk Threat Research Team followed the official documentation to set up the Cloudtrail logging from an AWS account to a Splunk server running in with an Attack Range environment in a few steps. Splunk Cloud users can also leverage Data Manager, which recently announced support to onboard AWS logs.

Google Workspace

Google Cloud provides a variety of public cloud services for computing, storage, networking, machine learning and application development. To manage the identities that interact with the resources on Google Cloud, it has several offerings including Google Cloud Identity, Google Workspace and third-party integrations to assist with Single Sign-Ons.

Google Workspace (GWS), previously known as GSuite, is usually only known for its  collaboration and productivity tools like Gmail, Calendar, Meet and more. However, GWS is also an identity provider and enables administrators to manage users as well as access policies. Based on our survey, GWS is the most common identity provider leveraged by Google Cloud customers. 

Telemetry and Logging

Google Workspace provides a comprehensive list of audit logs. For the account takeover use case, we leveraged User and Admin audit logs ingested from APIs using the Splunk Add-on for Google Workspace. It's important for security teams to learn about the data retention and lag times affecting GWS. For some events, it can take up to a few hours for the data to be available on the Google Admin console and to be indexed in Splunk.

Name

Description

Admin Log Events

These logs contain a record of actions performed in your Google Admin console, such as when an administrator added a user or turned on a Google Workspace service. 

User Log Events

These logs contain a record of critical actions carried out by users on their accounts. These actions include changes to passwords, account recovery details (telephone numbers, email addresses) and 2-Step Verification enrollment. 

Audit Logs Events

Configure Google Workspace to share data with the organization’s Google Cloud Platform and ingest these events via Splunk Add-on for Google Cloud Platform. These events contain Group Enterprise, Admin, User, OAuth and SAML based events generated from Google Workspace

The Splunk Threat Research Team followed the official documentation to set up the Google Workspace activity report data logging from a test Google Workspace environment to a Splunk server running in an Attack Range environment. Splunk Cloud users can also leverage Data Manager, which recently announced support to onboard Google Cloud Platform Audit logs.

  • There are two ways to onboard these user authentication logs into Splunk:
    Splunk Add-on for Google Workspace: This allows a Splunk administrator to collect Google Workspace event data using Google Workspace APIs. These logs are based on user log events like authentication, password change, and 2FA enrollment from the Google audit reports.
  • Splunk Add-on for Google Cloud Platform: Administrators can configure Google Workspace to share logs with Google Cloud Platform and ingest these into Splunk via prescribed inputs in app or by configuring HEC in Splunk to collect events via Google Pub/Sub.

The three account takeover analytic stories developed by the Splunk Threat Research Team (one for each cloud provider) include a total of 27 detection opportunities and cover 7 unique MITRE ATT&CK techniques and 6 sub-techniques. Security teams may leverage these analytics to catch potentially malicious behavior against cloud tenants in real-time monitoring as well as threat-hunting exercises. 

The following table provides a summary of these detections across the different cloud providers. For more details, visit the individual analytic stores at research.splunk.com:

 

Name

Id

Tactic

Platform

Description

Authentication Failed During MFA Challenge

T1078

Initial Access

Azure

GCP

AWS


This analytic identifies an authentication attempt event that fails during the Multi-Factor Authentication challenge. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled.

Multi-Factor Authentication Disabled

T1556

Defense Evasion

Azure

GCP

AWS

This analytic identifies an attempt to disable multi-factor authentication for a cloud user. An adversary who has obtained access to a tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account.

Multiple Failed MFA Requests For User

T1621

Credential Access

Azure

GCP

AWS

This analytic identifies multiple failed multi-factor authentication requests for a single user within a cloud tenant. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications or SMS messages, potentially resulting in the user finally accepting the authentication request.

Multiple Users Failing To Authenticate From Ip

T1110.003

Credential Access

Azure

GCP

AWS

This analytic identifies one source, Ip, failing to authenticate with 30 unique valid users within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against a cloud tenant to obtain initial access or elevate privileges.

Unusual Number of Failed Authentications From IP

T1110.003

Credential Access

Azure

GCP

AWS

This analytic identifies one source, IP, failing to authenticate with an unusual number of unique valid users. This behavior could represent an adversary performing a Password Spraying attack against a cloud tenant. The detection calculates the standard deviation for source Ip and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts.

Successful Single-Factor Authentication

T1078

Initial Access

Azure

GCP

AWS

This analytic identifies a successful authentication event against a cloud tenant for an account without Multi-Factor Authentication enabled. This could be evidence of a misconfiguration, a policy violation or an account takeover attempt that should be investigated.

Azure Active Directory High Risk Sign-in

T1110.003

Credential Access

Azure

This analytic triggers on a high-risk sign-in against Azure Active Directory identified by Azure Identity Protection. Identity Protection monitors sign-in events using heuristics and machine learning to identify potentially malicious events and categorizes them into three categories: high, medium, and low.

AWS Credential Access GetPasswordData

T1552

Unsecured Credentials

AWS

This detection analytic identifies more than 10 GetPasswordData API calls made to your AWS account with a time window of 5 minutes. Attackers can retrieve the encrypted administrator password for a running Windows instance.

Detect AWS Console Login by New User

T1552

Unsecured Credentials

AWS

This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour.

Detect AWS Console Login by User from New Country

T1535

Unused/Unsupported Cloud Regions

AWS

This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour.

AWS Credential Access RDS Password reset

T1110.002

Password Cracking

AWS

The master user password for Amazon RDS DB instance can be reset using the Amazon RDS console. Using this technique, the attacker can get access to the sensitive data from the DB. Usually, the production databases may have sensitive data like credit card information, PII orhealth care data. This event should be investigated further.

Detect AWS Console Login by User from New Region

T1535

Defense Evasion

AWS

This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour.

Conclusion

The actions carried out by Lapsus$ bring to light the risks and potential consequences associated with account takeover and identity attacks. It is likely that other threat actors, attracted by the success of Lapsus$, will start leveraging a similar approach to target organizations. The Splunk Threat Research Team (STRT) recommends complementing common prevention controls like password policies or multi-factor authentication with a detection approach. Cyber defenders should design and deploy effective monitoring capabilities that allow them to promptly detect and respond to suspicious activity that could be related to these types of attacks.

Learn more

You can find the latest security content on Splunkbase and GitHub. These detections are already available in Splunk Enterprise Security via an ESCU application update process built into the product and in Splunk Security Essentials (SSE) via API update.

For a full list of security content, check out the release notes on Splunk Docs.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Mauricio Velazco, and Bhavin Patel for authoring this post and the entire Splunk Threat Research Team Jose Hernandez, Teoderick Contreras, Rod Soto, Michael Haag, Lou Stella, Eric McGinnis, and Patrick Bareiss for their contribution to this release.

We would also like to thank Atomic Red Team, Stratus Red Team, and Beau Bullock for providing open-source tools for attack simulations.

 

The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.


Read more Splunk Security Content

TAGS
Show All Tags
Show Less Tags