One such targeting method is SMS phishing, also known as “smishing,” which continues to be a notable tactic in multiple publicly reported breaches. This method involves adversaries using expendable temporary phone numbers to send text messages, leading to a full escalation chain from credential theft to data exfiltration. Its simplicity lies in the ease with which adversaries can grab a temporary phone number and swiftly deploy text messages to targeted individuals in order for them to enter credentials on their mobile phone.

How do adversaries use cloud accounts?

It’s important to note that credentials in the cloud extend beyond traditional username and password combinations. While everyday users of SaaS applications—or even small companies—may predominantly rely on these credentials for authentication, the current landscape includes a spectrum of authentication factors. In the era of single sign-on (SSO), users often experience seamless access without the need for frequent manual sign-ins. This encompasses various factors such as API keys, access tokens, X.509 certificates, biometric data, one-time passwords (OTP), and more, contributing to a multifaceted and secure authentication ecosystem.

However, with the proliferation of diverse authentication methods comes a concurrent increase in potential attack vectors. Adversaries now have a broader range of opportunities to employ sophisticated and even simple tactics to steal these various types of credentials, necessitating heightened vigilance in securing the entire authentication process. It also becomes critical to minimize account access to only the resources required to achieve operational functions, (i.e., the principle of least privilege), thereby limiting the impact if adversaries do steal any credentials.

Once in possession of legitimate account access, adversaries can closely mimic the normal behavior of genuine users, making detection a formidable challenge. Newly obtained access is often leveraged through existing web applications, endpoint applications that make use of cloud resources, or even command-line tools. Their focus is mainly to perform reconnaissance through the compromised account to further escalate their permissions and establish permissions in the cloud environment.

Once in possession of legitimate account access, adversaries can closely mimic the normal behavior of genuine users, making detection a formidable challenge.

Using automated scripts, adversaries conduct systematic reconnaissance to explore available access points. This involves leveraging data obtained through accessible web API endpoints within the cloud or SaaS product. By interacting with these APIs, adversaries acquire a thorough understanding of their current position, enabling them to identify additional accounts for potential targeting. This reconnaissance phase serves as a precursor to subsequent attacks, such as allowing adversaries to socially engineer help desk employees for password resets or take advantage of misconfigurations to access sensitive data. Learn more about this tactic on the API abuse in the cloud trend page from the 2024 Threat Detection Report.

A good example of this reconnaissance stage is sifting through files and emails in a victim’s mailbox in search for passwords or sensitive data like payroll or banking information. We often identify adversaries taking advantage of their newly gained access almost immediately after compromising the cloud account in “smash and grab” style attacks. Upon login, we often see email attachments as their main target. Additionally we’ve seen an uptick in multi-factor authentication (MFA) factor changes, where the attacker changes the SMS OTP phone number to one under their control to maintain access.

In addition to proactive employee training, it is imperative for corporations to enforce MFA for all cloud accounts. For enhanced defense, consider implementing phish-resistant MFA methods, such as FIDO2 keys, smart cards, or biometric-based authentication.

However, not all MFA factors offer the same level of security. For instance, SMS OTPs are susceptible to breaches wherein adversaries gain access to legitimate credentials and conduct a “SIM swap” to intercept SMS OTP codes. While SMS-based MFA is considered a better-than-nothing approach, it remains a potentially vulnerable mechanism.

Similar concerns apply to push notification approvals, where users manually accept prompts on their mobile devices. The term “MFA fatigue” has been coined as adversaries bombard users with push notifications, hoping for prompt acceptance and unauthorized access. Although less common, this MFA factor is still susceptible to account takeover. Nevertheless, any MFA implementation is better than none, and adherence to MFA principles is crucial:

• Something you know: password or personal identification number (PIN)
• Something you have: smart card, mobile token, or hardware token
• Some form of biometric factor: fingerprint, palm print, or voice recognition

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Most SaaS applications or cloud providers offer a rich set of logs that can be used to track system and user behaviors. The issue, as is the case with all security-related log sources, comes down to the value proposition that comes with storing them as they can be high in volume leading to high storage costs. We suggest you make every effort to collect these logs and store them for retroactive hunting and investigations. Placing them into some sort of cold storage for later retrieval is a decent strategy to decrease cost while also maintaining that high value proposition.

User Account and Logon Sessions

User Accounts and Logon Sessions are great high-level data source categories for observing cloud account authentication activity that is, by definition, a prerequisite for adversaries seeking to abuse cloud accounts.

Cloud Service, Application Log, and Web Credential

In addition to the authentication logs, we suggest closely taking a look at the Cloud Service, Application Log, and Web Credential data sources  as they will be highly valuable during your post-breach investigations.

Note: The collection sections of this report showcase specific log sources from native event logs, third-party tools, and elsewhere that you can use to collect relevant security information.

The Cloud Accounts ATT&CK technique encompasses various identity types, across various different vendors and platforms, which prompted us to compile high-level key telemetry sources that offer significant insights. The ensuing logs we’ll discuss share a commonality: they capture a multitude of actions executed by cloud accounts. These actions extend beyond mere authentication and, during the detection process, it becomes crucial to align all logic with the origin of an action—consistently tying it back to a specific cloud account. This strategic approach ensures comprehensive visibility into the diverse activities performed within the cloud environment. Below are some important log sources we have found provide the most value.

AWS

CloudTrail is AWS’s overarching management and control plane level log source. Its value within security operations teams cannot be overstated as it is often seen as a journal for all user and system behavior operating within an AWS account. It records thousands of different types of events including AWS console login events, new long term access token creations, role assumptions, and much more. For a more in-depth view we highly suggest you check out Red Canary’s AWS Visibility Guide, where we cover different types of recorded CloudTrail events that may lead to the discovery of suspicious or potentially malicious activity.

In addition to the CloudTrail control plane logs exists another layer of visibility. Data plane operations include activity occurring within a given resource as opposed to operationalization modifications (control plane). Not every AWS service has data plane records made available, but a lot of them do like Amazon S3 and Amazon RDS. Enabling data plane operations greatly increases log volume so keep that in mind.

Microsoft

Providing a comprehensive understanding of Azure logging intricacies is challenging without addressing Entra ID (formerly known as Azure AD). Azure serves as the foundational resource and cloud infrastructure housing elements such as Virtual Machines and Storage, while Entra ID is responsible for identity and access management (IAM). Both platforms incorporate role-based access control (RBAC) mechanisms, but these mechanisms fundamentally rely on the identities established within Entra ID. Each platform provides various log sources, necessitating a segmented approach for clarity. To help untangle these log sources effectively, it is necessary to differentiate between the two platforms and distinguish what you should expect from them in terms of telemetry generation.

Entra ID

Entra ID houses all of the identities and cloud accounts that access Azure resources like applications, service principals, managed identities, and users. Within Entra ID are categories of authentication logs that are recorded by default and cannot be disabled. These include:

• interactive user sign-in logs
• non-interactive sign-in logs
• service principal sign-in logs
• managed identity sign-in logs

On top of authentication logs, an audit log exists that constantly records tenant-level modifications and cannot be disabled. In essence, the Entra ID logs offer a comprehensive overview of the behaviors exhibited by your cloud accounts.

Entra ID logs offer a comprehensive overview of the behaviors exhibited by your cloud accounts.

Beyond these default logs, additional layers of visibility exist that may need to be manually enabled, though access may necessitate the appropriate license level. One intriguing new source we are eager to explore is the Graph Activity Logs, which can be seen as a sort of data plane record for their SaaS-related products. These logs offer a more profound insight into the Microsoft Graph API, the foundational interface for numerous Microsoft SaaS products like Outlook, SharePoint, and Teams. They provide detailed records of the identities involved in initiating direct HTTP requests to the Graph API, along with the corresponding request URIs and the application responsible for the request. This granular information can unveil reconnaissance activities following a compromise of a cloud account. This holds particular significance, as in cases where adversaries refrain from making direct changes within the SaaS product, conventional logs might only capture a login event.

Azure

Azure offers the capability to deploy resources in a manner similar to AWS. The Azure Activity log serves as a record capturing modifications to your resources and noteworthy RBAC assignments, such as the granting of administrative or owner level privileges within Azure’s RBAC model. Notably, the activity log cannot be disabled. In addition to this, the majority of Azure resources provide the option to also activate supplementary data plane logging similar to AWS, often termed as resource logs or diagnostic logs. These logs meticulously document resource usage, such as when someone accesses a secret or recovers a key from the vault. All of these records include the originating cloud account and can be very high in volume, depending on your organization’s specific resource utilization.

With all of the disparate log sources to review, along with rapid daily changes made to infrastructure, keeping up with your enterprise is always a challenge for defenders. It’s hard to find a security team that knows every single detail about their organization in order to make informed decisions when hunting, triaging alerts, and developing custom detection rules.

Anomaly detection and baselining normal user behaviors is becoming increasingly important— and it’s no easy task. To tackle this, we highly encourage you to regularly communicate with your internal IT teams and to generate allowlists of IP ranges your company operates within. Leveraging automation is also important, as it allows you to define access in a programmatic way and define your environment as infrastructure as code (IAC). It then becomes easier to share access information with various teams because the accounts are, by definition, documented.

Being able to quickly identify legitimate attributes of your users’ authentications can allow your teams to swiftly investigate unusual logins or post-login behaviors. Similar to how defenders tune detection logic for endpoint detection rules, having a process in place to quickly tune out specific authentication attributes is crucial.

Please note that the feasibility of the following general hunting ideas will rely on whether you have access to the proper datasets required. We find that having this knowledge or having a process in place to answer these questions is crucial during an incident response scenario:

Geographical information, like country or city

• Where are your company’s remote office locations?
• Can you identify when a user is traveling based on their calendar to reduce investigation time for anomalous location alerts?
• Can you identify what city the user normally works from?

IP address, or a known VPN or proxy

• Do you funnel endpoint traffic to proxies like Zscaler or Netskope that can easily be tuned out?
• Do you have the IP ranges of your office network, VPNs, and the ISP typically associated with it?

Typical operating systems used

• Do your users use Linux machines at all?
• Can you identify non-compliant device logins?

Applications

• When new ones arise can you quickly tune them out?
• What applications regularly access  your users’ mailboxes?

Authentication protocols

• Is it common to see non-engineers use uncommon OAuth 2.0 flows like Device Code Flow or Resource Owner Password Credentials (ROPC)?

SMS phone number for MFA

• Is it a VoIP number or a non-corporate phone number if applicable?
• Does the owner of that phone number align with the name of the user?

Job description

• For example, is it normal for a non-engineer to login via a CLI-based application on a Linux machine over a non-corporate proxy or VPN?