MisCred: Leaked credentials

To access any application, including Facebook or a platform like the AWS console, you typically require a username & password for your account with that provider.

When employees from an organization share these user credentials on the internet when asking an external person for help, or accidentally copy/paste their credentials into an online forum, or are released publicly through data breaches, MisCred— the leaked credential villain — is born.

Common causes

A threat actor can access user credentials in various ways through phishing, malware, brute force attacks, snooping for misplaced credentials, or simply finding leaked email, username, and password combinations on the dark web. Once a threat actor has access to user credentials, they can subsequently use those credentials to gain access to elevated permissions and execute malicious actions.

Problems caused by leaked credentials

It is reported that 61% of data breaches are due to leaked credentials. Despite this, surveys have found that many executives report that their organizations don’t monitor key employee exposed credentials on the dark web.

Here are just a few recent examples where MisCredsurfaced recently:

• The Uber breach reported in September 2022. The threat actor allegedly gained access to an ex-contractor’s corporate password via the dark web. This was used then to infect the ex-contractor’s device with malware, expose credentials, and bypass MFA. The attacker subsequently gained access to several other employee accounts, elevating permissions and allowing the attacker to send company-wide Slack messages and reconfigure Uber’s OpenDNS to display a graphic image to employees on an internal site.

• Shiba Inu, a popular cryptocurrency, had their AWS infrastructure keys exposed on a public GitHub repository by one of Shiba’s internal developers (accidentally). The credentials were valid for two days and, if exploited, could have potentially resulted in “fund theft, token embezzlement, disruption of services”

3 places in AWS where MisCred hides

AWS storage (Public S3 Buckets, AWS EBS Volumes, RDS databases

AWS provides several solutions for users to store data and files on the cloud. Common examples of storage include  AWS S3, AWS EBS Snapshots, Amazon RDS & AWS EFS.

In a lot of use cases these storage services store sensitive information like user credentials or passwords in plain text for ease of access for applications or users that require them. When any of these storages are made accessible from the internet for bad actors to access and compromise which will make MisCred appear.

AWS IAM Users

In AWS IAM, Identity and Access Management users are an entity that represents the person or an application that uses it to interact with AWS. AWS IAM Credentials can be leaked in various ways:

• Committing IAM access keys to Git repositories where AWS keys are shared between developers

• Trusted third-party breaches that expose the password issued to them by the company to an attacker

• Social engineering of AWS users combined with spear phishing to target and steal user credentials

• Password reuse by users across various services in your Cloud Architecture

• Rogue employees or disgruntled AWS users

AWS CloudFormation templates

AWS CloudFormation is a service you can use to create templates for services and architecture of applications in your organization. You can then use these templates to create other services and applications in your organizations. Like with any template, though they create ease of replication they can also add to the risk of leaking information to applications and services where they don't belong. If any secret or AWS credential is stored as plain text in a CloudFormation template, if exposed, MisCred can rear its ugly head.

3 ways to stop MisCred

Use temporary credentials instead of permanent credentials

To prevent credentials from being leaked, you can “use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources.”

You can also use AWS Identity Center (previously know as SSO orSingle Sign-On) to create a federated user, which is a single set of credentials of a user to access various applications and services. The use of a industry standard for authentication would prevent most identity related risks.

Require multi-factor authentication (MFA)

The risk for leaked credentials can be reduced by adding a second authentication layer right after successful logins with usernames and passwords. MFA can prevent some identity related risk in cases where credentials are compromised. See also: Multi-Factor Authentication (MFA) for IAM

Use infrastructure as code (IAC) with AWS cloud native services

Using cloud native services from AWS, like AWS Secrets Manager, can help you manage, retrieve, and rotate database credentials adding an additional layer of security to prevent the need for credentials to be stored in CloudFormation or any other type of IaC templates. A tool like AWS Secrets Manager or a similar secret management applications will ensure that you are not storing your credentials in plain text in the config.