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

Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we no longer use. For more information on our updated terminology and our stance on biased language, please visit our blog post. We appreciate your understanding as we work towards making our community more inclusive for everyone.

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.

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:

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.

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:

• Azure Active Directory Account Takeover
• AWS Identity and Access Management Account Takeover
• GCP Account Takeover

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.