Cloud Hopper: A Zero Trust Perspective
Cloud Hopper, the hacking campaign suspected to be orchestrated by government-sponsored Chinese operatives (affectionately known as "APT10”), ran from 2014 through at least 2017, and impacted multiple Western companies in a range of industries. This specific collection of cyber espionage was so significant that it continued to attract attention in both the security and business media due to the scale of the operation, the range of organisations targeted, the type of information harvested, and – most significantly – the very nature of the initial breach. Cloud Hopper achieved its now well-known name due to the attackers’ compromise of the victims’ managed service providers (MSP), leveraging these to "hop" from the MSPs’ "cloud" to the target enterprises’ networks.
There have been many excellent summaries and detailed write-ups of the breach, such as the in-depth Operation Cloud Hopper report from PWC, which provides a deep analysis of the breach. Rather than repeating the same information here, we will look at Cloud Hopper from the perspective of a Zero Trust framework, and specifically into how adopting this type of approach to security could have reduced the effectiveness of the attackers.
Forrester Research first introduced Zero Trust nearly a decade ago, advocating a shift from the “trust but verify” attitude of security to a “trust nothing, monitor everything, least privilege” approach. This shift, from relying on a large perimeter to protect a group of many assets to one where every asset is considered a target, aims to eliminate the inherent trust that makes enterprises more vulnerable to attack.
The Zero Trust framework extends across seven pillars that, when combined, provide a comprehensive strategy for securing the enterprise. It also provides a useful starting point for analysing why an attack was successful, and understanding which pillar could have helped thwart the attack had it been stronger. As will become apparent, Cloud Hopper was highly successful due to excessive levels of trust, which attackers were able to exploit in a perfect storm of control deficiencies.
The starting point, as with many data breaches, was the compromise of the People pillar. Highly targeted spear phishing attacks leveraged documents tailored to both the sector of the company being targeted. and the job function of the individual receiving the message. This helped ensure the malicious payload was executed, allowing the attacker to gain a foothold into the MSP’s network and obtain the credentials of a victim. Further, if the victims had administrative access, the "barrier to entry" was further reduced. From a Zero Trust perspective, privileged access should be delivered "Just-In-Time" (only for the time period required, and removed once access is no longer needed) based on approved business need from an authorised system.
The next pillar to fall was the Network. The malware performed reconnaissance on the organization’s network, mapping out key assets, establishing persistent footholds, and determining how it could most efficiently reach its intended target. In the case of Cloud Hopper, this meant weaving a path from the initial compromised host (often called the “beachhead”) on the MSP network through to the ultimate target in the client’s environment. Another key network element was the malware’s ability to send information and receive instructions through its Command and Control (CNC or C2) environment on the internet. These two phases – reconnaissance through network traversal and call-home capabilities – will be looked at separately, as they highlight distinct types of failures addressed in the Zero Trust framework’s network security principles.
Taking the call-home piece first, the malware depended heavily on being able to talk back to its CNC infrastructure, to the extent that it would delete itself entirely if this access failed. Desktop environments, where malware is most commonly delivered, often use web proxies to access the internet – given internet access is essential for productivity. Organisations should take great care in how this access is managed, ensuring that only authorised, authenticated users have access the proxy, and that this access is at the minimum level in order for the users to perform their business as usual functions. However, despite these controls being properly implemented, attackers need only to register domains and have them placed in the web filtering provider’s legitimate category in order to bypass these proxy level controls. In such cases, the logging and monitoring of all web access should be mandatory and tied to some end-user behavioural analytics such that deviations from normal activity can be identified and investigated.
The real key to the success of Cloud Hopper was the ability for the attackers to move laterally.
But the real key to the success of Cloud Hopper was the ability for the attackers to move laterally within each MSP network, with little in the way of restrictions. This allowed them to quickly build a map of available hosts, processes and ports that could be exploited, and determine which might be the most suitable to leverage in the next phase of the attack. To use a military phrase, this is often described as an "island hopping" campaign by cyber professionals. The successful harvesting of privileged user credentials and relatively unrestricted network access allowed the attackers to access systems in a manner that appeared legitimate, using common management protocols, allowing them to fly under the radar. The relatively low-effort network reconnaissance allowed for the easy identification of jump hosts that provided the MSP access into each client’s network, from where the attackers were able to access the real targets of their efforts.
This is an amalgamation of the failing of the Zero Trust pillars for Devices, Networks, and Workloads. Flat networks – networks with little or no segmentation – are a playground for the adversary and this situation was no exception. The lack of adequate segmentation or monitoring on the MSP’s internal network allowed attackers to move effortlessly, and without detection. Segmentation would have blocked the attackers’ ability to map out the network, identify open paths, or move, except as permitted explicitly by policy. Visibility on all network traffic would have provided insight into the attacker’s movements, possibly triggering an investigation early enough to halt the attack before it found its target data. Key assets such as jump servers (also known as bastion hosts) had connectivity to both the MSP and client networks, but were not adequately secured in terms of either network or user access. Mandating some form of Privileged Access Management for all jump server access would have severely limited the attackers’ ability to penetrate the client networks.
The Cloud Hopper attack highlights the failure of multiple, key security controls, and reinforces the need for a different approach to security – an approach where organisations assume the probability of a breach is 100%, and architect their environments to be able to quickly detect a breach, and minimise its impact. Given the way advanced attackers operate, the most prudent approach is one where, from the ground up, everything is built from the principle of least privilege – a Zero Trust approach to security.