DEV Community

Cover image for Threat Detection with GuardDuty
Hyelngtil Isaac
Hyelngtil Isaac

Posted on • Originally published at hyelngtil.awstech

Threat Detection with GuardDuty

#security #aws #devops #cloudnative

Introducing Today's Project!

I built a hands-on project where I wore two hats; attacker and defender, to demonstrate how SQL injection and command injection can escalate into a full cloud credential breach, and how AWS GuardDuty surfaces those behaviors in near real-time.

Tools & Concepts

Services used: Amazon GuardDuty, Amazon EC2, Amazon S3, AWS CloudFormation, AWS CloudShell, IAM Roles, Amazon CloudFront, VPC and networking components.

Key concepts: Threat detection with GuardDuty, SQL injection, command injection, Instance Metadata Service (IMDS) and credential exfiltration, simulating attacker behavior with CloudShell, S3 Malware Protection, and incident investigation workflows.

This project took approximately 1 hour. The most challenging part was tuning GuardDuty detections and IAM role permissions. The most rewarding moment was watching real threat findings surface during testing.

Project Setup

I deployed a CloudFormation template that provisions three functional pillars:

  • Web App Infrastructure — an Amazon EC2 instance inside a dedicated VPC (not the default), with its own Subnet, Internet Gateway, and Elastic Load Balancer for isolated networking.
  • S3 Storage — a bucket containing a protected important-information.txt file that the EC2 instance is authorized to access, simulating sensitive data.
  • GuardDuty Monitoring — automatically enabled as a security sentinel to monitor resources and detect threats.

The web app deployed is OWASP Juice Shop, a deliberately vulnerable application. My objective as the simulated attacker: gain access to the EC2 web server and read the sensitive file in S3.

What is GuardDuty?

GuardDuty is an intelligent threat detection service that continuously monitors AWS accounts and workloads for malicious activity. In this project, it analyzes:

  • VPC Flow Logs
  • CloudTrail management events
  • S3 data events

It uses machine learning and integrated threat intelligence to detect indicators of compromise — credential exfiltration, communication with known malicious IPs, and more. Findings trigger an automated remediation workflow via Amazon EventBridge.

Attack Phase 1: SQL Injection

SQL injection involves injecting malicious SQL code into an input field to manipulate backend database queries. It's dangerous because it allows attackers to bypass authentication and access sensitive data without authorization.

I entered the following into the email field of the Juice Shop login page:

' or 1=1;--
Enter fullscreen mode Exit fullscreen mode

What this does:

  • 1=1 is always true, so the database validates the login regardless of the password.
  • -- comments out the rest of the original query, neutralizing the intended security check.

Result: administrative access to the OWASP Juice Shop portal — no password required.

Attack Phase 2: Command Injection

Command injection is a vulnerability where an attacker executes arbitrary OS commands via a vulnerable application. Juice Shop is vulnerable because it fails to sanitize user input before passing it to a system shell.

I exploited the search field by injecting a Node.js payload that:

  1. Queried the Instance Metadata Service (IMDSv2) to retrieve a session token.
  2. Identified the IAM Role attached to the EC2 instance.
  3. Fetched temporary security credentials — AccessKeyId, SecretAccessKey, and SessionToken.
  4. Piped the JSON output to a publicly accessible path: 
/frontend/dist/frontend/assets/public/credentials.json
Enter fullscreen mode Exit fullscreen mode

A simple application flaw became a significant cloud infrastructure breach.

Attack Verification

I navigated to the public URL at /assets/public/credentials.json and confirmed the exfiltrated credentials — a structured JSON object containing the stolen IAM temporary credentials tied to the EC2 instance's role.

This proved the attacker now had everything needed to authenticate as a legitimate internal service and begin compromising additional AWS resources, including the S3 bucket.

Using CloudShell to Escalate the Attack

CloudShell provided a pre-authenticated environment with the AWS CLI pre-installed — perfect for simulating an attacker operating from an external machine using stolen credentials.

Steps taken:

# Download the exfiltrated credentials file
wget <public-url>/assets/public/credentials.json

# Extract the credential values
cat credentials.json | jq '.AccessKeyId, .SecretAccessKey, .SessionToken'

# Configure a new AWS CLI profile called "stolen"
aws configure --profile stolen
Enter fullscreen mode Exit fullscreen mode

Using the stolen profile isolated the "hacker" identity from the default CloudShell credentials. I could now simulate unauthorized S3 access — the exact behavior GuardDuty would flag as anomalous.

GuardDuty's Findings

Within 15 minutes of executing the attack, GuardDuty generated a finding:

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS
Severity: HIGH
Enter fullscreen mode Exit fullscreen mode

What this means: GuardDuty detected that IAM credentials were exfiltrated and then used inside the AWS environment — indicating a likely credential compromise and unauthorized lateral movement within the account.

How it detected it:
GuardDuty models normal AWS behavior and flags deviations. It correlates telemetry from CloudTrail, VPC Flow Logs, and DNS logs to spot unusual patterns — atypical API calls, credential use from unexpected sources, sudden internal data access, or reconnaissance activity.

The detailed finding reported that credentials for the EC2 instance role were used from a remote AWS account, confirming the simulated exfiltration scenario.

S3 Malware Protection

To test GuardDuty's Malware Protection for S3, I uploaded the standard EICAR anti-malware test file — a harmless string that antivirus products are configured to recognize as a test signature.

GuardDuty instantly triggered a security alert, confirming that Malware Protection detected the uploaded object and generated a finding indicating potential malware.

Key Takeaways

  • A single unsanitized input field can escalate from a login bypass to full cloud credential theft.
  • IMDS is a high-value target; restricting it with IMDSv2 and tight IAM policies is critical.
  • GuardDuty's anomaly detection is effective, it flagged the credential misuse within 15 minutes with no manual configuration beyond enabling the service.
  • Simulating attacks in a controlled lab environment is one of the best ways to build intuition for both offensive techniques and defensive tooling.

🤝Next in the series builds on this, which will be "Secure Secrets with Secrets Manager"

Top comments (0)