Last updated
Learn & practice AWS Hacking: Learn & practice GCP Hacking:
In AWS there is a root account, which is the parent container for all the accounts for your organization. However, you don't need to use that account to deploy resources, you can create other accounts to separate different AWS infrastructures between them.
This is very interesting from a security point of view, as one account won't be able to access resources from other account (except bridges are specifically created), so this way you can create boundaries between deployments.
Therefore, there are two types of accounts in an organization (we are talking about AWS accounts and not User accounts): a single account that is designated as the management account, and one or more member accounts.
The management account (the root account) is the account that you use to create the organization. From the organization's management account, you can do the following:
Create accounts in the organization
Invite other existing accounts to the organization
Remove accounts from the organization
Manage invitations
Apply policies to entities (roots, OUs, or accounts) within the organization
Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization.
It's possible to login as the root user using the email and password used to create this root account/organization.
The management account has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts. You can't change an organization's management account.
Member accounts make up all of the rest of the accounts in an organization. An account can be a member of only one organization at a time. You can attach a policy to an account to apply controls to only that one account.
Member accounts must use a valid email address and can have a name, in general they wont be able to manage the billing (but they might be given access to it).
Accounts can be grouped in Organization Units (OU). This way, you can create policies for the Organization Unit that are going to be applied to all the children accounts. Note that an OU can have other OUs as children.
A service control policy (SCP) is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are similar to IAM permissions policies except that they don't grant any permissions. Instead, SCPs specify the maximum permissions for an organization, organizational unit (OU), or account. When you attach a SCP to your organization root or an OU, the SCP limits permissions for entities in member accounts.
This is the ONLY way that even the root user can be stopped from doing something. For example, it could be used to stop users from disabling CloudTrail or deleting backups. The only way to bypass this is to compromise also the master account that configures the SCPs (master account cannot be blocked).
Note that SCPs only restrict the principals in the account, so other accounts are not affected. This means having an SCP deny s3:GetObject will not stop people from accessing a public S3 bucket in your account.
SCP examples:
Deny the root account entirely
Only allow specific regions
Only allow white-listed services
Deny GuardDuty, CloudTrail, and S3 Public Block Access from
being disabled
Deny security/incident response roles from being deleted or
modified.
Deny backups from being deleted.
Deny creating IAM users and access keys
Amazon Resource Name is the unique name every resource inside AWS has, its composed like this:
Note that there are 4 partitions in AWS but only 3 ways to call them:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM is the service that will allow you to manage Authentication, Authorization and Access Control inside your AWS account.
Authentication - Process of defining an identity and the verification of that identity. This process can be subdivided in: Identification and verification.
Authorization - Determines what an identity can access within a system once it's been authenticated to it.
Access Control - The method and process of how access is granted to a secure resource
IAM can be defined by its ability to manage, control and govern authentication, authorization and access control mechanisms of identities to your resources within your AWS account.
When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This is the AWS account root user and is accessed by signing in with the email address and password that you used to create the account.
Note that a new admin user will have less permissions that the root user.
From a security point of view, it's recommended to create other users and avoid using this one.
An IAM user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials (password and up to two access keys).
When you create an IAM user, you grant it permissions by making it a member of a user group that has appropriate permission policies attached (recommended), or by directly attaching policies to the user.
Access Key ID: 20 random uppercase alphanumeric characters like AKHDNAPO86BSHKDIRYT
Secret access key ID: 40 random upper and lowercase characters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (It's not possible to retrieve lost secret access key IDs).
Whenever you need to change the Access Key this is the process you should follow: Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key
It's used to create an additional factor for authentication in addition to your existing methods, such as password, therefore, creating a multi-factor level of authentication. You can use a free virtual application or a physical device. You can use apps like google authentication for free to activate a MFA in AWS.
Policies with MFA conditions can be attached to the following:
An IAM user or group
A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic
The trust policy of an IAM role that can be assumed by a user
If you want to access via CLI a resource that checks for MFA you need to call GetSessionToken. That will give you a token with info about MFA.
Note that AssumeRole credentials don't contain this information.
You can attach an identity-based policy to a user group so that all of the users in the user group receive the policy's permissions. You cannot identify a user group as a Principal in a policy (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities.
Here are some important characteristics of user groups:
A user group can contain many users, and a user can belong to multiple groups.
User groups can't be nested; they can contain only users, not other user groups.
There is no default user group that automatically includes all users in the AWS account. If you want to have a user group like that, you must create it and assign each new user to it.
An IAM role consists of two types of policies: A trust policy, which cannot be empty, defining who can assume the role, and a permissions policy, which cannot be empty, defining what it can access.
AWS Security Token Service (STS) is a web service that facilitates the issuance of temporary, limited-privilege credentials. It is specifically tailored for:
Temporary credentials are primarily used with IAM roles, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This prevents you from accidentally performing tasks that are not permitted by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.
Are used to assign permissions. There are 2 types:
AWS managed policies (preconfigured by AWS)
Customer Managed Policies: Configured by you. You can create policies based on AWS managed policies (modifying one of them and creating your own), using the policy generator (a GUI view that helps you granting and denying permissions) or writing your own..
By default access is denied, access will be granted if an explicit role has been specified. If single "Deny" exist, it will override the "Allow", except for requests that use the AWS account's root security credentials (which are allowed by default).
This kind of policies are directly assigned to a user, group or role. Then, they do not appear in the Policies list as any other one can use them. Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the identity that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.
These are policies that can be defined in resources. Not all resources of AWS supports them.
If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed.
IAM boundaries can be used to limit the permissions a user or role should have access to. This way, even if a different set of permissions are granted to the user by a different policy the operation will fail if he tries to use them.
A boundary is just a policy attached to a user which indicates the maximum level of permissions the user or role can have. So, even if the user has Administrator access, if the boundary indicates he can only read S· buckets, that's the maximum he can do.
This, SCPs and following the least privilege principle are the ways to control that users doesn't have more permissions than the ones he needs.
A session policy is a policy set when a role is assumed somehow. This will be like an IAM boundary for that session: This means that the session policy doesn't grant permissions but restrict them to the ones indicated in the policy (being the max permissions the ones the role has).
This is useful for security meassures: When an admin is going to assume a very privileged role he could restrict the permission to only the ones indicated in the session policy in case the session gets compromised.
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because there is a session policy preventing it.
Identity federation allows users from identity providers which are external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account. An example of an identity provider can be your own corporate Microsoft Active Directory (via SAML) or OpenID services (like Google). Federated access will then allow the users within it to access AWS.
To configure this trust, an IAM Identity Provider is generated (SAML or OAuth) that will trust the other platform. Then, at least one IAM role is assigned (trusting) to the Identity Provider. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
However, you will usually want to give a different role depending on the group of the user in the third party platform. Then, several IAM roles can trust the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a central place that brings together administration of users and their access to AWS accounts and cloud applications.
The login domain is going to be something like <user_input>.awsapps.com.
To login users, there are 3 identity sources that can be used:
Identity Center Directory: Regular AWS users
Active Directory: Supports different connectors
External Identity Provider: All users and groups come from an external Identity Provider (IdP)
In the simplest case of Identity Center directory, the Identity Center will have a list of users & groups and will be able to assign policies to them to any of the accounts of the organization.
In order to give access to a Identity Center user/group to an account a SAML Identity Provider trusting the Identity Center will be created, and a role trusting the Identity Provider with the indicated policies will be created in the destination account.
It's possible to give permissions via inline policies to roles created via IAM Identity Center. The roles created in the accounts being given inline policies in AWS Identity Center will have these permissions in an inline policy called AwsSSOInlinePolicy.
Therefore, even if you see 2 roles with an inline policy called AwsSSOInlinePolicy, it doesn't mean it has the same permissions.
A user (trusting) can create a Cross Account Role with some policies and then, allow another user (trusted) to access his account but only having the access indicated in the new role policies. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account. It's recommended to specify the user who is trusted and not put some generic thing because if not, other authenticated users like federated users will be able to also abuse this trust.
Not supported:
Trust Relations
AD Admin Center
Full PS API support
AD Recycle Bin
Group Managed Service Accounts
Schema Extensions
No Direct access to OS or Instances
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
You can set a password policy setting options like minimum length and password requirements.
You can download "Credential Report" with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every four hours.
AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.
The following privileges grant various read access of metadata:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
In order for a regular user authenticate to AWS via CLI you need to have local credentials. By default you can configure them manually in ~/.aws/credentials or by running aws configure.
In that file you can have more than one profile, if no profile is specified using the aws cli, the one called [default] in that file will be used.
Example of credentials file with more than 1 profile:
If you need to access different AWS accounts and your profile was given access to assume a role inside those accounts, you don't need to call manually STS every time (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) and configure the credentials.
With this config file you can then use aws cli like:
Find JSON examples in
Users can have MFA enabled to login through the console. API tokens of MFA enabled users aren't protected by MFA. If you want to restrict the access of a users API keys using MFA you need to indicate in the policy that in order to perform certain actions MFA needs to be present (example ).
As , there are a lot of different cases where MFA cannot be used.
An IAM is a way to attach policies to multiple users at one time, which can make it easier to manage the permissions for those users. Roles and groups cannot be part of a group.
The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited. For more information, see .
An IAM role is very similar to a user, in that it is an identity with permission policies that determine what it can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it (and have enough perms). An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a who signs in by using an external identity provider instead of IAM.
The . The .
Note that by default AWS might add session policies to sessions that are going to be generated because of third reasons. For example, in by default (using enhanced authentication), AWS will generate session credentials with a session policy that limits the services that session can access .
In you can find the IAM ID prefixed of keys depending on their nature:
You can use the ~/.aws/config file to, and then use the --profile param as usual (the assume-role will be performed in a transparent way for the user).
A config file example:
If you are looking for something similar to this but for the browser you can check the extension .
Learn & practice AWS Hacking: Learn & practice GCP Hacking:
Check the !
Join the 💬 or the or follow us on Twitter 🐦 .
Share hacking tricks by submitting PRs to the and github repos.
ABIA |
ACCA | Context-specific credential |
AGPA | User group |
AIDA | IAM user |
AIPA | Amazon EC2 instance profile |
AKIA | Access key |
ANPA | Managed policy |
ANVA | Version in a managed policy |
APKA | Public key |
AROA | Role |
ASCA | Certificate |
ASIA |
use this prefix, but are unique only in combination with the secret access key and the session token.
