From AWS Logs to Security Alerts: My First CloudTrail Investigation

# From AWS Logs to Security Alerts: My First CloudTrail Investigation

## Introduction

When I started learning cloud security, I initially focused on services such as EC2, S3, and IAM. But I soon realized that protecting a cloud environment is only part of the problem.

We also need to know what is happening inside the environment.

Who created a resource?

Who changed a security group?

Who modified an IAM policy?

When did the activity happen?

This is where AWS CloudTrail becomes extremely useful.

In this article, I will explain how CloudTrail can help beginners understand AWS activity from a security perspective.

## What is AWS CloudTrail?

AWS CloudTrail records activities that occur in an AWS environment.

Many actions performed through the AWS Management Console, AWS CLI, and AWS APIs generate events that can be recorded by CloudTrail.

These events can provide useful information such as:

- Who performed an action
- What action was performed
- When it happened
- Which AWS resource was involved
- Where the request originated
- Whether the request was successful

This makes CloudTrail an important source of information during security investigations.

## Thinking Like a Security Analyst

Instead of looking at CloudTrail as simply a logging service, I find it more useful to think about it as a source of evidence.

Imagine that an unexpected IAM policy change appears in an AWS account.

A security analyst might ask:

1. Who performed the change?
2. What exactly was changed?
3. When did it happen?
4. Which resource was affected?
5. Was the activity expected?
6. Were there other suspicious activities around the same time?

CloudTrail can help answer many of these questions.

## A Simple Investigation Scenario

Imagine a fictional AWS account where a security team notices that an IAM permission was unexpectedly modified.

Instead of immediately assuming that the account was compromised, we can investigate the activity.

The first step is to identify the relevant CloudTrail event.

We might look for information such as:

- Event name
- Event time
- Username or identity
- Source IP address
- AWS region
- Resource name
- Request parameters

The goal is to build a timeline of what happened.

## Understanding an API Event

A CloudTrail event can contain many fields.

Some particularly interesting fields for security investigations include:

### EventName

This tells us which API operation was performed.

For example, an event might represent an IAM-related operation.

### EventTime

This tells us when the activity occurred.

Time is extremely important when building an incident timeline.

### UserIdentity

This provides information about the identity associated with the request.

It helps us understand which user, role, or AWS service was involved.

### SourceIPAddress

This can help identify where the request originated.

An unexpected source IP can be an important investigation clue, although it should not automatically be treated as malicious.

### AWSRegion

This tells us the AWS region associated with the event.

Unexpected activity in a region that an organization normally does not use could deserve additional investigation.

## What Makes an Event Suspicious?

A single unusual event does not necessarily mean an attack occurred.

Context is important.

For example, these situations could deserve investigation:

- An administrative action outside normal working hours
- Unexpected IAM permission changes
- Creation of unfamiliar access credentials
- Changes to security groups
- Activity from an unusual location
- Unexpected changes to logging configuration
- A user performing actions outside their normal responsibilities

The important lesson is:

> An unusual event is a clue, not automatically proof of an attack.

## Building a Timeline

One of the most useful techniques I learned is creating a timeline.

For example:

```text
10:02 — Successful login
10:05 — IAM policy modified
10:07 — New credential created
10:12 — S3 access detected