AWS Cloud Security Engineering Project

Stopping Attacks and Reducing
Cloud Misconfiguration

Built by Ebenezer Takpor at Phylax Cyber

How I built an AWS environment that blocks malicious traffic, detects risky configuration changes, remediates them automatically, and verifies compliance afterward.

What happens after deployment, when traffic turns hostile or someone makes a dangerous configuration mistake?

This project explores both sides of cloud security: stopping bad traffic before it reaches the application and reducing configuration drift inside the environment.

● AWS PROJECT CASE STUDY
See What HappenedNew to Cloud Security?
The Setup

Before protecting the server, I made it harder to reach.

The Nginx web server runs on an Amazon EC2 instance inside a private subnet. It has no public IPv4 address.

All public traffic enters through an Application Load Balancer and passes AWS WAF before reaching the application.

Internet Visitor↓Application Load Balancer↓AWS WAF↓Private EC2 / Nginx
Reduce exposure first.The backend is not directly reachable from the internet. Public application traffic has a defined entry point.
Attack Prevention

First, I attacked my own website.

I sent the live application a request designed to resemble a cross-site scripting attack.

AWS WAF stopped the request before it reached Nginx.

Test Result
HTTP/2 403 Forbidden
Rule: CrossSiteScripting_QUERYARGUMENTS
Evidence #1BLOCKED
AWS WAF sampled request showing the XSS-style request blocked
AWS WAF rejected the XSS-style request before it reached the private application server. Source IP has been redacted.
Configuration Drift

Attackers are not the only source of risk.

Cloud environments change constantly. A legitimate administrative change can produce an unsafe state.

I deliberately created one of the classic dangerous configurations: unrestricted SSH.

Misconfiguration Introduced
SSH
TCP Port 22
Source: 0.0.0.0/0
What does 0.0.0.0/0 mean?For this test it meant that any internet source could attempt to reach TCP/22.

AWS Config continuously evaluated the environment and marked the resource NON_COMPLIANT.

Evidence #2NON-COMPLIANT
AWS Config showing restricted-ssh noncompliant
AWS Config independently detected the public SSH exposure.
Automated Remediation

Detection was only half the problem.

CloudTrail recorded the security-group API activity. EventBridge matched the change and invoked a Lambda remediation function.

Step 1

Security group changed

Public SSH access was added.

Step 2

CloudTrail recorded the API call

The control-plane change became auditable evidence.

Step 3

EventBridge matched the event

The AuthorizeSecurityGroupIngress event entered the response path.

Step 4

Lambda evaluated the change

The function checked the resource opt-in tag, TCP/22, and source 0.0.0.0/0.

Step 5

The unsafe rule was removed

Lambda revoked the unrestricted SSH ingress rule.

Step 6

The operator was notified

SNS sent the incident details and remediation status.

The rule disappeared without manual deletion.The remediation workflow removed the public SSH exposure automatically.
Evidence #3REMEDIATED
SNS remediation email with sensitive values redacted
SNS confirmed that the public SSH rule had been revoked. Resource identifiers, account information and source IP are redacted.
Guardrails

I did not let Lambda touch everything.

Automatic remediation can create its own blast radius. A resource must explicitly opt into this workflow.

AutoRemediatePublicSSH = true
Automation needs boundaries.The tag creates an explicit remediation scope instead of giving the function permission to modify every matching resource indiscriminately.
Verification

Fixing the problem was not enough. I wanted proof.

Before Remediation

1 NON_COMPLIANT resource

After Remediation

0 NON_COMPLIANT resources

Misconfiguration↓Detection↓Decision↓Automatic Remediation↓Alert↓Compliance Restored
Evidence #4COMPLIANT
AWS Config showing compliance restored
AWS Config independently confirmed that the dangerous configuration no longer existed.
Management Plane

Removing the NAT Gateway exposed a hidden dependency.

After I removed the NAT Gateway to reduce unnecessary ongoing cost, the website stayed online but Systems Manager stopped working.

Instead of restoring broad internet egress, I added private VPC interface endpoints for Systems Manager.

Private EC2↓HTTPS 443↓Private SSM Endpoint↓AWS Systems Manager
Evidence #5PRIVATE MANAGEMENT
AWS Systems Manager private VPC interface endpoint
Private interface endpoint used to restore Session Manager connectivity without opening inbound SSH.
Control Responsibilities

Each service had a specific job.

AWS ServiceRole in the project
Application Load BalancerPublic application entry point
AWS WAFWeb-request enforcement
CloudTrailControl-plane audit trail
AWS ConfigIndependent compliance evaluation
EventBridgeEvent routing into the response workflow
LambdaBounded automated remediation
SNSOperator notification
GuardDutyThreat-pattern detection
Security HubCentralized security posture and findings
Systems ManagerPrivate administrative access
What I Learned

Cloud security is less about enabling tools and more about connecting controls.

A risky change became an auditable event. The event became a decision. The decision became an action. The action became an alert. Another control then verified that the unsafe state was gone.

Signal↓Decision↓Action↓Notification↓Independent Verification