It is no surprise that the rapid growth of cloud adaptation has attracted much-unwanted attention from potentially harmful parties. Where a company used to be directly targeted or via a connected partner (via federation or VPN), there is now another attack vector that provides unprecedented levels of access for any attacker able to “pull it off”: attacking the (Cloud) Service Providers. A breach of a Service Provider potentially gives an attacker access to the managed clients as well, hugely increasing the impact and the value of a successful attack. The “Cloud Hopper” report released in April 2017 by PWC and BAE Systems describes the actions undertaken by the APT10 group to achieve such an outcome. Although most of these actions fall into the more traditional attack categories such as spear phishing (but combined and on a much larger scale), it does indicate the shift in focus of attacks towards the Service Providers. Some more specific attacks, directly aimed at the managed cloud infrastructure have been seen over the recent years as well.

Escaping the Sandbox using Vulnerabilities

Various vulnerabilities have been published that (until patched) allowed an attacker to escape a sandboxed, cloud hosted system to gain access to the cloud platform itself. One example is the Azure 0day Cross-Site Scripting exploit published by Chris Dale in 2016. By using an XSS vulnerability in a web server, Chris has managed to crash a site and then attack the troubleshooting SaaS administrators via unauthorized Javascript execution in their browser. This was a relatively easy attack method and only covers a single platform. One thing is for sure; there are more of these vulnerabilities out there, most of them still unknown (to the public). Adequate system patching, regular penetration testing, and real-time security monitoring are the best risk mitigation measures to address these vulnerabilities. These measures will need to be covered by both the customer and the Service Provider to make it most effective.


Security often focusses on the very interesting vulnerabilities and exploits, but there is usually less focus on common misconfigurations or bad implementations. A misconfiguration such as a simple or default password, an insecure API
or a badly implemented and unpatched hypervisor can also lead to a security compromise. An API, for instance, can be used to manage systems, automatically push or pull data between systems, and many more administrative tasks. If such communication is not secure or there is no proper authentication in place, an attacker could manipulate requests, data, and even the systems itself. The best method to deal with these misconfigurations is to have proper Change Control systems in place, to include Security experts in the review panel and to have solid, secure configuration standards in place.

Man in the Cloud Attack

This recently discovered attack method focusses on the manipulation and theft of a user’s cloud synchronization token. The victim is usually hit with malware via a malicious web page or e-mail after which the attacker gains access to their local files. By replacing the cloud synchronization token for one that points to the attackers’ cloud account instead and placing the original token into the selection of files that will be synchronized, the victim at some point unknowingly uploads their original token to the attacker. That token can then be used by the attacker to gain access to the victim’s actual cloud data. From a protection perspective, proactive malware prevention is key here. Detection alone might not be enough because the cloud synchronizations are often scheduled at short intervals. In a reactive environment, a security team member might not be able to respond in time. It only takes minutes for an attacker to download a few Gigabyte of data from a public cloud platform.

Ethical Hacking Training – Resources (InfoSec)

Another protection control could be cloud-aware Data Leak Prevention (DLP). There does not seem to be much on the market in that area (yet) though. As a final resort, some organizations decide to block cloud applications and sites altogether.

(Distributed) Denial of Service

Due to the very large bandwidth capacity available to Cloud Service Providers, the traditional Distributed Denial of Service attack methods (using many systems at once to “overload” the target system with data or requests) are becoming less effective. We have seen, however, that there are many other vectors available to achieve a Denial of Service state on a target system located on a cloud platform. Even the cloud platform itself can be brought “to its knees,” as demonstrated by the 2016 Dyn attack. This attack was a targeted DDoS aimed at bringing down the DNS infrastructure for web provider Dyn. That in turn effectively took down access to large websites and platforms around the world such as Amazon and Twitter. From a customer perspective, there is not much that could be done against an attack on the hosting platform itself. It is recommended, however, to investigate how the traffic of a large DDoS attack could affect the costs of the service. It is also worth investigating the market and looking into what protections the various providers have in place to prevent such outages.


Successful attacks on Service Providers are rare, but their impact can be enormous, both to a provider and to its customers. This risk can be managed though. It does require a very broad approach, such as having the right security controls in place, monitoring their output in real-time, capacity planning and adequate change control policies. Expect to see more high profile attacks in this area in the future, with the growth of nation-state attackers and well-funded, well-resourced organizations of cyber-criminals. Attacking a Service Provider requires a higher skill level, more persistence and with that, more resources than attacking the more traditional targets.