METHODOLOGY

Proof of Exploitation

Every KAOS finding ships with a validated PoC. Here's what that looks like in practice.

attack chain

One low-severity flaw is noise. KAI chains them into the path an attacker would actually walk — and proves each hop.

  1. RECONT1595
    app.target.com
    public asset surfaced
    asset confirmed
    resolve app.target.com → 203.0.113.10
  2. DISCOVERYT1592
    :443 /api/users
    exposed endpoint
    reachable
    GET /api/users → 200 OK · 1,284 records
  3. EXPLOITT1190
    IDOR → SQLi
    low-sev flaws, chained
    PoC verified
    id=42' AND pg_sleep(5)-- → 5.42s
  4. ESCALATET1003
    creds dumped
    hash → token
    PoC verified
    hashcat -m 1000 → svc_admin:••••• → JWT
  5. IMPACTT1078objective reached
    DOMAIN ADMIN
    objective reached
    PoC verified
    whoami → CORP\Administrator
  1. Step 1. RECON: app.target.com. public asset surfaced. MITRE technique T1595. Evidence: resolve app.target.com → 203.0.113.10. asset confirmed.
  2. Step 2. DISCOVERY: :443 /api/users. exposed endpoint. MITRE technique T1592. Evidence: GET /api/users → 200 OK · 1,284 records. reachable.
  3. Step 3. EXPLOIT: IDOR → SQLi. low-sev flaws, chained. MITRE technique T1190. Evidence: id=42' AND pg_sleep(5)-- → 5.42s. PoC verified.
  4. Step 4. ESCALATE: creds dumped. hash → token. MITRE technique T1003. Evidence: hashcat -m 1000 → svc_admin:••••• → JWT. PoC verified.
  5. Step 5. IMPACT: DOMAIN ADMIN. objective reached. MITRE technique T1078. Evidence: whoami → CORP\Administrator. PoC verified.

Why it matters

The problem with traditional scanners

Most tools flag CVEs based on banner versions, response fingerprints, or static rules. The result: 60–80% false-positive rates, alert fatigue, and engineering teams chasing issues that turn out to be unreachable, mitigated, or simply wrong.

Security teams burn cycles triaging noise. Developers stop trusting the queue. Real vulnerabilities get buried.

The KAOS approach

Our platform — and our human experts — validate each finding by actually exploiting it in a controlled way. We capture the request, the response, and the impact. Only confirmed-impact issues land in your queue.

Your developers get a finding they can reproduce in seconds. Your security team gets a defensible risk assessment. Your auditors get evidence.

What's in a KAOS PoC report

Every finding includes the same seven elements — consistent across the platform and our manual engagements.

1

Vulnerability name + CVSS + CWE

Industry-standard identifiers so triage is automatic.

2

Affected endpoint, parameter, asset

Exact location — no guessing where the issue lives.

3

Reproduction steps

Step-by-step curl/HTTP commands a developer can replay locally.

4

Captured evidence

Request/response pairs, screenshots, or exfiltrated samples.

5

Business impact

What an attacker could actually do — data theft, lateral movement, persistence.

6

MITRE ATT&CK mapping

Tactic and technique IDs aligned to your detection engineering.

7

Remediation guidance

Specific code or config change — not generic OWASP boilerplate.

Example finding (anonymized)

A realistic blind SQL injection finding from a production engagement. Customer details redacted.

Finding KAOS-2025-0421
Blind SQL Injection in /api/v1/orders
CRITICALCVSS 9.8CWE-89
Affected Asset
app.example.com — GET /api/v1/orders — parameter: id
Reproduction
# 1. Baseline request — normal lookup
curl -s 'https://app.example.com/api/v1/orders?id=42' \
  -H 'Authorization: Bearer eyJhbGciOi...'

# 2. Inject time-based payload into the id parameter
curl -s "https://app.example.com/api/v1/orders?id=42'%20AND%20pg_sleep(5)--" \
  -H 'Authorization: Bearer eyJhbGciOi...' -o /dev/null -w '%{time_total}\n'
# -> 5.42s   (baseline 0.18s) — confirms blind SQLi

# 3. Boolean exfiltration of current_user()
curl -s "https://app.example.com/api/v1/orders?id=42'%20AND%20substr(current_user,1,1)='p'--" \
  -H 'Authorization: Bearer eyJhbGciOi...'
# -> 200 OK with order body  (TRUE branch confirmed)
Evidence Captured

Full HTTP request/response pairs for baseline + boolean + time-based payloads. Database banner extracted: PostgreSQL 14.9. Current DB user identified as app_prod with read access to orders, users, and payments tables.

Business Impact

An authenticated attacker can extract the full payments table (including PAN data and billing addresses) at roughly 1 row/second via boolean exfiltration. Combined with the observed lack of rate limiting, full database extraction is feasible within a single working day. Regulatory exposure: PCI-DSS Req. 6.5.1, GDPR Art. 32.

MITRE ATT&CK
T1190 · Exploit Public-Facing ApplicationTA0009 · CollectionT1213 · Data from Information Repositories
Remediation

In orders/repository.py:get_by_id(), replace the f-string query with a parameterized statement (cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))). Add input validation: id must be a positive integer before the DB call. Confirm the ORM-wide audit on PR #4421 covers the remaining 12 raw-SQL call sites.

How it integrates with your workflow

Findings flow into the tools your team already uses — no extra dashboards to babysit.

Issue trackers

Auto-create tickets in Jira, Linear, GitHub Issues, or GitLab with full PoC content as the issue body.

Chat alerts

Slack and Microsoft Teams notifications, severity-filtered, with one-click links back to the finding.

SARIF export

Native SARIF 2.1.0 output for GitHub Advanced Security, Azure DevOps, and any SAST aggregator.

Custom webhooks

HMAC-signed webhooks for SOAR playbooks, custom dashboards, or in-house ticketing.

Browse all integrations →

Ready to see real findings on your own assets?

Spin up a trial scan in minutes, or talk to one of our offensive security experts about a tailored engagement.

Start Free TrialTalk to Sales