How to Avoid Targeted AWS Attacks With Secure AWS Keys

by Pat Cable on July 25, 2018

If the headlines are any indication, hackers continue to exploit vulnerabilities in cloud infrastructure platforms, with targeted AWS attacks becoming very common. Many attacks follow similar patterns: Actors are typically looking opportunistically for AWS keys, which are either accidentally posted to open source code websites like GitHub or stolen from employee laptops using malware. Once the actor has gained access to the AWS account, they often look for fairly direct paths to sensitive data or valuable resources, such as an open S3 bucket or access to launch a new EC2 instance to mine cryptocurrency.

Many developers use AWS access keys that have not been changed in months or years. Although keeping these keys the same makes things easy for the developers, it’s not very good security hygiene. Many organizations aren’t aware that their stagnant AWS keys could be causing major vulnerabilities.

Despite these risks, busy developers don’t have the time to take extra steps every time they need to access their accounts. After all, constantly generating new keys is cumbersome and can lead to confusion that slows developers down from meeting their objectives.

So, what’s an organization to do? In a situation like this, there appear to be only two options:

Sponsorships Available

Limit access and slow the business down
Accept the risk and sacrifice security

Neither of these options is good for the business! That’s why we’re highlighting another way. By setting up a secrets management system such as HashiCorp Vault and taking stock of your developers’ current workflows, you can set up an automated solution that generates temporary credentials for AWS.

Three Steps to Creating Secure AWS Keys

Step 1. Automate the solution

Rather than relying on a manual solution that depends on developers constantly generating new access keys, organizations should automate their solution so that AWS keys are generated automatically, and are always available to the developers who need them. Organizations can set up HashiCorp Vault, which can generate temporary credentials for AWS for a set period of time, such as one hour (or however long it might take a developer to complete a certain task).

Step 2. Understand current workflows

Every organization’s developers use different workflows. For example, a business might use command-line tools to issue AWS commands. Rather than disrupt developers’ workflows, attempting to have a strong understanding of their day-to-day jobs could prevent a situation where they need to break productivity in order to follow security protocol. Before implementing a solution, take the time to talk with developers about what might work best for them.

Step 3. Build tools into existing workflows

Once you’ve established a baseline understanding of your team’s workflows, any security enhancements should be built in, as much as possible. For example, at Threat Stack, we’ve created homegrown automation tools designed to fit our team’s workflows for both role-based access control and public key authentication, which we’ve open-sourced for other organizations to take advantage of. Our teams are more likely to follow security best-practices since they’re built directly into the processes they follow every day.

Are Your Current AWS Keys a Security Risk?

Sophisticated AWS attacks are hitting organizations of all sizes, and it’s often due to stolen AWS keys. Whether the attack is rudimentary or sophisticated, the first step actors often take is to gain access using a key. It’s not always clear how these keys are obtained, so it’s essential to make them as secure as possible. Once the front door is open, hackers can move laterally through the system, executing multi-level, multi-step attacks.