As an attacker, it is important to understand how IAM policies work, because once you can read them, you can determine exactly what access you have to an environment and why certain API calls that you make will fail with an access denied error, even when it seems like they should be allowed. It's possible that you are targeting a resource that was not specified in the policy, you aren't multi-factor authenticated, or it could be for various other reasons.

When we are inspecting compromised keys during an attack, what we love to see is a statement like the following:

{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

This statement gives us administrator-level permissions. Because it allows for the use of the * permission, and because the "*" character is a wildcard, it means that any permission pertaining to an AWS service is allowed. The resource is also wild carded, so we can run any API call against any resource in our target account. There is an AWS-managed IAM policy with these permissions known as the AdministratorAccess policy. The ARN for this policy is arn:aws:iam::aws:policy/AdministratorAccess.

To manage a user's permissions while testing, you can attach an IAM policy to your user, role, or group, to provide or deny them the permissions setup in the policy. So far, the policy type that we have looked at can be reused and attached to multiple different kinds of resources. For example, the same IAM policy could be attached to a user, group, and/or role, all at the same time.

Inline policies also exist, and rather than being an independent resource that is then attached to users, roles, or groups, like managed policies, they are created directly on a user, role, or group. Inline policies cannot be reused like managed policies can, and for that reason, a security best practice is to try to avoid using inline policies. As an attacker, we can use them for a few different malicious reasons, but because they only apply to a single resource, it is a little stealthier when creating one during an attack. They work the same as managed policies but require a different set of permissions to interact with. Sometimes, you may find that a compromised user/role may have access to work with inline policies but not managed policies, or the other way around.

The following screenshot is from the AWS web console, which shows an IAM user that I have set up that has both a managed policy (AmazonEC2FullAccess) and an Inline policy (TestPolicy) attached: