1. How They Work?
1.1. Cyber Kill Chain has changed with using Cloud solutions
1.2. Similar pattern are used in a Cyber Kill Chain
1.2.1. The phase of reconnaisance is still needed to get access to an AWS account.
1.2.2. When attack is done, a clean up is still needed
1.2.3. All parts of the chain still exists
1.3. Some changes of the last few years
1.3.1. Shifted to checking vulnerabilities and dependencies during development
1.3.2. Sandboxing of the application
1.3.3. Containerization of applications
1.3.4. Runtime protection in applications
2. Cloud Attacks are different
2.1. Reconnaisance
2.1.1. Resources can be accessed using hte AWS CLI and do some Reconnaisance.
2.1.2. Reconnaisance has become often easier with the Cloud solutions
2.2. Delivery
2.2.1. Other trust relationships exists by using other solutions which integrates with AWS: ServiceNow, Github, etc.
2.2.2. Getting data in and out of AWS has become easier
2.2.3. Every command can have been tested outside of your AWS account. Everything is very good documented.
2.3. Exploitation
2.3.1. Clean up of tracks by the attacker could be done by setting lifecycle or logs.
2.3.2. Automation can work for you or against you.
2.4. AWS Organizations
3. Patterns of Escalation Attacks
3.1. Direct Self Escalation
3.1.1. Identity changes it's own rights to an administrator account
3.1.2. Example: Somebody misconfigures your identity in AWS
3.2. Indirect Escalation
3.2.1. Identity changes another account to administrator to impersonate it
3.2.2. Examples: 1. Add a user to a group. 2. Helpdesk admins can reset password or create access keys.
3.3. Confused Deputy
3.3.1. One identity can control or manipulate another identity, and coordinate it to work on your behalf.
3.3.2. Example 1: developer has access to a virtual machine. Somebody has provided the developer more permissions then needed. The developer is able to do more then allowed.
3.3.3. Example 2: API gateway triggering a serverless function doing something on its behalf. If the function is not specifically checking which API gateway is calling the function. The attacker could setup an API gateway in another account and fire a the function. The access to the other account could have been done through reconnaisance of that account.
3.4. Resource Permission
3.4.1. Example: Access to modify the permission of a resource and use it on your behalf. Modify the policy of a bucket, etc.
3.4.2. The account is properly protected, but the policy of resources like buckets, snapshots, disc voumes, etc can be modified.
4. Prevention Mechanisms
4.1. AWS Service Control Policy
4.1.1. Use SCP to block an escalation permission from all users except a certain Role.
4.2. Mapping of Trust Relationships
4.3. Identifying and closing potential sources of escalation attacks
4.3.1. Services that can be used for confused-deputy based attacks
4.3.2. Uncontrolled resource statements
4.3.3. Pre-signed Urls
4.4. Least privilege & least access policy and execution
4.5. Escalation Analysis
4.5.1. Example: Create to a lambda function, pass the function a Role, use the Role in the account, perhaps there is an administrator Role, and perhaps be able to delete the complete account.
4.6. AWS tools
4.6.1. AWS Guard Duty
4.6.2. Open Source: RhinoSecurityLabs
4.6.2.1. Good for one-time assessment
4.6.2.2. Use for one account only