The cloud is everything. Organizations have either moved completely to the cloud, have a hybrid approach, or are actively planning a cloud strategy. Penetration testers have always had to provide their services anywhere the client’s environment takes them. This often leads to finding vital information and credentials for their cloud provider of choice. With Amazon Web Services (AWS) being the number one player, finding AWS keys has become very common. But how does one utilize that recon information to further their attacks? Pivoting into these machines or querying the exposed services would make for a much more thorough assessment, but what type of access is available once there? That’s why we created an AWS Attack Library (WeirdAAL).
WeirdAAL has two goals related to the AWS keys you find, procure, or need to test. First, answer the “what can I do with this AWS key pair” from a blackbox perspective. Secondly, be a repository of useful functions, both offensive and defensive, to interact with AWS Services. This article is meant to be a basic tutorial to get you started.
Background on WeirdAAL
With fancy web GUIs, APIs and scripting, cloud providers have made it incredibly easy to spin up new virtual machines. So much so that it has allowed for organizations to massively increase their DevOps capabilities, often without the proper controls in place to manage this new attack surface. Ken Johnson and I have given a few talks  around common DevOps mistakes that can be made. Each of these talks contained sections on how AWS keys can become compromised.
The problem with finding yourself with an AWS key pair is that it can be quite difficult to have a full accounting of what AWS services the key pair has access to without privileges (Read more...)
*** This is a Security Bloggers Network syndicated blog from The Ethical Hacker Network authored by Chris Gates. Read the original post at: http://feedproxy.google.com/~r/eh-net/~3/5RTQDfzV-oU/