Your GuardDuty Alert Isn't The End, It's Where Investigation Begins.

Using Amazon Detective to uncover the full story behind an AWS Security Event.

Introduction
The time is 2:13 AM.

A high-severity alert from your Security Operations Center (SOC) causes your phone to vibrate. An UnauthorizedAccess:IAMUser/ConsoleLogin discovery has been found in your AWS environment by Amazon GuardDuty.

You briefly question if it's just another false positive. After all, not every security discovery results in a breach, yet cloud environments produce thousands of events every minute.

The GuardDuty console is opened.The discovery offers a detection, which is precisely what it is intended to offer. It informs you that an IAM user was able to successfully authenticate from a strange place that doesn't correspond with the account's past activity. The action is suspicious enough to be investigated right now.

But almost instantly more questions arise than answers.

• Was this login actually malicious?
• Has the IAM user been compromised?
• What happened immediately after the login?
• Did the attacker access sensitive resources?
• Were AWS Secrets Manager secrets retrieved?
• Was data exfiltrated?
• Has the attacker established persistence?
• Is the incident still active?

When a security engineer receives an alert, they always ask these questions.

Sadly, the alert itself is unable to respond to them.
One of the most common misconceptions about cloud security nowadays is this.

Many teams think that the most challenging aspect of security is threat detection. In actuality, detection is just the first step. The true difficulty is figuring out an incident's entire extent fast enough to make wise decisions.

An alert informs you of an event. A probe reveals the truth. As businesses continue to move workloads to AWS, this distinction becomes more crucial. Contemporary cloud infrastructures are extremely interconnected, distributed, and dynamic. Numerous AWS services can communicate with a single IAM role. Hundreds of API requests can be made in a few minutes using a hacked credential.

In order to manually investigate these events, it is frequently necessary to switch between CloudTrail logs, GuardDuty findings, IAM policies, VPC Flow Logs, and several AWS terminals while attempting to put together a timeline from disparate bits of information.

This not only takes a lot of time, but it also causes a major delay in incident response. Amazon Detective was created specifically to address this issue. After an alert has been raised, Amazon Detective assists security teams in answering the most important questions rather than creating new alerts.

It automatically establishes connections between identities and resources, correlates data from AWS services, shows activity over time, and gives investigators the background information they need to comprehend what actually occurred.

Rather than asking, "Where do I start?", "How far did this incident spread?" is a question that investigators can start asking right away.

Detection Is Only Half The Battle
For good reason, Amazon GuardDuty has grown to be one of the most popular AWS security services. To find suspect activity, it continuously examines AWS activity using machine learning, anomaly detection, and AWS threat intelligence.

GuardDuty offers useful indications that assist enterprises in identifying threats early on, whether they are related to bitcoin mining, strange API activity, compromised credentials, or reconnaissance activities.

GuardDuty, however, purposefully concentrates on detection. Think about a typical result.

IAMUser/ConsoleLogin Unauthorized Access Severity: High

This seems frightening at first. However, this discovery raises many more problems than it provides answers from the standpoint of incident response. Assume you are the analyst in charge of looking into this warning.

Your investigation immediately begins with questions like these:

• Has this IAM user ever logged in from this location before?
• Were MFA protections enabled?
• Which AWS Region was accessed?
• What API calls followed the login?
• Did the user enumerate S3 buckets?
• Were secrets retrieved?
• Were new IAM users or access keys created?
• Were EC2 instances launched?
• Was CloudTrail modified?

GuardDuty cannot provide the answers to these queries on its own.

Rather, analysts typically alternate between several services:

• AWS CloudTrail
• IAM
• Amazon S3
• VPC Flow Logs
• Route 53 Resolver logs
• Security Hub
• GuardDuty

One element of the puzzle is provided by each service. The difficulty is putting those parts together before important research time is lost. This procedure is doable for seasoned analyzers. It can easily become too much for smaller security teams or companies with little experience with cloud security. An attacker may stay active for an additional minute for every minute spent manually searching logs.

Meet Amazon Detective
This is where the discussion gets altered by Amazon Detective. Considering the distinction between a security camera and a detective looking into a crime is one of the simplest methods to comprehend Detective.

Events are captured via a security camera. The story is recreated by a detective. In a similar vein, GuardDuty alerts you to unusual conduct.

Amazon Detective clarifies:

• who carried out the task.
• which AWS resources were used.
• what took place prior to the warning.
• What followed?
• The connections between resources.
• if the behavior is out of the ordinary.
• How the event changed over time.

Detective automatically arranges and correlates data into an investigation-friendly structure rather than manually gathering evidence from many AWS services.

To create a thorough behavioral graph of your AWS environment, it continuously ingests telemetry from services like AWS CloudTrail, Amazon GuardDuty, VPC Flow Logs, and Route 53 Resolver DNS logs.

This eliminates the need for investigators to manually piece together evidence by allowing them to switch between identities, IP addresses, AWS resources, API calls, and timings.

Analysts can concentrate on comprehending the attack instead of wasting important time gathering data. It can seem like a small difference. In actuality, it can significantly shorten the duration of an investigation.

Our Investigation Begins
Let's examine a simulated, yet realistic, AWS security event to gain a better understanding of how Amazon Detective fits into a contemporary incident response workflow.

Consider yourself a member of a cloud security team that is in charge of safeguarding a production AWS account that houses many applications that interact with customers.

Before GuardDuty delivers a high-severity discovery concerning an IAM user named finance-automation, everything seems okay. Nothing about the account itself appears out of the ordinary at first glance. The IAM user has been in charge of automating financial reporting procedures for several months. Today's login, however, came from a nation in which the company has no workers, contractors, or commercial activities.

That prompts suspicion right away. Several API calls start to show up throughout the environment a few seconds after the login. Some appear innocuous. Some people don't. Finding out if the login was suspicious is no longer your goal. Understanding the attacker's intent is your goal.
Did they investigate the surroundings? Are you looking for secrets? Getting ready to persevere? Or was this just an automatic mechanism acting strangely? This is the real start of our inquiry.

Following The Evidence With Amazon Detective
We don't know much at this time. We've been notified by GuardDuty that an IAM user logged in from an odd place, but we're still unsure if this is just an employee traveling abroad or if the account has been compromised.

In cloud security, this uncertainty is typical. Each warning is a possibility rather than a conclusion. While waiting too long can enable an attacker to get farther into the environment, jumping to containment too soon can interfere with legitimate company operations.

Our objective is straightforward: Prior to developing assumptions, gather evidence. We launch Amazon Detective rather than manually searching CloudTrail, IAM, VPC Flow Logs, and many AWS consoles.In contrast to conventional logging tools, Detective starts narrating a story right away.

Starting With Entity Profile
An entity profile for the IAM user that caused the GuardDuty discovery is among the first items Detective displays. An entity profile can be compared to a dossier. Detective compiles all of its knowledge about a specific identity into a single screen rather than displaying discrete log entries.

The profile for our inquiry comprises:

• Recent action involving sign-ins
• Findings related to GuardDuty
• Access to AWS Regions
• IP addresses of the source
• History of API calls
• Associated AWS resources
• Past patterns of behavior

An intriguing information emerges in a matter of seconds.Over the past six months, the finance-automation IAM user has regularly accessed AWS from Sydney, Australia. During regular business hours, all successful logins came from the same corporate IP range.

The login for today reveals a different picture. The source IP comes from a different nation where the company doesn't have any offices, staff, or anticipated business activity. A breach might not be confirmed by a single odd login. However, it undoubtedly warrants further investigation.

Looking Beyond Login
Rarely is authentication the attack. It's just the start. Credentials are rarely compromised by attackers merely to admire the AWS Management Console.

They nearly always have one of the following goals in mind:

• Find resources
• Access private information
• Increase privileges
• Develop perseverance
• Hide their tracks.

This implies that the most crucial query is now: What transpired right after logging in? Thankfully, Detective creates an API activity timeline automatically.

We witness the following sequence in a matter of seconds.

02:13:17  Successful Console Login
02:13:34  ListBuckets
02:13:51  GetCallerIdentity
02:14:09  ListSecrets
02:14:28  GetSecretValue
02:15:11  DescribeInstances
02:15:52  ListRoles
02:16:40  PassRole
02:17:03  RunInstances

None of these incidents seem very concerning when viewed separately. But taken as a whole, they show something far more alarming. This login is no longer questionable. It's starting to look like a planned attack sequence.

Recognizing The Attacker's Playbook
The ability for analysts to comprehend activity in context rather than in isolation is one of Amazon Detective's greatest benefits.

Let's look at the chronology. The attacker lists each S3 bucket as soon as they log in. Why? because the location of valuable data is rarely known to attackers. The first step is generally always enumeration.

They then make a call to GetCallerIdentity.This API verifies the rights linked to the hacked credentials and lets them know exactly who they are inside the AWS account. The attacker is now aware of their access. Even more fascinating is the next task. They make a query to AWS Secrets Manager.

Because secret stores contain credentials, API keys, database passwords, certificates, and tokens that access extra resources, current attackers often target these instead of databases directly.

When a GetSecretValue request is successful, the incident's severity is immediately increased. The assailant is no longer investigating. They have started gathering private data. Shortly after, they list all of the EC2 instances before looking at the IAM roles that are available.

Lastly, they try to use an existing IAM role to start a new EC2 instance. Every security engineer should feel uneasy about that action right away. One popular method of establishing persistence or establishing a foothold for future action is to launch compute resources utilizing an existing privileged role.

In less than four minutes, the entire sequence takes place. It would be necessary to manually scan hundreds or even thousands of CloudTrail records in order to reconstruct these occurrences without Detective's chronology.

Visualizing Relationships Instead Of Reading Logs
Logs are a great way to document happenings. Their comprehension of relationships is appalling. This is where Amazon Detective really stands out. Detective creates an entity graph that illustrates the connections between AWS identities, resources, and network activities rather than exhibiting discrete occurrences.

Instead than inquiring, "What happened next?" "What else is connected?" is the first question we ask. Detective instantly provides more context by choosing the EC2 instance. The instance has never been started before.

It is present in a subnet used for production. Multiple S3 buckets and Secrets Manager secrets can be accessed by its IAM role. Our perception of the incident is significantly altered by just one visualization. The assailant wasn't just playing around. They were trying to inherit a more affluent identity.

Pivoting Into CloudTrail
Analysts want accurate evidence at some point in every investigation. Here's where CloudTrail comes in very handy. By enabling investigators to go straight into the underlying API activity, Detective greatly simplifies this process. We are directed straight to the pertinent CloudTrail records rather than having to manually sift through millions of events.

We can now verify information like:

• Precise timestamps
• Request specifications
• IP addresses of the source
• Strings for user agents
• Regions of AWS
• Request IDs
• Error messages

This degree of specificity aids in differentiating between successful and unsuccessful endeavors.For instance, Detective demonstrates that although the attacker was able to list IAM roles, an IAM policy constraint prevented them from passing a highly privileged role.

We learn something crucial from that one unsuccessful API call. The attacker was making a concerted effort to get further rights. Thankfully, such escalation was avoided thanks to the organization's least-privilege IAM policy. Attacks are not always prevented by security measures. At times, they only compel attackers to disclose their motivations.

Identifying The Blast Radius
During any crisis, one of the most challenging questions is: What is the extent of the damage? Manually determining the solution frequently entails examining dozens of services one at a time. By displaying each AWS resource linked to the compromised identity throughout the investigation window, Detective expedites this procedure.

We find that the attacker engaged with the following in our simulation:

• Three buckets on Amazon S3
• There are two manager secrets.
• One instance of EC2
• Seven CloudTrail API types and four IAM roles

It's interesting to note that there is no proof that DynamoDB tables, Lambda functions, or Amazon RDS databases were accessed. The possible blast radius is immediately decreased as a result. Detective verifies that no new IAM users or access keys were generated, which is equally crucial. It seems that persistence is ineffective. Responders can prioritize containment based on facts rather than conjecture thanks to these insights.

Turning Evidence Into Action
Compared to the initial GuardDuty alert, our study has now provided a far clearer picture. A confirmed credential compromise, reconnaissance, secret discovery, and an attempt at privilege escalation have all followed what at first seemed to be a strange login.

We arrived to this conclusion in minutes rather than hours since Detective correlated metrics across several AWS services.Asking what happened is no longer the next step.

It's choosing how to react. Should the IAM credentials be cancelled right away? Which secrets should be rotated? Was any private information compromised? Are other accounts impacted as well? The change from investigation to incident response is signaled by these questions.

From Investigation To Response
The GuardDuty discovery is now more than just a dashboard alert. We have recreated the events, determined the compromised identity, seen reconnaissance activities, verified access to sensitive resources, and discovered an attempted privilege escalation using Amazon Detective.

More significantly, all of this has been done with evidence rather than conjecture. This distinction is crucial.

Acting too soon without fully comprehending the scope of an assault is one of the major mistakes businesses make when responding to incidents. Disabling an IAM user right away might halt the current activity, but the attacker might still have access if temporary credentials have already been issued or if there are other persistence measures in place.

Making wise decisions is more important for effective incident response than merely responding to alarms. Now that we know what went wrong, we can concentrate on stopping the attack, recovering safely, and making sure it doesn't happen again.

Containing The Incident
In our simulated research, the attacker was able to launch compute resources using an existing IAM role, enumerate cloud resources, access secrets, and successfully authenticate using compromised IAM credentials.

IAM controls prevented privilege escalation, but the inquiry found sufficient evidence to support rapid containment.Revoking the compromised credentials is the first step. Passwords should be changed, any temporary AWS STS sessions should be canceled, and any current access keys connected to the IAM user should be disabled. Credential hygiene comes next.

Every secret observed during the investigation should be regarded as potentially compromised since the attacker was able to get access to AWS Secrets Manager. The organization's incident response protocols should be followed when rotating database passwords, API tokens, third-party credentials, and application secrets.

Many teams fail to learn this crucial lesson. You should presume that an attacker copied a secret if they saw it. Rotation is frequently far faster than attempting to ascertain whether exfiltration took place.

Validating The Blast Radius
One aspect of the response is containment. Determining whether the compromise extended beyond the initial identity is the next goal. Investigators should use Amazon Detective in conjunction with AWS

CloudTrail and AWS Security Hub to confirm whether the attacker:

• added more IAM roles or users
• created fresh access keys
• IAM trust relationships that have been modified
• created EventBridge rules or scheduled tasks
• New Lambda functions were deployed.
• Unexpected EC2 instances were launched
• S3 bucket policies that have been modified
• Disabled security or logging features

Thankfully, no indication of successful persistence was discovered during our study. Every encounter, though, should end with confirmation rather than hope. The lack of further activity is only significant when it is backed up by data.

Lessons From The Investigation
The chance to get better is one of the most beneficial results of any security incident. Our research reveals a number of lessons that go beyond Amazon Detective. First, visibility is more important than volume.

Every day, massive volumes of telemetry are produced by cloud systems. Every API request is recorded by CloudTrail, network traffic is captured by VPC Flow Logs, GuardDuty reports discoveries, and Security Hub compiles warnings from several services.

If this information cannot be integrated into a cohesive narrative, it is all useless. Because it turns discrete incidents into significant connections, Amazon Detective succeeds.

It offers context, which significantly reduces the amount of time needed for investigations, rather than requiring analysts to manually correlate thousands of log entries.

The second lesson is that the cloud's major attack surface is still identity. Cloud assaults often start with compromised credentials, in contrast to traditional on-premises setups where attackers frequently target network perimeters.

Unless businesses monitor behavior instead of just authentication, once an attacker establishes a trusted identity, all subsequent actions appear legal. This supports the continued use of IAM, multi-factor authentication, short-lived credentials, and least privilege as fundamental security measures.

Lastly, the probe serves as a reminder that speed is important. An attacker can continue to operate for an additional minute for each minute spent manually searching logs. The results of incident response are immediately improved by cutting down on investigative time.

Building A Stronger Investigation Workflow
When Amazon Detective is integrated into a larger AWS security plan as opposed to functioning independently, it yields the best results. Every service has a certain function.

Suspicious activity is identified by GuardDuty. Findings from all AWS services are centralized via Security Hub. Investigative context is provided by the detective. CloudTrail provides thorough evidence for forensic examination.

Then, when necessary, automation technologies like Amazon EventBridge, AWS Lambda, or AWS Systems Manager can carry out specified containment actions. Cloud security cannot be resolved by a single service. Their cooperation is what gives them strength.

Best Practices For Using Amazon Detective
Businesses thinking in using Amazon Detective should consider more than just enabling the service.

To increase its efficacy:

• Enable thorough event logging for AWS CloudTrail in all regions.
• Activate Amazon GuardDuty across the entire enterprise to guarantee reliable threat identification.
• Utilize AWS Security Hub to compile results for a cohesive security perspective.
• Review unneeded permissions on a regular basis and implement least-privilege IAM policies.
• Use multi-factor authentication (MFA) to safeguard privileged identities.
• Rotate secrets kept in AWS Secrets Manager on a regular basis.
• Create and test incident response playbooks so that responders are prepared to take appropriate action when a detective finds suspicious activity.
• To verify investigation procedures and team preparedness, conduct simulated security drills.

Effective crisis response involves more than just technology. Equally crucial is preparation.

Looking Ahead
Cloud environments are still developing at a remarkable rate. Infrastructure is becoming more and more transient. In a matter of seconds, serverless workloads appear and vanish. Applications driven by AI use AWS services on their own. Organizations frequently support thousands of identities and millions of API calls daily while operating across various accounts and regions.

Scaling traditional research approaches becomes more challenging as situations become more dynamic. Gathering more logs is not the way of the future for cloud security. It involves deriving significant context from the existing telemetry.

A significant move toward context-driven investigations is represented by services like Amazon Detective, which enable security teams to spend more time comprehending attacker behavior and less time looking for evidence.

The adoption of autonomous systems, AI agents, and increasingly sophisticated cloud infrastructures by enterprises will only make this trend more significant.

Conclusion
This investigation's most significant lesson is shockingly straightforward. An incident is not the same as an alert. A GuardDuty finding indicates that anything out of the ordinary happened.

It doesn't explain why it occurred, how far it spread, or what the attacker was attempting to achieve. That void is filled by Amazon Detective. Detective helps security teams go beyond detection and into understanding by establishing entity links, correlating telemetry from AWS services, and presenting investigations through timelines and behavioral analysis.

That distinction is crucial for cloud defenders. The quantity of notifications generated is not a measure of security. It is determined by how fast teams can look into, comprehend, and react when those signals are most important.

Don't consider that the end of the tale the next time GuardDuty alerts you to questionable activities. Consider it the opening page. Because each alert informs you about an event. You can learn the remainder of the tale using Amazon Detective.