New research from Palo Alto Networks’s Unit 42 exposes an active attack campaign in which a threat actor hunts for Amazon IAM credentials in real time in GitHub repositories and starts using them less than five minutes later. The final payload runs customized Monero cryptomining software on virtual machines deployed on the Amazon instances.

Jump to:

IAM credentials exposed on GitHub

GitHub offers its users many features for handling their code within the platform. One of these features consists of providing a list of all public repositories to any user requesting it, which helps developers easily track various developments they are interested in. The tracking is done in real time and allows anyone, including threat actors, to see new repositories as soon as they are being pushed to GitHub.

SEE: 8 Best Identity and Access Management (IAM) Solutions for 2023 (TechRepublic)

Palo Alto Networks’s Unit 42 researchers report that it is possible to find Amazon Web Services Identity and Access Management credentials within GitHub’s public repositories and that these credentials are actively hunted for by cybercriminals.

To analyze the risk deeper, the researchers decided to store IAM credentials on GitHub and check all activity around it. That honeypot testing revealed that leaked AWS keys that were encoded in base64 and stored on GitHub were not found or used by threat actors, who only fetched clear text AWS keys hidden behind a past commit in a random file.

The honeypot enabled researchers William Gamazo and Nathaniel Quist to detect a particular attack campaign starting within five minutes after the credentials were put on GitHub.

Technical details about this attack campaign

The campaign, dubbed EleKtra-Leak by the researchers in reference to the Greek cloud nymph Electra and the usage of Lek as the first 3 characters in the passwords used by the threat actor, has been active since at least December 2020, according to Unit 42.

Once IAM credentials are found, the attacker performs a series of reconnaissance actions to know more about the AWS account that is accessed (Figure A).

Figure A

After those actions are done, the threat actor creates new AWS Security Groups before launching multiple Amazon Elastic Compute Cloud instances per region across any accessible AWS region.

Gamazo and Quist could observe more than 400 API calls within seven minutes, all done via a VPN connection, showing that the actor has automated the attack against those AWS account environments.

The threat actor aimed at large-format cloud virtual machines to perform their operations, as those have higher processing power, which is what attackers are looking for when running cryptomining operations. The threat actor also chose private images for Amazon Machine Images; some of those images were old Linux Ubuntu distributions, leading the researchers to believe the operation dates back to at least 2020.

The threat actor also appeared to block AWS accounts that routinely expose IAM credentials, as this kind of behavior might originate from threat researchers or honeypot systems.

The goal of this attack campaign: Cryptomining

Once all the reconnaissance is done and virtual machines are launched, a payload is being delivered, downloaded from Google Drive. The payload, encrypted on Google storage, is being decrypted upon download.

Unit 42 states the payload is a known cryptomining tool seemingly used in 2021 and reported by Intezer, a company specializing in autonomous Security Operation Systems platforms. In the reported attack campaign, Intezer indicated that a threat actor had accessed exposed Docker instances on the internet to install cryptomining software for mining Monero cryptocurrency. That customized cryptomining software is the same as what is used in the new campaign exposed by Palo Alto Networks.

The software is configured to use the SupportXMR mining pool. Mining pools allow several people to add their computing time to the same workspace, increasing their chances to earn more cryptocurrency. As stated by Palo Alto Networks, the SupportXMR service only provides time-limited statistics, so the researchers pulled the mining statistics for several weeks, as the same wallet was used for the AWS mining operations (Figure B).

Figure B

Between Aug. 30, 2023 and Oct. 6, 2023, a total of 474 unique miners appeared, each one being a unique Amazon EC2 instance. It is not yet possible to obtain an estimation of the financial gain generated by the threat actor, as Monero includes privacy controls limiting the tracking of this kind of data.

GitHub’s automated measures for detecting secrets

GitHub automatically scans for secrets in files stored on the platform and notifies service providers about leaked secrets on GitHub.

During their investigation, Gamazo and Quist noticed the secrets they were intentionally storing on GitHub as honeypot data for their research were indeed successfully detected by GitHub and reported to Amazon, who in turn automatically applied within minutes a quarantine policy that prevents attackers from performing operations such as accessing AWS IAM, EC2, S3, Lambda and Lightsail.

During the research process, Unit 42 was leaving the quarantine policy in place and passively studying the attackers’ tests of the accounts; then, the policy was dropped to study the entire attack chain.

The researchers write that they “believe the threat actor might be able to find exposed AWS keys that aren’t automatically detected” and that according to their evidence, the attackers likely did, as they could operate the attack without any interfering policy. They also state that “even when GitHub and AWS are coordinated to implement a certain level of protection when AWS keys are leaked, not all cases are covered,” and that other potential victims of this threat actor might have been targeted in a different manner.

How to mitigate this cybersecurity risk

IAM credentials should never be stored on GitHub or any other online service or storage. Exposed IAM credentials should be removed from repositories, and new IAM credentials should be generated to replace the leaked ones.

Businesses should use short-lived credentials for performing any dynamic functionality within a production environment.

Security teams should monitor GitHub repositories used by their organizations. Auditing clone events that occur on those repositories should be done because it is necessary for threat actors to first clone repositories to view their content. That feature is available for all GitHub Enterprise accounts.

Custom dedicated scanning for secrets on repositories should also be done constantly. Tools such as Trufflehog might help with that task.

If there is no need to share the organization’s repositories publicly, private GitHub repositories should be used and only accessed by the organization’s personnel. Access to the private GitHub repositories should be protected by multifactor authentication to avoid an attacker accessing them with leaked login credentials.

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.