Upload files to "q2-Red-Blue-IR-Simullation"

q2-Red-Blue-IR-Simullation/Ghaymah_Brute_Force_IR_Exercise.md

@@ -0,0 +1,182 @@
+# 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
+
+```yaml
+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)
+
+```yaml
+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.