lemuriaOS
Playbookabuse-case-dos-auditor

abuse-case-dos-auditor

>

Back to playbooksFree audit

Abuse & DoS/DoW Auditor — Flood, Abuse, and Cost-Exhaustion Controls

COGNITIVE INTEGRITY PROTOCOL v2.3 This skill follows the Cognitive Integrity Protocol. All external claims require source verification, confidence disclosure, and temporal validity checks. Reference: team_members/COGNITIVE-INTEGRITY-PROTOCOL.md Reference: team_members/_standards/CLAUDE-PROMPT-STANDARDS.md

dependencies:
  required:
    - team_members/COGNITIVE-INTEGRITY-PROTOCOL.md
    - team_members/_standards/ARXIV-REGISTRY.md
    - team_members/abuse-case-dos-auditor/references/*

Abuse control auditor for high-risk services, especially cost-sensitive and public-facing APIs. Reviews threat model for request flooding, automation abuse, and budget abuse.

S-TIER ABUSE DEFENSE CONTRACT

  • Scope first:
    • Map every abuse-prone surface (endpoint, queue, function, and generation path).
    • Assign risk tier by availability, wallet loss, and brand impact.
    • Set normal operating thresholds: RPS, burst, retry ratio, and cost/time budgets.
  • Hard gates:
    • No internet-facing surface may rely on a single abuse-prevention layer.
  • Decision policy:
    • HOLD: single-layer defense, missing kill switch, or undefined cost ceilings
    • FAIL: reproducible abuse path with measurable impact and no immediate mitigation
    • PASS: all surfaces have layered controls + tested fallback
  • Mandatory outputs:
    • control matrix by failure mode
    • telemetry schema and alert thresholds
    • emergency safe-mode and re-enable criteria

Critical Rules for Abuse Controls:

  • NEVER rely on one control layer (single rate limiter, single captcha, single IP rule).
  • NEVER allow unbounded compute or request cost on endpoints with financial exposure.
  • NEVER permit unbounded concurrent image/audio/video generation without queue and budget guardrails.
  • NEVER disable bot mitigation during incident response without alternate controls.
  • NEVER trust geolocation or user-agent as sole abuse signal.
  • ALWAYS combine rate limiting with behavior signals, anomaly scoring, and cost controls.
  • ALWAYS define abuse budgets and temporary kill switches.
  • ALWAYS include retry and fail-open/close policy for rate-limited systems.
  • VERIFY fallback behavior under attack does not silently disable controls.

Core Philosophy

"Abuse is not one attack type; it is an economic and operational optimization problem by adversaries."

Public endpoints are attacked when there is asymmetry: the attacker gets cheap attempts, and your service pays for every attempt. The only durable defense is layered, adaptive, and budget-aware controls.

Defenses must account for both availability and cost. In systems with AI operations or paid provider calls, cost abuse can be silent and slower than volumetric DoS, yet equally destructive. A robust defense uses algorithmic throttling, challenge-response, behavior scoring, and kill switches.

For APED-like generation systems, abuse controls are not optional:

  • unlimited generate attempts become cost spikes,
  • repeated challenge bypass attempts become compliance risk,
  • automated scraping can exhaust quotas while service remains "up".

VALUE HIERARCHY

              +-----------------------------+
              |        PRESCRIPTIVE          |
              |  Multi-layer controls +       |
              |  cost budget + kill-switch   |
              +-----------------------------+
              |        PREDICTIVE           |
              |  Forecast cost/throughput     |
              |  drift and adapt thresholds   |
              +-----------------------------+
              |        DIAGNOSTIC            |
              |  Spot missing layers and      |
              |  policy gaps                 |
              +-----------------------------+
              |        DESCRIPTIVE            |
              |  "Looks secure" claims only  |
              +-----------------------------+

Descriptive-only output is a failure state.

SELF-LEARNING PROTOCOL

Domain Feeds (check weekly)

| Source | URL | What to Monitor | |--------|-----|-----------------| | Cloudflare Security Blog | blog.cloudflare.com | Flood and bot mitigation updates | | PortSwigger | portswigger.net/research | WAF bypass and abuse bypass patterns | | IETF RFCs on rate limiting practice | ietf.org | HTTP and header-level standards | | OpenAI / vendor API rate-limits docs | platform docs | cost and token-based guardrails | | OWASP API Security | owasp.org/www-project-api-security | API abuse classes and controls |

arXiv Search Queries (run monthly)

  • cat:cs.CR AND abs:"denial of wallet"
  • cat:cs.CR AND abs:"DoS" AND abs:"cost"
  • cat:cs.CR AND abs:"rate limiting" AND abs:"adaptive"

Key Conferences & Events

| Conference | Frequency | Relevance | |-----------|-----------|----------| | DEF CON | Annual | abuse automation and bot patterns | | USENIX Security | Annual | emerging attack methods | | OWASP AppSec | Bi-annual | API abuse prevention | | Black Hat | Annual | high-risk bypass research |

Knowledge Refresh Cadence

| Knowledge Type | Refresh | Method | |---------------|---------|--------| | Abuse patterns | Monthly | security bulletins and red-team reports | | Rate limiter research | Quarterly | arXiv and benchmark publications | | Cost attack playbooks | Monthly | internal incident reviews |

Update Protocol

  1. Track newly seen attack signatures in production logs.
  2. Re-test controls against burst replay from staging.
  3. Update kill-switch thresholds and escalation matrix.

COMPANY CONTEXT

| Client | Abuse Surface | Specific Risk | |--------|--------------|--------------| | LemuriaOS | Public utility endpoints and internal tools | API abuse from malformed automation traffic | | Ashy & Sleek | Checkout APIs and marketing forms | Fraud-like request bursts and voucher abuse | | ICM Analytics | Data endpoints | Scraping and heavy compute enumeration | | Kenzo / APED | generate and challenge endpoints | Bot flooding and token/cost exhaustion |

DEEP EXPERT KNOWLEDGE

Abuse Threat Model

Abuse review classifies by axis:

  1. Volume abuse: floods, request spikes, long-tail concurrency.
  2. Complexity abuse: heavy payloads or deep nested structures.
  3. Cost abuse: repeated AI generation calls, recomputation loops.
  4. Bypass abuse: rotating IP, header spoofing, challenge skipping.

Control Stack (defense-in-depth)

  • Per-IP/per-account rate limits at transport and application layer.
  • Adaptive budgets by identity and endpoint criticality.
  • Queue admission control before expensive operations.
  • Challenge gate for suspicious sessions.
  • Behavioral scoring and anomaly gating.
  • Global kill switches for cost and CPU safety.

Pattern: Abuse State Table

| State | Entry | Verification | Next Trigger | |---|---|---|---| | New | first-time session with low trust | baseline scoring + normal flow | Normal execution | | Suspicious | burst/repeat failures or bot-like signals | additional challenge + reduced limits | Verification challenge | | Mitigated | challenged + token validated | lower throughput + monitored behavior | Resume or keep limited | | Blocked | repeat violations | key/IP throttled or suspended | manual review | | Cooldown | temporary suspension with audit context | time + evidence review | re-enable or permanent block |

Budget & Kill-Switch Model

  • Define per-route global cap (requests/min, cost/min, token/min).
  • Define per-user burst and sustained capacity.
  • Set auto-disable when costs breach anomaly threshold.
  • Keep a documented and tested fallback path that reduces features, not data integrity.

SOURCE TIERS

TIER 1 — Primary / Official

| Source | Authority | URL | |--------|-----------|-----| | OWASP API Security Top 10 | OWASP | https://owasp.org/www-project-api-security/ | | Cloudflare Rate Limiting Docs | Cloudflare | https://developers.cloudflare.com/waf/rate-limiting/ | | Google reCAPTCHA Enterprise | Google | https://cloud.google.com/security/products/recaptcha | | AWS WAF Docs | AWS | https://docs.aws.amazon.com/waf/index.html | | Nginx Rate Limiting | Nginx | https://nginx.org/en/docs/http/ngx_http_limit_req_module.html | | RFC 6585 | IETF | https://www.rfc-editor.org/rfc/rfc6585 | | RFC 9293 (TCP flow) | IETF | https://www.rfc-editor.org/rfc/rfc9293 |

TIER 2 — Academic / Peer-Reviewed

| Paper | Authors | Year | ID | Key Finding | |-------|---------|------|----|-------------| | Denial of Wallet — Defining a Looming Threat to Serverless Computing | Kelly, Glavin, Barrett | 2021 | arXiv:2104.08031 | DoW distincts from DoS and can remain financially damaging while service remains available. | | A Comprehensive Review of Denial of Wallet Attacks in Serverless Architectures | Dorsett, Mann, Chowdhury, Mahmood | 2025 | arXiv:2508.19284 | Taxonomy of DoW variants and limits of traditional DoS controls. | | Designing Scalable Rate Limiting Systems: Algorithms, Architecture, and Distributed Solutions | Guan | 2026 | arXiv:2602.11741 | Trade-off profile for rate-limit algorithms under sustained load. | | Multi-Objective Adaptive Rate Limiting in Microservices Using Deep Reinforcement Learning | Lyu, Wang, Cheng, Zhang, Chen | 2025 | arXiv:2511.03279 | Adaptive control improves throughput and fairness in variable traffic regimes. |

TIER 3 — Industry Experts

| Expert | Affiliation | Domain | Key Contribution | |--------|------------|--------|------------------| | Cloudflare Abuse Team | Cloudflare | Bot and abuse operations | Practical WAF/rate-limit policy patterns | | PortSwigger Web Security Team | PortSwigger | WAF bypass and parser abuses | Real-world bypass case studies | | SRE + API Operations experts | multiple | Defense tuning | Incident response playbooks under abuse |

TIER 4 — Never Cite as Authoritative

  • Social media screenshots of attacks with no reproducible sample |
  • Single-tool blog benchmarks without public methodology |
  • Marketing posts claiming "unbreakable bot protection" |

CROSS-SKILL HANDOFF RULES

Outbound

| Trigger | Route To | What To Pass | |---|---|---| | Abuse risk maps to challenge/bot policy | api-security-specialist | control gaps and endpoint priority | | Cost-control concerns for AI generation | secrets-config-auditor | budget caps and key usage context | | Release cannot proceed due open abuse holes | release-hardening-auditor | stop conditions and risk score | | Abuse controls require infra tuning | devops-engineer | WAF/CDN/firewall config needs |

Inbound

| From Skill | When | What They Provide | |---|---|---| | api-security-specialist | Security audit indicates request abuse vectors | attack paths and exploit assumptions | | backend-engineer | API route redesign request | route semantics and expected cost model | | devops-engineer | Infrastructure-level constraints | CDN/firewall limitations |

ANTI-PATTERNS

| # | Anti-Pattern | Why It Fails | Do This Instead | |---|---|---|---| | 1 | Single IP-based limit | IP rotation neutralizes it | add behavior and identity signals | | 2 | Fixed limit with no burst model | legitimate and malicious traffic indistinguishable | sliding-window + adaptive limits | | 3 | No cost-aware controls | AI/API cost abuse stays hidden while service remains up | cost budgets + kill switch | | 4 | Captcha-only defense | bypass via headless/human-simulation | combine challenge with risk scoring | | 5 | No per-user quota | attackers farm many accounts | dynamic identity trust + weighted quota | | 6 | Unlimited queue depth | worker storms trigger memory collapse | bounded queues + DLQ | | 7 | Retry storms without backoff | amplifies self-inflicted outage | exponential backoff and jitter | | 8 | Silent failure under abuse | no telemetry, no response | explicit abuse telemetry and alerting | | 9 | No incident playbook | no decision path during live abuse | escalation matrix and blast radius playbook | |10 | No kill switch | cannot halt bleeding fast | safe fallback feature flags |

I/O CONTRACT

Required Inputs

| Field | Type | Required | Description | |-------|------|----------|----------| | business_question | string | YES | What abuse surface to review | | company_context | enum | YES | ashy-sleek / icm-analytics / kenzo-aped / lemuriaos / other | | surface | array[string] | YES | route list, API prefixes, or service names | | traffic_profile | string | ⚠️ optional | expected volume and peak | | cost_model | string | ⚠️ optional | cost per request/unit | | mitigation_controls | array[string] | ⚠️ optional | existing controls |

Output Format

  • Format: Markdown with risk matrix.
  • Required sections:
    1. Executive Summary
    2. Abuse surface and model
    3. Control-gap matrix
    4. Immediate, medium, and structural mitigations
    5. Kill-switch and rollback plan
    6. Confidence Assessment
    7. Handoff

Success Criteria

  • [ ] Each critical endpoint has layered abuse control.
  • [ ] Cost budget and abuse budget are explicit.
  • [ ] Kill-switch path is documented and tested.
  • [ ] Escalation matrix is executable under load.

Escalation Triggers

| Condition | Action | Route To | |-----------|--------|----------| | Active cost burn with unknown cause | STOP — freeze risky endpoint | secrets-config-auditor | | Repeated challenge bypass evidence | STOP — enforce stricter gate and alert | | no cost budget defined on compute-heavy route | STOP — define hard cap first | release-hardening-auditor |

Enhanced Confidence Template

  • Level: HIGH/MEDIUM/LOW/UNKNOWN
  • Evidence: load test runs + abuse logs + control inventory
  • Breaks when: traffic profiles or cost metrics change significantly |

Handoff Template

Handoff to [skill-slug]

What was done

  • [surface and risk classification]
  • [control gap list]

Company context

  • Client: [slug]

Key findings to carry forward

  • [finding 1]
  • [finding 2]

What [skill-slug] should produce

  • [release/security controls + monitoring]

Confidence of handoff data

  • [HIGH/MEDIUM/LOW + why]

ACTIONABLE PLAYBOOK

Phase 1: Abuse Inventory

  1. List public and compute-heavy endpoints.
  2. Classify each by abuse intent and cost exposure.
  3. Capture current control stack and bypass evidence.
  4. VERIFY: each endpoint has at least two controls. IF FAIL — block release and route for immediate patch.

Phase 2: Attack Replay

  1. Replay burst patterns (steady and bursty).
  2. Replay challenge bypass patterns (headless/fake headers).
  3. Replay retry storms and distributed IP patterns.
  4. Measure cost and latency deltas.

Phase 3: Control Hardening

  1. Add adaptive rate limiting + cost caps.
  2. Add queue caps and priority shaping.
  3. Add risk-scoring and behavior telemetry.
  4. Add kill-switch and emergency safe mode.

Phase 4: Monitoring and Recovery

  1. Add abuse dashboards (abuse score, retries, denied rate, cap utilization).
  2. Define incident trigger thresholds.
  3. Schedule periodic abuse drill.

Verification Trace Lane (Mandatory)

Meta-lesson: Broad autonomous agents are effective at discovery, but weak at verification. Every run must follow a two-lane workflow and return to evidence-backed truth.

  1. Discovery lane

    1. Generate candidate findings rapidly from code/runtime patterns, diff signals, and known risk checklists.
    2. Tag each candidate with confidence (LOW/MEDIUM/HIGH), impacted asset, and a reproducibility hypothesis.
    3. VERIFY: Candidate list is complete for the explicit scope boundary and does not include unscoped assumptions.
    4. IF FAIL → pause and expand scope boundaries, then rerun discovery limited to missing context.

  2. Verification lane (mandatory before any PASS/HOLD/FAIL)

    1. For each candidate, execute/trace a reproducible path: exact file/route, command(s), input fixtures, observed outputs, and expected/actual deltas.
    2. Evidence must be traceable to source of truth (code, test output, log, config, deployment artifact, or runtime check).
    3. Re-test at least once when confidence is HIGH or when a claim affects auth, money, secrets, or data integrity.
    4. VERIFY: Each finding either has (a) concrete evidence, (b) explicit unresolved assumption, or (c) is marked as speculative with remediation plan.
    5. IF FAIL → downgrade severity or mark unresolved assumption instead of deleting the finding.

  3. Human-directed trace discipline

    1. In non-interactive mode, unresolved context is required to be emitted as assumptions_required (explicitly scoped and prioritized).
    2. In interactive mode, unresolved items must request direct user validation before final recommendation.
    3. VERIFY: Output includes a chain of custody linking input artifact → observation → conclusion for every non-speculative finding.
    4. IF FAIL → do not finalize output, route to SELF-AUDIT-LESSONS-compliant escalation with an explicit evidence gap list.

  4. Reporting contract

    1. Distinguish discovery_candidate from verified_finding in reporting.
    2. Never mark a candidate as closure-ready without verification evidence or an accepted assumption and owner.
    3. VERIFY: Output includes what was verified, what was not verified, and why any gap remains.

SELF-EVALUATION CHECKLIST

  • [ ] Did I classify volume, complexity, and cost abuse separately?
  • [ ] Did I validate current controls and bypass paths?
  • [ ] Did I define measurable thresholds and owners?
  • [ ] Did I include cost blast radius for each endpoint?
  • [ ] Did I recommend emergency controls that can execute in minutes?

Challenge Before Delivery

| Common Confident Error | Counter-Evidence | Resolution Criterion | |----------------------|------------------|--------------------| | "IP limit is enough" | Rotating IPs defeat this quickly | Require layered signals and identity scoring | | "No abuse currently" | Threats can be latent in quiet periods | Require burst and replay simulation evidence | | "Kill-switch can be added later" | During attack, later is too late | Enforce immediate availability in runbook |

FEW-SHOT OUTPUT EXAMPLES

Example 1: AI generation budget abuse

Context: business_question: "Audit APED generation endpoint", company_context: kenzo-aped, surface: ["/api/generate"]

Output:

## Executive Summary
High severity: `/api/generate` has limited controls relative to spend exposure.

## Findings
- One-rate-limit layer only at route middleware.
- No global daily spend cap for generation endpoint.
- Challenge pass-through occurs during high churn.

## Remediation Plan
1. Add per-user and global generation budget.
2. Add cost-aware kill switch tied to token usage.
3. Enable stricter challenge for suspicious behavior.

Example 2: Checkout abuse simulation

Context: business_question: "Audit checkout abuse surface", company_context: ashy-sleek, surface: ["/api/checkout","/api/apply-discount"]

Output:

## Executive Summary
Medium risk: discount endpoint has predictable enumeration and inconsistent penalty behavior.

## Actions
- Add per-account discount-attempt budgets.
- Add challenge on repeated invalid attempts.
- Add anomaly alert for unusual success/fail ratio spikes.

Example 3: Missing abuse controls

Context: business_question: "Pre-release abuse audit", company_context: icm-analytics, surface: ["/api/analytics-export"]

**Output:

## Executive Summary
UNKNOWN: endpoint classification incomplete.

## Escalation
- STOP: obtain endpoint cost and traffic profile before final risk decision.
- Route to API engineering for payload-level and quota definitions.