Pernicious Permissions: How Kubernetes Cryptomining Became an AWS Cloud Data Heist

A vulnerable Kubernetes container and lax permissions allowed an attacker to turn a opportunistic cryptojacking attack into a wide-ranging intrusion that targeted intellectual property and sensitive data.

The attack, which cloud-security firm Sysdig dubbed “SCARLETEEL,” started with a threat actor exploiting a Kubernetes cluster, using an internal service to gain temporary credentials, and then used those credentials to enumerate other Elastic Compute Cloud (EC2) services that had been deployed in the targeted company’s infrastructure. In the end, the company — which was not named in the incident report published today — had properly limited the scope of permissions for the stolen identity, which blunted the attack.

The incident, however, underscores that companies need to be careful when configuring the controls that allow cloud resources to interact with each other, says Michael Clark, director of threat research at Sysdig.

“Having EC2 roles being able to access other resources can be common, though usually it is tightly scoped to prevent incidents like this one,” he says. “It’s more about understanding how misconfigurations like this can combine with other issues leading to a larger breach.”

The sophisticated cyberattack also shows that attackers are increasingly targeting cloud infrastructure in better ways. In the past, threat actors have focused on rudimentary interaction with cloud services, such as deploying cryptojacking software, but as they understand the vulnerabilities introduced by businesses in their own environments, cloud-focused attacks are becoming more popular.

In fact, observed cloud exploitation cases nearly doubled in 2022, while the number of incidents where threat actors interacted with cloud resources nearly tripled, cybersecurity services firm CrowdStrike stated in its latest annual “Global Threat Report” published on Feb. 28.

“It took a while for them to figure out how to operate in the cloud,” says Adam Meyers, head of intelligence at CrowdStrike. “Organizations really need to be taking a hard look at their cloud security, because the cloud comes secure out of the box, but as people start to operate on it and change it, they make it less secure.”

From Minor to Major Security Breach

The attacker compromised the target’s cloud infrastructure through a vulnerable Internet-exposed service that allowed access to a Kubernetes pod, a technology used to manage and deploy containerized applications. Once inside the cluster, the attacker used the access to deploy containers with cryptojacking software, essentially stealing processing capacity from the victim’s cloud infrastructure to mine for cryptocurrency.

“This is a common practice in automated container threats,” Sysdig researchers stated in their analysis, adding that the attackers then “exploited that role to do enumeration in the cloud, search for sensitive information, and steal proprietary software.”

The attackers had knowledge of how to move through the AWS cloud, including EC2 services, connecting to Lambda serverless functions, and using the continuous integration and continuous deployment (CI/CD) service known as Terraform. Because Terraform often saves the state of its pipeline to Simple Storage Service (S3) buckets, the attacker was able to retrieve those files and find at least one more additional credential in the plaintext data.

The second identity, however, had limited permissions, stopping the attacker’s lateral movement, Sysdig stated in its analysis. Meanwhile, the attacker’s attempts to enumerate users and cloud infrastructure led to detection, Clark says.

“It was caught by abnormal amounts of AWS actions being taken, especially from roles that shouldn’t be making those types of requests,” he says. “There is a threat intelligence aspect [too] — some of the IP addresses, which were involved, have been associated with malicious activity in the past.”

Misconfiguration, Not Lack of MFA

The takeaways of the attack? For one, companies need to ensure that they have good visibility into the operation and telemetry of their cloud infrastructure. In addition, limiting access — even assigning read-only access to specific cloud resources — can make all the difference in stopping an attack while in progress. The more attackers hammer at resources using stolen identities, the greater chance of detecting them, according to Sysdig.

“First, zero trust and the principle of least privilege are important and if you implement them, you will reduce the likelihood of compromise,” the researchers wrote. “Second, strong detections and alerts should help you catch these activities before an attacker gets too deep.”

Clark also points out that multifactor authentication (MFA) technologies will likely not make a great deal of difference in blunting cloud infrastructure attacks, since most of the cloud identities that attackers take advantage of are machine identities — so, alternate protections need to be put into place.

“MFA may have been helpful for the other involved accounts to prevent their access,” Clark says, “but these were internal accounts made for automation purposes rather than ones that were expected to be logged into by a person.”