AWS Forensics : What you need to know

Introduction 

Contrary to Microsoft Azure and Entra ID which are mostly used as extensions to a company's internal and corporate information system, Amazon Web Services are essentially used to deploy external applications.
Over the past few years, AWS has issued a number of security recommendations, including a comprehensive incident response plan. Unfortunately, the latter is difficult for most companies to apply in the event of a security incident.

The purpose of this article is to provide a clear and practical starting point for anyone new to AWS who needs to handle an incident on the platform. It isn't claiming to replace the official documentation, a proper training or cover every aspect in detail, in particular the topic of networking, which deserves a whole article of its own. It also does not address the costs associated with deploying different services or components, as these vary significantly depending on the service or resource being deployed or configured.

Identity and Access Management

Organization and AWS Account

An AWS environment is built around an AWS organization, which forms the basic structure. It is the equivalent of an Azure tenant in the Microsoft ecosystem. This organization is made up of AWS accounts, which are used to deploy and manage resources. An AWS account corresponds to an isolated space or container within which resources can be created, configured and managed.

The management account is the organization’s main account. It enables the administration of the entire AWS environment, centralizing billing and ‘orchestrating’ the deployment of other accounts. Each AWS organization has only one management account.

The member account is used to deploy and isolate resources according to business or technical requirements. It is common to have accounts dedicated to test environments, production environments, or different types of activities.

Within the management account, it is also possible to group member accounts into organizational units. These units allow you to group together several AWS accounts to which you can apply a set of common rules (structure, permissions, configuration, etc.).

In some cases, some resources may be deployed directly from the management account. However, this practice is generally discouraged in production environments and may be an indicator of an anomaly.

The following diagram summarizes the basic components found within an AWS organization:

Each AWS Account is identified by a 12-digit number, such as 012345678901: the Account ID. It is used to distinguish resources in one account from those in another account.

Identity

AWS account management is based on user accounts known as identities. In AWS, the term ‘identity’ refers to an entity (a person or a ‘programmable’ resource) that can authenticate itself and has permissions to access resources and perform actions. There are four main types of identities: the root user, the IAM user, federated identities and IAM roles.

A programmable resource is a service or component that can be controlled via programming using an API or SDK to automate tasks. Unlike static resources, they can authenticate themselves, perform actions using temporary permissions, and interact with other AWS services.

The root user is the primary and sole identity (or user account) for each AWS account (only one root identity per account). They have full privileges for account administration. Access is granted via the email address associated with the account, a password, and a second factor (usually physical as recommended by AWS, but it can also be virtual). As this is the most sensitive identity within the account, it is often reserved for managing billing, account recovery or changes to permissions at the AWS account level. Day-to-day administration is generally delegated to another identity.

An IAM role is a temporary identity, a kind of container that bundles permissions to access resources and perform actions. Authorized users or services can assume (i.e. use) this role to obtain temporary privileges. This mechanism is particularly useful for multi-account access or for delegating day-to-day administrative tasks without needing to use the root user.

IAM users are identities associated with an AWS account and are uniquely identified within that account. They access the AWS Console using a username, password and Account ID, or via programmatic access using permanent API keys (identified by the prefix AKIA*).

Federated identities allow access to AWS via an external identity provider such as Okta, Microsoft Entra ID (ex-Azure AD) or Google, using the SAML or OIDC protocols. They can be granted temporary access to different accounts by assuming IAM roles and using temporary API keys (identified by the prefix ASIA*).

The following diagram provides a simplified overview of the types of idenity that can be held within an AWS account:

Permissions

To specify a resource unambiguously across all of AWS, Amazon Resource Names (ARNs) are used. The structure of ARN is the following: arn:partition:service:region:account-id:resource-type/resource-id

Permissions in AWS are managed by the IAM service, which determines who can access which resources and perform which actions. These permissions are described in a JSON document structured as follows: 

• Version: indicates the version of the policy language used. Version 2012-10-17 is the most recent; it defines the syntax and available features.
• Statement: this is the core of the policy. It contains all the instructions that define the access rules.
• Effect: specifies whether the action is allowed (Allow) or denied (Deny). By default, everything is denied (implicit deny), and a Deny instruction always takes precedence over others.
• Action: defines the list of AWS actions allowed or denied on a resource. The level of granularity allows you to target a specific action on a resource, or conversely all actions via a wildcard (*).
• Resource: contains the ARN of the relevant AWS resource. It often takes the form arn:aws:resource_type:::my_resource/*. The wildcard is used when the resource contains several sub-elements to which the policy must apply.

In some cases, other fields may also appear, sometimes optionally:

• Principal: in the context of a resource-based policy, it may be necessary to specify the AWS account or identity to which the policy applies. This field is not used in the case of a policy associated with a role.
• Sid: an optional identifier used to distinguish between multiple instructions within the same statement.
• Condition: allows specific constraints to be added to the rule, for example to restrict certain actions to a given range of IP addresses.

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "S3ReadWrite",
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:ListBucket"
        ],
        "Resource": [
            "arn:aws:s3:::my-bucket-prod",
            "arn:aws:s3:::my-bucket-prod/*"
        ],
        "Condition": {
            "Bool": {
                "aws:MultiFactorAuthPresent": "true"
            },
            "IpAddress": {
                "aws:SourceIp": "203.0.113.0/24"
            }
        }
    },
}

In this example, we define a policy called S3ReadWrite. This permission allows users to access and list files, as well as create files in the my-bucket-prod bucket, provided that they are authenticated using two-factor authentication and belong to a specific IP range.

Furthermore, there are several types of policies in AWS, depending on how they are applied.

Identity-based policies correspond to permissions granted (or attached) directly to users, roles or groups. They fall into three categories, two types of managed policies and inline policies: 

• AWS managed policies are created and maintained by AWS. They are generic and can be attached to multiple identities
• Customer managed policies are created by the user. They allow for the creation of custom permissions and can also be reused across multiple identities.
• Inline policies, on the other hand, are attached to a single identity and cannot be shared. They are generally used to apply specific restrictions, for example to manage an identity external to the organization, or to prevent a very permissive policy (such as delegated administrative rights) from being accidentally applied to other identities.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadBucketS3",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket-example/*"
    }
  ]
}

In the example above, the policy allows an IAM role or user to download files (Action: s3:GetObject) from my-bucket-example, but not to delete them or access other buckets.

Resource-based policies correspond to permissions defined directly at the level of an AWS resource. Their distinctive feature is that they explicitly specify which identities (or principals) are authorized to access the resource. Thus, even if an identity has broad permissions via identity-based policies, it will not be able to access the resource unless it is listed in the resource’s policy (with the exception of the owner). This type of policy is commonly used with services such as Amazon S3, and allows access to be controlled directly at the resource level, regardless of the policy attached to the identities.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:user/JohnDoe"},
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket-example/*"
  }]
}

In the example above, this is a policy that applies not to an identity but to a resource. Here, only the user JohnDoe (whose Principal is specified) can read the objects in the bucket.

Permission boundaries are a mechanism for setting a maximum limit on the permissions granted to an identity. They are primarily used to mitigate the risks associated with the delegation of permissions. For example, a team of developers may have permissions allowing them to create IAM roles as required. Without controls, they could create a role with very broad permissions such as s3:*, granting full access to all S3 buckets. By applying a permissions boundary, it is possible to allow the creation of roles whilst restricting the actions they can contain. In this case, permissions could be limited to s3:GetObject to prevent sensitive actions such as deleting buckets.

Permission boundaries are generally associated with IAM roles or users and can be identified via the iam:PermissionsBoundary condition.

SCPs (Service Control Policies) are policies that define a maximum level of permissions at the level of an AWS organization, an organizational unit (OU) or an account. They apply to all identities within the relevant scope, including the root user of each account. Furthermore, a “Deny” rule defined in an SCP takes precedence over all other policies.

At this point, a question naturally arises: can these different policies be combined? The answer is yes. It is therefore essential to understand how they interact with one another. The diagram below provides an overview of the order in which the different types of policies are assessed.

Less commonly, other types of policy may be encountered. These include permissions based on ACLs (Access Control Lists), which have been deprecated since 2023 but are still present in some environments for historical reasons. One may also come across RCPs (Resource Control Policies) as well as session-based policies.

Session policies allow temporary permissions to be granted for a limited duration, such as one hour. They are particularly useful for streamlining administration by providing one-off access, usually based on an existing role, rather than creating a new role each time a need arises.

In practice, permissions are most often associated with IAM roles, as these are simpler to manage and maintain over time.

Landing Zones

In multi-account environments, the concept of a landing zone is often misunderstood. It is frequently reduced to simply having multiple accounts accessible via the AWS portal, each with different roles associated with their identity.
 

While access to multiple accounts can indeed be a result of a landing zone, it is important to understand that this concept is not limited to that. A landing zone is a secure architecture designed to centralize governance and standardize account deployment. Rather than creating each account manually, which risks introducing significant inconsistencies in policies, administration, and security, a common framework is established that applies to all accounts.

In practice, a landing zone is generally characterized by:

• an AWS organization that allows accounts to be centralized and structured ;
• OUs to segment environments and use cases ;
• accounts dedicated to specific functions, such as security, logging, shared services, administration or applications ;
• global policies, such as SCPs, applied to all accounts or certain OUs, as well as more targeted policies depending on account types ;
• centralized identity management, often via IAM Identity Center ;
• a common, predefined network strategy covering routing, VPCs, traffic management and firewalls according to account types ;
• centralized log and security management, to provide a comprehensive view of compliance, monitoring and alerts.

A landing zone typically includes the following components:

• Management account: used to create and organize accounts and organizational units (OUs), as well as to set up SCPs ;
• Logging account: centralizes and stores audit logs in raw format in an immutable manner ;
• Security and audit account: hosts security tools and enables monitoring, detection of abnormal events, and auditing of resources deployed across the various account ;
• Infrastructure account: manages shared resources and network connectivity, such as VPCs, routing, or firewalls, to prevent duplication ;
• Workload account: It is associated with an application, a team, or an environment. It represents the business or operational side of organization.

The following diagram illustrates a landing zone architecture.

AWS Control Tower is often used to deploy a landing zone, as it provides a foundation for structuring this environment.

Services and Resources

In a traditional infrastructure, companies directly own and manage physical servers, storage, networking equipment, and all associated services and applications installed on-site for which the company is responsible. In a virtualized cloud environment, the cloud provider handles the entire physical layer, servers, networking, and storage, and delivers it as on-demand services. This is the shared responsibility model:

AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.

As a result, all infrastructure components are delivered as configurable services that can be provisioned on demand. In this first chapter, we focus on the core AWS services, over 200 in total today, particularly those in key categories: compute, containers, databases, storage, security, identity & compliance, networking & content delivery, and serverless. These categories cover most of the traditional components found in a conventional information system and are often involved or provide contextual information about security incident.

In AWS, the terms service and resource are sometimes used interchangeably, although this is a misnomer. In reality, a service refers to a functional capability offered by AWS, whereas a resource refers to a specific object or instance that enables the use of that service.

AWS resources often share several common attributes, including:

• a name ;
• a unique identifier within the service ;
• the AWS account in which they are deployed ;
• sometimes an identity or permissions associated with them ;
• the region and, where applicable, the availability zone ;
• its ARN (Amazon Resource Name), which is, as stated before, the unique identifier for the resource within the AWS context.

In this section, we will present some examples of resources commonly used in AWS, specifying for each one the associated service, category, role, and key AWS characteristics. The aim is to be able to easily identify the key and relevant information related to any given resource.

Amazon EC2

• Name: Amazon Elastic Compute Cloud
• Category: Compute
• Description: Instance of virtual server (i.e: virtual machine) with dynamic resources (memory, CPU, size, ...)
• Core properties: 
  • Instance ID: unique alphanumeric identifier (for example i-0123456789abcdef0) assigned to an instance of virtual machine, used mainly for managing operation and monitoring
  • IMDS: local REST services on each EC2 instances that provide dynamic metadata like instance ID, IAM credentials and network information
  • AMI ID: unique alphanumeric identifier (for example ami-0123456789abcdef0) used to identify image template use to create an instance of virtual machine
  • AMI Name: name of the image used to create an instance of virtual machine
  • Launch time: creation date of an instance of virtual machine
  • Instance ARN: unique alphanumeric identifier (for example arn:aws:ec2:us-east-1:123456789012:instance/i-0123456789abcdef0) which is a combination of service ec2, region us-east-1, account ID 123456789012 and instance ID instance/i-0123456789abcdef0. It is mainly used to define rights via a policy
  • VPC ID:  global network associated with the AWS environment
  • Subnet ID: subnetwork with specific IP range associated with the EC2 instance
  • IAM Role: Identity attached to a virtual instance that provides credentials (Access Key, Secret Key and Token) that define permissions on AWS resources
  • Owner ID: account identifier (inside Instance ARN) that own and launch the virtual instance
  • Other usual information: private IP, instance name, DNS 

Amazon Lambda

• Name: Amazon Lambda
• Category: Compute
• Description: Serverless compute service that runs code in response to events without provisioning or managing servers
• Core properties: 
  • Last modified: last change of code or configuration
  • Function ARN: unique alphanumeric identifier (for example arn:aws:lambda:region:123456789012:function:lambda_name), the numeric ID belongs to the owner of the lambda
  • Runtime: programming language and version
  • Code source: Source code content that is executed
  • Trigger (if existing): event that triggers code execution
  • Execution role: IAM role granting permissions to access AWS resources

Amazon VPC

• Name: Virtual Private Cloud
• Category: Networking and Content Delivery
• Description: Logical virtual private network of AWS environment (LAN equivalent in AWS)
• Core properties: 
  • VPC ID: unique alphanumeric identifier (for example vpc-0123456789abcdef0) assigned to an instance of a virtual private network
  • DNS Resolution: allows instances in the VPC to query Amazon's DNS server (Route 53 Resolver) to translate domain names into IP addresses (including external and internal domains)
  • DNS Hostname: determines whether AWS automatically assigns public DNS hostnames to instances launched with public IPs, enabling access via a friendly name like ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com 
  • Subnet: subnet list with associated CIDR blocks and region of the VPC
  • Main Network ACL: list of stateless rules that control "allow" and "deny" traffic of a subnet

Amazon S3

• Name: Amazon Simple Storage Service
• Category: Storage
• Description: Storage service of object (file and metadata) inside containers (bucket) that provide logical organization (as a classical file system)
• Core properties: 
  • ARN: unique alphanumeric identifier (for example arn:aws:s3:::bucket_name) to identify the bucket
  • Creation Date: date and time when the bucket was created
  • Block Public Access: defines external access policy
  • Bucket Policy: policy defining the permissions on objects stored in the bucket
  • Lifecycle rules: object retention period
  • Bucket versioning: enables multiple variants of an object in the same bucket
  • ACL: permissions (list, write) granted to other accounts, including "Everyone" (anonymous account) on stored object
  • Source Account: Account ID of the bucket's owner

Amazon SNS

• Name: Amazon Simple Notification Service
• Category: Application Integration
• Description: Messaging service for sending notifications and messages 
• Core properties: 
  • ARN: unique alphanumeric identifier (for example arn:aws:sns:region:094487668201:topic_name) to identify the topic
  • Topic: communication channel where publishers (AWS Services when an event is triggered) send messages for distribution
  • Subscription: action (e-mail sending, lambda execution, etc.) associated with the topic
  • Owner: identifier of the creator and owner of the topic

AWS Region and Availability Zones

AWS has numerous data centers located around the world. An AWS region corresponds to a distinct geographic area where AWS deploys its services and hosts data. Its location is chosen to minimize latency, comply with regulatory requirements, and allow users to choose where their resources are hosted. 

Regions are independent of one another and isolated by default: a resource deployed in one region is not accessible from another region unless explicitly configured. Additionally, it is important to note that not all AWS services are available in every region.

Each region is subdivided into Availability Zones (AZs). An Availability Zone corresponds to a physically isolated data center, but one that is interconnected with other zones in the same region via a low-latency network. Resources deployed within the same region but in different Availability Zones can therefore communicate with each other if the network configuration allows it.

In the event of an incident, it is necessary to verify and confirm all active regions that are normally in use.

AWS key artifacts

In all environments, activity logs are the primary source of information analyzed in the event of an incident. These analyses often rely on two main services: CloudTrail and GuardDuty.

CloudTrail is the default logging system for AWS services. It records in detail all actions performed via the console or programmatically (via API calls in both cases), whether initiated by users, roles, or services. These are primarily management events, which are enabled by default, and cover the creation, viewing, modification, and deletion of resources. 

For example, in Amazon S3, there are actions such as CreateBucket, ListBuckets, DeleteBucket and GetBucketAcl. Amazon documents the full list of these events along with their descriptions.

CloudTrail offers other types of events that are not enabled by default and must be explicitly enabled as required:

• Data events: actions performed directly on resources. For example, in the case of S3 buckets, retrieving, uploading or deleting an object is not logged by default.
• Insights events: anomalies detected by CloudTrail Insights, such as unusual spikes in API calls or a high error rate.
• Network activity events: events related to network activity, such as cross-VPC actions. Furthermore, they only apply to a limited number of services.

In practice, analyses are primarily based on management events, while other types are often left disabled.

CloudTrail logs can be accessed via the AWS Console, under the Event History tab

By default, Event History retains 90 days of events.

It allows you to view all CloudTrail events and quickly filter them using the filter menu, based on criteria such as identity (user or role), source (service or resource involved), or event name when searching for a specific action.

You can customize the displayed columns, but their number is intentionally limited for consistency and does not cover all the information available for each record.

For more advanced searches, including specific attributes such as the user-agent, it is preferable to use Data Lake queries. This is a datastore that centralizes CloudTrail events and allows them to be queried via SQL queries.

However, this datastore must first be configured: create the datastore (with a specific name), define the retention period (based on the desired cost), and select the relevant regions and the types of events to track (management events, data events, or insights).  

It is important to note that the datastore will only contain events generated after its creation: if it was not activated before the incident, it will not contain event before for that incident.

In this case, you can use Athena, a serverless AWS service that allows you to run SQL queries directly on data stored in an S3 bucket. This is the case for CloudTrail events, which are generally stored (in JSON format) in an S3 bucket.

In addition to CloudTrail logs, you can use GuardDuty, a service for detecting and monitoring the AWS environment (not enabled by default, but sometimes already present in the environments we encounter).

GuardDuty automatically analyzes multiple data sources, including CloudTrail events, activity from certain services (S3, EC2, RDS, EKS, ECS, Lambda), and logs specific to certain activities, particularly network activity. It leverages threat intelligence feeds (lists of malicious IP addresses and domains, file hashes) and machine learning (ML) models to identify suspicious or potentially malicious behavior. The results can be viewed in the Findings tab.

The official GuardDuty documentation lists the main detection rules offered by the service. Viewing the details of each alert allows you to identify the affected resources, as well as the specific actions that triggered the detection.

Before use, the service must be configured: select the protections (plans) to enable, set the retention period for findings (90 days by default), and specify an S3 bucket for storage. Unlike CloudTrail, GuardDuty retains only alerts related to a specific region and does not natively centralize findings from multiple regions. Similar to DataLake, detection is performed only on logs generated after activation

AWS Threat : common techniques and events

As we have seen, an AWS environment functions like a traditional information system, with the difference that the hardware is not managed directly by the organization. 

An intrusion on AWS often unfolds in the same way as a traditional intrusion: reconnaissance phase, privilege escalation, persistence, lateral movement, and final actions driven by the attacker’s objectives (often data theft, exploiting calculation resources like crypto-mining, or ransomware, as with the Codefinger malware).

In the AWS context, the main attack vectors are generally related to:

• a vulnerability in an exposed service (for example, a vulnerable application running on EC2);
• the use of credentials discovered outside the environment (exfiltrated from a workstation, or poorly protected in code repositories);
• or misconfigured services (S3 accessible from the internet, EC2 exposing SSH/RDP without IP restrictions).

The starting point for an incident is often the detection of unusual behavior by operations and administration teams: unexplained spikes in billing, large-scale service deployments, unexpected executions of Lambda functions, or alerts triggered by GuardDuty. These indicators help quickly identify the key areas to focus on during the investigation.

The main challenge often lies in identifying relevant events related to an attack, as well as in interpreting them. In this context, we will focus on some common techniques, especially attack phases, used by attackers who already have a foothold in the environment. These techniques are based on observations from real incidents, insights from Synacktiv’s penetration testing and Red Team activities, and widely documented attack patterns. Each technique will be mapped to their corresponding detection indicators.

Common Enumeration Events

This phase encompasses the techniques used by an attacker to gather information to identify users, analyse their permissions and gain a deeper understanding of the environment. It often involves a series of Get / List / Describe requests following the retrieval or compromise of credentials.

Detailed examples of enumeration and discovery techniques 

Technique: Retrieving the Account ID from an S3 bucket

Using an identity with s3:GetObject and s3:ListBucket permissions, an attacker can make several requests in an attempt to discover the Account ID. This technique relies in particular on the s3:ResourceAccount condition, which is often used in policies restricting access to certain accounts. As this condition accepts the * wildcard, it is possible to construct requests that allow the various digits making up the Account ID to be inferred. This approach is documented by Tracebit and implemented in the tool s3-account-search.
Detection: Repeated occurrences of s3:GetBucketAcl on the same resource or across multiple buckets.

Technique: Retrieving the Account ID from an API key
When an attacker has a compromised access key, they can retrieve the associated Account ID, even in some cases where the key has expired. To do this, they can use the command aws sts get-access-key-info --access-key-id , and then exploit the result offline.
Detection: This type of request is not usually logged in CloudTrail, which severely limits visibility on the AWS side.

Technique: Enumerating roles and users from an S3 bucket and an account ID
When a compromised identity owns a bucket, it may have the necessary permissions to modify its policy. The attacker can then test different Principals from a wordlist to identify the existing IAM roles and users in the account. This is the principle behind the tool enumate_iam_using_bucket_policy by Nick Frichette.
Detection: Repetition of s3:PutBucketPolicy events with successive variations in the Principal values.

Technique: Enumerating permissions using an API key
When an attacker possesses an access key and its associated secret, even if they have expired, they can test various API actions to identify the permissions that are actually available. Tools such as enumerate-iam automate this process by issuing a list of API calls and analyzing the ‘Allow’ or ‘Deny’ responses.
Detection: A high volume of API calls across several services or resources, indicating abnormal behavior.

Technique: Retrieving and exploiting credentials from a compromised EC2 instance
EC2 instances expose a service called the Instance Metadata Service (IMDS), which allows access to certain local information about the instance. This metadata includes, in particular, the network configuration, attached roles and other sensitive information.

Access is via HTTP requests to the address 169.254.169.254, for example http://169.254.169.254/latest/meta-data/<category>.

After compromising an instance, an attacker can check for the presence of an instance profile via http://169.254.169.254/latest/meta-data/iam/info, then retrieve the associated temporary credentials with http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole or http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance.
Detection: As these requests are made locally from the instance, they are not usually logged directly in AWS.

Post-recon and persistence

This section describes other techniques commonly used by attackers to steal secrets and establish persistence, typically following the reconnaissance and discovery phases.

Technique: Windows Password Retrieval
Once an attacker has compromised an EC2 instance and obtained a valid identity, they may attempt to retrieve the system’s administrator password. If this password is reused on other instances, it can facilitate lateral movement and enable the attacker to gain administrative privileges.
Detection: Events  ec2:GetPasswordData and sts:AssumeRole, often accompanied by an error code indicating that the action is not authorized. Analysis of the Account ID, API key, and user-agent can serve as a pivot.

Technique: Secret Retrieval
An attacker with a valid, privileged account may attempt to retrieve secrets managed in AWS Secrets Manager in order to further compromise the system. This service can store various types of secrets, such as API keys, application credentials, or tokens.
Detection: Event secretsmanager:ListSecrets to list available secrets followed by secretsmanager:GetSecretValue to retrieve their contents.

Technique: Retrieving the EC2 Instance Boot Script
When an EC2 instance is created, it can execute a boot script via Instance User Data, typically used for its initial configuration. This source of information may be of interest to an attacker, as it may contain hard-coded secrets or sensitive parameters.
Detection: Event ec2:DescribeInstanceAttribute, often followed by a sts:AssumeRole.

Technique: Modifying an EC2 instance’s initialization script
After retrieving the initialization script’s information, an attacker may attempt to modify it to inject code that will execute at every startup or to establish a persistence mechanism.
Detection: Events ec2:StopInstances, required to stop the instance before modification, followed by ec2:ModifyInstanceAttribute with a non-empty requestParameters.userData parameter containing the elements to be executed.

Technique: SES Enumeration
Once the AWS environment has been compromised, an attacker may seek to exploit the infrastructure for malicious purposes, such as phishing campaigns. The SES service can then be used to send emails.
Detection: Event ses:GetAccountSendingEnabled to check if the service is enabled, ses:GetSendQuota to determine the daily quota, ses:ListIdentities to identify identities capable of sending emails, and ses:GetIdentityVerificationAttributes to confirm that an email identity is active.

Technique: Executing commands on EC2 instances
When an attacker obtains sufficiently high privileges, they may attempt to execute commands on multiple EC2 instances to conduct reconnaissance. This approach often relies on AWS Systems Manager, an administration service present on many instances.
Detection: Event ssm:StartSession to start a session on one or more machines, and ssm:SendCommand to execute a command with a requestParameters parameter containing the list of targeted instances. The executed command is not always visible in AWS logs for security reasons. However, it can often be found in the EC2 instance’s system logs.

Technique: IAM Role Backdoor
When an attacker has access to multiple accounts in an environment, they may seek to establish persistent access to a sensitive account. Rather than creating a new identity or role, they can modify the trust policy of an existing role to make it assumable from another account that is less sensitive and less monitored.
Detection: Event iam:UpdateAssumeRolePolicy, with a search for the added principal or identity.

Technique: Lambda Function Backdoor
When an attacker has access to a Lambda function, they can use it to inject code that will be executed on every invocation. This can, for example, trigger a reverse shell or add a persistence mechanism.
Detection: Event lambda:UpdateFunctionCode20150331v2. A manual review of the code is still necessary, as the logs do not detail the exact nature of the changes.

Toolbox: Logging, Audit and Analysis

Strengthening Logging

Although CloudTrail and the default activation of GuardDuty make it possible to track most of an attacker’s actions, these logs are often incomplete. 

For example, they do not capture massive data downloads from an S3 bucket (a sign of data exfiltration) or activity within an EC2 instance. Other log sources and configuration adjustments can improve coverage and visibility. Below is a list of additional logs and configurations.

CloudTrail

Data events

Unlike management events, which log management actions on resources (creation, modification, deletion), data events capture actions performed directly on the data itself. For example, for an S3 bucket, management events document the creation/deletion of the bucket, but access to objects (GetObject, PutObject) remains disabled by default. During data exfiltration or encryption, these actions become invisible without explicit activation.

Insights Events

Detect anomalies in API call volume (spikes in requests per minute or errors). Particularly effective for identifying brute-force or reconnaissance attacks.
 

Network Activity Events log API calls traversing VPC Endpoints (network interfaces allowing access to AWS services without going through the internal network) from a private VPC (internal subnet without internet access) to AWS services (S3, KMS, Secrets Manager, etc.). Equivalent to internal network traffic in an on-premises IT system, they help identify abnormal access (e.g., a suspicious account accessing a sensitive bucket via a private endpoint) that is not captured in standard management events.
 

Retention: 90 days by default. Recommended configuration: log to an S3 bucket with a retention period of 6–12 months via Lifecycle Policy.

GuarDuty

GuardDuty is a threat detection service that continuously monitors and analyzes in AWS environment.

It automatically analyses multiple sources of information, such as:

• AWS CloudTrail logs (API activity) ;
• VPC flow logs (network traffic) ;
• DNS queries ;
• Activity mainly on S3, RDS, EKS, ECS and EC2.

The key elements to configure in GuardDuty include:

• Protection plans, which represent the specific features and threat detection capabilities to activate ;
• Configuration of result export and retention, typically by setting up an S3 bucket to store findings

Protections plans are set of rules and features focused on specific use cases to improve threat detection in various AWS services (such as S3, Lambda, EKS, RDS, etc. Below is the list of available plans in GuardDuty. Unless otherwise specified, these plans are disabled by default:

• S3 Protection: monitors Amazon S3 buckets by analyzing CloudTrail data events to detect suspicious access and data exfiltration
• Malware Protection for S3: automatically scans newly uploaded S3 objects for malware presence
• EKS Protection (enabled by default for new account): monitors Amazon EKS clusters by analyzing Kubernetes audit logs to detect suspicious or harmful activity.
• Runtime Monitoring: provides real-time monitoring of processes, file access, and network connections on Amazon EC2, ECS, and EKS environments
• Malware Protection for EC2: scans EBS volumes attached to EC2 instances for malware.
• RDS Protection: monitors access and login activity on Amazon RDS and Aurora databases to detect suspicious behavior.
• Lambda Protection: monitors AWS Lambda network activity logs to detect suspicious or malicious behavior such as cryptomining
• Extended Threat Detection (enabled by default): a new plan enabled by which Automatically detects and correlates multi-stage attacks across multiple AWS data sources and services overtime

S3 Access Logs

S3 access logs record all HTTP requests made to a bucket, with a particular focus on the volume of data exchanged (bytes transferred, repeated requests), which is useful in cases of suspected data exfiltration

Lambda Logs

In addition to Data Events, which indicate who invoked a Lambda function, Lambda logs (CloudWatch Logs) capture execution details (stdout/stderr, errors, duration). Enabled by default with an appropriate IAM role (logs:*), they require configuration of the log group and retention policy (1 day to 10 years).

CloudWatch Logs

A monitoring service that collects metrics, events, alarms, and logs. The CloudWatch Logs component can be deployed on EC2 instances to collect and centralize system and application logs—depending on the desired configuration—in Log Groups, thereby facilitating their analysis.

VPC Flow Logs

Network logs that capture incoming and outgoing IP traffic from network interfaces (ENIs), covering both internal and external traffic. Similar to NetFlow, they record the following information: source/destination IPs, ports, and actions (ACCEPT/REJECT). Unlike Network Activity Events, which focus on the APIs and identities responsible for the event.

AWS Config

A service that continuously monitors and logs changes to resource configurations. Designed for service auditing and compliance, it offers the following features:

• Inventory: comprehensive list of resources and metadata;
• History: allows you to identify which identity modified which configuration and when;
• Compliance: use of managed or custom rules to assess services

Choosing Logs

The list provided is not exhaustive but covers common use cases, particularly CloudWatch Logs, which deserves special attention.
These logs, when enabled retroactively during an incident, do not capture events that occurred before they were set up. Nevertheless, they can serve as recommendations to address gaps identified during analyses or to help internal teams improve visibility.

The activation of additional logging must take the following criteria into account:

• Precise targeting: Avoid logging unused services (e.g., EKS not deployed);
• Prioritize critical and sensitive assets (e.g., S3 buckets with sensitive data or exposed EC2 instances);
• Cost assessment: Analyze the financial impact in advance.

Audit and Hunting

When analyzing logs, it is common to examine the configuration and security level of a resource or identity (e.g., Is MFA enabled? Is an S3 bucket accessible to anyone from the internet?). AWS offers various tools, originally designed for auditing, but which are also useful for hunting.

IAM Access Analyzer

Enables a comprehensive analysis of IAM policies to identify potentially excessive access based on the following profiles:

• External access: Resources accessible from outside the account (internet, other accounts);
• Internal access: Identification of privileged access;
• Unused access: Identification of inactive identities, keys, and secrets.

It also features a policy generator that allows you to validate and test (syntax and compliance) policies before deployment.

The analyses generate findings with associated risks. For example, this S3 policy:

{
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::secrets-bucket/*"
}

It will generate an alert indicating that the secrets-bucket resource is accessible from the internet with the following information :

• Resource: secrets-bucket
• External access: Principal:* (internet)
• Risk: Public read on secrets
• Action: Archive / Delete / Ignore

AWS Inspector

A vulnerability management service that automatically scans workloads (EC2, Lambda, ECS, code repositories) to detect CVEs, hard-coded secrets, and network exposure. It allows for fine-grained configuration to target only specific resources.

AWS Security Hub and CSPM

A security data aggregator and correlator. It centralizes, standardizes, correlates, and analyzes multiple data sources (CloudTrail, GuardDuty, Inspector, Config, etc.). It provides a severity score and prioritized insights (e.g., 3 major risks). Example of multi-source correlation on an EC2 instance:

• Vulnerability report from Inspector;
• Detection of SSH access from a foreign IP address in GuardDuty ;
• Identification of public Security Group 0.0.0.0/0 (EC2 accessible from any IP address on any port) from AWS Config.

The combination of these three findings generates a high-priority alert regarding the EC2 instance.

In addition to its correlation engine, it also relies on compliance rules based on standards such as CIS, PCI-DSS, or NIST.

Other tools such as Audit Manager, Macie, and Trusted Advisor can supplement the service analysis for more specific needs, even though the aforementioned tools already cover a wide range of requirements.

Other Tools 

AWS CLI

The official command-line interface for interacting with all AWS services. It is particularly useful for obtaining detailed and specific information about a given IAM identity or service.

For example, if you suspect that an identity has been compromised, you can determine whether an access key already existed or was created by an attacker using the following command: aws iam list-access-keys --user-name user_name.

This query lists the access keys associated with the user, along with their status (active/inactive) and exact creation date
Whether for an audit or an investigation, mastering the AWS CLI in your toolkit is a significant advantage.

Furthermore, it can also be used to copy logs stored in an S3 bucket and export them to third-party tools, thereby avoiding reliance on tools like Athena, which can be less flexible and more expensive.

Complementary Third-Party Tools

In addition to native AWS services, several open-source tools provide a holistic view of the environment and actionable insights for security analysis.

• Invictus-AWS: This tool enumerates active services in the account, collects their detailed configurations, and automatically extracts relevant logs related to the identified services.
• CloudMapper: Although deprecated, it remains useful for analyzing the entire AWS environment. It generates a network diagram of deployed resources and produces dashboards showing the security posture of identities and services.
• IAMHoundDog: Inspired by BloodHound, it builds a graph of relationships between IAM identities, policies, and selected resources. This allows you to visualize and identify potential paths for compromise or privilege escalation.
• Cloud Scout: Works similarly to IAMHoundDog, mapping cloud environments (including AWS) to detect vulnerabilities and exposures.
• ScoutSuite: A multi-cloud audit tool with capabilities similar to Security Hub. It scans configurations and identifies risk factors, generating structured and actionable reports.

These open-source tools ideally complement AWS’s native capabilities, covering a wide range of reconnaissance and analysis needs.

Conclusion

This article is intended to serve as an introduction for those with little or no experience with AWS. The topics covered are not meant to be exhaustive, but have been selected to illustrate fundamental and essential concepts.

Key points highlighted and worth noting include:

• The concept of AWS accounts and identities, which can be confusing for beginners;
• Permission management, whose apparent complexity requires a clear explanation;
• How AWS services work, highlighting their commonalities and specific features, in order to understand and identify the elements of interest in a given service;
• Common attack techniques used by attackers, as well as the traces they leave in the environment;
• The different types of logs available;
• Tools that facilitate analysis and strengthen overall security.

These elements are key to understanding how AWS works and make it easier to navigate this cloud environment.

Further Reading

For those who want to dig deeper, here are some recommendations for high-quality resources:

• The Datadog Security team blog, which features in-depth technical articles on AWS.
• Hacking Cloud, a blog focused on intrusion in cloud environments.
• Nick Frichette’s blog, an essential resource for AWS offensive security.
• The Stratus-red-team tool, which provides numerous examples of attack techniques and associated detection methods.
• CloudGoat by Rhino Security Labs, a simulation environment for replicating and testing various AWS attacks.
• A post-incident review of a real-world incident handled by our team (presentation available in French only).