ghaymah-exam-Mohamed-Ashraf-Helmi-SecOps/q2-Red-Blue-IR-Simullation/Ghaymah_Brute_Force_IR_Exercise.md

Simulated Incident Response Exercise

Brute-Force Attack → Login API → Data Breach (Ghaymah Cloud)

Scenario disclaimer: This is a hypothetical, simulated exercise written for exam/training purposes. It does not claim that an actual breach occurred at Ghaymah — it's a realistic case study built on Ghaymah's publicly known architecture (Git-push container deployment, managed Kubernetes, managed PostgreSQL, a customer-facing Login API/dashboard) as identified in Part 1 of this audit.

---

PART 1 — Step-by-Step Attack Analysis

Mapped loosely to the Cyber Kill Chain and MITRE ATT&CK, so each step has a defensive framework you can cite in your exam.

Step	What Happens	ATT&CK Technique
1. Reconnaissance	Attacker identifies the Login API endpoint (e.g. via the dashboard's client-side JS bundle, API docs, or simply deploy.ghaymah.systems/login) and fingerprints response behavior — does it return different errors for "user not found" vs "wrong password"? Does it rate-limit?	T1595 – Active Scanning
2. Credential Sourcing	Attacker uses either (a) a common-password/dictionary list (classic brute force), or (b) a leaked-credential list from unrelated past breaches (credential stuffing — more realistic and dangerous, since it exploits password reuse rather than weak passwords)	T1110.004 – Credential Stuffing
3. Execution / Delivery	Automated tooling submits authentication requests at scale, rotating through a proxy/residential-IP pool or botnet specifically to evade simple per-IP rate limiting	T1110 – Brute Force
4. Detection Gap (root cause)	The Login API has no effective rate limiting, no account lockout, no CAPTCHA challenge, and no anomaly alerting on failed-login volume — this is the actual vulnerability, not the attacker's sophistication	—
5. Initial Access	One or more valid credential pairs succeed. Attacker receives a valid session token / JWT	T1078 – Valid Accounts
6. Discovery	Using the legitimate session, attacker enumerates what the compromised account can reach: deployed apps, environment variables/secrets, connected managed database, container registry, API keys/CLI tokens	T1087 / T1526 – Account & Cloud Service Discovery
7. Collection & Exfiltration	Attacker downloads environment variables (which commonly hold DB credentials, third-party API keys), or directly queries the connected managed PostgreSQL instance, and exfiltrates the data out over normal HTTPS (blends into legitimate traffic)	T1552 – Unsecured Credentials; T1567 – Exfiltration Over Web Service
8. Impact	Confidentiality breach of customer data; potential secondary compromise if exfiltrated API keys/DB credentials are reused elsewhere; reputational and (if PII involved) regulatory impact	—

Key takeaway for the analysis section: the breach didn't require a sophisticated exploit — it required the absence of three basic controls: rate limiting, lockout/backoff, and detection. That's the through-line into the rest of this exercise.

---

PART 2 — Incident Response Plan

Structured on the NIST SP 800-61 lifecycle (Preparation → Detection & Analysis → Containment → Eradication → Recovery → Post-Incident Activity), scoped to this specific scenario.

2.1 Preparation (what should already exist before this happens)

• A named Incident Response team with clear roles: Incident Commander, Security Analyst (Investigation), Engineering Lead (Containment), Communications/Legal (customer & regulatory notification)
• Centralized authentication logs (failed + successful logins, source IP, user-agent, timestamps) retained and searchable
• A pre-approved playbook for "credential compromise" so responders aren't improvising during the incident
• Pre-established communication channels (on-call paging, incident Slack/War-room channel)

2.2 Detection & Analysis

1. Alert fires (see Part 4 rule design) — e.g. "50+ failed logins for account X across 6 IPs in 10 minutes, followed by a successful login."
2. Analyst triages: confirm it's not a false positive (e.g. legitimate user with a broken password manager).
3. Determine scope: which account(s) compromised, what that account could access (apps, DB, secrets, registry), whether data was actually accessed/exfiltrated (check access/query logs, egress volume).
4. Classify severity (e.g. Sev-1 if customer data confirmed exfiltrated; Sev-2 if account compromised but no confirmed data access).

2.3 Containment

Short-term (minutes):

• Force-revoke all active sessions/tokens for the compromised account
• Lock the account and require identity-verified password reset
• Temporarily rate-limit or block the source IP(s)/ranges involved

Longer-term (hours):

• Rotate any secrets/API keys/DB credentials the compromised account had access to (assume anything reachable was seen)
• Review and, if needed, temporarily restrict the Login API more broadly (e.g. tighten rate limits platform-wide) while the root cause is patched

2.4 Eradication

• Confirm no persistence mechanism was planted (e.g. a newly-added API token, SSH key, or webhook the attacker created for continued access) — check the account's audit log of created credentials/tokens during the compromise window, and revoke anything created that the legitimate user didn't authorize
• Patch the actual gap: deploy rate limiting/lockout on the Login API (see Part 3)

2.5 Recovery

• Restore the account to the legitimate user with new credentials + mandatory MFA enrollment
• Monitor the account and related infrastructure closely for a defined period (e.g. 30 days) for signs of reoccurrence
• Gradually lift any emergency-tightened rate limits once confidence in the fix is established

2.6 Post-Incident Activity

• Blameless post-mortem: root cause (missing rate limiting/lockout/alerting), timeline, what worked, what didn't
• Update the IR playbook and detection rules based on lessons learned
• Customer/regulatory notification: if this were real and PII was exposed, this is where Ghaymah's stated "prompt notification" commitment (from their /security page) would be executed — legal/comms determines notification obligations based on applicable law (e.g. GDPR-style breach notification timelines if EU data subjects are involved)

---

PART 3 — Prevention

3.1 Network Policies

• Rate limiting at the API gateway/edge: cap login attempts per IP and per account (e.g. via the WAF Ghaymah already advertises on their /security page)
• Progressive backoff / account lockout: exponentially increasing delay after repeated failures, temporary lockout after a threshold, with self-service unlock via email verification (avoids permanent denial-of-service against the legitimate user)
• CAPTCHA/challenge triggered after N failed attempts, before further attempts are accepted
• IP reputation / bot-mitigation filtering on the login endpoint specifically (block known malicious ranges, Tor exit nodes, datacenter-IP traffic patterns inconsistent with normal user logins)
• Kubernetes NetworkPolicies (default-deny egress/ingress between tenant namespaces): even if one customer's account is compromised, this limits how far an attacker can move laterally toward other tenants' workloads or Ghaymah's internal control-plane services
• mTLS / private networking for internal service-to-service and admin APIs, so a compromised customer-facing credential can't be leveraged to reach internal management interfaces

3.2 Container Security

• Secrets management: never bake DB credentials/API keys into container images or plaintext env vars long-term — use a secrets manager (e.g. Vault-style short-lived, auto-rotating credentials) so a leaked env-var dump has a short shelf life
• Least-privilege service accounts: each deployed container/pod gets only the RBAC permissions it needs — no default cluster-admin, no broad service-account tokens mounted unnecessarily
• Image scanning in the CI/CD pipeline: block deployment of images with known-critical CVEs (relevant given Ghaymah's "push Git → auto-build" pipeline runs customer code automatically)
• Runtime security monitoring (e.g. Falco-style tooling) to detect anomalous in-container behavior post-compromise (unexpected process execution, outbound connections to new destinations)
• Read-only root filesystems and dropped Linux capabilities by default, reducing what an attacker can do even with container-level access
• Automatic credential rotation tied to security events — if an account tied to a deployment is flagged compromised, auto-rotate that deployment's DB credentials and registry tokens rather than waiting for manual response

3.3 Identity Hardening (closes the loop back to Part 1's IAM findings)

• Enforce MFA for account logins and, ideally, for CLI/API token generation
• Strong password hashing (Argon2id or bcrypt with an appropriate cost factor) so even a full DB compromise doesn't yield plaintext-equivalent credentials
• Breached-password checking at signup/reset time (reject passwords found in known-breach corpora)
• Short-lived sessions + refresh token rotation, so a stolen token has a limited window of usefulness

---

PART 4 — Alert Rule Design

Two versions: a vendor-agnostic Sigma rule (the standard portable format security teams use across SIEMs) and a Prometheus/Alertmanager rule, since Ghaymah's stack is Kubernetes-based and likely already emits Prometheus-style metrics.

4.1 Sigma Detection Rule

title: Brute Force / Credential Stuffing Attempt on Login API
id: 7e4b1a2c-91f3-4d6e-8a2b-6c1f9e0d3a55
status: experimental
description: >
  Detects a high volume of failed authentication attempts against the
  Login API, either concentrated from a single source (classic brute
  force) or spread across many sources against a single account
  (credential stuffing).
references:
  - https://attack.mitre.org/techniques/T1110/
logsource:
  category: application
  product: ghaymah-login-api
detection:
  failed_by_ip:
    event_type: "authentication_failure"
  cond_ip:
    failed_by_ip | count(by: source_ip) > 10
    timeframe: 5m
  failed_by_account:
    event_type: "authentication_failure"
  cond_account:
    failed_by_account | count(by: username, distinct: source_ip) > 5
    timeframe: 10m
  condition: cond_ip or cond_account
level: high
tags:
  - attack.credential_access
  - attack.t1110
  - attack.t1110.004
falsepositives:
  - Misconfigured client/app repeatedly retrying with a stale credential
  - Legitimate user with a broken password manager

4.2 Prometheus / Alertmanager Rule (metric-based, fits a K8s-native stack)

groups:
  - name: login-api-brute-force
    rules:
      - alert: LoginAPIBruteForceByIP
        expr: sum(rate(login_failures_total[5m])) by (source_ip) > 10
        for: 1m
        labels:
          severity: high
        annotations:
          summary: "Possible brute-force attack from {{ $labels.source_ip }}"
          description: "More than 10 failed logins/5m from a single IP against the Login API."

      - alert: LoginAPICredentialStuffingByAccount
        expr: sum(count without (source_ip) (login_failures_total)) by (username) > 5
              and count(count by (username, source_ip)(login_failures_total)) by (username) > 3
        for: 2m
        labels:
          severity: high
        annotations:
          summary: "Possible credential-stuffing attempt against account {{ $labels.username }}"
          description: "5+ failed logins for one account from 3+ distinct source IPs within the window."

      - alert: LoginSuccessAfterFailureBurst
        expr: increase(login_success_total[1m]) > 0
              and increase(login_failures_total[10m]) > 5
        for: 0m
        labels:
          severity: critical
        annotations:
          summary: "Successful login immediately follows a failure burst - possible account takeover"
          description: "Treat as high-risk: consider forcing step-up MFA or session re-verification."

4.3 Recommended Automated Response (tied to the alerts above)

• LoginAPIBruteForceByIP → auto-block the source IP at the WAF/edge for a cooldown period (e.g. 30 min) + notify SOC
• LoginAPICredentialStuffingByAccount → force account lockout + require password reset + notify the account owner by email
• LoginSuccessAfterFailureBurst → don't auto-block (avoid locking out the legitimate user who just succeeded), but flag the session as high-risk: require step-up MFA re-verification and alert SOC for manual review

---

Summary

The scenario's real lesson: the technical attack (brute force / credential stuffing) is unsophisticated and well-understood — what determines whether it becomes a breach is whether basic controls (rate limiting, lockout, MFA, alerting) exist on the Login API. The IR plan, prevention controls, and alert rules above form a closed loop: prevent the easy cases, detect what gets through, and respond fast enough to limit blast radius when it does.