Techniques

What is it?

Cloud Accounts is the MITRE ATT&CK technique for when an adversary abuses a legitimate account in an intrusion into an organization’s cloud environment. The technique is extremely broad in the context of the cloud, since legitimate accounts are among the only ways that an adversary can interact with their victim’s cloud. APIs are the crucial knobs and dials that allow an adversary to accomplish their goals in the cloud, whatever they are, and a valid cloud account is the essential prerequisite for accessing APIs. In this way, cloud accounts are more of a means to an end than a standalone adversary technique. It’s also inextricably bound to the major trend (identity) covered earlier in this report, as accessing a valid cloud account almost always entails compromising an identity. Further, accessing cloud-hosted emails is one of the ends that an adversary may seek when exploiting valid cloud accounts, which is why it should come as no surprise that Email Hiding Rules and Email Forwarding Rules are also in our top 10.

Most confirmed threat detections that are associated with the cloud accounts techniques in our dataset arise from a mix of alerts from identity providers, custom detection analytics leveraging identity telemetry, and malicious activity occurring in cloud-hosted email services (more on this in the following section). In addition to these, we also detect activity emanating from valid cloud accounts based on alerts from cloud service providers and custom detection analytics built on top of logging capabilities provided by the cloud providers.

In general, upon gaining access to a cloud account, adversaries typically perform various Account Manipulations, like gathering long-term credentials, gaining new permissions, or taking advantage of misconfigurations to maintain persistence or elevate their privileges. They may also perform discovery actions to enable pivoting to resources of interest such as email, internal company chat resources, document storage, Git resources, and more.

The precipitous rise of cloud account abuse in our detection dataset is the result of five interrelated factors:

1. technique broadness (as discussed above)
2. increased adoption of cloud technology among businesses
3. internal security teams emphasizing cloud security in response to increased adoption
4. security vendors emphasizing cloud security to help internal security teams meet their newfound cloud security needs
5. adversaries following enterprises into the cloud

As such, the data and systems that adversaries have always sought are increasingly moving to the cloud. At the same time, there’s increased visibility from defenders into the cloud, both internally and from third-party vendors. As a result (and as an industry), we’re seeing a lot more malicious and suspicious cloud activity than we have in years past.

The broadness of this technique makes it difficult to succinctly summarize what exactly adversaries are doing in the cloud, but, in a general sense, they’re using whatever APIs are available to them to access the data and systems that are valuable to them. You can read the Cloud Accounts section of the Threat Detection Report for a more detailed look at cloud intrusions. However, you don’t necessarily need to know what an adversary’s ultimate objective is in your cloud to reduce the risk associated with its compromise.

What can we do about it?

A cloud defense strategy effectively comes down to three broad categories:

• securing identities
• avoiding misconfigurations
• monitoring API usage

We covered identities extensively earlier in this report, but we’ll briefly reiterate some of the key recommendations security teams can follow to lock down the identities that can provide adversaries access to your cloud accounts:

• Implement and enforce MFA across your corporate identities
• Leverage conditional access policies to block suspicious logins
• Use passwordless or hardware-based authentication solutions where feasible (especially for highly sensitive accounts)

Take advantage of short-term access solutions like Entra ID PIM or AWS STS to prevent adversaries from getting their hands on long-lasting access tokens

Practically speaking, organizations should also assume that accounts can get compromised, and they should strive to implement defense-in-depth strategies for protecting their cloud environments accordingly.

Misconfigurations that leave cloud resources accessible on the open internet have been the source of countless cloud breaches over the years. Unfortunately, documenting all the various ways to avoid misconfiguration across multiple cloud service providers and their innumerable services would require an entire standalone report. So, put briefly, it’s important to educate anyone who’s spinning up cloud services and applications about the configuration options available within the cloud services and providers they’re using and the implications of those configuration options.

Last but not least, APIs are basically the LOLbins of the cloud. Nearly every malicious or suspicious action that an adversary might undertake in the cloud involves the use of one API or another. It’s critically important that security teams understand the APIs that adversaries frequently abuse and, just as importantly, that security teams have reliable visibility into API usage across their cloud infrastructure. This alone though isn’t enough. Differentiating benign from malicious API use in the cloud is a tricky problem, so it’s necessary that security teams monitor all API usage and become deeply familiar with what’s normal and what isn’t.

The following is a non-comprehensive list of cloud log sources that security teams should consider collecting from across the big three cloud providers.

AWS:

• AWS CloudTrail
• Amazon GuardDuty
• AWS CloudWatch
• Amazon Detective
• Amazon Security Lake

Azure:

• Audit logs
• Interactive Sign In Logs + Non-interactive Sign in Logs
• Azure Activity (“control plane”)
• Resource/Diagnostics Logs per resource (“data plane”)
• Graph API Activity Logs

Google Cloud Platform:

• Cloud audit logs

What are they?

Email Forwarding Rules and Email Hiding Rules are two distinct but closely related ATT&CK techniques that we attempt to track separately across detections as best we can. However, we’re grouping them together here because many of the custom detection analytics we leverage to detect suspicious email activity are somewhat ambiguous in the sense that they can unearth both email hiding rules and email forwarding rules. With additional context, you may be able to differentiate the techniques in some circumstances, but there are also times where email forwarding and hiding are happening concurrently. Beyond that, adversaries often leverage these to conduct similar types of attacks, predominantly BEC but also espionage and reconnaissance.

In either case, the general goal is to compromise an email account, typically after compromising an identity, and then to either:

1. exfiltrate email (i.e., when the forwarding address is to an adversary-controlled external email address)
2. send email on behalf of the compromised identity, abusing the established trust of the identity

Adversaries leverage compromised email accounts in an effort to reroute payments in one form or another. Two common examples include leveraging a legitimate email account to contact the payroll department and convincing them to update the employee’s direct deposit account so that an employee’s paycheck is sent to an account controlled by an adversary. Adversaries also compromise the accounts of procurement employees (or any employees that receive payments for that matter) and use them to trick vendors into routing payments to bank accounts controlled by the adversaries rather than to an organization’s legitimate business account.

Adversaries create email forwarding rules to send emails from a particular sender or that contain specific keywords to a location—like a newly created folder where the legitimate user is unlikely to look—or to an external email address. Similarly, email hiding rules typically involve an adversary blocking a sender, marking their emails as spam, or otherwise routing email messages to places where the legitimate user won’t look, like the archive folder, for example.

What can we do about it?

We’ve included extensive detection guidance on how to spot these activities in the Email Forwarding Rules section of the Threat Detection Report as well as in the Email threats section that you can find in the Threat Detection Report archive.

Office 365 users can disable external email forwarding rules for their organization by following this guide by Microsoft. Google has a similar guide for Google Workspace users.

Beyond that, most email providers have an application log of some kind that will collect the telemetry you need to gain visibility into suspicious email forwarding or hiding rules. For Office 365, this would include the Unified Audit Log (UAL), and you can hunt for email rules using PowerShell cmdlets and by monitoring other log sources. For Google Workspace users, the Security Investigation Tool will be your starting point and suspicious email rules can be observed by obtaining user Gmail settings through the Gmail API.