9 Things To Do Before Someone Steals Your AWS Credentials

In 2017 I visited the headquarters of a large national financial advising firm. We got to take a tour of the facilitiy which included their “security operations center” (SOC). It was a locked, windowless room on the 15th floor, with a dozen desks with big monitors, and a wall full of monitors, dashboards, and screens. On these monitors were important-looking displays. A dark map of the world showed intermittent traces of light streaking out from bad places like Russia, indicating something bad cyber-related was being launched from Russia.

Their SOC was incredible

Our host gave us a talk on what they did there. He spoke with gravity about “the attacker” as a nameless, faceless foe, continually plotting the demise of good people. The Attacker would b e there if you left your laptop in the car. The Attacker is actively trying to hack into their networks, this very second - or at least you should assume that.

This looked very serious and impressive to me. Their IT infrastructure, it should be noted, was self-hosted, meaning they also had to defend their servers right there in the Florida building, provide security guards, cooling, access control, and maintenance, not to mention the significant networking monitoring and defense that surely was needed given the barrage of cyber warfare underway.

But a giant SOC doesn’t guard against leaked credentials

While the SOC was certainly impressive and the team was pretty gung-ho about defending their assets, I left the tour skeptical about the usefulness of it all. Every issue the SOC raised has a defense in AWS. The vast majority of companies will experience a step change in their security confidence by following a few simple steps.

The seriousness of their situation came into question when someone asked what is the most typical and risky attack. His answer came without hesitation: employees entering their credentials into a fake site after opening up a fake email, known as phishing.

Wait, What about the glowing threat centers on the map? Security guards? Forensics? Not really an issue when employees are freely handing out their credentials.

At the end of the day, their biggest risk--and it turns out most companies’ biggest risks--are tied to unauthorized use of credentials. Put another way, their biggest risk is when the wrong people get a legitimate username / password combination and go wreak havoc in their account. Training employees not to open obvious scam emails is important and will get you a long way.

AWS already offers a mini Security Operations Center (SOC)

Amazon Web Services already has a defense for most of the things the SOC was worried about. First of all, attacks like the ones highlighted in the dark map usually start with things like port scanning, which is a computer trying to see if a server is available over the public internet, and if so, which ports are open. This can be defended by:

1. Web Application Firewall (WAF), which has IP address blacklists that you can place in front of your public-facing servers.
2. Least privilege access to your EC2 instances, by using network access controls lists (NACLs) on your subnets and using security groups around your instances to control traffic.
3. GuardDuty, which will alert you to port scanning attempts. You can have a workflow to take automatic action to remediate it if it’s a legitimate weakness.
4. Shield guards against distributed denial of service (DDoS) attacks, which try to overwhelm servers by sending a lot of traffic.

So what do you do if someone gets your credentials?

What if someone gets credentials… how do you know if someone uses the credentials? How do you monitor that? How do you limit their activity once they log in? (also known as limiting the “blast radius”).

If an employee somehow gives out their credentials, here is how you defend, before and after.

9 Best practices to guard against stolen AWS credentials:

1. Enable multi-factor authentication (MFA) on each and every user account. This makes it really, really hard to log in as someone else.
2. Enforce a password rotation policy of every 3 or 6 months. Sometimes credential thieves don’t use the credentials right away, so you might end up changing the password before they use yours.
3. Create a whitelist of allowed IP addresses for user logins to the console, and for SSH access. Places like your employees’ home router IP address, office IP addresses, local coffee shops, and so on. If the login IP address doesn’t match the whitelist, not only will the request get blocked, but you can get sent a notification.
4. Let’s assume they actually still get in, after all that: Using the Principle of Least Privilege (POLP), limit their access within their IAM role. So whatever IAM role is assumed by a credential thief, limits their access.
5. Limit the policy “IAMFullAccess” only to people who really should have it, because an attacker can modify their permissions if they have full access.
6. Strictly limit the use of AdministratorAccess roles and “*” statements in policies.
7. Enable GuardDuty, which will alert you to a strange login. Tie an automated action to it to kill the console session.
8. Enable Cloudtrail, sending logs to a separate read-only account. This way you can find out exactly what the person did, and when. This will be useful when customers and other people on the team ask, “well, what did they do once they got it?”
9. Enable Athena to be able to query those logs quickly. You don’t want to be setting it all up after the fact, in the heat of the moment.

If the attack is ongoing:

• Kill the active session by logging out everyone from the console.
• Have everyone change their passwords (or, have an administrator change it for them).
• Have the user change their email password too. This limits an attacker’s ability to reset an AWS password.

Conclusion

When I was just getting started with cloud security, I was impressed by the security operations center. On reflection, I believe that is only necessary for the largest, most complex architectures. If you have to monitor hundreds or thousands of accounts, then yes, you should have a large, in-house team dedicated to monitoring and resolving issues (whether you build a windowless room with cool flat screens is up to you). But, as I have seen with dozens, if not hundreds, of customers, if most people took the precautions above, they would be safe from creating their own security headaches.

Most teams do not need a costly security operations center. They just need to apply AWS best practices and reinforce them throughout the team. For teams that understand this but don’t have the time, CloudSheriff provides managed security services to take it all on. We have an automated tool that sets up a best-practices environment around your existing infrastructure. Then, we have certified security engineers not only monitoring your infrastructure, but also actively implementing safeguards for you, like the list of best practices above.