Menu

AWS Security Hub & GuardDuty Lab

A hands-on lab demonstrating the full incident response lifecycle in AWS. This project showcases the use of native AWS tools to detect, analyze, and remediate a potential account compromise (GuardDuty) and a critical data exposure risk (public S3 bucket).

View on GitHub

Objective

This project demonstrates the hands-on ability to use native AWS security services to detect, analyze, and remediate both a potential account compromise and a critical data exposure risk, providing a comprehensive overview of a cloud security analyst’s workflow.

Tools & Technologies Used

  • AWS Security Hub: For centralizing, managing, and analyzing security findings.
  • Amazon GuardDuty: For intelligent, behavior-based threat detection.
  • Amazon S3: Used to create and remediate a common storage misconfiguration.
  • AWS IAM: For implementing identity and access management best practices.
  • Markdown: For creating the final project report.

Project Walkthrough

This lab simulates a real-world security scenario. First, an active threat is detected via a potential credential compromise. Second, a static infrastructure misconfiguration is identified. The project follows the full lifecycle: introducing vulnerabilities, detecting them with AWS tools, analyzing the risk, and performing remediation.

Phase 1: Setup & Baseline

The initial phase involved enabling and configuring core AWS security services to establish a monitoring baseline. AWS Security Hub was enabled to centralize security findings, and Amazon GuardDuty was activated for intelligent threat detection.

Phase 2: Introducing Vulnerabilities

This phase involved the introduction of both a behavioral threat and a common infrastructure misconfiguration.

  • (Unintentional) Behavioral Threat: A login to the AWS Root User account was performed from an IP address associated with a known VPN service, simulating a potential credential compromise.
  • Infrastructure Misconfiguration: An Amazon S3 bucket was configured for public access by disabling the “Block Public Access” setting and applying a public-read bucket policy.

Phase 3: Detection & Analysis

This phase covers the detection and analysis of the findings using AWS GuardDuty and Security Hub.

Finding 1: Potential Root Credential Compromise (CRITICAL) Amazon GuardDuty generated a critical alert after detecting anomalous activity associated with the account’s root user. 

  • Analysis: This is the most severe type of alert, as a compromise of the root user gives an attacker unrestricted access to the entire AWS account. The finding was triggered by a login from an IP address associated with a VPN, which GuardDuty’s behavioral analysis correctly identified as a tactic used by attackers to obscure their location. The finding cited several MITRE ATT&CK techniques, including T1078.004 - Valid Accounts: Cloud Accounts, indicating a potential attacker was using legitimate (stolen) credentials for initial access.

Finding 2: Public S3 Bucket Detected (CRITICAL) A CRITICAL severity finding was generated by Security Hub after the public-read bucket policy was applied. 

  • Analysis: This finding indicates a severe data exposure risk, as any data placed in this bucket would be readable by anyone on the internet, potentially leading to a data breach.

Phase 4: Remediation & Verification

The final phase involved correcting the misconfiguration and implementing security best practices to mitigate the identified risks.

Root Credential Compromise Remediation:

  • Investigation: The alert was investigated and confirmed to be a false positive resulting from an accidental administrative login from a VPN.
  • Best Practice Implementation: To align with AWS security best practices, the following actions were taken:
    1. The root user will no longer be used for any daily administrative or lab tasks.
    2. A dedicated IAM user (ej-admin) with administrative privileges has been created for all future work.
    3. Multi-Factor Authentication (MFA) has been enforced on both the root account and the new IAM admin user.

S3 Bucket Remediation: The public-read bucket policy was removed, and the “Block Public Access” setting was re-enabled at the bucket level. The finding was confirmed as “Resolved” in Security Hub. 

Conclusion & Key Learnings

This project provided practical experience in the full detect-analyze-remediate lifecycle using native AWS security tools. Key learnings include:

  • The importance of behavioral threat detection (GuardDuty) in identifying potential account compromises, not just static misconfigurations.
  • The critical need to adhere to IAM best practices, especially by avoiding the use of the root user and enforcing MFA.
  • The process of analyzing and remediating a critical data exposure risk (public S3 bucket) to protect sensitive information.