SC-043: API Abuse & Rate Limit Bypass¶

Threat Actor Profile¶

RATE BREAKER is a synthetic cybercriminal syndicate specializing in API vulnerability exploitation targeting financial services platforms. The group combines deep technical knowledge of REST/GraphQL API architecture with expertise in financial system business logic. Their operations focus on identifying and exploiting rate limiting gaps, authentication weaknesses, and business logic flaws in payment processing APIs.

RATE BREAKER operates a structured team: reconnaissance specialists who discover and document API endpoints, exploit developers who craft abuse techniques, and operators who execute the attacks at scale. The group sells API exploit kits and "configs" on underground forums, allowing lower-skilled criminals to replicate their attacks against other targets.

Motivation: Financial — direct monetary theft through payment manipulation, fraudulent transactions, and resale of API exploitation toolkits. Average campaign yield: $500K–$2M before detection.

Scenario Narrative¶

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

FinEdge Payments is a synthetic payment processing company providing REST APIs for e-commerce merchants. FinEdge processes $2.3 billion in annual transaction volume across 14,000 merchant accounts. Their API platform (api.finedge-payments.example.com) handles payment authorization, capture, refund, and settlement operations.

RATE BREAKER begins reconnaissance on FinEdge's API surface:

Step 1 — Public Documentation Mining:

The attacker discovers FinEdge's public API documentation at docs.finedge-payments.example.com, which includes:

• OpenAPI/Swagger specification (/openapi.json) with all endpoint definitions
• Authentication flows (API key + HMAC signature)
• Request/response schemas with example payloads
• Rate limit headers documented: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
• Sandbox environment: sandbox.api.finedge-payments.example.com (no rate limiting)

Step 2 — API Endpoint Enumeration:

Using the OpenAPI spec and brute-force directory scanning, RATE BREAKER maps the full API surface:

Step 3 — Vulnerability Identification:

RATE BREAKER identifies four critical vulnerabilities:

1. Legacy API without rate limiting: /v1/payments is deprecated but still active, with no rate limiting and weaker authentication (API key only, no HMAC signature)
2. Exposed internal endpoints: /internal/health and /internal/metrics are accessible without authentication, leaking infrastructure details and transaction volume metrics
3. BOLA on merchant endpoints: /v2/merchants/{id} and /v2/merchants/{id}/balance accept any merchant ID — no authorization check that the API key belongs to the requested merchant
4. Rate limit bypass via header manipulation: The X-Forwarded-For header is trusted for rate limiting — injecting different IPs resets the rate limit counter

Evidence Artifacts:

Phase 2 — Rate Limit Bypass & Authentication Abuse (~35 min)¶

RATE BREAKER exploits the identified vulnerabilities systematically.

Attack Vector 1 — Rate Limit Bypass via X-Forwarded-For:

The API gateway uses the X-Forwarded-For header value for rate limiting instead of the actual source IP. By rotating the X-Forwarded-For value, the attacker bypasses the 100 requests/minute limit entirely:

POST /v2/payments HTTP/1.1
Host: api.finedge-payments.example.com
Authorization: Bearer sk_live_REDACTED
X-Forwarded-For: 10.0.0.1
Content-Type: application/json

{
  "amount": 100,
  "currency": "USD",
  "source": "tok_REDACTED",
  "description": "Test payment"
}

By cycling through 10,000 spoofed X-Forwarded-For addresses, RATE BREAKER achieves an effective rate of 10,000 requests/minute — 100x the intended limit.

Attack Vector 2 — BOLA on Merchant Balance Endpoint:

Using a single compromised API key (from a small merchant account merchant_12847), the attacker queries the balance endpoint for all 14,000 merchants:

GET /v2/merchants/merchant_00001/balance HTTP/1.1
Host: api.finedge-payments.example.com
Authorization: Bearer sk_live_REDACTED

Response (should return 403 but returns 200):

{
  "merchant_id": "merchant_00001",
  "available_balance": 847293.50,
  "pending_balance": 124500.00,
  "currency": "USD",
  "last_payout": "2026-02-19T00:00:00Z"
}

RATE BREAKER enumerates all 14,000 merchant accounts, collecting balance information and identifying high-value targets for the next phase.

Attack Vector 3 — Legacy API Exploitation:

The deprecated /v1/payments endpoint accepts API key authentication without HMAC signatures. Using the compromised API key, the attacker creates payment authorizations on the legacy endpoint without rate limiting:

POST /v1/payments HTTP/1.1
Host: api.finedge-payments.example.com
X-API-Key: pk_live_REDACTED
Content-Type: application/json

{
  "amount": 0.01,
  "card_number": "4111111111111111",
  "exp_month": 12,
  "exp_year": 2028,
  "cvv": "REDACTED"
}

Evidence Artifacts:

Phase 3 — Business Logic Exploitation & Financial Fraud (~30 min)¶

RATE BREAKER escalates to their primary objective: financial fraud through business logic exploitation.

Attack Vector 4 — Race Condition on Payment Capture:

The attacker discovers a time-of-check-to-time-of-use (TOCTOU) race condition in the payment capture flow. When a payment is authorized, it can be captured (settled) exactly once. However, sending multiple simultaneous capture requests before the database transaction commits allows the same authorization to be captured multiple times:

Thread 1: POST /v2/payments/pay_ABC123/capture  → Check: not captured → Process capture → DB commit
Thread 2: POST /v2/payments/pay_ABC123/capture  → Check: not captured (Thread 1 hasn't committed yet) → Process capture → DB commit
Thread 3: POST /v2/payments/pay_ABC123/capture  → Check: not captured (Thread 1 hasn't committed yet) → Process capture → DB commit

Result: A single $500 authorization is captured 3 times, resulting in $1,500 deposited to the merchant account.

RATE BREAKER automates this attack:

1. Create a payment authorization for $500 using a controlled merchant account
2. Send 50 simultaneous capture requests within a 10ms window
3. Average success rate: 3–5 duplicate captures per authorization
4. Repeat across 200 authorizations over 4 hours

Attack Vector 5 — Price Manipulation via Unsigned Amount:

On the legacy /v1/payments endpoint, the payment amount is client-specified and not cryptographically signed. The attacker creates a payment flow where:

1. A legitimate checkout shows $500 to the customer
2. The API call to /v1/payments submits "amount": 0.01 instead of 500.00
3. The payment processes for $0.01 but the merchant's system records it as $500.00

This allows the attacker to purchase high-value goods for $0.01 each through compromised merchant integrations.

Evidence Artifacts:

Detection & Hunting¶

KQL Detection Queries¶

// Detect X-Forwarded-For spoofing — many unique XFF values from single source IP
ApiManagementGatewayLogs
| where TimeGenerated > ago(1h)
| extend XFF = tostring(parse_json(RequestHeaders)["X-Forwarded-For"])
| extend SourceIP = CallerIpAddress
| summarize UniqueXFF = dcount(XFF), RequestCount = count() by SourceIP
| where UniqueXFF > 100 and RequestCount > 500
| sort by UniqueXFF desc

// Detect BOLA — single API key accessing multiple merchant resources
ApiManagementGatewayLogs
| where TimeGenerated > ago(24h)
| where RequestPath matches regex @"/v2/merchants/[^/]+/balance"
| extend MerchantID = extract(@"/v2/merchants/([^/]+)/", 1, RequestPath)
| extend APIKey = tostring(parse_json(RequestHeaders)["Authorization"])
| summarize UniqueMerchants = dcount(MerchantID), RequestCount = count() by APIKey
| where UniqueMerchants > 10
| sort by UniqueMerchants desc

// Detect race condition — multiple captures on same payment ID within short window
AppRequests
| where TimeGenerated > ago(24h)
| where Url contains "/capture"
| extend PaymentID = extract(@"/payments/([^/]+)/capture", 1, Url)
| summarize CaptureCount = count(),
            MinTime = min(TimeGenerated),
            MaxTime = max(TimeGenerated)
  by PaymentID
| extend WindowMs = datetime_diff('millisecond', MaxTime, MinTime)
| where CaptureCount > 1 and WindowMs < 1000
| sort by CaptureCount desc

SPL Detection Queries¶

// Detect X-Forwarded-For manipulation
index=api sourcetype=api_gateway
| stats dc(xff_ip) as unique_xff_values, count as request_count by src_ip
| where unique_xff_values > 100 AND request_count > 500
| sort -unique_xff_values

// Detect BOLA — API key accessing unauthorized merchant resources
index=api sourcetype=api_gateway uri_path="/v2/merchants/*/balance"
| rex field=uri_path "/v2/merchants/(?<merchant_id>[^/]+)/balance"
| stats dc(merchant_id) as merchants_accessed, count as request_count by api_key
| where merchants_accessed > 10
| sort -merchants_accessed

// Detect duplicate payment captures (race condition)
index=api sourcetype=api_gateway uri_path="*/capture" method=POST status=200
| rex field=uri_path "/payments/(?<payment_id>[^/]+)/capture"
| stats count as capture_count, range(_time) as time_window by payment_id
| where capture_count > 1 AND time_window < 1
| sort -capture_count

Indicators of Compromise (IOCs)¶

Full Attack Timeline¶

Lessons Learned¶

Critical Failures¶

1. Deprecated API left active: The /v1/payments endpoint was marked deprecated in documentation but remained fully functional with no rate limiting and weaker authentication. API deprecation must include a hard sunset date with traffic monitoring and eventual decommissioning.

2. Rate limiting based on spoofable header: Using X-Forwarded-For for rate limiting without validating the header chain allows trivial bypass. Rate limiting must use the true client IP determined by the outermost trusted proxy.

3. No object-level authorization: The merchant balance endpoint performed authentication (valid API key) but not authorization (does this key belong to the requested merchant). BOLA/IDOR vulnerabilities are the #1 API security risk per OWASP.

4. No race condition protection: The payment capture endpoint lacked idempotency controls, optimistic concurrency, or database-level locking. Financial transaction endpoints require atomic operations with proper concurrency control.

5. Internal endpoints exposed: /internal/health and /internal/metrics were accessible from the internet, leaking infrastructure details and transaction metrics that aided reconnaissance.

Recommended Controls¶

Cross-References¶

• Chapter 30: Application Security — API security, OWASP Top 10, and web application attack vectors
• Chapter 30: Application Security — Secure development, business logic security, and race condition prevention
• Chapter 35: DevSecOps Pipeline — API security testing in CI/CD, DAST for APIs, and security automation