General

  • In AWS, access keys function much like traditional usernames and passwords, granting programmatic entry to services through an access key ID and secret key pair.

  • Identity and Access Management (IAM) defines how those credentials are used. Policies exist in two main forms:

    • Managed policies are reusable and can be applied across multiple identities

    • Inline policies are bound to a specific user or group, providing highly targeted control.

  • Roles operate similarly to users but differ in that they do not carry long-term credentials. Instead, they rely on temporary credentials issued when the role is assumed, making them central to delegated access and lateral movement scenarios.

  • Amazon S3 serves as the cloud’s equivalent of an FTP service. Data is organized into buckets, which act as globally unique top-level containers, and within them, objects represent the files or datasets being stored. Access to these resources is governed by several control mechanisms:

    • Identity-based IAM policies (identity-based)

    • resource-based bucket policies (bucket-based)

    • Access Control Lists (legacy)

  • AWS Lambda is a serverless compute service that executes code in response to events without requiring server management. Functions run within isolated environments with resources, permissions, and triggers defined by the configuration. This model enables rapid, event-driven execution but also makes security heavily dependent on IAM roles, environment variables, and network settings. When testing look for:

    • Overly privileged execution roles (e.g. iam:PassRole -> you can assume whatever permissions the lambda function has)

    • Exposed secrets (env vars, source code)

    • Writable functions

  • Amazon EC2 (Elastic Compute Cloud) provides virtualized servers in the cloud that allow deployment of applications with configurable compute, memory, storage, and networking resources. Instances can run various operating systems and are managed similarly to traditional servers but with scalable, on-demand provisioning. Security and exposure largely depend on IAM roles, security groups, and proper configuration of the underlying operating system and applications.

    • VMs in the cloud

    • Security groups are FW rules that sit in front of each EC2 instance

    • Key pairs -> SSH access

    • Instance Metadata Service

    • IAM Instance Profile (run as)

    Access to an EC2 can lead to:

    • Metadata

    • IAM Perms

    • Exposed secrets

    What to look for:

    • SSH ports

    • Metadata endpoint (http://169.254.169.254)

    • User data (e.g. startup scripts for EC2 configuration)

Last updated

Was this helpful?