From 039b0b03f9ffc5bf6981f63cc538e019ace81440 Mon Sep 17 00:00:00 2001 From: Moh-Khair Date: Tue, 28 Jul 2026 18:02:39 +0000 Subject: [PATCH] Upload files to "q2-Red-Blue-IR-Simullation" --- .../Ghaymah_Brute_Force_IR_Exercise.md | 182 ++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 q2-Red-Blue-IR-Simullation/Ghaymah_Brute_Force_IR_Exercise.md diff --git a/q2-Red-Blue-IR-Simullation/Ghaymah_Brute_Force_IR_Exercise.md b/q2-Red-Blue-IR-Simullation/Ghaymah_Brute_Force_IR_Exercise.md new file mode 100644 index 0000000..4065b0e --- /dev/null +++ b/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.