EmeraldWhale Steals 15,000 Credentials From Exposed Git Configurations
A bad actor identified as EmeraldWhale was observed running a global operation that targeted exposed Git configurations — a campaign that resulted in more than 15,000 cloud service credentials stolen.
The Sysdig Threat Research Team said Oct. 30 that the threat actor abused multiple misconfigured web services that let attackers steal credentials, clone private repositories, and extract cloud credentials from their source code.
The kicker: the stolen data was stored in an S3 bucket of a previous victim.
Sysdig researchers said that while EmeraldWhale relied solely on misconfigurations rather than vulnerabilities — which isn’t unique — what was different was the target: exposed Git configuration files.
Here’s how the Sysdig researchers found the EmeraldWhale campaign: While monitoring the Sysdig cloud honeypot, the researchers observed an unusual ListBuckets call using a compromised account. The S3 bucket, s3simplisitter, that was referenced did not belong to Sysdig’s account. Instead, it belonged to an unknown account and was publicly exposed. While investigating this bucket, the researchers discovered malicious tools and over a terabyte of data, which included compromised credentials and logging data. In doing an analysis, the researchers discovered a multi-faceted attack, including web scraping GitHub config files, Laravel .env files, and raw web data.
Sysdig then reached out to AWS to report the bucket — and AWS promptly took it down.
These files and the credentials they contain offer access to private repositories that normally would be difficult to access, explained the Sysdig researchers. In a private repository, developers may be more prone to include secrets because it offers a false sense of security.
“The underground market for credentials is booming, especially for cloud services,” wrote the researchers. “This attack shows that secrets management alone is not enough to secure an environment. There are just too many places credentials could leak from. Monitoring the behavior of any identities associated with credentials has become a requirement to protect against these threats.”
Attackers continue to steal credentials
This campaign is yet another example of how credentials continue to be a top target for hackers, said Rom Carmel, co-founder and CEO at Apono. Carmel said with the right set of credentials, an attacker can compromise an identity and gain access to all of the resources they have privileges to, offering malicious actors a potentially unending list of enticing targets.
“While MFA is a crucial first step in protecting identities after stolen credentials fall into the wrong hands, we’ve seen the steady stream of credential-stuffing attacks as proof that we need to do more,” said Carmel. “Implementing ‘just-in-time’ access security removes the opportunity for attackers to abuse credentials by simply ensuring that access is only available when it is needed. This, along with right-sizing excessive privileges, goes a long way in reducing the blast radius in an event like this where such a sensitive stash of credentials have been compromised.”
Elad Luz, head of research at Oasis Security, added that the attack highlights the critical need for a comprehensive strategy to secure and manage non-human identities (NHIs), such as secrets, keys, and tokens. Luz said implementing automated security protocols, including continuous scanning and credential rotation, can help reduce the risk of similar incidents.
Luz said teams should consider the following actions in response:
- Regularly scan code repositories — both public and private — for exposed secrets. Although most organizations avoid hard-coding credentials in public repositories, attackers may still target private repositories for the same purpose. Consider using AI-based scanning tools that go beyond simple regular expressions to identify a broader range of secrets.
- Enable GitHub’s audit logs and IP logging to track account activity. Since IP logging is off by default, enabling it can help trace any suspicious activity back to its source.
- Rotate credentials and other sensitive data regularly. This will minimize the window of exposure if a secret becomes compromised.
- Avoid storing GitHub tokens in the .git directory to prevent accidental exposure. Use .gitignore to exclude sensitive files, and verify configuration settings to avoid inadvertently committing sensitive information.
- Incorporate continuous lifecycle management and governance for NHIs in the company’s security and identity programs. Avoid hardcoding secrets in code. Instead, store sensitive credentials in a secret manager, rather than within code repositories or local files. Secret managers offer secure storage, controlled access, and automated rotation options, reducing the risk of accidental exposure and enhancing security across the environment.
READ MORE HERE
