I initially wrote this to provide some guidance for the AWS cloud lab, Hailstorm lab on HTB, figured it would be useful out in the world too.
When you find AWS credentials you'll need to set them in order to connect to any of the supported services.
There are a few different types of credentials, that you will encounter in the lab. A full list of these types can be found at: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids.
The two main categories of credentials you will encounter during the lab can be classified as permanent and temporary credentials. Permanent credentials will consist of a pair, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. The prefix of the AWS_ACCESS_KEY_ID will be ASIA. Temporary credentials will consist of a triplet, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN. The temporary credentials can be identified by the presence of the AWS_SESSION_TOKEN and the prefix of the AWS_ACCESS_KEY_ID being AKIA. These temporary credentials range from lasting 1-12 hours depending on the configuration.
There are two ways to set them, via environment variables, and via the command, aws configure. Both methods have their pros and cons, I personally use the environment variables as it is much easier to work with when using scripts. Obviously, don't do this on real engagements as they will be stored in certain files as you'll find out ;).
You can set the credentials using the following commands:
export AWS_ACCESS_KEY_ID=XXX;
export AWS_SECRET_ACCESS_KEY=XXX;
export AWS_SESSION_TOKEN=XXX;
If you use aws configure to set the credentials, you won't be able the AWS_SESSION_TOKEN. This is particularly frustrating for temporary credentials as you'll either need to run aws configure set aws_session_token XXXX or go to the file, ~/.aws/credentials and add the line aws_session_token = XXXX
Once you have your credentials set, run aws sts get-caller-identity. Memorise this off by heart because you'll be using every time you want to verify what account/role you are currently using/have found.
Note that you may run into issues like, An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation:
The security token included in the request is invalid, if you set these credentials using both these ways at the same time. If this is the case then either remove the file ~/.aws/credentials or unset the environment variables.
There are several tools which can automate checking what services you have access to. These are but not limited to:
These tools will be useful throughout as you progress through the lab. However, these tools often throw false positives and maybe not provide all the information that you need. Manual enumeration in certain cases will sometimes be better.
If you need small hints, the names of the flags and contents of the previous flags can sometimes give an indicator as to what you need to research or find.
Remember to make a note of all the AWS credentials that you find, some accounts in particular will be repeatedly be useful later on.
You'll also find some resources tailored towards pentesting AWS infrastructure, a lot of the information will be irrelevant for the lab (from what I've seen in the lab) but does provide a good background knowledge and is good material for further reading.
SSH port forwarding will be useful in the later parts of the lab. If you want to access a particular service X (such as a website) from a box Y that Y only has access to, you can run a command like:
ssh root@3.136.91.110 -L 1337:169.254.169.254:80
You can then access the service (http:/169.254.169.254:80 hosted on X) through http://localhost:1337 on your host machine which routes your traffic through Y.