Cloud-native watering hole attack: Simple and potentially devastating

In this era of increasing technological complexity, watering hole attacks build on a model of simplicity. Just like predatory animals that hover near sources of water favored by their prey, attackers systematically infect websites likely to be visited by their targets. The law of probability suggests that a member of the target group frequenting the site will eventually become infected and expose exploitable vulnerabilities in the target’s network. The strategy is simple, subtle and potentially devastating.

The perpetrators are as diverse as their targets – fraudsters looking to steal identities, cybercriminal gangs in pursuit of quick profits, nation-state-backed attackers seeking access to larger networks – but the goal is typically the same: gain access to the victim’s place of employment, which likely contains valuable data. And, as cloud technologies become more varied and omnipresent and as cloud stacks become increasingly modular and layered, we’re going to see a higher rate of full-on attacks.

That’s particularly true of the supply chain. As cloud components continue to get democratized — think containers, Kubernetes distributions, service mesh, serverless, container registries, etc. — there’s going to be a fresh supply of vendors filling the demand for components, consulting, and so on. This clearly meets a critical need, but also opens up potential security compromises, including cloud-native watering hole attack risks.

Industrial control systems and infrastructures make for particularly interesting areas to watch. These environments are typically required to be air-gapped and self-contained, specifically to enhance security as mandated by their mission-critical nature. However, as more ICS environments head for the clouds, we see a greater decentralization of potential risks. In fact, this set of circumstances are hugely alluring to cyber criminals using watering hole techniques—simple pathways into highly sensitive (and otherwise protected) networks.

One notorious example of this would be the Energetic Bear (aka Dragonfly) attacks back in 2013-14. The group behind the coordinated campaign used the Havex remote access trojan to infiltrate numerous targets in critical industries, including defense, pharma, energy and petrochemicals. The malware was delivered by compromising vendor websites and serving trojanized versions of software updates for computers running ICS equipment.

More recently, in the highly publicized case of SolarWinds, the attackers accessed a Data Link Layer (that was part of a fix delivered to customers), corrupted it and added the Sunburst malware. And we also surely remember that in July of last year, cloud communications PaaS provider Twilio uncovered a nasty surprise: its cloud storage systems had been breached, and a copy of a JavaScript SDK had been modified. That SDK, of course, got disseminated among the company’s customers, with the desired goal of a watering hole effect. While the Twilio hack was not malicious, it did prove the feasibility of the attack — and others in a similar position may not be as lucky.

The really bad news is that it will get worse.

There’s extensive research, including from Accurics, to suggest that the rampant cloud breaches of the past two or three years are on an upward trajectory. Going one level deeper, misconfigured storage services have emerged in the vast majority of cloud deployments, and most have at least one network exposure where a security group is left wide open. For the record, these two practices alone were at the core of some 200 breaches that exposed 30 billion records from 2018 to 2020.

With that foundation, imagine a cloud-native environment at, for example, a healthcare organization with a tech stack including a public cloud service provider, self-managed k8s distro, a public container registry for pulling container images, and a commercially supported service mesh distro (a fairly routine scenario). What if attackers compromise the container registry and upload a malicious container image with a backdoor embedded inside it? This will provide direct access into the cloud-native environment—and that’s the template for a cloud-native watering hole attack.

As with many threats, there’s no panacea to counter this danger. The best way to protect yourself is by implementing multiple layers of security, starting with policy guardrails throughout the DevOps lifecycle. Security must be codified into all layers of the cloud stack to identify and fix misconfigurations before cloud infrastructure is provisioned.

This is best done by using policy as code to ensure that policies are enforced before supply chain components are deployed in production. Subsequently, the visualization of risks and breach paths helps illuminate the security posture and prioritize mitigations.

Again, a cloud-native watering hole attack represents only one strain of digital threat, but it’s disarmingly simple, potentially devastating and increasingly common. In this era of rapid cloud migration, it mandates a diligent, sophisticated and comprehensive defense.