In December, a grand jury indicted members of the APT10 group for a tactical campaign known as Operation Cloud Hopper, a global series of sustained attacks against managed service providers and, subsequently, their clients. These attacks aimed to gain access to sensitive intellectual and customer data. US-CERT noted that a defining characteristic of Operation Cloud Hopper was that upon gaining access to a cloud service provider (CSP) the attackers used the cloud infrastructure to hop from one target to another, gaining access to sensitive data in a wide range of government and industrial entities in healthcare, manufacturing, finance, and biotech in at least a dozen countries . In this blog post, part of an ongoing series of posts on cloud security, I explore the tactics used in Operation Cloud Hopper and whether the attacks could have been prevented by applying the best practices that we outlined for helping organizations keep their data and applications secure in the cloud.

Last year, my colleague Tim Morrow and former colleague Don Faatz published 12 Risks, Threats, & Vulnerabilities in Moving to the Cloud and Best Practices for Cloud Security. This post will use Operation Cloud Hopper as a case study to examine what we got right in this posts, what we got wrong, and what we may have missed. We also hope to demonstrate how abstract concepts associated with cyber-security can be translated into specific actions and lessons.

The Cloud Hopper Method of Attack

In Operation Cloud Hopper, attackers initially used phishing emails to compromise accounts, then a malware implant to harvest credentials, followed by PowerShell and PowerSploit for command-line scripting to perform reconnaissance and gather information used for lateral movement to get access to additional systems. The attackers also use command and control (C2) to sites spoofing legitimate domains, and file-less malware that only resides in memory. The attackers leverage compromised credentials to cross security boundaries, effectively using cloud service providers as a step to gain access to corporate data of multiple organizations.

In examining these attacks against our recommendations, I used MITRE's ATT&CK Framework, which breaks different attacks into techniques that could be mapped to our previous recommendations.

To recap, the risks, threats, or vulnerabilities identified in the first blog post included the following. I highlighted in bold the ones that are particularly relevant to the Cloud Hopper case:

1. Consumers Have Reduced Visibility and Control
2. On-Demand Self Service Simplifies Unauthorized Use
3. Internet-Accessible Management APIs can be Compromised
4. Separation Among Multiple Tenants Fails
5. Data Deletion is Incomplete
6. Credentials are Stolen
7. Vendor Lock-In Complicates Moving to Other CSPs
8. Increased Complexity Strains IT Staff
9. Insiders Abuse Authorized Access
10. Stored Data is Lost
11. CSP Supply Chain is Compromised
12. Insufficient Due Diligence Increases Cybersecurity Risk

Consumers Have Reduced Visibility and Control. Because CSPs take on some responsibilities from their consumers, such as providing Identity and Access Management (IAM) tools, it reduces the amount of control and visibility those consumers maintain. APT10 used this reduced visibility to leverage credentials and/or systems that had access to both CSP and customer infrastructure. By nature, customers will not have visibility or control into the CSP infrastructure itself, making it harder for a customer to monitor and detect when attackers access one system then pivot within the CSP infrastructure to access a another system.

Credentials are Stolen. This exploit was particularly notable since Operation Cloud Hopper "heavily leverages the shared nature of client-side MSP infrastructure to move laterally between MSPs and other victims," according to a report on the attacks from PWC and BAE Systems. Although cloud computing can reduce some risks and mitigate some threats, the shared nature means that stolen credentials may grant access to the CSP and one or more customers, as appears to be the case with Cloud Hopper.

Increase Complexity Strains IT Staff, and Insufficient Due Diligence Increases Cybersecurity Risk. Although it is hard to point to the specifics in Operation Cloud Hopper, it seems clear that cybersecurity risk was high because of both increased complexity and a lack of diligence from some customers who were targeted. Rather than assigning blame, the takeaway is that the complexity of a hybrid environment involving a CSP and on-premise systems makes it hard to adequately address problems, such as stolen credentials or lateral movement from a customer to the CSP and then to a second customer. The lack of diligence by one cloud customer can increase risk even to another customer who is diligent.

Insiders Abuse Authorized Access. Reports on Operation Cloud Hopper do not reference insider threat, but some mitigations for insiders abuse of authorized access also apply to mitigating stolen credentials. Many recommendations from the SEI's Common Sense Guide to Mitigating Insider Threats could be applied to also reduce the impact of attackers using stolen credentials, including but not limited to

• knowing critical assets
• documenting and consistently enforcing policies and controls
• implementing strict account management practices
• instituting stringent access controls and monitoring policies
• define the explicit service agreement between customers and CSP
• institutionalizing change controls.

Insider threat mitigations do differ from this scenario because motivations are different, which means there are other insider threat recommendations not listed here because they would not be useful in the case of Operation Cloud Hopper.

According to publicly available reports, APT10 did not create on-demand public services, which could have made the attacks and their implications more serious. On-demand services could have provided alternate means to the PlugX, RedLeaves, and Quasar malware for remote access and other attacker functions. There were also no reports of separation between tenants failing because of exploits of vulnerabilities in software or systems in the CSP infrastructure, likely because this type of advanced attack would be of much more value and wasted when there were more basic avenues to leverage, namely credential theft.

Risk From One Customer Can Transfer to Another. In a CSP environment the risk from one customer can easily transfer to another, as mentioned above. Such a transfer seems to be a new risk. If one customer has poor risk management practices that easily allow undetected credential compromise, the impact to another customer can be similar to an organization with business partners who perform no due diligence. Unlike the case of business partners, the second CSP customer has no leverage to enforce due diligence in the first customer who is the entry point for attackers. Lateral movement from one customer to the CSP puts even an exceedingly diligent second customer at increased risk.

Traditional Risks, Threats, and Vulnerabilities. Although we only identified one risk not covered in our previous blog posts, it is important to note that many more traditional risks, threats, or vulnerabilities that are not unique to the cloud will still apply even after migrating to the cloud. The best example of traditional risks in this case is that the initial credential compromise was reportedly achieved through phishing attacks. Remote Access Trojans (RATs), PowerShell usage, and Remote Desktop Protocol (RDP) were all used after initial compromise for various purposes, none of which is unique to the cloud.

Our suggested cloud security best practices could help mitigate risk in attacks like Operation Cloud Hopper, as discussed below.

Managing Access. Managing access does not just apply to the customer. CSPs provide many security tools that can benefit customer security, as well as their own. Since phishing has been identified as a primary initial attack vector for Operation Cloud Hopper, multi-factor authentication (MFA) is a good way to improve identification and authentication of users working for the CSP and users working for the customer. Properly assigning user access rights can also potentially help by reducing instances of shared credentials. Resource access policies can also reduce opportunities for movement between the CSP infrastructure and customers.

Monitor and Defend. Analyzing both cloud and on-premises monitoring applies to deciding where to perform monitoring of both categories and how to combine the information into something that is more useful and efficient for analysts. Monitoring cloud-deployed resources by the customer is essential to increase the ability to detect lateral movement from the CSP to the customer or vice versa. Coordinating with the CSP--as well as CSP coordination with the customer--provides an effective combination of information that can increase the likelihood of detecting the post-compromise activities.

Operation. Knowing and managing infrastructure as a part of due diligence should help to identify systems or operations caused by malware implants used in Operation Cloud Hopper. Changes to production systems can be hard to detect, but in a situation where the infrastructure is treated as code, it could potentially make detection easier when systems or services are clearly operating outside of expected specifications. Infrastructure-as-code--the automated configuration, provisioning and management of technology infrastructure often used in cloud computing--will ideally provide good information to security operations about expectations of that infrastructure, so deviations from normal activity are more likely to identify malware or its activity.

In the post 12 Risks, Threats, and Vulnerabilities in Moving to the Cloud, we stated:

Cloud environments experience--at a high level--the same threats as traditional data center environments; the threat picture is the same. That is, cloud computing runs software, software has vulnerabilities, and adversaries try to exploit those vulnerabilities.

This advice deserves reinforcement considering the tactics, techniques, and procedures (TTPs) identified in public Cloud Hopper analyses. Phishing, command-and-control (C2), RATs, dynamic DNS, network and resource mapping, RDP, and data exfiltration are all tried-and-true methods for attackers that go back years. None are unique to cloud computing environments.

CSPs have the unique positions of being able to view information collected across their whole infrastructure covering numerous customers, which provides an ideal vantage point for early identification and detection of some types of activity. As attackers move across networks that are all visible to the CSP, command-and-control (C2), RAT usage, dynamic DNS abuse, network and resource mapping by attackers, and lateral movement between their customers are all identifiable. Just as customers must coordinate with CSPs, CSPs should ideally coordinate with customers when they detect suspicious activity or identify new TTPs.

Looking Ahead

In today's global environment, organizations that maintain their data and applications via cloud-based services must rely on CSPs to gain a greater understanding of the threat landscape.

One aim of this post is to motivate organizations to work with CSPs to gain a greater understanding of the threat environment and as well as their role in keeping their data and applications safe in the cloud. This post also builds a foundations for CSPs to gain a greater understanding of their responsibility for taking action to mitigate these types of attacks.

Looking ahead I am interested in examining the recommendations in our best practices post to make them more granular and actionable.

Additional Resources

Read 12 Risks, Threats, & Vulnerabilities in Moving to the Cloud.

Read Best Practices for Cloud Security.

Read the Operation Cloud Hopper report from PwC's UK Division and BAE Systems.