ghaymah-exam-yamin_zeadneh-SecOps/Attack_Simulation/README.md

Time	Event
09:40	Unusual volume of POST requests to /api/login detected from a single IP.
09:42	Failed login attempts exceed 300 within one minute.
09:44	No rate limiting or temporary IP blocking was triggered.
09:46	One login attempt succeeds using a password from a common wordlist (e.g., rockyou.txt).
09:47	The server issues a valid JWT for the compromised account.
09:49	The attacker uses the JWT to access /api/users/me.
09:51	The attacker begins probing undocumented API endpoints (shadow APIs).
09:54	Sensitive data is exfiltrated through repeated API requests.
09:58	The SOC team detects the incident through a SIEM alert triggered by an abnormal spike in HTTP 401 responses.

Incident Response Plan

1. Identification

• Review API, application, and authentication logs.
• Identify the source IP addresses responsible for the brute force attack.
• Determine which user accounts were compromised.
• Analyze the scope of the data accessed or exfiltrated.
• Correlate events using the SIEM to establish the attack timeline.

2. Containment

• Block the attacker's IP address using the firewall or Web Application Firewall (WAF).
• Temporarily disable the compromised user account.
• Revoke all active JWT access tokens and terminate existing sessions.
• Enable temporary rate limiting on the /api/login endpoint.
• Isolate affected containers if compromise is suspected.

3. Eradication

• Reset passwords for affected accounts.
• Remove any malicious processes or unauthorized changes.
• Patch the authentication service to enforce rate limiting and account lockout.
• Verify container images for integrity and rebuild compromised containers from trusted images.
• Scan systems for indicators of compromise (IOCs).

4. Recovery

• Restore normal service after confirming the environment is secure.
• Re-enable affected user accounts with new credentials.
• Continue monitoring logs for suspicious authentication attempts.
• Validate that security controls (MFA, rate limiting, monitoring) are functioning correctly.

Preventing the Attack on Ghaymah

1. Network Policies

• Apply Rate Limiting on the /api/login endpoint to limit the number of login attempts from a single IP address.
• Configure Kubernetes Network Policies so that only the API service can communicate with the PostgreSQL database.
• Deploy a Web Application Firewall (WAF) to filter malicious requests and block brute force attacks.
• Restrict access to internal services by allowing traffic only from trusted containers and namespaces.
• Enable automatic IP blocking after multiple failed authentication attempts.
• Encrypt all communication using HTTPS/TLS to protect authentication traffic.

2. Container Security

• Run containers as non-root users to minimize the impact of a container compromise.
• Use trusted and regularly updated base images to reduce known vulnerabilities.
• Store passwords, API keys, and JWT secrets in Kubernetes Secrets or a secure secret manager instead of environment variables or Docker images.
• Continuously scan container images with tools such as Trivy before deployment.
• Apply the Principle of Least Privilege by granting containers only the permissions they require.
• Enable centralized logging and monitoring for all containers to quickly detect suspicious authentication activity.

Alert Rule (Splunk SPL)

normally request look something like

{
  "timestamp": "2026-07-27T09:42:11Z",
  "src_ip": "192.168.1.50",
  "endpoint": "/api/login",
  "method": "POST",
  "status": 401,
  "username": "admin",
  "user_agent": "Mozilla/5.0"
}

so we can make SPL code like

index=api_logs endpoint="/api/login" status=401
| bucket span=1m _time
| stats count by src_ip, _time
| where count >= 20

Alert Condition

• Trigger when a single IP generates 20 or more failed login attempts within 1 minute.
• Alert severity: High.
• Send an email notification to the SOC team.
• Automatically block the source IP for 15 minutes using the firewall or WAF.