Forem: LaTerral Williams

Git & GitHub for Beginners (Amazon Linux 2023): Fork, Branch, Commit, Pull Request (Walkthrough)

LaTerral Williams — Sat, 31 Jan 2026 15:24:48 +0000

This is a beginner-friendly, step-by-step; Git + GitHub walkthrough you can follow on an AWS EC2 instance running Amazon Linux 2023 (SSH access).

By the end, you will be able to:

Understand Git vs GitHub
Create a clean project workspace
Install and configure Git locally per repo (no global settings)
Generate and add a GitHub SSH key (with troubleshooting)
Fork an upstream repository
Clone your fork to your VM
Create a feature branch
Edit index.html + style.css
Commit changes, push to your fork, and open a Pull Request
Understand what a PR does (and does not do) to the original repo
Optionally publish your page under Nginx as /your-github-project/ alongside an existing React deployment

Learning context: This walkthrough supports self-paced learning and collaboration workflows using open-source materials.

Prerequisites
Git vs GitHub
Step 1 — Connect to Your VM
Step 2 — Install Git (Amazon Linux 2023)
Step 3 — Create a Clean Project Workspace
Step 4 — Local Git Config (Per Repository Only)
Step 5 — Generate a GitHub SSH Key
- Common Error: “Key is invalid…”
Step 6 — Fork the Assignment Repo on GitHub
Step 7 — Clone Your Fork to the VM
Step 8 — Add Upstream (What It Does)
Step 9 — Create a Feature Branch
- How to Confirm You’re on the Right Branch
- Why You Might See master Instead of main
Step 10 — Make Your Changes (index.html + style.css)
Step 11 — Stage, Commit, and Review History
Step 12 — Push Your Branch to GitHub
Step 13 — Open a Pull Request (PR)
- Does a PR change the original repo?
- Suggested PR Description
Step 14 — Keep Your Fork Updated (Sync Upstream)
Debugging Example: UI Broke After CSS Update
Optional: Publish Under Nginx as /your-github-project/
Key Takeaways
Credits

Prerequisites

You need:

An AWS EC2 instance running Amazon Linux 2023
SSH access to that instance
A GitHub account
Basic terminal comfort (copy/paste commands is fine)

Optional (but helpful):

A text editor like nano (I used vim)

Git vs GitHub

Git: a version control tool that runs on your computer (or VM). It tracks changes to files over time.

GitHub: a website that hosts Git repositories online so you can collaborate, share, and open pull requests.

Simple analogy:

Git = the save/history engine
GitHub = the online place where projects live and collaboration happens

Step 1 — Connect to Your VM

From your local computer, connect to your EC2 instance:

ssh -i /path/to/your-key.pem ec2-user@YOUR_PUBLIC_IP

What the pieces mean:

ssh = secure shell (remote terminal)
-i ...pem = your EC2 private key file
ec2-user@... = the username and server address

Once logged in, you’re working on the VM.

Step 2 — Install Git (Amazon Linux 2023)

Update system packages:

sudo dnf update -y

Install Git:

sudo dnf install -y git

Verify:

git --version

Flag notes:

sudo = run as admin
dnf = Amazon Linux 2023 package manager
-y = auto “yes” to prompts

Step 3 — Create a Clean Project Workspace

Create a parent folder for all repos:

mkdir -p ~/projects
cd ~/projects

Important rule:

Do not run git init in ~/projects
Each repo should be its own separate folder with its own .git directory

Step 4 — Local Git Config (Per Repository Only)

You asked an important question: “Global vs local?”

Global config applies to all repos on this VM user account
Local config applies only to one repo

For this walkthrough, we use local config only to keep things isolated.

You can only set local config after a repo exists (after git init or git clone).

We’ll do it after cloning in Step 7.

Step 5 — Generate a GitHub SSH Key

Should you add a passphrase?

Recommended: Yes (especially on cloud VMs). A passphrase protects your private key if the VM is compromised.

Generate an SSH key:

ssh-keygen -t ed25519 -C "YOUR_EMAIL@example.com"

What flags mean:

-t ed25519 = modern, secure key type
-C = a label/comment (helps identify the key)

When prompted for a file location:

Press Enter to accept the default (~/.ssh/id_ed25519)

When prompted for passphrase:

Set a passphrase (recommended), then confirm it

Start the SSH agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Copy the public key (this is what GitHub needs):

cat ~/.ssh/id_ed25519.pub

Now on GitHub:

Settings → SSH and GPG keys → New SSH key
Key type: Authentication Key
Paste the full line from .pub

Test connectivity:

ssh -T git@github.com

Expected result:

A message saying you authenticated successfully (GitHub does not provide shell access)

Common Error: “Key is invalid…”

If GitHub says:

“Key is invalid. You must supply a key in OpenSSH public key format”

It almost always means one of these:

You pasted the private key by accident (wrong)
You didn’t paste the .pub key
You included extra characters (like the terminal prompt)

Fix checklist:

Make sure you copied only the output of:

   cat ~/.ssh/id_ed25519.pub

It should be a single line starting with:
- ssh-ed25519 ...
Do NOT paste:
- id_ed25519 contents (private key)
- $ prompts or extra spaces

Step 6 — Fork the Assignment Repo on GitHub

Open the upstream repository in your browser:

https://github.com/pravinmishraaws/Week-2---Git-GitHub-Assignment

Click:

Fork (top right)

This creates your own copy under your account (example):

https://github.com/yourusername/Week-2---Git-GitHub-Assignment

Why forks matter:

You can change your fork freely
You can open a PR to propose changes back to the original

Step 7 — Clone Your Fork to the VM

In your VM terminal:

cd ~/projects
git clone git@github.com:yourusername/Week-2---Git-GitHub-Assignment.git
cd Week-2---Git-GitHub-Assignment

Explanation:

git clone downloads the repo and creates a folder
It also sets a remote called origin automatically

Check remotes:

git remote -v

You should see origin pointing to your fork.

Set local git config in THIS repo

Now that you’re inside the repo, set local config:

git config user.name "Your Username"
git config user.email "yourusername@users.noreply.github.com"

Verify local settings:

git config --list --local

Step 8 — Add Upstream (What It Does)

Add the original repo as upstream:

git remote add upstream https://github.com/pravinmishraaws/Week-2---Git-GitHub-Assignment.git
git remote -v

What this does:

origin = your fork (where you push)
upstream = original repo (where you fetch updates)

It does NOT:

merge changes automatically
change the original repo
give you permission to push to upstream

Step 9 — Create a Feature Branch

Create and switch to a new branch:

git switch -c your-branch-name

Why branch?

Keeps your changes separate from the default branch
Makes PRs clean and reviewable

How to Confirm You’re on the Right Branch

Use any of these:

git status

Look for: On branch ...

Or:

git branch

The branch with * is your current branch.

Or quick output:

git branch --show-current

Why You Might See master Instead of main

Some repos use master as the default branch instead of main.

This is normal.
There is no functional difference for this assignment.

Use whatever default branch exists in your repo.

Step 10 — Make Your Changes (index.html + style.css)

Edit your files:

vim index.html
vim style.css

Vim basics:

When you first open a file, Vim is in command mode (you cannot type yet)
Press i to enter insert mode (so you can type and edit)
Press Esc to leave insert mode
Type :w then press Enter to save
Type :q then press Enter to quit
Type :wq then Enter to save and quit
Type :q! then Enter to quit without saving

Make your updates (student details + theme).

Step 11 — Stage, Commit, and Review History

Check what changed:

git status

Preview changes line-by-line:

git diff

Stage (add to the “next commit”):

git add index.html style.css

Commit (save snapshot):

git commit -m "Your descriptive commit note"

View history:

git log --oneline

Step 12 — Push Your Branch to GitHub

Push your branch:

git push -u origin your-branch-name

What -u does:

sets tracking so next time you can run git push without extra arguments

Step 13 — Open a Pull Request (PR)

On GitHub, go to your fork repo page.
You should see a prompt like:

“Compare & pull request”

Create a PR:

Base repository: pravinmishraaws/Week-2---Git-GitHub-Assignment
Base branch: main or master (whatever the upstream uses)
Compare branch: your branch (your-branch-name)

Does a PR change the original repo?

No.

A PR is a request to merge.
The upstream repo does not change until:

the maintainer approves and merges it

Suggested PR Description

You can paste this:

This pull request is for learning purposes only.

The goal is to practice the GitHub pull request workflow, understand how forks and branches are compared, and learn how collaboration works in a real repository. The changes are intentionally simple and focused on hands-on learning rather than introducing new features.

Thank you, Pravin, for providing open-source learning materials and repositories that make it easier to learn Git and GitHub through real practice.

Step 14 — Keep Your Fork Updated (Sync Upstream)

If upstream changes later:

git fetch upstream

Merge upstream changes into your default branch (example uses master):

git switch master
git merge upstream/master

Push updates to your fork:

git push origin master

Notes:

Use main if your repo uses main instead of master.
fetch is safe because it downloads without changing files until you merge.

Debugging Example: UI Broke After CSS Update

Scenario:

You update style.css
The page layout looks broken

Find recent commits that touched the file:

git log -- style.css

Compare changes:

git diff

If you know the commit hash that introduced the issue:

git diff <good_commit_hash> <bad_commit_hash>

Why this matters (DevOps mindset):

You may not be the original author
You still need to identify what changed and when
Git history is a debugging tool, not just “backup”

Optional: Publish Under Nginx as /your-github-project/

This is optional, but it’s a great real-world deployment skill:

serve your Git assignment page alongside your React app via Nginx

Reference article (React + Nginx deployment on Amazon Linux):
https://dev.to/ldwit/deploying-a-react-app-with-nginx-on-aws-amazon-linux-beginner-walkthrough-3h76

Confirm your Nginx root

Run:

sudo nginx -T | grep -i root

In the example setup, the active root was:

/var/www/react-app/current

Create a folder for your static page

sudo mkdir -p /var/www/react-app/current/your-github-project

Copy your assignment files into that folder

From your repo folder:

sudo cp index.html style.css /var/www/react-app/current/your-github-project/

Fix permissions (avoid 403 errors)

sudo chmod -R 755 /var/www/react-app/current/your-github-project

Reload Nginx safely

sudo nginx -t
sudo systemctl reload nginx

Test it

Open:

http://YOUR_PUBLIC_IP/your-github-project/

Key Takeaways

Git tracks history in commits
Staging (git add) is your “commit preview”
Branches keep work isolated
Fork + PR is the safe collaboration workflow
A PR does not change upstream until merged
Git commands like log and diff help debug issues quickly
Nginx can serve static pages alongside apps for portfolio demos

Credits

Pravin Mishra -- open-source DevOps learning materials and the DMI community
Self-paced practice and notes from a real Amazon Linux 2023 VM workflow
Udemy Course -- DevOps for Beginners: Docker, Kubernetes, Cloud & CI/CD (4 Projects)
- https://www.udemy.com/course/devops-for-beginners-docker-k8s-cloud-cicd-4-projects/
GitHub Repository
- https://github.com/pravinmishraaws

🚀 Deploying a React App with NGINX on AWS (Amazon Linux) — Beginner Walkthrough

LaTerral Williams — Wed, 28 Jan 2026 16:04:22 +0000

This project documents a beginner-friendly, real-world style deployment of a React application using NGINX on an AWS EC2 instance running Amazon Linux.

The goal was to:

Keep costs low
Avoid over-engineering
Learn how Linux + NGINX actually serve frontend apps
Debug real problems instead of hiding them

This walkthrough reflects the exact path taken, including lessons learned during troubleshooting.

🧠 What You’ll Learn

How NGINX serves a static React build
How to deploy a React app directly on an EC2 instance
Why Single Page Applications (SPAs) need special NGINX configuration
How to diagnose and fix common NGINX errors (500 errors, redirect loops)
How Node.js versions affect modern frontend tooling

💰 Cost & Environment

Cloud Provider: AWS
Instance Type: t2.micro / t3.micro
OS: Amazon Linux 2023
Web Server: NGINX
Frontend: React (Vite)
Estimated Cost: Free tier or a few dollars/month

🏗️ Architecture Overview

Browser
   ↓
Public IP (EC2)
   ↓
NGINX (port 80)
   ↓
/var/www/react-app
   ↓
React build (index.html, JS, CSS)

NGINX serves static files only. React is built first, then copied into the web root.

🔐 Phase 1: Launch the EC2 Instance

Launch a new EC2 instance
Select Amazon Linux 2023
Choose instance type: t2.micro or t3.micro
Enable Auto-assign Public IP

Security Group (Inbound Rules)

Type	Port	Source
SSH	22	Your IP
HTTP	80	0.0.0.0/0

SSH is restricted. HTTP is public so the app is accessible.

Note: Do not forget to create your Key Pair and save in a location you can find later.

I used my linux desktop to connect to the instance so my key needed to be in the same directory where I was launching ssh.

If you are using an ssh tool (like Putty) you will need to upload the key into the ssh tool, so it is important to remember where you saved the key.

🔑 Phase 2: Connect to the Instance

From your local machine:

ssh -i your-key.pem ec2-user@<PUBLIC_IP>

Amazon Linux uses the ec2-user account by default.

🧰 Phase 3: Install System Dependencies

Update packages

sudo dnf update -y

Install NGINX

sudo dnf install -y nginx
sudo systemctl enable --now nginx

Verify:

sudo systemctl status nginx --no-pager

⚙️ Phase 4: Install Node.js (Temporary Session)

Modern React tools require newer Node versions.

For this project, Node was upgraded for the active shell only (not persisted across reboots).

Install nvm:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Note: I did not use this step, as I completed this in a single sitting. I only used exec bash to refresh the shell. This step may be necessary if you need the shell to persist to continue work later.

Load nvm for the current shell:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

Install and use Node 22:

nvm install 22
nvm use 22

Verify:

node -v
npm -v

Note: Node will revert to the system version after logout unless nvm is persisted.

⚛️ Phase 5: Create and Build the React App

Create the project

mkdir -p ~/projects
cd ~/projects
npm create vite@latest react-app -- --template react
cd react-app
npm install

Build for production

npm run build

The production-ready files are created in the dist/ directory.

📁 Phase 6: Create the NGINX Web Root

Create a directory for the React app:

sudo mkdir -p /var/www/react-app
sudo chown -R ec2-user:ec2-user /var/www/react-app

Copy the build output:

sudo rm -rf /var/www/react-app/*
sudo cp -r dist/* /var/www/react-app/

Fix permissions so NGINX can read files:

sudo chown -R nginx:nginx /var/www/react-app
sudo chmod -R 755 /var/www/react-app

🌐 Phase 7: Configure NGINX for React (SPA Routing)

Create the NGINX configuration:

sudo nano /etc/nginx/conf.d/react-app.conf

Paste:

server {
    listen 80 default_server;
    server_name _;

    root /var/www/react-app;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Disable the default config if present:

sudo mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.disabled

Test and restart:

sudo nginx -t
sudo systemctl restart nginx

✅ Phase 8: Verify Deployment

From the server:

curl -I http://localhost

From your browser:

http://<EC2_PUBLIC_IP>

Your React app should now load successfully.

🧯 Troubleshooting (Lessons Learned)

❌ 500 Internal Server Error

Cause

NGINX root pointed to a directory that did not exist
Missing index.html

Fix

ls -la /var/www/react-app/index.html

Ensure the build was copied correctly.

❌ Infinite redirect / rewrite loop

Error

rewrite or internal redirection cycle while internally redirecting to "/index.html"

Cause

SPA routing without proper try_files
Conflicting server blocks

Fix

Disable default.conf
Use a single server block
Verify try_files configuration

❌ Vite / crypto.hash error

Cause

Node.js version too old

Fix

nvm use 22
rm -rf node_modules package-lock.json
npm install

🧠 Final Thoughts

This project intentionally avoided:

Load balancers
Containers
CI/CD pipelines

Instead, it focused on:

Linux fundamentals
NGINX configuration
Real debugging scenarios

If you can deploy and troubleshoot this setup, you’re building the right foundation.

🔜 Possible Next Steps

Persist Node using nvm
Add HTTPS with Let’s Encrypt
Introduce a release + rollback structure
Move the frontend to S3 + CloudFront

🙏 Credits & Learning Acknowledgement

This project builds on foundational DevOps concepts learned from Pravin Mishra teaching; beginner-focused content providing an initial framework for understanding how applications move from development to deployment.

The original learning foundation came from the following resources:

Udemy Course -- DevOps for Beginners: Docker, Kubernetes, Cloud & CI/CD (4 Projects)
- https://www.udemy.com/course/devops-for-beginners-docker-k8s-cloud-cicd-4-projects/
GitHub Repository
- https://github.com/pravinmishraaws

How This Project Differs and Expands

While the course introduced core ideas, this implementation represents my own hands-on work and problem-solving, including:

Deploying a React application on Amazon Linux 2023
Configuring NGINX to serve a Single Page Application (SPA)
Troubleshooting real-world issues such as:
- Node.js version incompatibilities with modern tooling
- NGINX 500 Internal Server Errors
- SPA rewrite and redirect loops
Adapting the deployment process to fit a low-cost, beginner-accessible AWS setup
Documenting mistakes, fixes, and reasoning to reflect the actual learning process

All configuration choices, debugging steps, and documentation in this project reflect my own experimentation and understanding, built on top of the foundational concepts introduced in the referenced materials.

🔒 Building a Secure AWS Environment with Terraform + AWS CloudShell

LaTerral Williams — Mon, 29 Dec 2025 12:27:42 +0000

⭐ Why I Built This Project

(Project 6 of 6 — Terraform Security Module: Secure AWS Baseline with Infrastructure as Code)

Instead of studying cloud security concepts in isolation, I’m using real job descriptions as a roadmap and building hands-on projects that map directly to cloud security, cloud operations, and security engineering roles.

This 6-part series focuses on practical, cloud security skills, including:

Identity hardening and MFA enforcement
IAM governance and access reviews
Continuous monitoring of cloud resources
Misconfiguration detection and drift analysis
Log analysis, audit readiness, and evidence gathering
Infrastructure-as-Code (IaC) security baselines and guardrails
Guard rails at scale using AWS Organizations + Service Control Policies (SCPs)
Threat detection, anomaly monitoring, and incident triage

Each project is designed to reflect real-world responsibilities, not just theoretical learning.

📌 Project Sequence

👉 Part 1: AWS IAM Hardening — strengthening identity boundaries and improving authentication hygiene

👉 Part 2: Cloud Security Posture Management (CSPM) using Security Hub + AWS Config

👉 Part 3: CASB-Like Monitoring with GuardDuty + CloudTrail, focusing on anomalies, delegated admin, and safe threat simulation

👉 Part 4: Drift Detection with AWS Config, using managed rules, EventBridge routing, tags, and optional remediation

👉 Part 5: Log Analysis & Dashboards with Athena + QuickSight, turning raw CloudTrail logs into actionable security insights

👉 Part 6: (this project) — Terraform Security Module, building a secure AWS baseline using Infrastructure as Code

🧱 Why This Project Matters

In real-world cloud environments, security doesn’t start in the console, it starts in code.

Modern cloud security teams rely on Infrastructure as Code (IaC) tools like Terraform to ensure environments are:

Secure by default
Consistent across deployments
Auditable and reviewable
Resistant to configuration drift

This project focuses on using Terraform to define and deploy a secure AWS foundation, including:

A baseline VPC configuration
A secure S3 bucket with encryption, versioning, and public access blocked
CloudTrail logging enforced through code

Instead of manually clicking through the AWS console, this project demonstrates how security controls can be:

Version-controlled
Peer-reviewed
Re-deployed on demand
Automatically restored if misconfigured

You’ll also see how Terraform helps detect and prevent drift, a critical requirement in regulated and enterprise cloud environments.

To keep the project accessible and low-cost, Terraform is executed using AWS CloudShell, eliminating local installation challenges (especially on Windows ARM systems) while still following real-world DevSecOps workflows.

By the end of this project, you’ll have a repeatable, secure AWS baseline defined entirely in code, a strong capstone that ties together identity, monitoring, logging, and governance concepts from the entire series and aligns directly with expectations for cloud security and cloud operations roles.

Beginner-Friendly | Fun | Technical | Real-World Cloud Security Project

Welcome to Project 6 - Terraform Security Module, where you’ll learn how to build a secure AWS baseline using Terraform, AWS CloudShell, and a workflow that mirrors real cloud security engineering.

This guide is fun, practical, and perfect for beginners who want hands-on cloud security experience without breaking the bank.

📚 Table of Contents

Introduction
Why This Project Matters
Prerequisites
Using VS Code vs CloudShell
Setting Up AWS CloudShell
Creating Your Terraform Project Structure
Writing Terraform Configuration Files
Initializing Terraform
Planning and Applying
Verifying the Deployment
Cleaning Up Resources
Troubleshooting Tips
Final Thoughts

🌟 Introduction

Terraform is one of the most powerful Infrastructure-as-Code (IaC) tools in the cloud ecosystem.

But installing Terraform locally, especially on Windows ARM devices, can get complicated.

So instead, we take the fun, beginner-friendly, zero-hassle route:

🎉 Run Terraform directly inside AWS CloudShell, which comes preconfigured with AWS credentials and a Linux environment, exactly like real DevOps teams use.

🔐 Why This Project Matters

You will create three essential security components using Terraform:

A VPC (Virtual Private Cloud)
A Secure S3 Bucket for CloudTrail logs
A CloudTrail Trail for auditing AWS activity

These are foundational in cloud security operations, compliance, and threat detection.

This entire environment is:

✔ Free or extremely low-cost

✔ Fully repeatable using IaC

✔ Destroyable in minutes

✔ Perfect for portfolios

🧰 Prerequisites

AWS account
Basic familiarity with AWS Console
A browser (for CloudShell)
Optional: VS Code for code editing

No Terraform account required.

No installations on your laptop required.

💻 Using VS Code vs AWS CloudShell

You can write Terraform locally in VS Code, but ARM64 Windows devices don’t have native Terraform binaries.

So the recommended approach is:

🥇 Use VS Code for editing

🥇 Use AWS CloudShell for running Terraform

CloudShell gives you:

Linux environment
Pre-installed Terraform (or installable)
Preconfigured IAM authentication
Safe sandbox

This combo gives you real-world DevSecOps workflow.

☁️ Setting Up AWS CloudShell

Log in to the AWS Console
Click the CloudShell terminal icon in the upper-right corner
CloudShell opens a terminal inside AWS
Check if Terraform is installed:

terraform version

If Terraform is missing:

Run uname -m to detect architecture
Install Terraform using the latest ARM64 or AMD64 Linux binary

sudo yum install -y wget unzip

TERRAFORM_VERSION="1.14.2" 

//At the time of this project **1.14.2** was the most recent version of terraform.

wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip

unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip

sudo mv terraform /usr/local/bin/

terraform version

📁 Creating Your Terraform Project Structure

Inside CloudShell:

mkdir terraform-security-module
cd terraform-security-module

Recommended real-world folder structure:

terraform-security-module/
│
├── main.tf
├── variables.tf
├── outputs.tf
├── versions.tf
└── .gitignore

Add a .gitignore:

.terraform/
terraform.tfstate
terraform.tfstate.backup
*.backup

🛠 Writing Terraform Configuration Files

Below is the full configuration needed to deploy a secure AWS baseline.

🔹 versions.tf

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

🔹 variables.tf

variable "aws_region" {
  description = "AWS region to deploy into"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Prefix for all resource names"
  type        = string
  default     = "tf-security-demo"
}

🔹 main.tf

Contains:

VPC
S3 bucket
Public access block
Versioning
Encryption
Bucket policy
CloudTrail

Note: I added notes to describe what each section should complete.

//Create a basic VPC

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "${var.project_name}-vpc"
    Environment = "lab"
    ManagedBy   = "terraform"
  }
}

//Generate Unique Suffix to Avoid Bucket Name Conflicts

resource "random_id" "suffix" {
  byte_length = 4
}

//Create the Bucket

resource "aws_s3_bucket" "cloudtrail_logs" {
  bucket = "${var.project_name}-cloudtrail-logs-${random_id.suffix.hex}"

  tags = {
    Name        = "${var.project_name}-cloudtrail-logs"
    Environment = "lab"
    ManagedBy   = "terraform"
  }
}

//Block All Public Access

resource "aws_s3_bucket_public_access_block" "cloudtrail_logs" {
  bucket                  = aws_s3_bucket.cloudtrail_logs.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

//Enable Versioning

resource "aws_s3_bucket_versioning" "cloudtrail_logs" {
  bucket = aws_s3_bucket.cloudtrail_logs.id

  versioning_configuration {
    status = "Enabled"
  }
}

//Enable Encryption (SSE-S3)

resource "aws_s3_bucket_server_side_encryption_configuration" "cloudtrail_logs" {
  bucket = aws_s3_bucket.cloudtrail_logs.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

//Bucket Policy for CloudTrail

data "aws_caller_identity" "current" {}

resource "aws_s3_bucket_policy" "cloudtrail_logs" {
  bucket = aws_s3_bucket.cloudtrail_logs.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid = "AWSCloudTrailAclCheck"
        Effect = "Allow"
        Principal = {
          Service = "cloudtrail.amazonaws.com"
        }
        Action   = "s3:GetBucketAcl"
        Resource = aws_s3_bucket.cloudtrail_logs.arn
      },
      {
        Sid = "AWSCloudTrailWrite"
        Effect = "Allow"
        Principal = {
          Service = "cloudtrail.amazonaws.com"
        }
        Action   = "s3:PutObject"
        Resource = "${aws_s3_bucket.cloudtrail_logs.arn}/AWSLogs/${data.aws_caller_identity.current.account_id}/*"
        Condition = {
          StringEquals = {
            "s3:x-amz-acl" = "bucket-owner-full-control"
          }
        }
      }
    ]
  })
}

//Create a CloudTrail Trail

resource "aws_cloudtrail" "main" {
  name                          = "${var.project_name}-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_logging                = true

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }

  depends_on = [
    aws_s3_bucket_policy.cloudtrail_logs,
    aws_s3_bucket_public_access_block.cloudtrail_logs
  ]

  tags = {
    Name        = "${var.project_name}-trail"
    Environment = "lab"
    ManagedBy   = "terraform"
  }
}

🔹 outputs.tf

output "vpc_id" {
  value = aws_vpc.main.id
}

output "cloudtrail_logs_bucket" {
  value = aws_s3_bucket.cloudtrail_logs.bucket
}

output "cloudtrail_trail_name" {
  value = aws_cloudtrail.main.name
}

output "region" {
  value = var.aws_region
}

⚙️ Initializing Terraform in CloudShell

Run:

terraform init
terraform validate

Your environment is now ready.

🚀 Planning and Applying

Preview what Terraform will create:

terraform plan -out tfplan

Apply the infrastructure:

terraform apply tfplan

Terraform will deploy:

A new secure VPC
A CloudTrail-ready S3 bucket
Encryption + versioning + public access blocks
A CloudTrail trail

🔍 Verifying the Deployment

Check VPC

AWS Console → VPC → Your VPCs → Look for the name tf-security-demo-vpc

Check S3

Look for:

✔ Versioning enabled

✔ AES-256 encryption

✔ Public Access Block = ON

Check CloudTrail

AWS Console → CloudTrail → Trails → Your trail should be active

🧹 Cleaning Up Resources

Always run this to avoid costs:

terraform destroy

Confirm with yes when prompted.

CloudShell removes:

CloudTrail
S3 bucket
VPC

🛠 Troubleshooting Tips

❗ Terraform not found

Install Terraform manually inside CloudShell after running:

uname -m

❗ Permission denied

Ensure your IAM user has:

S3 bucket creation permissions
CloudTrail permissions
VPC permissions

❗ S3 bucket name already exists

Use random suffix:

resource "random_id" "suffix" {
  byte_length = 4
}

🎉 Final Thoughts

You just built:

A secure AWS logging architecture
Using Terraform
Inside AWS CloudShell
Without installing anything locally

This is professional-grade IaC experience—perfect for:

Cloud Security
DevOps
SOC roles
Portfolio projects

🛡️ Building a Cloud Security Dashboard with AWS Athena + QuickSight (Beginner Friendly)

LaTerral Williams — Mon, 29 Dec 2025 11:52:12 +0000

⭐ Why I Built This Project

(Project 5 of 6 — Log Analysis & Dashboards with Athena + QuickSight)

This 6-part series focuses on practical, resume-ready cloud security skills, including:

Identity hardening and MFA enforcement
IAM governance and access reviews
Continuous monitoring of cloud resources
Misconfiguration detection and drift analysis
Log analysis, audit readiness, and evidence gathering
Guard rails at scale using AWS Organizations + Service Control Policies (SCPs)
Threat detection, anomaly monitoring, and incident triage

Each project is designed to reflect real-world responsibilities, not just theoretical learning.

📌 Project Sequence

👉 Part 1: AWS IAM Hardening — strengthening identity boundaries and improving authentication hygiene

👉 Part 2: Cloud Security Posture Management (CSPM) using Security Hub + AWS Config

👉 Part 3: CASB-Like Monitoring with GuardDuty + CloudTrail, focusing on anomalies, delegated admin, and safe threat simulation

👉 Part 4: Drift Detection with AWS Config, using managed rules, EventBridge routing, tags, and optional remediation

👉 Part 5: (this project) — Log Analysis & Dashboards with Athena + QuickSight

🔍 Why This Project Matters

Modern cloud security teams rely heavily on logs they are the single source of truth during an investigation or audit.

But raw CloudTrail logs are huge, noisy, and difficult to interpret without the right tools.

This project teaches you how to:

Centralize your CloudTrail logs in S3
Query them efficiently using Amazon Athena
Build a real security dashboard using Amazon QuickSight
Visualize user behavior, anomalies, and region-based activity
Identify failed logins, root usage, and high-risk API calls
Understand how analysts and cloud security engineers perform forensics and evidence gathering

You'll also learn the practical limitations of CloudTrail logs (delayed ingestion, missing fields, errorcode inconsistencies, timestamp parsing issues), and how to design visuals that still work even when the underlying logs aren’t perfect, a genuine real-world skill.

By the end of this project, you'll have a portfolio-ready CloudTrail security dashboard that demonstrates real account activity, provides security insights, and aligns directly with responsibilities listed in cloud security job descriptions.

Welcome to a hands-on, beginner-friendly walkthrough of building a Cloud Security Dashboard using three AWS services:

CloudTrail → captures account activity
Athena → queries CloudTrail logs using SQL
QuickSight → visualizes security events

Along the way, I’ll share real troubleshooting moments, beginner tips, and cost-saving advice because learning AWS should be fun and affordable.

Introduction
What You’ll Build
Prerequisites & Cost Awareness
Step 1 — Enable CloudTrail Logging
Step 2 — Verify CloudTrail Logs in S3
Step 3 — Set Up Athena
Step 4 — Create the External CloudTrail Table
Step 5 — Repair Partitions & Validate Data
Step 6 — Run Security SQL Queries in Athena
Step 7 — Build the QuickSight Dashboard
Step 8 — Publish & Share Your Dashboard
Step 9 — Cleanup & Cost Optimization
Troubleshooting
Final Thoughts

1. Introduction

Cloud security can feel overwhelming when you're new. AWS has logs everywhere, alerts everywhere, and tools everywhere. But once you learn how to connect a few core services, you unlock something powerful:

👉 You can see what’s happening inside your AWS account.

In this project, you'll turn raw CloudTrail logs into a visual dashboard showing:

Failed console login attempts
Root account activity
API usage by region
Top users making API calls

And you'll do it without needing expensive tools.

2. What You’ll Build

By the end, you’ll have:

A working CloudTrail → S3 → Athena → QuickSight pipeline
A security dashboard with four visuals
Saved queries to help you think like a cloud security engineer
A repeatable workflow you can show in interviews or your portfolio

And yes, this entire project stays within free or very low-cost AWS usage.

3. Prerequisites & Cost Awareness

You will need:

An AWS account
IAM permissions to use CloudTrail, S3, Athena, and QuickSight
A region where QuickSight is supported

Cost Notes (Important)

CloudTrail: 1 trail recording management events is free
S3 storage: pennies for logs
Athena: ~$5 per TB scanned (our dataset is tiny—cost is near $0)
QuickSight: SPICE storage has a generous free tier

💡 Pro Tip: Delete Athena query results and disable CloudTrail when finished (covered in Cleanup).

4. Step 1 — Enable CloudTrail Logging

If you haven't already:

Open CloudTrail
Go to Trails → Create Trail
Choose:
- Management events = Read/Write
- Storage location = new S3 bucket
Click Create

CloudTrail will begin writing log files to S3 in about 5–10 minutes.

5. Step 2 — Verify CloudTrail Logs in S3

Navigate to the bucket you created:

s3://your-cloudtrail-bucket/AWSLogs/ACCOUNT-ID/CloudTrail/

Inside you should see folders named by region and date, such as:

us-east-1/2025/12/11/

Each folder contains .json.gz CloudTrail logs.

If you don’t see them, wait a few minutes or trigger activity in your account (login, create an IAM user, etc.).

6. Step 3 — Set Up Athena

Note: Query your data in Athena console

Go to Athena → Query Editor

Choose a results location (S3 bucket)
Create a new database:

CREATE DATABASE security_logs_db;

Select this database in the left panel.

7. Step 4 — Create the External CloudTrail Table

Use this DDL (adjust bucket/account ID):

CREATE EXTERNAL TABLE cloudtrail_logs(
  eventversion string,
  useridentity struct<
      type:string,
      principalid:string,
      arn:string,
      accountid:string,
      invokedby:string,
      accesskeyid:string,
      username:string,
      sessioncontext:struct<
        attributes:struct<mfaauthenticated:string,creationdate:string>,
        sessionissuer:struct<
          type:string,principalid:string,arn:string,accountid:string,username:string
        >
      >
  >,
  eventtime string,
  eventsource string,
  eventname string,
  awsregion string,
  sourceipaddress string,
  useragent string,
  errorcode string,
  errormessage string,
  requestparameters string,
  responseelements string,
  additionaleventdata string,
  requestid string,
  eventid string,
  resources array<struct<arn:string,accountid:string,type:string>>,
  eventtype string,
  apiversion string,
  readonly string,
  recipientaccountid string,
  serviceeventdetails string,
  sharedeventid string,
  vpcendpointid string
)
PARTITIONED BY (region string, year string, month string, day string)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://your-cloudtrail-bucket/AWSLogs/<ACCOUNT-ID>/CloudTrail/';

Note: You'll likely need to create a table view to gather specific information.

CREATE OR REPLACE VIEW cloudtrail_flattened AS
SELECT
  -- Core event metadata
  eventtime,
  eventsource,
  eventname,
  awsregion,
  sourceipaddress,
  useragent,
  errorcode,
  errormessage,
  responseelements,
  eventid,

  -- Flattened identity fields
  useridentity.type        AS useridentity_type,
  useridentity.arn         AS useridentity_arn,
  useridentity.accountid   AS useridentity_accountid,
  useridentity.username    AS useridentity_username,
  useridentity.principalid AS useridentity_principalid,

  -- Additional context (optional but useful for investigations)
  eventtype,
  apiversion,
  readonly,
  recipientaccountid,
  vpcendpointid

FROM cloudtrail_logs;

8. Step 5 — Repair Partitions & Validate Data

Run:

MSCK REPAIR TABLE cloudtrail_logs;

This tells Athena to scan all folders (regions/dates) and register them.

Next, verify:

SELECT * 
FROM cloudtrail_logs 
ORDER BY eventtime DESC 
LIMIT 20;

If you get data → success!

If not, check:

S3 bucket path
CloudTrail folders
IAM permissions for Athena

9. Step 6 — Run Security SQL Queries in Athena

Now let’s run some practical security queries.

9.1 Check event types

SELECT eventname, COUNT(*) 
FROM cloudtrail_logs
GROUP BY eventname
ORDER BY COUNT(*) DESC;

This tells you what kinds of actions occur in your account.

9.2 Failed Console Login Attempts

Failed logins often appear with a non-null errorMessage:

SELECT eventtime, sourceipaddress, errormessage
FROM cloudtrail_logs
WHERE eventname = 'ConsoleLogin'
  AND errormessage IS NOT NULL
ORDER BY eventtime DESC;

9.3 Root Account Activity

SELECT eventtime, eventname, sourceipaddress
FROM cloudtrail_logs
WHERE useridentity.type = 'Root'
ORDER BY eventtime DESC;

Any root event is worth noticing.

9.4 Events by Region

SELECT awsregion, COUNT(*) 
FROM cloudtrail_logs
GROUP BY awsregion
ORDER BY COUNT(*) DESC;

9.5 Top IAM Users by Activity

SELECT useridentity.username, COUNT(*) AS api_calls
FROM cloudtrail_logs
WHERE useridentity.username IS NOT NULL
GROUP BY useridentity.username
ORDER BY api_calls DESC
LIMIT 10;

You now have everything you need for your dashboard.

10. Step 7 — Build the QuickSight Dashboard

Open QuickSight → Datasets → New Dataset

Choose Athena → cloudtrail_logs → Import as SPICE.

Because CloudTrail timestamps sort correctly as strings, you do not need to convert them to date type.

Dashboard Visual 1 — Failed Console Logins

Visual type: Line chart

X-axis: eventtime

Value: eventid (Count)

Filter:

eventname = ConsoleLogin
errormessage is not null

Dashboard Visual 2 — Root Account Activity

Visual type: Bar chart

X-axis: eventtime

Value: eventid (Count)

Filter:

useridentity_type = Root

Dashboard Visual 3 — Events by AWS Region

Visual type: Horizontal bar chart

Y-axis: awsregion

Value: eventid (Count)

Dashboard Visual 4 — Top Users by API Calls

Visual type: Vertical bar chart

X-axis: useridentity_username

Value: eventid (Count)

Filter:

Top N = 10

Your dashboard is complete!

11. Step 8 — Publish the Dashboard

Click:

Share → Publish Dashboard → Select "All Sheets"

This ensures your entire analysis is shared, not just the first sheet.

12. Step 9 — Cleanup & Cost Optimization

To avoid unnecessary charges:

Athena

Delete old query results from its S3 bucket

CloudTrail

Disable logging if this was only for learning
Or reduce event types to lower S3 usage

QuickSight

Delete unused datasets to free SPICE capacity

S3

Remove old log folders if no longer needed

13. Troubleshooting (Beginner-Friendly)

Even with a simple architecture like CloudTrail → S3 → Athena → QuickSight, a few common issues can cause missing data or broken visuals. Here are some troubleshooting tips you can quickly check before diving deeper.

- CloudTrail Data Not Appearing in Athena

Cause: CloudTrail logs haven’t reached S3 yet or the path doesn’t match the table LOCATION.

Quick Fixes:

Wait 5–10 minutes after enabling CloudTrail.
Trigger activity in your AWS account (login, create an IAM user, etc.).
Confirm your S3 path looks like:

s3://your-bucket/AWSLogs/<ACCOUNT-ID>/CloudTrail/

Re‑run:

MSCK REPAIR TABLE cloudtrail_logs;

If no rows appear afterward, the folder structure or bucket path is incorrect.

- MSCK REPAIR Succeeds but Queries Return No Results

Cause: Athena’s table LOCATION is missing the trailing slash or points to the wrong folder.

Quick Fix:

Make sure LOCATION ends with:

.../CloudTrail/

Then run:

MSCK REPAIR TABLE cloudtrail_logs;

Athena needs this exact folder structure to identify partitions.

- QuickSight SPICE Dataset Shows “No Data”

Cause: SPICE may have ingested an empty or outdated version of your dataset.

Quick Fixes:

Go to Datasets → Refresh SPICE
If that doesn’t fix it, delete the dataset and recreate it from Athena.
Verify the dataset preview actually shows rows before building visuals.

- Visuals Still Show “No Data”

Most common causes:

Filters are hiding all your data
The visual is still referencing an old field
The field type was changed and QuickSight isn’t mapping it correctly

Quick Fixes:

Remove all filters, then re‑add only the ones you need.
Re‑add fields to the visual (drag them in fresh).
Keep eventtime as a string—it sorts correctly and avoids parsing issues.

- Failed Console Login Events Not Showing

Cause: CloudTrail sometimes logs failed logins using `errorMessage` instead of `errorCode`.

Fix:

Use this condition:

errormessage is not null

This catches failures reliably.

- QuickSight Permissions Errors

If you see errors about S3 access or Athena metadata:

Quick Fix:

Make sure QuickSight has the following enabled:

Access to Athena
Access to your CloudTrail S3 bucket

You can configure this in:

QuickSight → Manage QuickSight → Security & Permissions

Final Advice

If something looks blank:

Remove filters
Refresh SPICE
Re-add fields
Run a simple table visual to confirm data exists

Most issues in Athena + QuickSight come down to filters, paths, or SPICE not refreshing.

You now have everything you need to keep the pipeline running smoothly!

14. Final Thoughts

You just built a cloud security monitoring workflow used in real organizations.

You learned:

How CloudTrail logs work
How to query logs with Athena
How to analyze activity using SQL
How to build a security dashboard in QuickSight
How to troubleshoot common AWS data issues
How to optimize costs

Most importantly, you now understand how to observe what's happening inside your AWS account, which is a core cloud security skill.

🤝 Connect

If you publish your own dashboard, have any tips or advice, tag me. I’d love to see it!

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

Thanks for reading!

Black‑Box Web Vulnerability Testing (Nikto, SQL Injection, XSS)

LaTerral Williams — Sun, 28 Dec 2025 13:43:16 +0000

Scope & Ethics
This article documents testing performed only inside an intentionally vulnerable Kali Linux class lab. All activities were authorized and executed in a controlled environment for educational purposes.

GitHub Repo with Additional Details:
Black-Box Web Vulnerability Testing

Why This Lab Matters
Lab Environment & Scope
Methodology (Black‑Box Approach)
Phase 1: Network & Host Discovery
Phase 2: Service Enumeration
Phase 3: Vulnerability Scanning with Nikto
Phase 4: SQL Injection Testing
Phase 5: Cross‑Site Scripting (XSS)
Findings Summary
Mitigations & Secure Design Takeaways
Common Beginner Pitfalls
Conclusion

Why This Lab Matters

Web vulnerabilities are rarely found by jumping straight to exploitation. In practice, testers start with discovery, validate assumptions, and document both positive and negative results. This lab demonstrates that workflow end‑to‑end using three foundational categories:

Nikto – server misconfiguration and hygiene
SQL Injection (SQLi) – backend trust and input handling failures
Cross‑Site Scripting (XSS) – client‑side trust and output encoding failures

The goal is understanding and documentation, not weaponization.

Lab Environment & Scope

Operating System: Kali Linux (class OVA)

Authorization: Testing limited to intentionally vulnerable services inside the lab network.

Discovered Targets (internal network):

DVWA (Damn Vulnerable Web Application)
WebGoat
Additional intentionally vulnerable apps

Beginner note: In real assessments you often don’t know what’s vulnerable. The first win is simply discovering what exists.

Methodology (Black‑Box Approach)

A black‑box test assumes no prior knowledge of the application internals. The workflow used:

Identify reachable networks and hosts
Enumerate open services and versions
Scan for misconfigurations
Test application behavior
Document what changed and why it matters

Negative results are documented as carefully as successful ones.

Phase 1: Network & Host Discovery

Goal: Identify live hosts on the internal lab network.

Determined local IP and routes
Performed host discovery on the internal bridge network
Identified multiple intentionally vulnerable services by hostname

Beginner note: Host discovery prevents wasted effort. Testing the wrong IP is common early on.

Phase 2: Service Enumeration

Goal: Identify what each host is running and where to focus.

Enumerated open ports on discovered hosts
Identified HTTP services and supporting components (web servers, databases)
Confirmed which apps were best suited for each vulnerability type

Key takeaway: Enumeration tells you where to test, not how to exploit.

Phase 3: Vulnerability Scanning with Nikto

Target: DVWA web service

Tool: Nikto

What Nikto checks:

Outdated server software
Missing security headers
Exposed directories and default files

Key Findings

Outdated Apache version
Missing security headers (X‑Frame‑Options, X‑Content‑Type‑Options)
Session cookies missing HttpOnly
Directory indexing enabled
Authentication endpoint identified

Why this matters: These findings don’t “hack” anything—but they dramatically increase risk and often point directly to deeper vulnerabilities.

Phase 4: SQL Injection Testing

Initial Test (Negative Result)

The login page returned a generic “Login failed” message regardless of input.

No visible SQL errors
No behavioral deviation

Why document this? Consistent error handling is a defensive control. Not every endpoint is vulnerable.

Pivot to a Better Target

Using enumeration results, SQL Injection testing moved to a dedicated SQLi module designed to demonstrate unsafe input handling.

Observed Behavior

User‑supplied input directly influenced backend queries
Multiple records returned where one was expected
Unauthorized access to user data and database metadata

Impact Demonstrated

Exposure of user records
Disclosure of database schema and version
Retrieval of password hashes

Beginner note: The vulnerability isn’t “seeing data”—it’s that untrusted input controls database logic.

Supplemental Risk Evidence

A representative unsalted MD5 hash was verified as trivially reversible using a public lookup service, demonstrating how weak hashing compounds SQL Injection risk.

Phase 5: Cross‑Site Scripting (XSS)

Reflected XSS (DVWA)

Baseline test:

Plain text input reflected directly into the response
No HTML output encoding observed

Conclusion:
User input is reflected verbatim, confirming a Reflected XSS condition at low security settings.

Beginner note: A popup is not required to prove XSS. Unsafe reflection alone is enough.

Stored XSS (DVWA)

Baseline storage test:

User comments persisted in the backend
Content rendered for all users
Entries remained after page refresh

Why this is critical:
Stored XSS affects every user who views the page, not just the attacker.

Root Cause (from Source Review)

Input was escaped for SQL usage but not encoded for HTML output.

Key lesson: SQL escaping ≠ XSS protection. Output must be encoded for the browser context.

Findings Summary

Category	Result
Nikto	Multiple misconfigurations identified
SQL Injection	Backend query manipulation confirmed
Reflected XSS	Unsafe reflection detected
Stored XSS	Persistent unsafe rendering confirmed

Mitigations & Secure Design Takeaways

Use parameterized queries (PDO / MySQLi)
Apply context‑aware output encoding (htmlspecialchars)
Set security headers (HttpOnly, X‑Frame‑Options, CSP)
Avoid weak or unsalted password hashes
Validate input and encode output

Defense‑in‑depth matters: No single control is sufficient.

Common Beginner Pitfalls

Expecting every input to be vulnerable
Skipping enumeration and guessing targets
Confusing SQL escaping with XSS prevention
Failing to document negative results

Learning to say “this did not change behavior” is a skill.

Conclusion

This lab demonstrated how a structured black‑box approach uncovers vulnerabilities systematically, not magically. By combining discovery, scanning, behavioral testing, and documentation, it’s possible to explain not just what is vulnerable, but why it matters.

The most important takeaway:

Security testing is about understanding trust boundaries, not memorizing payloads.

Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🛡️ AWS Config Drift Detection Lab - Beginner-Friendly Guide

LaTerral Williams — Sat, 20 Dec 2025 13:46:23 +0000

⭐ Why I Built This Project

(Project 4 of 6 — Drift Detection with AWS Config)

This 6-part series focuses on practical, resume-ready cloud security skills, including:

Identity hardening and MFA enforcement
IAM governance and access reviews
Continuous monitoring of cloud resources
Misconfiguration detection & drift analysis
Log analysis, audit readiness, and evidence gathering
Guard rails at scale using AWS Organizations + Service Control Policies (SCPs)
Threat detection, anomaly monitoring, and incident triage

Each project is designed to reflect real-world responsibilities, not just theoretical learning.

📌 Project Sequence

👉 Part 1: AWS IAM Hardening — strengthening identity boundaries and improving authentication hygiene

👉 Part 2: Cloud Security Posture Management (CSPM) using Security Hub + AWS Config

👉 Part 3: CASB-Like Monitoring with GuardDuty + CloudTrail, focusing on anomalies, delegated admin, and safe threat simulation

👉 Part 4: (this project) — Drift Detection with AWS Config, using managed Config rules, scoped evaluations, EventBridge routing, SNS notifications, and optional auto-remediation to detect when cloud resources deviate from approved security baselines

🔐 Why This Progression Matters

Modern cloud security teams approach protection in layers:

Identity first → Posture second → Threat Detection → Drift Governance

After establishing IAM hygiene (Project 1), posture baselines (Project 2), and threat intel/anomaly detection (Project 3), the next natural step is detecting when cloud resources drift away from their intended configuration.

Drift detection is critical because:

Many breaches originate from accidental misconfigurations
Public S3 buckets remain a top cloud security incident
Compliance frameworks require continuous configuration monitoring
Security teams rely on automated alerts not manual checks

This project simulates a realistic workflow used by cloud security analysts, compliance engineers, and platform security teams by combining:

AWS Config managed rules
Scoped evaluations (tags, resource types)
EventBridge event pattern filtering
SNS notification routing
Optional SSM auto-remediation actions
Cost-safe cleanup practices

You’ll intentionally make an S3 bucket public, watch AWS detect the drift, trigger an automated alert, and optionally repair the issue automatically... a true end-to-end cloud security workflow.

A hands‑on walkthrough using AWS Config, EventBridge, and SNS to detect when an S3 bucket becomes public (a classic example of security drift).

This is a fun, friendly, technical guide designed for absolute beginners including troubleshooting from a real-world lab run.

📘 Table of Contents

Introduction
What Is Drift Detection?
Architecture Overview
Prerequisites & Cost Notes
Step 1 — Create a Config Logs Bucket
Step 2 — Enable AWS Config (S3-Only Setup)
Step 3 — Create the Drift-Test S3 Bucket
Step 4 — Add the AWS Config Rule
Step 5 — Create SNS Topic for Alerts
Step 6 — Create EventBridge Rule
Step 7 — Introduce Drift
Step 8 — Verify Detection & Alerts
Troubleshooting & Gotchas
Cleanup
Final Thoughts

🔰 Introduction

Cloud environments change fast. Sometimes too fast — and not always intentionally.

This lab shows you how to detect unwanted changes (drift) using:

AWS Config → Detects drift
Amazon EventBridge → Routes drift events
Amazon SNS → Sends email alerts

You’ll break an S3 bucket on purpose and watch AWS alert you.

You'll also see real-world troubleshooting issues I hit along the way and how to fix them.

🌪️ What Is Drift Detection?

Security drift happens when a resource moves away from your intended configuration.

Example:

You want your S3 bucket private
Someone makes it public
Drift detected! 🔔

This lab focuses on detecting when an S3 bucket becomes publicly accessible.

🏗️ Architecture Overview

High-level flow:

You create a private S3 bucket
AWS Config evaluates it using a managed rule
You introduce drift (make it public)
Config marks it NON_COMPLIANT
EventBridge catches the change
SNS sends you an email alert

🛠️ Prerequisites & Cost Notes

You Need:

An AWS account
Basic IAM permissions:
- AWSConfigFullAccess
- S3FullAccess
- EventBridgeFullAccess
- SNSFullAccess

Cost Notes:

AWS Config is not fully free-tier.

To keep this project low cost:

Use one region
Track only S3 resources
Use a single rule
Delete everything at the end (cleanup section included)

🪣 Step 1 — Create a Config Logs Bucket

Go to S3 → Create Bucket
Name it something like:

config-logs-lab-<yourinitials>-123

Enable Block Public Access
Leave default encryption on
Click Create Bucket

📝 Step 2 — Enable AWS Config (S3-Only)

Open AWS Config → Set Up
Choose Record specific resource types
Select:

AWS::S3::Bucket
(Optional but recommended) AWS::S3::AccountPublicAccessBlock
1. Set the delivery S3 bucket to the one you created
2. Skip SNS notifications (we’ll create our own later)

🪣 Step 3 — Create the Drift-Test S3 Bucket

Name example:

drift-demo-bucket-<yourinitials>-123

Create the bucket
Keep Block Public Access = ON
Add tag:

Key: Project
Value: ConfigDriftLab

This tag lets us scope the Config rule later.

🧩 Step 4 — Add the AWS Config Rule

Search for the managed rule:

✅ `s3-bucket-level-public-access-prohibited`

This is the new bucket-level drift rule that detects whether bucket policies or ACLs make the bucket public.

Set Scope to:

Resources with specific tags
Key: Project
Value: ConfigDriftLab

📣 Step 5 — Create SNS Topic for Alerts

Go to SNS → Topics → Create Topic
Name: drift-alerts-test-topic
Create
Add a subscription:
- Protocol: Email
- Endpoint: your email address
Confirm the email in your inbox

🔔 Step 6 — Create EventBridge Rule

This rule listens for AWS Config compliance changes.

Use this event pattern:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["s3-bucket-level-public-access-prohibited"],
    "newEvaluationResult": {
      "complianceType": ["NON_COMPLIANT"]
    }
  }
}

Set the Target = SNS topic you just created.

If needed, re-add the target so EventBridge automatically updates the SNS policy.

💥 Step 7 — Introduce Drift (Make the Bucket Public)

To simulate drift:

Disable Block Public Access
Add a public bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::drift-demo-bucket-<yourinitials>-123/*"
    }
  ]
}

AWS Config will soon detect this change.

📨 Step 8 — Verify Drift Detection & Alerts

You should see:

AWS Config → Rule Status:

NON_COMPLIANT 🔴

EventBridge → Monitoring:

Invocations > 0

SNS Email →

Check inbox and spam folder (real story from this lab 😅)

🧰 Troubleshooting & Gotchas (Real Lab Issues)

This section includes both a narrative + clean reference list, based on actual problems encountered while building this project.

🧵 Narrative: What Actually Broke & How I Fixed It

1. SNS Never Delivered the Alert

Turns out the SNS topic had the default policy, which does NOT allow EventBridge to publish messages.

Fix:

I added this to the SNS Access Policy:

{
  "Sid": "Allow_EventBridge_Publish",
  "Effect": "Allow",
  "Principal": {
    "Service": "events.amazonaws.com"
  },
  "Action": "SNS:Publish",
  "Resource": "arn:aws:sns:us-east-1:<account-id>:drift-alerts-test-topic",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:events:us-east-1:<account-id>:rule/aws-config-drift-to-sns"
    }
  }
}

2. The First Alert Went to Spam

SNS emails come from:

no-reply@sns.amazonaws.com

I marked it as Not Spam so future alerts land correctly.

3. Config Rule Name Mismatch

AWS updated the naming of S3 Config rules.

The correct one is:

✔ s3-bucket-level-public-access-prohibited

📋 Clean Troubleshooting Checklist

Problem	Fix
No email alert	Confirm SNS subscription is Confirmed
EventBridge not firing	Check Monitoring tab for Matches
Invalid pattern	Temporarily test with `{ "source": ["aws.config"] }`
SNS access denied	Add EventBridge → SNS publish policy
Alert went to spam	Mark “Not Spam”
No event emitted	Ensure compliance changed from COMPLIANT → NON_COMPLIANT

🧹 Cleanup (Avoid Costs!)

Delete in this order:

Drift S3 bucket
AWS Config rule
Stop Configuration Recorder
Delete delivery channel
Delete Config logs bucket
Delete EventBridge rule
Delete SNS topic & subscription
Delete IAM roles used for remediation (if any)

This ensures AWS Config stops billing you.

🎉 Final Thoughts

You just built:

Drift detection
Automated alerting
AWS Config recording pipeline
Real debugging scenarios

This is a perfect beginner‑friendly cloud security project to show on a resume or portfolio.🚀

🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🔐 Building an IAM Security Dashboard with Power BI (Beginner-Friendly Walkthrough)

LaTerral Williams — Fri, 19 Dec 2025 17:17:27 +0000

Goal: Build a leadership-ready IAM security dashboard in Power BI Desktop using a simulated IAM dataset you generate yourself.

Audience: Beginners transitioning into security analytics

What you’ll end with:

A working Power BI dashboard (.pbix)

A CSV dataset + Python generator script

A GitHub repo with clear structure + screenshots

A documented “enterprise-style” workflow (Linux + Windows)

✅ What This Dashboard Answers

This dashboard is designed to help a security analyst answer:

Are failed logins trending up?
Which users have the highest risk?
What’s the MFA posture?
Where should we investigate first (user + location)?

This is security reporting maturity not just “here are logs.”

🧾 Table of Contents

1. Project Overview
2. Tools You Need
3. Professional Setup
4. Install VirtualBox on Ubuntu
5. Create the Windows 11 VM
6. Install Power BI Desktop in Windows
7. Create the Project Folder Structure
8. Generate the IAM Dataset (Python)
9. Move the CSV to Windows (OneDrive Method)
10. Import Data into Power BI
11. Create DAX Measures
12. Build the Dashboard Visuals
13. Build “Risk by User” Table (and Fix MFA Count)
14. Export Screenshots and Save the PBIX
15. Push to GitHub (Tokens + Common Errors)
16. Automation Note (Why We Documented It)
17. Final Checklist

1. Project Overview

Output files you’ll have by the end:

data/iam_security_events.csv (dataset)
data/generate_data.py (generator)
data/IAM_Security_Dashboard.pbix (Power BI dashboard)
screenshots/ (images of final dashboard)

2. Tools You Need

Linux (Ubuntu)

Python 3
Git
(Optional) OneDrive sync client or manual upload via browser

Windows (VM)

Power BI Desktop (free)
OneDrive (optional but easy)

Note: You can likely accomplish all of this using Windows. I was already working on my linux machine when structuring this project. This made it easier for me to work with python and push to github. My steps are not law to complete this project.

3. Professional Setup

This is the setup many analysts use:

✅ Linux for:

dataset generation (Python)
validation
GitHub version control
writing documentation

✅ Windows for:

Power BI Desktop
visuals + DAX
exporting .pbix + screenshots

4. Install VirtualBox on Ubuntu

4.1 Install dependencies

sudo apt update
sudo apt install -y build-essential dkms linux-headers-$(uname -r)

4.2 Install VirtualBox

Install VirtualBox from Ubuntu repos (beginner friendly):

sudo apt install -y virtualbox

4.3 Fix common VirtualBox kernel module errors

If you see errors like “Kernel driver not installed”:

sudo /sbin/vboxconfig

If it still fails, Secure Boot may be blocking modules. Disable Secure Boot in BIOS/UEFI for lab use.

4.4 Fix VMX/KVM conflict (if VirtualBox says VMX root mode error)

Check KVM modules:

lsmod | grep kvm

Temporarily unload (Intel):

sudo modprobe -r kvm_intel
sudo modprobe -r kvm

(AMD systems use kvm_amd.)

5. Create the Windows 11 VM

Recommended VM settings (good balance)

Name: Windows11
Type: Microsoft Windows
Version: Windows 11 (64-bit)
RAM: 8 GB (minimum 4 GB)
CPU: 2 cores (4 if available)
Virtual disk: 60 GB, dynamically allocated (recommended)

5.1 Attach the Windows 11 ISO

If the VM won’t boot, it usually means you forgot to attach the ISO:

Settings → Storage → Empty → Choose ISO

5.2 Install Windows

Choose “I don’t have a product key” (fine for labs)
Complete setup

6. Install Power BI Desktop in Windows

Inside the Windows VM:

Open browser
Install Power BI Desktop
Confirm it opens successfully

7. Create the Project Folder Structure

On Linux, create a clean repo structure:

mkdir -p ~/Projects/powerbi-security-dashboard/{data,screenshots}
cd ~/Projects/powerbi-security-dashboard

8. Generate the IAM Dataset (Python)

8.1 Create a generator script

Create data/generate_data.py:

import random
import csv
from datetime import datetime, timedelta

random.seed(7)

USERS = [
    "alex.lee@company.com",
    "jane.doe@company.com",
    "sam.taylor@company.com",
    "morgan.chan@company.com",
    "devon.king@company.com",
]

LOCATIONS = ["US-TX", "US-CA", "US-NY", "GB-LON", "ZA-JHB"]
EVENT_TYPES = ["LoginSuccess", "LoginFailure", "MFAChallenge"]
AUTH_METHODS = ["Password", "MFA"]

def risk_for_event(event_type: str, mfa_enabled: bool) -> str:
    # Simple rules to make data feel realistic
    if event_type == "LoginFailure" and not mfa_enabled:
        return random.choices(["Medium", "High"], weights=[60, 40])[0]
    if event_type == "LoginFailure":
        return random.choices(["Low", "Medium"], weights=[40, 60])[0]
    if event_type == "MFAChallenge":
        return "Low"
    return "Low"

def generate_rows(days: int = 14, rows_per_day: int = 80):
    start = datetime.now().date() - timedelta(days=days)
    for d in range(days):
        day = start + timedelta(days=d)
        for _ in range(rows_per_day):
            user = random.choice(USERS)
            mfa_enabled = random.choice([True, True, True, False])  # mostly enabled
            event_type = random.choices(EVENT_TYPES, weights=[70, 25, 5])[0]
            auth_method = "MFA" if (mfa_enabled and event_type != "LoginFailure") else "Password"
            location = random.choice(LOCATIONS)
            risk = risk_for_event(event_type, mfa_enabled)

            yield {
                "EventDate": day.isoformat(),
                "UserPrincipalName": user,
                "EventType": event_type,
                "AuthMethod": auth_method,
                "MFAEnabled": mfa_enabled,
                "Location": location,
                "RiskLevel": risk,
            }

def main():
    out_path = "data/iam_security_events.csv"
    fieldnames = ["EventDate", "UserPrincipalName", "EventType", "AuthMethod", "MFAEnabled", "Location", "RiskLevel"]

    with open(out_path, "w", newline="", encoding="utf-8") as f:
        w = csv.DictWriter(f, fieldnames=fieldnames)
        w.writeheader()
        for row in generate_rows():
            w.writerow(row)

    print(f"Wrote dataset to {out_path}")

if __name__ == "__main__":
    main()

8.2 Run it

python3 data/generate_data.py

8.3 Sanity check the CSV

head -n 5 data/iam_security_events.csv

9. Move the CSV to Windows (OneDrive Method)

Because Power BI Desktop runs on Windows, you need your CSV accessible in the VM.

Option A (Recommended): OneDrive

Upload data/iam_security_events.csv to OneDrive (from Linux browser)
In Windows VM, open OneDrive folder
Confirm the CSV is synced locally

This is common in real environments: Linux generates data; Windows consumes it for reporting.

10. Import Data into Power BI

In Power BI Desktop (Windows VM):

Home → Get Data → Text/CSV
Select iam_security_events.csv
Click Transform Data
Confirm types:
- EventDate = Date
- MFAEnabled = True/False (or Boolean)
Close & Apply

11. Create DAX Measures

Right-click your table in the Fields pane (example: IAMSecurityEvents) → New measure

11.1 Total Login Attempts

Total Login Attempts =
COUNT(IAMSecurityEvents[EventType])

11.2 Failed Logins

Failed Logins =
CALCULATE(
    COUNT(IAMSecurityEvents[EventType]),
    IAMSecurityEvents[EventType] = "LoginFailure"
)

11.3 High Risk Events

High Risk Events =
CALCULATE(
    COUNT(IAMSecurityEvents[RiskLevel]),
    IAMSecurityEvents[RiskLevel] = "High"
)

11.4 MFA Coverage % (optional but strong)

MFA Coverage % =
DIVIDE(
    CALCULATE(
        COUNT(IAMSecurityEvents[UserPrincipalName]),
        IAMSecurityEvents[MFAEnabled] = TRUE()
    ),
    COUNT(IAMSecurityEvents[UserPrincipalName]),
    0
)

Format it as Percentage (Measure tools → Format → Percentage).

12. Build the Dashboard Visuals

12.1 KPI Cards (use Card visual)

Add 4 Card visuals and drop in:

Total Login Attempts
Failed Logins
High Risk Events
MFA Coverage %

Note: Power BI has a “KPI” visual, but for beginner dashboards, Card visuals are simpler and more reliable.

12.2 Line chart (Failed Logins over time)

Use a Line chart:

X-axis: EventDate
Y-axis: Failed Logins

12.3 Bar chart (High risk by location)

Use a Clustered bar chart:

Axis: Location
Values: High Risk Events

Sort descending by High Risk Events.

13. Build Risk by User Table (and Fix MFA Count)

13.1 Create the table

Add a Table visual and add these fields:

UserPrincipalName
Failed Logins (measure)
High Risk Events (measure)
MFAEnabled (column)

13.2 Fix: MFAEnabled shows as “Count”

This happens because Power BI auto-aggregates fields.

In the table visual:

In the Values well, click the dropdown next to MFAEnabled
Change from Count → First (or Max)

Now it will show TRUE/FALSE per user instead of a number.

Note: If you have difficulty finding this, like I did... you may also create another measure.

MFA Enabled Status =
FIRSTNONBLANK(
    IAMSecurityEvents[MFAEnabled],
    1
)

13.3 Sort the table for triage

Sort by:

High Risk Events descending Then by:
Failed Logins descending

This makes the table investigation-ready.

14. Export Screenshots and Save the PBIX

14.1 Save the dashboard

Save the Power BI file as:

data/IAM_Security_Dashboard.pbix

14.2 Take screenshots (Windows VM)

Capture:

Full dashboard view
Risk by User table close-up
High risk by location chart

Save them into your repo folder:

screenshots/

Tip: name your files so they are easy to locate.

Example:

01-dashboard-overview.png
02-risk-by-user.png
03-high-risk-by-location.png

15. Push to GitHub (Tokens + Common Errors)

15.1 Initialize repo

git init
git add .
git commit -m "Initial commit: Power BI IAM security dashboard"

15.2 Add remote

git remote add origin https://github.com/<your-username>/powerbi-security-dashboard.git

15.3 Push

git push -u origin main

Token permissions

Your GitHub token needs:

✅ repo scope (classic token)

Common error: “fetch first”

If GitHub repo already has commits (like a README):

git pull origin main --rebase
git push -u origin main

16. Automation Note (Why We Documented It)

Power BI alerts + Power Automate typically require a work/school tenant and licensing.

For this project:

We built the dashboard in Power BI Desktop
We documented automation as a “production extension”

This is realistic: many portfolio builds don’t have enterprise tenancy.

17. Final Checklist

✅ CSV generated and committed

✅ Power BI report built and saved as .pbix

✅ Measures working (cards update with filters)

✅ Risk by user table sorted and MFA fixed

✅ Screenshots captured and saved

✅ Repo pushed to GitHub

🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🛡️ Ethical Hacking Lab Walkthrough: Website Cloning & SMB Enumeration (Beginner-Friendly)

LaTerral Williams — Thu, 18 Dec 2025 12:06:18 +0000

Lab Context:

This article documents a controlled, educational cybersecurity lab completed in a VirtualBox-based Kali Linux environment.

All techniques demonstrated were performed only against intentionally vulnerable lab machines (DVWA & Metasploitable) and never against real-world systems.

📌 Table of Contents

Why I Built This Lab
Lab Environment Setup
Part 1: Website Cloning with SEToolkit
- Understanding Website Cloning
- SEToolkit Attack Flow
- Captured Credentials & XML Report
Part 2: SMB Vulnerability Scanning with Enum4Linux
- Network Discovery with Nmap
- User Enumeration
- NetBIOS & OS Enumeration
- Share Enumeration
- Password Policy Enumeration
- Full Enumeration (-a)
SMB Access & File Upload with smbclient
Key Security Findings
Defensive Takeaways
Final Thoughts

Why I Built This Lab

This is a part of my Parocyber ethical hacking training. The instructors course design provides opportunities to gain hands-on experience that mirrors real-world penetration testing workflows.

This lab helped me practice:

Understanding how phishing attacks work behind the scenes
Enumerating SMB services and misconfigurations
Reading tool output and translating it into meaningful findings

Everything here is framed from a defender’s mindset: learning how attacks work so they can be prevented.

Lab Environment Setup

Attacker Machine: Kali Linux OVA (VirtualBox)
Targets:
- DVWA (http://dvwa.vm)
- Metasploitable (172.17.0.2)
Network: Isolated lab network
Attacker IP: 10.6.6.1

Part 1: Website Cloning with SEToolkit

Understanding Website Cloning

Website cloning is a technique used in phishing attacks where a legitimate login page is copied and hosted elsewhere to harvest credentials.

In this lab, the goal is educational to see how credential harvesting works so we can better defend against it.

SEToolkit Attack Flow

Tool: Social-Engineer Toolkit (SEToolkit)

Attack Type: Credential Harvester → Site Cloner

High-level steps:

Clone a login page (http://dvwa.vm)
Host it on the Kali attacker machine
Capture submitted credentials
Review the generated report

A custom redirect file was created:

<html>
  <head>
    <meta http-equiv="refresh" content="0; url=http://10.6.6.1/" />
  </head>
</html>

Fake credentials submitted:

Email: marvelfan@demo.com
Password: 1234

Captured Credentials & XML Report

SEToolkit logged the credentials and exported an XML report:

<harvester>
   URL=http://dvwa.vm
   <url>
      <param>username=marvelfan@demo.com</param>
      <param>password=1234</param>
      <param>Login=Login</param>
      <param>user_token=...</param>
   </url>
</harvester>

This clearly shows how form fields are captured during phishing attacks.

Part 2: SMB Vulnerability Scanning with Enum4Linux

Network Discovery with Nmap

A null scan was used (requires root):

nmap -sN 172.17.0.0/24

This revealed the Metasploitable host (172.17.0.2) with SMB-related ports:

139/tcp
445/tcp

User Enumeration

enum4linux -U 172.17.0.2

Result:

Dozens of local users discovered
Anonymous SMB sessions allowed

This alone is a critical misconfiguration.

NetBIOS & OS Enumeration

enum4linux -n 172.17.0.2
enum4linux -o 172.17.0.2

Key findings:

Workgroup: WORKGROUP
OS: Samba 3.0.20 (Debian) — known vulnerable version

Share Enumeration

enum4linux -Sv 172.17.0.2

Shares discovered:

print$
tmp
opt
IPC$
ADMIN$

The tmp share allowed anonymous read/write access.

Password Policy Enumeration

enum4linux -P 172.17.0.2

Findings:

Minimum password length: 5
Password complexity: Disabled
Account lockout: None

This configuration allows easy brute-force attacks.

Full Enumeration (-a)

enum4linux -a 172.17.0.2

This combined all enumeration techniques:

Users
Groups
Shares
Password policy
RID cycling

A full attacker profile of the system was built without authentication.

SMB Access & File Upload with smbclient

Listing shares:

smbclient -L //172.17.0.2

Anonymous login succeeded.

Connecting to the writable share:

smbclient //172.17.0.2/tmp

Uploading a file:

put virus.exe group_work.txt

The uploaded file appeared in the directory listing, confirming anonymous write access.

⚠️ Note: The local file must exist in your current directory before using put, or the upload will fail.

Key Security Findings

Phishing pages easily capture credentials if users are unaware
SMB anonymous access exposes:
- Users
- OS details
- Writable shares
Weak password policies enable brute-force attacks
SMB1 fallback is still enabled (dangerous)

Defensive Takeaways

To defend against these attacks:

Enforce MFA and phishing-resistant authentication
Disable anonymous SMB access
Remove SMB1 support
Enforce strong password policies
Restrict share permissions
Monitor logs for enumeration activity

Final Thoughts

This lab reinforced how small misconfigurations can lead to full system compromise.

By practicing these techniques in a safe environment, defenders can better recognize, detect, and prevent real-world attacks.

If you’re learning cybersecurity, labs like this bridge the gap between theory and practice.

🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🛡️ Building a CASB‑Like Threat Monitoring Lab in AWS (Beginner Friendly)

LaTerral Williams — Wed, 17 Dec 2025 19:59:39 +0000

⭐ Why I Built This Project (Project 3 of 6 — CASB‑Like Monitoring with GuardDuty + CloudTrail)

Instead of studying cloud security concepts in isolation, I’m using real job descriptions as a roadmap and building hands‑on projects that map directly to what employers expect in cloud security, cloud operations, and security engineering roles.

This 6‑part series focuses on practical skills such as:

Identity hardening and MFA enforcement
IAM governance and access reviews
Continuous monitoring of cloud resources
Log analysis, audit readiness, and evidence gathering
Guard rails at scale using AWS Organizations + Service Control Policies (SCPs)
Threat detection, anomaly monitoring, and incident triage

Each project reflects real‑world responsibilities, not just theoretical learning.

📌 Project Sequence

🔐 Why This Progression Matters

Modern cloud security teams approach protection in layers.

Identity first → Posture second → Threat Detection next

Project 3 builds on the earlier foundations by adding behavioral visibility, anomaly detection, and event‑driven alerts core fundamentals used by SOC analysts, detection engineers, threat hunters, and cloud security specialists.

This lab simulates a lightweight Cloud Access Security Broker (CASB) workflow inside AWS using managed services, allowing you to explore:

CloudTrail event logging & integrity
GuardDuty findings (sample + real)
Safe adversary simulation
Region‑based anomaly detection
Delegated administrator restrictions
Cleanup for cost control

A hands‑on, beginner‑friendly guide to setting up threat monitoring in AWS, generating safe test activity, interpreting findings, troubleshooting delegated admin errors, and cleaning the environment properly.

Introduction
What You Will Build
Prerequisites
Step 1 — Enable CloudTrail With Secure Settings
Step 2 — Enable GuardDuty (Threat Detection)
Step 3 — Generate Safe Test Activity
Step 4 — Review GuardDuty Findings
Step 5 — Cleanup to Avoid Costs
Final Thoughts

Introduction

Cloud security monitoring doesn’t have to be complicated and you don’t need enterprise CASB tools to begin learning how threat detection works in the cloud.

This beginner‑friendly lab shows how to simulate CASB‑like monitoring using AWS CloudTrail + GuardDuty, while keeping everything free or extremely low‑cost.

You’ll generate safe test activity, view detections, and learn how these tools help security teams identify risky behavior inside AWS environments.

This guide also includes troubleshooting notes and real issues encountered during setup (manual KMS encryption, delegated admin restrictions, etc.) so beginners know what to expect.

What You Will Build

By the end of this lab you will have:

CloudTrail logging your AWS API activity
GuardDuty analyzing logs for threats
Sample findings + real findings from safe test events
A lightweight, CASB‑like monitoring workflow
A clean environment with no ongoing costs

Prerequisites

AWS account
IAM user or role with admin‑level permissions
A single region chosen for the lab (recommended: us-east-1)
Optional: AWS CLI installed

Step 1 — Enable CloudTrail With Secure Settings

CloudTrail records API activity across your AWS account. It’s the backbone for detection and threat monitoring.

✅ Create a CloudTrail Trail

Open CloudTrail → Trails → Create trail
Name your trail:

   casb-guardduty-lab-trail

Create a new S3 bucket for logs
Manually enable:
- SSE‑KMS encryption (AWS managed key)
- Log file validation

🔎 Many beginners miss this — CloudTrail does NOT always enable SSE-KMS or validation by default depending on UI version.

These settings add integrity and confidentiality protections to your logs.

Step 2 — Enable GuardDuty (Threat Detection)

GuardDuty analyzes CloudTrail logs, VPC Flow Logs, and DNS logs for suspicious or malicious activity.

✅ Enable GuardDuty

Open GuardDuty
Click Enable GuardDuty
If GuardDuty creates a Delegated Administrator, note it for cleanup later

You now have threat detection running automatically.

Step 3 — Generate Safe Test Activity

To make this a real learning experience, you’ll generate safe events that CloudTrail and GuardDuty can analyze.

🔹 Option A - Generate AWS Sample Findings

In GuardDuty:

Open the Actions menu
Choose Generate sample findings

These simulated attacks help you practice incident triage.

🔹 Option B - Generate Real CloudTrail Events

1. Console Login Events

Log out and back into the AWS console
Create a test IAM user and intentionally fail login attempts

These appear as ConsoleLogin events in CloudTrail.

2. Activity From an Unusual Region

Switch from your home region to eu-west-1 or ap-southeast-1
Open services or start to create resources (cancel before provisioning)

CloudTrail logs these actions with the region included.

Step 4 — Review GuardDuty Findings

Now you get to see your CASB‑like visibility in action.

🔍 View All Findings

Go to:

GuardDuty → Findings

You may see findings such as:

UnauthorizedAccess:IAMUser/ConsoleLogin
Recon:EC2/PortProbe
AnomalousBehavior findings for unusual logins
Sample simulated threats such as:
- IAM compromise sequences
- EC2 compromise
- Kubernetes or ECS compromise

If GuardDuty detects unusual database access, you may see:

A user successfully logged into an RDS database in an unusual way.
Severity: HIGH

These help you understand what real-world threat detection looks like.

Step 5 — Cleanup to Avoid Costs

This lab is cheap, but not free if left running for days or months.

❗ REQUIRED: Remove Delegated Administrator First

You cannot disable GuardDuty until the delegated admin is removed.

Open GuardDuty → Settings → Accounts
Click Disable delegated administrator
Confirm

Now you can safely disable GuardDuty.

✅ Disable GuardDuty

Open GuardDuty → Settings
Choose Disable GuardDuty

✅ Delete CloudTrail Trail

Open CloudTrail → Trails
Select your trail
Delete it

✅ Remove S3 Logs Bucket

Empty the bucket
Delete the bucket

✅ Delete Test IAM User

If you created one for failed login testing.

Final Thoughts

This project gives you real hands‑on experience with:

Logging
Threat detection
Cloud security monitoring
CASB‑like visibility inside AWS
Proper cleanup and cost management

It’s a strong beginner → intermediate cloud security project you can showcase in a portfolio or LinkedIn post.

🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🛡️ Building a Mini Cloud Security Posture Management (CSPM) Lab Using AWS Security Hub + AWS Config

LaTerral Williams — Wed, 17 Dec 2025 18:15:36 +0000

⭐ Why I Built This Project

Instead of studying cloud security concepts in isolation (theory only), I’m using real job descriptions as a roadmap and building hands-on projects that map directly to what employers expect.

This 6-part series focuses on skills frequently requested in cloud security, cloud operations, and security engineering roles, including:

Identity hardening and MFA enforcement
IAM governance and access reviews
Continuous monitoring of cloud resources
Log analysis, audit readiness, and evidence gathering
Guardrails at scale using AWS Organizations + Service Control Policies

Each project aims to reflect real-world responsibilities, not just theoretical knowledge.

📌 Project Sequence

👉 Part 1 focused on AWS IAM Hardening, tightening identity boundaries and improving authentication hygiene.

👉 Part 2 (this project) expands into Cloud Security Posture Management (CSPM), using AWS Security Hub + AWS Config to detect misconfigurations, enforce security standards, and simulate an enterprise multi-account security architecture.

🔐 Why This Progression Matters

Modern cloud security teams approach security in layers:

Identity first → Posture second → Threat detection next.

A hands-on, beginner-friendly guide to setting up Cloud Security Posture Management (CSPM) in AWS, using a real enterprise deployment pattern with AWS Organizations + Delegated Administrator, intentional misconfigurations, CLI exports, troubleshooting, and a final cleanup plan.

📘 Table of Contents

Overview: What We’re Building
Architecture: How CSPM Works in the Real World
Prerequisites
Step 1: Prepare AWS Organizations
Step 2: Create & Access the Delegated Admin Account
Step 3: Enable AWS Config Across the Org
Step 4: Enable AWS Security Hub CSPM
Step 5: Validate CSPM Is Working
Step 6: Create Intentional Misconfigurations
Step 7: View & Export Findings
Troubleshooting (Real Errors I Hit & Fixes)
What Not To Do in Production (But OK in This Lab)
Cleanup Steps
Final Thoughts

1️⃣ Overview: What We’re Building

In this lab you’ll build a mini CSPM using:

AWS Security Hub CSPM
AWS Config
AWS Organizations with a Delegated Administrator

You will:

Stand up a realistic enterprise-style architecture (management account + security account).
Create intentional misconfigurations (like a public S3 bucket and open security group).
Let Security Hub CSPM detect them.
Export findings with the AWS CLI / CloudShell.
Practice remediation and then clean everything up to control cost.

2️⃣ Architecture: How CSPM Works in the Real World

In production, CSPM rarely runs from the same account that owns workloads.

Instead, you usually see:

Management Account
- Owns AWS Organizations
- Enables services like Security Hub + Config at the org level
- Assigns a delegated administrator
Delegated Admin Account (Security / Audit account)
- Runs Security Hub CSPM
- Aggregates findings from all member accounts
- Sees the overall security posture
- Drives remediation across the org

That’s exactly the pattern we’ll follow here.

3️⃣ Prerequisites

You’ll need:

An AWS Organization already created (or permission to create one).
Permission to create a new member account.
Basic understanding of:
- IAM users / roles
- S3 buckets
- EC2 security groups
Either:
- AWS CloudShell (recommended), or
- AWS CLI installed on your machine.

This lab assumes a personal / sandbox environment, not production.

4️⃣ Step 1: Prepare AWS Organizations

In the management account, open AWS Organizations.
If Organizations is not enabled, enable it.
(Optional but nice) Create a simple structure:

   Root
    └── Security OU
         └── cspm-admin-account

We’ll put our delegated admin account in the Security OU later.

5️⃣ Step 2: Create & Access the Delegated Admin Account

5.1 Create a new member account

From the management account:

Go to Organizations → Accounts → Add an AWS account → Create an AWS account.
Example values:

   Account name: cspm-admin-account
   Email: yourname+securityhub@example.com

Place it into your Security OU if you created one.

This new account will become the Security Hub delegated administrator.

5.2 Assign the delegated administrator

Still in the management account:

Open Security Hub.
Go to Settings → Accounts.
Choose Designate a delegated administrator.
Select the cspm-admin-account.

Security Hub will now treat that account as the org-wide CSPM brain.

5.3 Switch role into the delegated admin account

You normally don’t log into member accounts directly as root.

Instead, use Switch Role.

Log in to the management account as an IAM admin user (not root).
In the top-right, choose your username → Switch role.
Enter:
- Account ID: of cspm-admin-account
- Role:
```
 OrganizationAccountAccessRole
```
Optionally give the role a display name and a color (e.g., CSPM-Admin in blue).

You are now operating inside the delegated admin account with full admin rights.

6️⃣ Step 3: Enable AWS Config Across the Org

AWS Config records configuration history and feeds data to Security Hub.

In the management account:

Go to AWS Config → Settings / Get started.
Resource recording:
- Choose Record all resources supported in this region.
S3 bucket for configuration history & snapshots:
- Create or choose a bucket (defaults are fine for this lab):
  - ACLs disabled
  - Versioning off
  - SSE-S3 encryption on
  - Bucket Key enabled
Skip SNS notifications to avoid alert noise for the project.
Save your settings and make sure recording is ON.

💡 In a larger environment you might scope to specific resource types for cost, but for a mini CSPM lab recording all resources gives you a more realistic feel.

7️⃣ Step 4: Enable AWS Security Hub CSPM

Still in the management account:

Open Security Hub.
Choose Get started → Configure Security Hub CSPM.
You’ll be asked for:
- Home Region (choose the region you’ll mainly work in).
- AWS Account Number (enter the management account’s 12‑digit ID).
Accept the prompt to create/update the delegation policy.

Once enabled, Security Hub CSPM will automatically turn on:

AWS Foundational Security Best Practices v1.0.0
CIS AWS Foundations Benchmark v1.2.0

You now have an org-level CSPM engine, with cspm-admin-account as the delegated administrator.

8️⃣ Step 5: Validate CSPM Is Working (Delegated Admin View)

Switch role back into the cspm-admin-account (delegated admin).

Open Security Hub and check:

Dashboard – You should see:
- Number of controls
- Findings over time
- A breakdown of threats / exposure / resources
Security standards – Confirm:
- AWS Foundational Security Best Practices v1.0.0 is Enabled.
- CIS AWS Foundations Benchmark v1.2.0 is Enabled.
Settings → Accounts – Should say:
- “This account is the delegated administrator for your organization.”

If all of that looks good, CSPM is officially online. 🎉

9️⃣ Step 6: Create Intentional Misconfigurations

Now the fun part: we’ll create a few misconfigurations on purpose in the delegated admin account so Security Hub can yell at us.

⚠️ Do this only in a sandbox environment.

Never create intentional vulnerabilities in production.

9.1 Misconfig #1 – Public S3 bucket

In S3, choose Create bucket.
Name it something like: cspm-test-bucket-001.
Region: same as your Security Hub home region.
In Block Public Access settings for this bucket:
- Uncheck Block all public access.
- Acknowledge the scary warning.
(Optional but loud) Add a bucket policy that allows public reads.

Security Hub should eventually trigger a finding similar to:

“Amazon S3 Block Public Access was disabled for the S3 bucket cspm-test-bucket-001.”

You can even add a comment in the finding like:

Will triage and disable public access.

9.2 Misconfig #2 – Open security group

Go to EC2 → Security Groups → Create security group.
Name: cspm-open-ssh-test.
Inbound rule:
- Type: SSH
- Port: 22
- Source: 0.0.0.0/0 (anywhere)
Save.

Security Hub will flag this with an EC2-related control (e.g., “Security groups should not allow unrestricted SSH access”).

9.3 Misconfig #3 – Root account use (already flagged)

If you’ve logged in or used the root account recently, Security Hub may already show findings like:

“The API ConsoleLogin was invoked using root credentials.”
“The API DescribeRegions was invoked using root credentials.”

These are a great example of how CSPM watches for bad identity hygiene, not just network or S3 misconfigurations.

🔟 Step 7: View & Export Findings

10.1 View findings in the console

In the delegated admin account:

Security Hub → Findings
Use filters such as:
- Product name: Security Hub
- Severity label: LOW, MEDIUM, or HIGH
Click on a finding for details:
- Title & Description
- Resource (e.g., S3 bucket ARN)
- Severity
- Remediation (often linked AWS docs)
- Notes / Comments (you can add your own)

The Dashboard also gives you a nice view of:

Threats
Exposure
Number of resources
Findings by Region and severity breakdown

Example Snippets:

10.2 Export findings with AWS CLI (CloudShell)

For this project, we’ll use AWS CloudShell so we don’t have to store credentials locally.

While still in the delegated admin account, open CloudShell from the console.
Verify your identity:

   aws sts get-caller-identity

Export findings to a JSON file:

   aws securityhub get-findings      --region us-east-1      --output json > securityhub-findings.json

List the file:

   ls -l securityhub-findings.json

10.3 Small JSON example

Here’s a safe, shortened snippet similar to what you’ll see:

{
  "Findings": [
    {
      "Title": "Amazon S3 Block Public Access was disabled",
      "Description": "Block Public Access settings were disabled for bucket cspm-test-bucket-001.",
      "Severity": { "Label": "LOW" },
      "Resources": [
        {
          "Id": "arn:aws:s3:::cspm-test-bucket-001",
          "Type": "AwsS3Bucket"
        }
      ]
    }
  ]
}

In a real environment, this JSON could be fed into SIEMs, dashboards, or automation workflows.

1️⃣1️⃣ Troubleshooting (Real Errors I Hit & Fixes)

I ran into several very real-world errors while building this.

Here’s what they meant and how they were resolved.

🔧 “The delegated administration for SecurityHub CSPM was not fully configured…”

Variations included:

“…is already a member under another account for these regions…”
“You specified an account that doesn't exist…”

Cause:

Old Security Hub Org configuration or delegated admin metadata existed from a previous project.

Fix:

From the management account:

Remove any existing delegated admin for Security Hub.
Disable trusted access for Security Hub under Organizations → Services.
Re-run the CSPM setup wizard and assign the new cspm-admin-account as delegated admin.

🔧 “You cannot register the management account as delegated administrator”

Cause:

By design, the management account cannot also be the delegated admin for CSPM.

Fix:

Create a separate member account (cspm-admin-account).
Use that as the delegated admin.

Lesson: this project accidentally forced me into the correct enterprise pattern. 😄

🔧 CLI error: explicit deny in a Service Control Policy (SCP)

Example:

AccessDeniedException: ... not authorized to perform: securityhub:GetFindings ...
with an explicit deny in a service control policy

Cause:

An SCP attached at the Root or OU level explicitly denied Security Hub actions, even though my IAM user had permissions.

Fix:

From the management account:

Review SCPs attached to the OU / account.

Either:

Remove the restrictive SCP from the delegated admin account, or
Add an exception:

"Condition": {
  "StringNotEquals": {
    "aws:PrincipalAccount": "DELEGATED_ADMIN_ACCOUNT_ID"
  }
}

Lesson: SCPs override IAM. If an SCP says “no,” nothing else can say “yes.”

🔧 “Switch role” option missing

Cause:

I was logged in as the root user, which doesn’t get the Switch Role option.

Fix:

Create an IAM admin user in the management account.
Log in as that IAM user instead.
The Switch role menu appears in the top-right.

1️⃣2️⃣ What Not To Do in Production (But OK in This Lab)

I intentionally bent a few rules to keep this lab simple.

They’re fine here, but you should not copy them into a real environment.

❌ Long-lived access keys for a CSPM admin user

For testing the CLI, I created an IAM user and access key.

In production you should instead:

Use AWS IAM Identity Center (SSO)
Or use STS AssumeRole with short-lived credentials
Or stick to CloudShell, which gives you ephemeral credentials bound to your console role.

❌ Creating misconfigurations directly in the security account

In enterprises, the delegated admin account is often locked down and doesn’t host workloads.

For learning, it was convenient to create test S3 buckets and security groups there.

In production, do this kind of testing in separate test accounts.

❌ Disabling S3 Block Public Access

We temporarily disabled this to generate findings.

In real environments, you usually want:

Account-level Block Public Access ON
Bucket-level Block Public Access ON
Tight bucket policies and IAM least privilege

1️⃣3️⃣ Cleanup Steps

To avoid surprise bills and leave your org clean, run through these steps when you’re done.

13.1 Disable Security Hub CSPM (delegated admin account)

In cspm-admin-account, go to Security Hub.
Under Security standards, disable each enabled standard (FSBP, CIS).
In Settings, disable Security Hub entirely for that region.

13.2 Disable Security Hub Org integration (management account)

In the management account, open AWS Organizations → Services.
Select Security Hub.
Choose Disable trusted access.

Optionally also remove cspm-admin-account as the delegated admin for Security Hub.

13.3 Stop AWS Config recording

In the management account, open AWS Config.
Go to Settings.
Stop the configuration recorder.

If you created any extra Config rules just for the lab, delete those as well.

13.4 Clean up S3 buckets

In S3:

Empty and delete:
- The Config logs bucket (if you created a dedicated one).
- The test misconfig bucket (cspm-test-bucket-001, etc.).

13.5 Remove test security groups

In EC2:

Delete cspm-open-ssh-test and any other lab-only security groups.

13.6 Remove IAM test users & access keys

In the delegated admin account:

Delete any lab-only IAM users (for example cspm-cli-access).
Delete any associated access keys.

This is important so old credentials don’t linger.

13.7 (Optional) Remove delegated admin assignment

If this was purely a one-off lab:

In the management account, open Security Hub → Settings → Accounts.
Remove cspm-admin-account as the delegated administrator.

You can keep the account for future security experiments, or close it if you want to minimize cost and clutter.

1️⃣4️⃣ Final Thoughts

By the end of this lab you’ve:

Built a mini CSPM using AWS-native tools.
Followed a real enterprise pattern with a management account and delegated admin.
Enabled AWS Config and Security Hub CSPM at the org level.
Created and fixed intentional misconfigurations.
Exported findings via the AWS CLI / CloudShell.
Navigated SCPs, delegated admin errors, and role switching.
Cleaned up resources to keep your bill (and attack surface) low.

From here, great next steps would be:

Adding auto-remediation with Lambda or Systems Manager Automation.
Forwarding findings to a SIEM or logging platform.
Combining this with GuardDuty, IAM Access Analyzer, and Config Conformance Packs.

🤝 Connect

If you build on this and share your own twist, tag me; I’d love to see how your CSPM lab evolves. 🚀

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🔒 Beginner’s Guide to AWS IAM Hardening

LaTerral Williams — Wed, 17 Dec 2025 01:49:32 +0000

⭐ Why I Built This Project (Part 1 — IAM Hardening)

Instead of studying cloud security concepts in isolation, I’m using real job descriptions as a roadmap and building hands-on projects that map directly to what employers expect in day-to-day cloud security roles.

When reviewing cloud security, cloud operations, and security engineering job postings, the same foundational skills appear repeatedly. This 6-part project series is designed to build those skills progressively through practical, portfolio-ready labs.

This series focuses on real-world responsibilities such as:

Identity hardening and MFA enforcement
IAM governance and access reviews
Continuous monitoring of cloud resources
Log analysis, audit readiness, and evidence gathering
Guardrails at scale using AWS Organizations and Service Control Policies (SCPs)

Each project emphasizes hands-on implementation, not just theory, and mirrors how security controls are applied in real AWS environments.

📌 Project Sequence Overview

👉 Part 1 — AWS IAM Hardening (this project)

Establishes a secure identity foundation by:

Securing the root account
Enforcing MFA
Strengthening password policies
Applying least-privilege access
Auditing identities using CloudTrail and credential reports

👉 Part 2 — Cloud Security Posture Management (CSPM)

Builds on the identity foundation by introducing:

AWS Security Hub and AWS Config
Misconfiguration detection
Posture evaluation against security standards
Enterprise-style governance patterns

🔐 Why This Progression Matters

Modern cloud security programs are layered by design:

Identity first → Posture second → Threat detection next.

Without a strong IAM foundation, posture management, threat detection, and incident response controls become far less effective. This first project intentionally focuses on IAM hardening to set the stage for everything that follows in the series.

A hands-on portfolio lab covering IAM hardening basics.

Introduction
What You’ll Build
Lab Setup
Step 1 — Create an IAM Admin User
Step 2 — Enable MFA for Root & Admin
Step 3 — Strengthen the IAM Password Policy
Step 4 — Create Billing & Finance Groups
Step 5 — Enforce MFA Using Service Control Policies (SCPs)
Step 6 — Validate MFA Enforcement
Step 7 — Configure & Verify CloudTrail
Step 8 — Inspect CloudTrail Logs in S3
Step 9 — Generate the IAM Credential Report
Step 10 — Before/After Hardening Comparison
Optional — Billing Conductor & Real-World Finance Modeling
Troubleshooting Guide
Cleanup to Avoid Charges
Credits

1. Introduction

AWS Identity and Access Management (IAM) is one of the most important skills for any cloud engineer or cloud security analyst.

In this beginner-friendly project, you’ll harden an AWS account using real cloud security techniques:

Multi‑Factor Authentication (MFA)
IAM Groups & Roles
Strong Password Policies
Service Control Policies (SCPs)
CloudTrail auditing
IAM Credential Reports
Billing & Finance Access Controls

This guide mixes friendly explanations and technical depth, perfect for beginners building a portfolio.

2. What You’ll Build

By the end of this lab, you will have:

A secured AWS root account
Admin users protected with MFA
Billing + Finance access modeled like a real company
An MFA-required SCP that blocks API calls without MFA
CloudTrail logging all management events
IAM Credential Reports showing weak vs hardened states
Before/after screenshots for your portfolio

3. Lab Setup

All you need:

AWS Free Tier account
A phone with an authenticator app
Browser
Optional spreadsheet for credential report review

Group creation is used later, but I thought it would make sense to provide an overview.

🧩 Creating IAM Groups (Foundational Step)

Before assigning permissions directly to users, AWS best practice is to use IAM groups.

Groups make access easier to manage, audit, and scale; especially in real environments.

In this project, IAM groups represent real-world roles, not individuals.

🔐 Admin Group

The Admin group is used for trusted administrators who manage AWS resources.

Steps to create the Admin group:

Go to IAM → User groups
Click Create group
Group name: Admin
Attach policy:
- AdministratorAccess
Create group

You will assign your admin user (test-admin1) to this group.

👀 View-Only Group

The ViewOnly group represents auditors, security analysts, or stakeholders who need visibility without the ability to make changes.

Steps to create the ViewOnly group:

IAM → User groups → Create group
Group name: ViewOnly
Attach policy:
- ViewOnlyAccess
Create group

This aligns with real-world read-only access used for audits and reviews.

💰 Billing / Finance Group (Standard IAM)

Outside of Billing Conductor, many organizations still create a basic billing group for controlled access.

Optional standard billing group:

IAM → User groups → Create group
Group name: Billing
Attach policy:
- Billing (AWS managed policy)
Create group

⚠️ Note:

Some billing features remain root-only. This is expected behavior in AWS.

🧠 Why Groups Matter

Using groups instead of attaching policies directly to users:

Simplifies permission management
Reduces misconfiguration risk
Improves audit readability
Mirrors how IAM is managed in enterprise environments

This group-based design sets the foundation for later steps like MFA enforcement, SCP guardrails, and credential reporting.

4. Step 1 — Create an IAM Admin User

Never use the root account for daily operations.

Steps:

Go to IAM → Users → Create user
Name your admin user: test-admin1
Select Provide access to AWS Management Console
Assign to the Admin group
Keep password autogenerated

5. Step 2 — Enable MFA for Root & Admin

MFA increases login security dramatically.

Root account MFA:

Login as root
Go to IAM → Security Credentials
Add Virtual MFA
Use any authenticator app

Admin MFA:

Repeat the same steps under the user’s security credentials.

6. Step 3 — Strengthen the IAM Password Policy

Before hardening:

After hardening:

The improved settings:

14–character minimum
Require uppercase, lowercase, number, symbol
Expire passwords after 45 days
Prevent last 6 password reuse
Require admin reset

Note: You'll find password policy in the IAM dashboard, under Account Settings.

7. Step 4 — Create Billing & Finance Groups

If you are a beginner (like me) using a standard user account, in AWS only the root user has access to customize billing.

To simulate a finance department, you may optionally use Billing Conductor:

Step-by-Step: Create the Billing Conductor Admin Group

Step 1 — Open IAM

Search IAM in the AWS Console

Step 2 — Create a new group

Click User groups → Create group
- BillingConductorAdmins

Step 3 — Attach Billing Conductor IAM Managed Policies

Search for and attach:
- AWSBillingConductorFullAccess
This AWS-managed policy includes:
- billingconductor:*
- Relevant IAM permissions to modify pricing rules, billing groups, pricing plans, etc.
- Full CRUD access for Billing Conductor resources

This is the correct and realistic choice for FinOps/Billing Engineers.

🧠 Quick Summary Table

Feature	AWS Billing	AWS Billing Conductor
Standard monthly bills	✔ Yes	✔ Yes (customized)
Cost Explorer	✔ Yes	❌ No
Budgets	✔ Yes	❌ No
Payment methods	✔ Yes	❌ No
Free-tier usage	✔ Yes	❌ No
Custom pricing/markups	❌ No	✔ Yes
Enterprise multi-account invoicing	❌ No	✔ Yes
Needed for your project?	✔ Yes	❌ No

8. Step 5 — Enforce MFA Using a Service Control Policy (SCP)

What SCPs actually do:

They do NOT block login
They DO block all AWS actions until MFA is used
They apply at the Organizations level

Enforcing MFA at Scale with AWS Organizations (Most Common Modern Method)

Step 1 — Create an AWS Organization

Free
Automatically designates your current account as the management account

Step 2 — Go to “Service Control Policies”

Turn SCPs ON

Step 3 — Create SCP: “Require-MFA-For-All-Actions”

Paste the JSON below.

Step 4 — Attach SCP to the Root OU

This enforces it for ALL accounts.

Step 5 — Test the Behavior

Sign in as a non-MFA user.
Try to open S3 → Access Denied
Try to use CLI → AccessDeniedException

Your MFA Enforcement SCP

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllAPICallsWithoutMFA",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    },
    {
      "Sid": "AllowMFASelfManagement",
      "Effect": "Allow",
      "Action": [
        "iam:ListUsers",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice"
      ],
      "Resource": "*"
    }
  ]
}

Attaching the SCP

You must go to SCP → Targets → Attach
Then select Attach Policy → Root or the account(s) you want to apply the policy.

This is essential for activation.

9. Step 6 — Validate MFA Enforcement

You tested login without MFA:

Expected:

Login succeeds (AWS does not enforce MFA during login)
All actions fail once logged in

This is correct behavior.

10. Step 7 — Configure & Verify CloudTrail

Enable CloudTrail management events:

- 1. Open CloudTrail

AWS Console → search CloudTrail

- 2. Go to “Trails”

Left menu → Trails

- 3. Click “Create Trail”

Choose a Trail name. Example: iam-hardening-trail

Apply trail to all regions: ✔ Yes (recommended)
Management events: ✔ Read/Write
Data events: ❌ Off (not needed for this project)
Insight events: ❌ Off (optional)

- 4. Create (or select) an S3 Bucket

Let AWS auto-create it

Use an existing bucket; Example: cloudtrail-iam-hardening-logs-12345

- 5. Save

Your trail is now active.

Settings used:

Management Events: ON
Read Events: ON
Write Events: ON
No cost for first copy

11. Step 8 — Inspect CloudTrail Logs in S3

You correctly observed:

Logs appear immediately in S3
But object URL access is blocked by design
Even with CloudTrailReadOnly + SecurityAudit, S3 bucket policy must allow object access

12. Step 9 — Generate the IAM Credential Report

Before hardening:

After hardening:

AWS Timing Note

Credential Reports:

Are generated automatically every 4 hours
But can be requested manually
May not update instantly due to eventual consistency

Note: The above images represent user additions only. Users have been removed post project. This is a single account enterprise approach.

Users will need to login and activate / setup MFA

Never expose access keys

Be careful about exposing account info, immediately remove / disable accounts after testing

13. Step 10 — Before/After Hardening Comparison

You now have:

No unused access keys
MFA enabled
Strong password policies
SCP enforcing MFA
Billing access restricted
CloudTrail logging everything
Credential Report shows secure posture

Note: Your results may be different. I have existing test / project accounts.

14. Optional — Billing Conductor Overview

Billing Conductor is used to:

Group accounts for billing
Apply discounts/markups
Model finance departments

You tested pricing rule creation:

15. Troubleshooting Guide

❗ CloudTrail logs visible but cannot open object URL

Expected. Bucket policy blocks access.

❗ SCP attached but login not requiring MFA

Correct. SCP works at API level, not login.

❗ Credential report missing new users

Wait 5–20 minutes or re-request.

16. Cleanup to Avoid Costs

Delete CloudTrail trail
Delete S3 log bucket
Delete Billing Conductor rules
Remove test IAM users
Remove SCP
Remove MFA from test users
Remove IAM groups you created

17.🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn

🕵️‍♀️ Nmap & Scapy on Kali: A Beginner-Friendly Packet Adventure

LaTerral Williams — Thu, 11 Dec 2025 11:01:31 +0000

This guide walks through the Nmap and Scapy labs I completed as part of a cybersecurity class.

Lab context:

Kali Linux OVA on VirtualBox, using a class lab network range (e.g. 10.6.6.0/24).

Tools: Nmap, Scapy, tcpdump, Wireshark, and a bit of SMB.

I’ll show:

The exact commands I ran
What each option means (beginner-friendly)
How to capture and inspect traffic
How this maps to real-world security work

I’ll also include a snippet for if you want to consider a GitHub repo later.

🛑 Ethics & Safety Reminder

Only scan networks and systems you own or have explicit permission to test.

Everything here is done inside a controlled class lab environment.

📚 Table of Contents

Introduction
Lab Setup Overview
Quick Tool Overview
Part 1 – Nmap Lab
- 4.1 Host Discovery with -sn
- 4.2 OS Detection with -O
- 4.3 Service Detection & Aggressive Scan
- 4.4 SMB Enumeration (Ports 139 & 445)
- 4.5 Capturing Scan Traffic with tcpdump + Wireshark
Part 2 – Scapy Lab
- 5.1 Starting Scapy the Right Way
- 5.2 First Sniff: Watching a Ping to Google
- 5.3 Using Variables (paro) and .summary()
- 5.4 Sniffing Lab Traffic on br-internal
- 5.5 ICMP-Only Sniff with Filters and Counts
- 5.6 Inspecting Individual Packets & Fields
Troubleshooting & Common Gotchas
How This Maps to Real-World Security Work
How I’ll Structure the GitHub Repo
Final Reflections

1. Introduction

In this lab, I used Kali Linux on VirtualBox to:

Discover hosts on a lab subnet
Probe a specific target (10.6.6.23) with Nmap
Enumerate SMB shares
Capture traffic with tcpdump and open it in Wireshark
Use Scapy to sniff, store, and inspect packets (including ICMP and HTTP-like traffic)

If you’re new to Nmap and Scapy:

Think of Nmap as a network scanner (who’s online, what ports, what services).
Think of Scapy as Python-powered packet LEGO – you can sniff, dissect, and even craft packets.

2. Lab Setup Overview

Environment:

Host: Your regular OS (Windows / macOS / Linux)
VM: Kali Linux OVA imported into VirtualBox
Network: Class lab network (example: 10.6.6.0/24)
Target system: 10.6.6.23 (lab host with SMB services)

📝 Document your VM networking mode (NAT, Bridged, Internal Network). My lab environment used an internal bridge named br-internal.

Note: It is important that your VM has network access for some of the testing to work.

3. Quick Tool Overview

Tools used in this assignment:

Nmap – Port scanning, OS detection, service identification, SMB enumeration
smbclient – Connect to SMB shares
tcpdump – Capture packets into .pcap
Wireshark – GUI packet analysis
Scapy – Python-based packet crafting/sniffing toolkit

4. Part 1 - Nmap Lab

Commands used:

nmap -sn 10.6.6.0/24
sudo nmap -O 10.6.6.23
nmap -p21 -sV -A -T4 10.6.6.23
nmap -A -p139,445 10.6.6.23
nmap --script smb-enum-shares.nse -p445 10.6.6.23
smbclient //10.6.6.23/print$ -N
ifconfig
ip route
cat /etc/resolv.conf
sudo tcpdump -i eth0 -s 0 -w packetcapture.pcap
ls packetcapture.pcap
wireshark

4.1 Host Discovery with `-sn`

nmap -sn 10.6.6.0/24

What it does:

Performs a ping scan across the /24 network to identify active hosts.

Why it matters:

You always start by identifying what is alive before deeper scans.

┌──(kali㉿Kali)-[~]
└─$ nmap -sn 10.6.6.0/24
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-10 01:36 UTC
Nmap scan report for 10.6.6.1
Host is up (0.00019s latency).
Nmap scan report for webgoat.vm (10.6.6.11)
Host is up (0.00017s latency).
Nmap scan report for juice-shop.vm (10.6.6.12)
Host is up (0.00013s latency).
Nmap scan report for dvwa.vm (10.6.6.13)
Host is up (0.000074s latency).
Nmap scan report for mutillidae.vm (10.6.6.14)
Host is up (0.000035s latency).
Nmap scan report for gravemind.vm (10.6.6.23)
Host is up (0.00027s latency).
Nmap scan report for 10.6.6.100
Host is up (0.000049s latency).
Nmap done: 256 IP addresses (7 hosts up) scanned in 6.31 seconds

4.2 OS Detection with `-O`

sudo nmap -O 10.6.6.23

Uses TCP/IP fingerprinting to guess the remote OS.

Root is required because raw packets are used.

┌──(kali㉿Kali)-[~]
└─$ sudo nmap -O 10.6.6.23
[sudo] password for kali: 
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-10 01:39 UTC
Nmap scan report for gravemind.vm (10.6.6.23)
Host is up (0.000037s latency).
Not shown: 994 closed tcp ports (reset)
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
53/tcp  open  domain
80/tcp  open  http
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
MAC Address: 02:42:0A:06:06:17 (Unknown)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94%E=4%D=12/10%OT=21%CT=1%CU=38430%PV=Y%DS=1%DC=D%G=Y%M=02420A%
OS:TM=6938CF53%P=x86_64-pc-linux-gnu)SEQ(SP=FA%GCD=1%ISR=FF%TI=Z%CI=Z%II=I%
OS:TS=A)OPS(O1=M5B4ST11NW7%O2=M5B4ST11NW7%O3=M5B4NNT11NW7%O4=M5B4ST11NW7%O5
OS:=M5B4ST11NW7%O6=M5B4ST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=
OS:FE88)ECN(R=Y%DF=Y%T=40%W=FAF0%O=M5B4NNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%                                                                                     
OS:A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0                                                                                     
OS:%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S                                                                                     
OS:=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R                                                                                     
OS:=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N                                                                                     
OS:%T=40%CD=S)                                                                                                                                                  

Network Distance: 1 hop                                                                                                                                         

OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .                                                                       
Nmap done: 1 IP address (1 host up) scanned in 11.39 seconds

4.3 Service Detection & Aggressive Scan

nmap -p21 -sV -A -T4 10.6.6.23

Breakdown:

-p21 → Scan only port 21 (FTP)
-sV → Service/version detection
-A → Aggressive mode (OS detect, versioning, scripts, traceroute)
-T4 → Faster scans

┌──(kali㉿Kali)-[~]
└─$ nmap -p21 -sV -A -T4 10.6.6.23
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-10 01:41 UTC
Nmap scan report for gravemind.vm (10.6.6.23)
Host is up (0.000092s latency).

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| -rw-r--r--    1 0        0              16 Aug 13  2021 file1.txt
| -rw-r--r--    1 0        0              16 Aug 13  2021 file2.txt
| -rw-r--r--    1 0        0              29 Aug 13  2021 file3.txt
|_-rw-r--r--    1 0        0              26 Aug 13  2021 supersecretfile.txt
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 10.6.6.1
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 3
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
Service Info: OS: Unix

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds

4.4 SMB Enumeration (Ports 139 & 445)

SMB enumeration is the process of querying a target system or network for information related to the Server Message Block (SMB) protocol.

Scan SMB ports:

nmap -A -p139,445 10.6.6.23

┌──(kali㉿Kali)-[~]
└─$ nmap -A -p139,445 10.6.6.23
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-10 01:48 UTC
Nmap scan report for gravemind.vm (10.6.6.23)
Host is up (0.000090s latency).

PORT    STATE SERVICE     VERSION
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open  netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
Service Info: Host: GRAVEMIND

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.9.5-Debian)
|   Computer name: gravemind
|   NetBIOS computer name: GRAVEMIND\x00
|   Domain name: \x00
|   FQDN: gravemind
|_  System time: 2025-12-10T01:48:34+00:00
| smb2-time: 
|   date: 2025-12-10T01:48:33
|_  start_date: N/A
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.18 seconds

Enumerate shares:

nmap --script smb-enum-shares.nse -p445 10.6.6.23

Command Breakdown:

nmap: The network scanner tool.
--script smb-enum-shares.nse: Tells Nmap to use the specific Nmap Scripting Engine (NSE) script designed to enumerate SMB shares.
-p445: Restricts the scan to TCP port 445, the common port for SMB traffic.
10.6.6.23: The IP address of the target machine.

┌──(kali㉿Kali)-[~]
└─$ nmap --script smb-enum-shares.nse -p445 10.6.6.23
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-10 01:50 UTC
Nmap scan report for gravemind.vm (10.6.6.23)
Host is up (0.00032s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds

Host script results:
| smb-enum-shares: 
|   account_used: <blank>
|   \\10.6.6.23\IPC$: 
|     Type: STYPE_IPC_HIDDEN
|     Comment: IPC Service (Samba 4.9.5-Debian)
|     Users: 1
|     Max Users: <unlimited>
|     Path: C:\tmp
|     Anonymous access: READ/WRITE
|   \\10.6.6.23\print$: 
|     Type: STYPE_DISKTREE
|     Comment: Printer Drivers
|     Users: 0
|     Max Users: <unlimited>
|     Path: C:\var\lib\samba\printers
|     Anonymous access: READ/WRITE
|   \\10.6.6.23\workfiles: 
|     Type: STYPE_DISKTREE
|     Comment: Confidential Workfiles
|     Users: 0
|     Max Users: <unlimited>
|     Path: C:\var\spool\samba
|_    Anonymous access: READ/WRITE

Nmap done: 1 IP address (1 host up) scanned in 7.31 seconds

Connect manually:

smbclient //10.6.6.23/print$ -N

Command Breakdown:

Component	Meaning	Purpose
`smbclient`	SMB/CIFS client tool	Connect to Windows-style shared folders
`//10.6.6.23`	Server IP	Where the SMB service is hosted
`/print$`	Share name (hidden)	Printer admin share on the target
`-N`	No password prompt	Anonymous login attempt

┌──(kali㉿Kali)-[~]
└─$ smbclient //10.6.6.23/print$ -N                                                                                                                             
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \>

Exit with:

exit

4.5 Capture Traffic with `tcpdump` + Wireshark

Check network settings:

ifconfig
ip route
cat /etc/resolv.conf

└─$ ifconfig
br-internal: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.6.6.1  netmask 255.255.255.0  broadcast 10.6.6.255
        inet6 fe80::42:b1ff:feae:eb4f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:b1:ae:eb:4f  txqueuelen 0  (Ethernet)
        RX packets 1565  bytes 99196 (96.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2534  bytes 168594 (164.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

┌──(kali㉿Kali)-[~]
└─$ ip route                                                                                                                                                    
default via 10.0.2.2 dev eth0 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100 
10.5.5.0/24 dev br-339414195aeb proto kernel scope link src 10.5.5.1 
10.6.6.0/24 dev br-internal proto kernel scope link src 10.6.6.1 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.0.0/24 dev br-355ee7945a88 proto kernel scope link src 192.168.0.1

┌──(kali㉿Kali)-[~]
└─$ cat /etc/resolv.conf                                                                                                                                        
# Generated by NetworkManager
nameserver 172.16.0.1

Capture packets:

sudo tcpdump -i eth0 -s 0 -w packetcapture.pcap

Command Breakdown:

Flag / Component	Meaning	Purpose
`sudo`	Run as root	Required for packet capture
`tcpdump`	Packet capture tool	Similar to Wireshark CLI
`-i eth0`	Interface selection	Capture only from eth0
`-s 0`	Snapshot length	Capture full packets
`-w packetcapture.pcap`	Write to file	Save packets for later analysis

┌──(kali㉿Kali)-[~]
└─$ sudo tcpdump -i eth0 -s 0 -w packetcapture.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C38 packets captured
38 packets received by filter
0 packets dropped by kernel

Note: You will need to create traffic in a second terminal.

┌──(kali㉿Kali)-[~]
└─$ ping google.com
PING google.com (64.233.177.138) 56(84) bytes of data.
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=1 ttl=255 time=21.1 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=2 ttl=255 time=21.2 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=3 ttl=255 time=21.4 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=4 ttl=255 time=21.4 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=5 ttl=255 time=21.6 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=6 ttl=255 time=21.9 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=7 ttl=255 time=21.7 ms
64 bytes from yx-in-f138.1e100.net (64.233.177.138): icmp_seq=8 ttl=255 time=21.8 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 21.129/21.518/21.916/0.276 ms

Ctrl + C in both terminals to stop capture.

Open in Wireshark:

wireshark <yourpcapfilename>.pcap

5. Part 2 – Scapy Lab

Commands used:

sudo su
scapy
sniff()
# new terminal
ping google.com

paro = _
paro.summary()

sniff(iface="br-internal")
ping 10.6.6.1

paro2 = _
paro2.summary()

sniff(iface="br-internal", filter="icmp", count=5)
ping 10.6.6.23

paro3 = _
paro3.summary()
paro3[3]

5.1 Starting Scapy

sudo su
scapy

Scapy opens an interactive Python shell for packet manipulation.

┌──(root㉿Kali)-[/home/kali]
└─# scapy
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().

                     aSPY//YASa       
             apyyyyCY//////////YCa       |
            sY//////YSpcs  scpCY//Pp     | Welcome to Scapy
 ayp ayyyyyyySCP//Pp           syY//C    | Version 2.5.0
 AYAsAYYYYYYYY///Ps              cY//S   |
         pCCCCY//p          cSSps y//Y   | https://github.com/secdev/scapy
         SPPPP///a          pP///AC//Y   |
              A//A            cyP////C   | Have fun!
              p///Ac            sC///a   |
              P////YCpc           A//A   | Craft packets like it is your last
       scccccp///pSP///p          p//Y   | day on earth.
      sY/////////y  caa           S//P   |                      -- Lao-Tze
       cayCyayP//Ya              pY/Ya   |
        sY/PsY////YCc          aC//Yp 
         sc  sccaCY//PCypaapyCP//YSs  
                  spCPY//////YPSps    
                       ccaacs         
                                       using IPython 8.14.0
>>>

5.2 First Sniff: Watching a Ping to Google

Inside Scapy:

sniff()

>>> sniff()
^C<Sniffed: TCP:0 UDP:16 ICMP:12 Other:2>
>>>

New terminal:

ping google.com

┌──(kali㉿Kali)-[~]
└─$ ping google.com
PING google.com (64.233.177.101) 56(84) bytes of data.
64 bytes from yx-in-f101.1e100.net (64.233.177.101): icmp_seq=1 ttl=255 time=22.0 ms
64 bytes from yx-in-f101.1e100.net (64.233.177.101): icmp_seq=2 ttl=255 time=21.9 ms
64 bytes from yx-in-f101.1e100.net (64.233.177.101): icmp_seq=3 ttl=255 time=22.0 ms
64 bytes from yx-in-f101.1e100.net (64.233.177.101): icmp_seq=4 ttl=255 time=21.9 ms
64 bytes from yx-in-f101.1e100.net (64.233.177.101): icmp_seq=5 ttl=255 time=21.6 ms
64 bytes from yx-in-f101.1e100.net (64.233.177.101): icmp_seq=6 ttl=255 time=22.0 ms
^C
--- google.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 21.641/21.896/22.043/0.127 ms

Stop both with Ctrl + C.

5.3 Using Variables and `.summary()`

paro = _
paro.summary()

_ holds the last Scapy result. This prints a one‑line summary of all packets.

>>> paro=_
>>> paro.summary()
Ether / IP / UDP / DNS Qry "b'google.com.'" 
Ether / IP / UDP / DNS Qry "b'google.com.'" 
Ether / IP / UDP / DNS Ans "2607:f8b0:4002:c08::71" 
Ether / IP / UDP / DNS Ans "64.233.177.101" 
Ether / IP / ICMP 10.0.2.15 > 64.233.177.101 echo-request 0 / Raw
Ether / IP / ICMP 64.233.177.101 > 10.0.2.15 echo-reply 0 / Raw
Ether / IP / UDP / DNS Qry "b'101.177.233.64.in-addr.arpa.'" 
Ether / IP / UDP / DNS Ans "b'yx-in-f101.1e100.net.'" 
Ether / IP / ICMP 10.0.2.15 > 64.233.177.101 echo-request 0 / Raw
Ether / IP / ICMP 64.233.177.101 > 10.0.2.15 echo-reply 0 / Raw
Ether / IP / UDP / DNS Qry "b'101.177.233.64.in-addr.arpa.'" 
Ether / IP / UDP / DNS Ans "b'yx-in-f101.1e100.net.'" 
Ether / IP / ICMP 10.0.2.15 > 64.233.177.101 echo-request 0 / Raw
Ether / IP / ICMP 64.233.177.101 > 10.0.2.15 echo-reply 0 / Raw
Ether / IP / UDP / DNS Qry "b'101.177.233.64.in-addr.arpa.'" 
Ether / IP / UDP / DNS Ans "b'yx-in-f101.1e100.net.'" 
Ether / IP / ICMP 10.0.2.15 > 64.233.177.101 echo-request 0 / Raw
Ether / IP / ICMP 64.233.177.101 > 10.0.2.15 echo-reply 0 / Raw
Ether / IP / UDP / DNS Qry "b'101.177.233.64.in-addr.arpa.'" 
Ether / IP / UDP / DNS Ans "b'yx-in-f101.1e100.net.'" 
Ether / IP / ICMP 10.0.2.15 > 64.233.177.101 echo-request 0 / Raw
Ether / IP / ICMP 64.233.177.101 > 10.0.2.15 echo-reply 0 / Raw
Ether / IP / UDP / DNS Qry "b'101.177.233.64.in-addr.arpa.'" 
Ether / IP / UDP / DNS Ans "b'yx-in-f101.1e100.net.'" 
Ether / IP / ICMP 10.0.2.15 > 64.233.177.101 echo-request 0 / Raw
Ether / IP / ICMP 64.233.177.101 > 10.0.2.15 echo-reply 0 / Raw
Ether / IP / UDP / DNS Qry "b'101.177.233.64.in-addr.arpa.'" 
Ether / IP / UDP / DNS Ans "b'yx-in-f101.1e100.net.'" 
Ether / ARP who has 10.0.2.2 says 10.0.2.15
Ether / ARP is at 52:55:0a:00:02:02 says 10.0.2.2 / Padding

5.4 Sniffing on `br-internal`

sniff(iface="br-internal")

Generate traffic:

ping 10.6.6.1

Save results:

paro2 = _
paro2.summary()

Note: Here you may have noticed no traffic was captured. This is my assumption: This is a lab envionment to mimic real-world environments.

In many lab or corporate networks:

.1 is the default gateway

It may be configured to drop or ignore ping (ICMP) for security.

5.5 ICMP-Only Sniff with Filter + Count

sniff(iface="br-internal", filter="icmp", count=5)

Generate ICMP traffic:

ping 10.6.6.23

Due to count set only the first 5 packets were captured.

┌──(kali㉿Kali)-[~]
└─$ ping 10.6.6.23
PING 10.6.6.23 (10.6.6.23) 56(84) bytes of data.
64 bytes from 10.6.6.23: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 10.6.6.23: icmp_seq=2 ttl=64 time=0.035 ms
64 bytes from 10.6.6.23: icmp_seq=3 ttl=64 time=0.034 ms
64 bytes from 10.6.6.23: icmp_seq=4 ttl=64 time=0.029 ms
64 bytes from 10.6.6.23: icmp_seq=5 ttl=64 time=0.030 ms
64 bytes from 10.6.6.23: icmp_seq=6 ttl=64 time=0.018 ms
64 bytes from 10.6.6.23: icmp_seq=7 ttl=64 time=0.028 ms
^C
--- 10.6.6.23 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6144ms
rtt min/avg/max/mdev = 0.018/0.030/0.041/0.006 ms

5.6 Inspecting Packet Fields

paro3 = _
paro3.summary()
paro3[3]

<Sniffed: TCP:0 UDP:0 ICMP:5 Other:0>
>>> paro3=_
>>> paro3.summary()
Ether / IP / ICMP 10.6.6.1 > 10.6.6.23 echo-request 0 / Raw
Ether / IP / ICMP 10.6.6.23 > 10.6.6.1 echo-reply 0 / Raw
Ether / IP / ICMP 10.6.6.1 > 10.6.6.23 echo-request 0 / Raw
Ether / IP / ICMP 10.6.6.23 > 10.6.6.1 echo-reply 0 / Raw
Ether / IP / ICMP 10.6.6.1 > 10.6.6.23 echo-request 0 / Raw

Full details:

paro3[3].show()

Shows details for the third entry in the summary list.

>>> paro3[3].show()
###[ Ethernet ]### 
  dst       = 02:42:b1:ae:eb:4f
  src       = 02:42:0a:06:06:17
  type      = IPv4
###[ IP ]### 
     version   = 4
     ihl       = 5
     tos       = 0x0
     len       = 84
     id        = 2449
     flags     = 
     frag      = 0
     ttl       = 64
     proto     = icmp
     chksum    = 0x50f5
     src       = 10.6.6.23
     dst       = 10.6.6.1
     \options   \
###[ ICMP ]### 
        type      = echo-reply
        code      = 0
        chksum    = 0x56f3
        id        = 0xb2ed
        seq       = 0x2
        unused    = ''
###[ Raw ]### 
           load      = 'n\\xde8i\x00\x00\x00\x00\\x87\x02\t\x00\x00\x00\x00\x00\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./01234567'

6. Troubleshooting

Common issues:

No packets captured

Verify interface: ifconfig
Use correct iface in Scapy

Nmap OS detection fails

Firewalls may block probes
OS detection is best-effort

tcpdump permission denied

Use sudo.

Wireshark shows nothing useful

Apply filters:

icmp
smb
ip.addr == 10.6.6.23

7. Real-World Applications

These labs build skills used in:

Asset discovery & attack surface mapping
Vulnerability assessments
Incident response (packet capture)
Forensics
Custom IDS/IPS development (Scapy)

8. GitHub Repo Structure - Example

nmap-scapy-lab/
├── README.md
├── nmap/
│   ├── nmap-host-discovery.md
│   ├── nmap-smb-enum.md
│   └── images/
│       ├── 01-nmap-host-discovery.png
│       └── 02-smb-enum.png
└── scapy/
    ├── scapy-sniffing.md
    ├── scapy-icmp-analysis.md
    └── images/
        ├── 01-scapy-summary.png
        └── 02-scapy-show.png

9. Final Reflections

This lab helped me:

Understand Nmap flags and scan behavior
Capture and analyze real traffic with tcpdump/Wireshark
Use Scapy to dissect packet fields in detail

Happy scanning responsibly! 🕵️‍♂️📡

🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn