In June of 2014, we saw one of the first hacks that actually put an organization out of business entirely. The company, Code Spaces, was a small software code hosting service that was housed entirely in Amazon Web Services. A malicious attacker compromised their account’s control panel, and numerous extortion attempts were made (along with several DDoS attacks targeting the company). The attacker created multiple backdoor accounts to gain access, and ultimately succeeded in destroying most of the company’s AWS assets when they refused to pay the ransom. How did the attackers compromise the account in the first place? Simple - they compromised an administrative account, logged in, and then created new admin accounts for their own use.
There are a lot of lessons to learn from this compromise scenario. First, the company did not enable multifactor authentication on the management interface, which provided the initial entry vector for the attackers. By simply brute forcing an admin account, they gained access with nothing more than a username and password. All privileged accounts should have more stringent authentication standards in place. Another major mistake made in this scenario revolved around logging - the brute force attacks should have triggered some sort of alarms, but the company was not carefully tracking privileged account activity through log and event monitoring. Logging all privileged account activities should be a top priority for security teams who want to ensure privileged access isn’t abused. Finally, the company was obviously unable to identify and track all the privileged accounts within their cloud environment, as the attacker was able to get back in and wreak havoc. Every privileged account should be unique and carefully tracked in an account inventory.
There were lots of other issues that contributed to Code Spaces’ downfall, but at the core of the problem was an obvious lack of awareness and concern for privileged access to their most important assets. This is becoming a much bigger problem with cloud services, as organizations are finding new privileged accounts that don’t integrate with corporate directory services, incompatible API access for identity management services, and “shadow” cloud services in use that they may not even be aware of! With more sensitive data being sent to the cloud than ever before, this is an issue that organizations need to get a handle on, and the sooner the better.
To start, security teams need to start monitoring privileged users initiating sessions to cloud-based services and administrative interfaces. Just keeping tabs on outbound access to cloud providers and looking for admin access can go a long way to identifying what types of accounts are in use. Tracking those accounts and protecting them with strong privileged user management tools are also steps organizations need to take to better secure cloud service access and management. If you’re controlling privileged access internally, you need to extend that same mentality to any cloud services you’re using, too. Logging and monitoring this access in the cloud environment is critical, too, but protection starts internally using supported and integrated privileged user management controls.
Join me in the upcoming webcast with BeyondTrust where we’ll dig into this issue even further, and present some new options for getting control of privileged accounts in the cloud!
Register Now | October 27, 2015 | 10am PT / 1pm ET
Author/Presenter: Dave Shackleford, SANS Instructor
