3.9 KiB
Task2:
Attack Scenario An attacker successfully performed a brute-force attack against the application's login API hosted on Ghaymah Cloud. After compromising a valid user account, the attacker accessed sensitive customer data and exfiltrated part of the database.
Attack Flow
Internet ↓ Recon ↓ API Discovery ↓ Brute Force ↓ Successful Login ↓ Data Access ↓ Data Exfiltration ↓ Cleanup
Root Cause Analysis The attack succeeded because: • No Rate Limiting on the login endpoint. • Weak user password. • No Multi-Factor Authentication (MFA). • Insufficient monitoring of repeated failed logins. • Missing Web Application Firewall (WAF) protections. 2. Incident Response Plan Phase 1 – Identification Objectives: • Confirm the brute-force attack. • Identify affected user accounts. • Determine compromised resources. • Preserve forensic evidence. Actions: • Review application logs. • Analyze firewall logs. • Check authentication logs. • Identify suspicious IP addresses.
Phase 2 – Containment Immediate actions: • Disable compromised accounts. • Block malicious IP addresses. • Enable emergency rate limiting. • Rotate exposed API tokens. • Isolate affected application containers if necessary.
Phase 3 – Eradication Remove the root cause. Tasks: • Force password reset. • Patch authentication vulnerabilities. • Remove malicious scripts. • Update security configurations. • Scan containers using Trivy.
Phase 4 – Recovery Actions: • Restore clean services. • Monitor user authentication. • Validate system integrity. • Notify affected customers. • Resume production gradually.
Phase 5 – Lessons Learned Conduct a post-incident review. Questions: • Why did monitoring fail? • Why wasn't MFA enabled? • Why were brute-force attempts not detected? • Which controls should be added?
-
Preventing the Attack on Ghaymah Cloud Network Security Controls API Rate Limiting E.G. Maximum 5 login attempts per minute/per IP
Web Application Firewall (WAF) Configure rules to: • Detect brute-force attacks. • Block suspicious IP addresses. • Prevent SQL Injection. • Prevent XSS. Firewall Rules Only expose => HTTPS (443) Restrict: • SSH • Database ports • Internal services Network Segmentation Application ↓ Private Network ↓ Database The database should never be directly accessible from the Internet.
Container Security Controls • Scan every Docker image before deployment. • Run containers as non-root users. • Store secrets securely. • Use read-only file systems when possible. • Apply least privilege to Kubernetes service accounts. • Continuously monitor container runtime activity.
- Alert Rule for Early Detection Detection Logic Trigger an alert if: More than 10 failed logins from the same IP within 60 seconds.
Additional Detection Rules Alert when: • Login attempts originate from multiple countries in a short time. • One account receives failed logins from multiple IPs. • Sudden spike in authentication failures. • API requests exceed expected thresholds.
Recommendations • Enable MFA for all users. • Implement account lockout after repeated failures. • Deploy a Web Application Firewall. • Use centralized logging with SIEM. • Perform continuous container vulnerability scanning. • Conduct regular penetration testing.