New Research From Accurics Reveals Emergence Of New Cloud Watering Hole Attacks


Kubernetes users who try to implement role-based access controls (RBAC) often fail to define roles at the proper granularity. This increases credential reuse and the chance of misuse – in fact, 35% of the organizations evaluated struggle with this problem, according to the latest report from Accurics.

In Helm charts, 48% of problems came about through insecure defaults. Improper use of the default namespace – where system components run – was the most common mistake, which could give attackers access to the system components or secrets.

The findings reveal an increased adoption of managed infrastructure services and the emergence of new cloud watering hole attacks. Of all violations identified, 23 percent correspond to poorly configured managed service offerings – largely the result of default security profiles or configurations that offer excessive permissions.

As demonstrated by a recent high-profile hack, attackers increasingly strive to leverage weaknesses that enable them to deliver malware to end users, gain unauthorized access to production environments or their data, or completely compromise a target environment. This strategy is known as a watering hole attack, and Accurics researchers have seen them emerge in cloud environments where they can cause even more damage.

This is partly because development processes in the cloud that leverage managed services are not hidden inside the organization as they are in on-premise environments – in fact, they’re largely exposed to the world.

To address this risk, enterprises should assume the entire development process is easily accessible, and restrict access to only the users who need it.

On average, the research reveals that the mean time to remediate issues (MTTR) for violations is 25 days across all environments – a luxury for potential attackers.

In this report, MTTR is particularly important as it pertains to drift – when configuration changes occur in runtime, causing cloud risk posture to drift from established secure baselines. For drifts from established secure infrastructure postures, the MTTR is 8 days overall.

Even organizations that establish a secure baseline when infrastructure is provisioned will experience drift over time, as happened in another well-publicized breach. While in this case the AWS S3 bucket was configured correctly at the time it was added to the environment in 2015, a configuration change made five months later to fix a problem was not properly reset once the work was complete. This drift went undetected and unaddressed until it was exploited nearly five years later.