'Elektra-Leak' Attackers Harvest AWS Cloud Keys in GitHub Campaign

Attackers are actively harvesting exposed Amazon Web Services (AWS) identity and access management (IAM) credentials in public GitHub repositories to create AWS Elastic Compute (EC2) instances for cryptocurrency mining purposes.

Researchers from Palo Alto Networks, who are tracking the campaign as "Elektra-Leak," said this week that they observed the attacker creating at least 474 unique large-format — or compute-optimized — Amazon EC2 instances for crypto-mining just between Aug. 30 and Oct. 6.

Quick Detection and Abuse

In a report this week, the researchers described the campaign as noteworthy for the threat actor's ability to launch a full-fledged attack within just five minutes of an IAM credential getting exposed on a public GitHub repository. The attacker has been able to use exposed keys to create AWS EC2 instances even though Amazon has been successfully implementing its quarantining polices within minutes of exposure to protect against such misuse.

"Despite successful AWS quarantine policies, the campaign maintains continuous fluctuation in the number and frequency of compromised victim accounts," Palo Alto researchers William Gamazo and Nathaniel Quist said in a report this week. "Several speculations as to why the campaign is still active include that this campaign is not solely focused on exposed GitHub credentials or Amazon EC2 instance targeting."

Palo Alto researchers discovered the Elektra-Leak campaign via a honey trap the company implemented for gathering threat intelligence on new and emerging cloud security threats. Their investigation of the campaign showed the threat actor is likely using automated tools to continuously clone public GitHub repositories and to scan them for exposed AWS keys. Many organizations clone their GitHub repositories so that they have a local copy of the repository within their development environment.

Data from the threat actor's attacks on Palo Alto's honeypot showed the adversary scanning public GitHub repositories in real-time from behind a VPN and using exposed AWS keys to conduct reconnaissance on the associated AWS account. After conducting the initial reconnaissance, the Palo Alto researchers found the threat actor using an AWS API to instantiate multiple EC2 instances per region for any AWS region they could access via the account. The attackers then downloaded a payload, stored in Google Drive, for Monero cryptomining.

Monero's privacy protections prevented Palo Alto researchers from tracking associated wallets, so it was not possible to obtain any figures on how much cryptocurrency the threat actor has been able to mine so far, the security vendor said. The fact that the adversary is doing the automated scanning from behind a VPN and is using Google Drive to stage payloads also made it difficult for Palo Alto researchers to pin down the adversary's geolocation, the report added.

Bypassing Amazon's Quarantining Protection?

When Palo Alto researchers deliberately exposed AWS keys on a public GitHub repository as part of the honeypot exercise, they found AWS quickly spotting the exposed keys and applying a quarantine policy that prevented the keys from being misused. In fact, by the time the attacker spotted the Palo Alto's deliberately exposed keys on GitHub, AWS had already quarantined them.

The fact that the threat actor is still able to use exposed keys to create EC2 accounts for cryptomining suggests that they are able to find exposed keys that AWS isn't able to. "According to our evidence, they likely did," Palo Alto said in its report. "In that case, the threat actor could proceed with the attack with no policy interfering with their malicious actions to steal resources from the victims."

The campaign highlights a disappointing failure by organizations to apply fundamental security practices, said Jeff Williams, co-founder and CTO of Contrast Security. "It's not complicated, you just don't post your keys in public," Williams said in an emailed comment. "However, it's also not fair to blame developers. There are thousands of these kinds of issues, and they have to perform perfectly on all of them or get dragged for being dumb or lazy," he said. What really can help are authentication systems that make it easier for developers to make good choices, he added.

Palo Alto itself recommended that organizations that might have inadvertently exposed AWS IAM credentials immediately revoke API connections tied to the credentials. They should also remove the credential and generate new AWS credentials. "We highly recommended that organizations use short-lived credentials to perform any dynamic functionality within a production environment," the security vendor advised.