SC-041: Credential Stuffing at Scale¶

Threat Actor Profile¶

HYDRA SWARM is a synthetic financially motivated threat group specializing in large-scale credential stuffing campaigns targeting loyalty and rewards programs. The group operates as a service — acquiring breached credential databases from underground markets, operating rotating residential proxy infrastructure, and selling compromised loyalty accounts through dedicated reseller channels.

HYDRA SWARM's operational model is industrialized: they maintain a custom Python-based credential testing framework capable of processing 500,000+ credential pairs per hour across distributed infrastructure. Their proxy network consists of 40,000+ residential IPs obtained through a mix of legitimate proxy services and compromised IoT devices. They employ CAPTCHA-solving services (both ML-based and human farm) to bypass bot mitigation controls.

Motivation: Financial — loyalty points are treated as a liquid currency. Compromised accounts with high point balances are sold on dark web marketplaces at 60–70% of face value. Points are laundered through gift card purchases, merchandise orders shipped to drop addresses, and transfer to mule accounts.

Scenario Narrative¶

Phase 1 — Credential Acquisition & Infrastructure Setup (~30 min)¶

Velocity Airlines is a synthetic mid-size commercial airline operating a loyalty rewards program called VelocityRewards with 12 million members. Members accumulate points through flights, credit card spending, and partner purchases. Points can be redeemed for flights, seat upgrades, gift cards, and merchandise through the VelocityRewards web portal (rewards.velocityairlines.example.com).

HYDRA SWARM acquires a credential database containing 85 million email/password pairs from a 2025 breach of an unrelated e-commerce platform. The group processes the database through their custom deduplication and formatting pipeline, producing a refined list of 42 million unique credential pairs. Based on historical success rates (0.5–2.0% match rate against airline loyalty programs), they estimate 210,000–840,000 valid account compromises.

The group provisions their attack infrastructure:

• Proxy infrastructure: 40,000 residential IPs across 28 countries, rotated every 3–5 requests per IP
• CAPTCHA solving: Contract with a human CAPTCHA farm (avg. solve time: 8 seconds, cost: $2.50/1000 solves) and an ML-based CAPTCHA solver for reCAPTCHA v2 (70% success rate)
• Credential testing framework: Custom Python tool (hydra-stuffer) with configurable request templates, rate limiting, session management, and result classification
• Command and control: Coordination via encrypted messaging; results aggregated to a PostgreSQL database hosted at 203.0.113.50

Evidence Artifacts:

Phase 2 — Automated Credential Testing (~35 min)¶

On 2026-01-18, HYDRA SWARM launches the credential stuffing campaign against rewards.velocityairlines.example.com/api/v2/auth/login. The attack runs continuously for 72 hours.

The login API accepts JSON POST requests:

{
  "email": "user@example.com",
  "password": "REDACTED",
  "captcha_token": "03AGdBq24..."
}

HYDRA SWARM's attack framework operates with the following parameters:

• Request rate: 150 requests/second (distributed across 40,000 IPs — avg. 0.00375 req/s per IP)
• Session rotation: New TLS session per IP rotation — randomized User-Agent strings from a pool of 2,000 browser fingerprints
• CAPTCHA handling: Pre-solved tokens injected into requests — average token lifetime: 120 seconds
• Error handling: Automatic retry on HTTP 429 (rate limited) with exponential backoff; skip on HTTP 403 (IP blocked)
• Result classification: HTTP 200 + valid session cookie = success; HTTP 401 = invalid credentials; HTTP 403 = account locked

Over the 72-hour campaign:

Evidence Artifacts:

Phase 3 — Account Takeover & Point Liquidation (~30 min)¶

After validating 287,400 accounts, HYDRA SWARM begins the monetization phase. The group prioritizes the 8,720 accounts with balances exceeding 200,000 points (each worth approximately $2,000 in redemption value).

The monetization workflow:

1. Account lockout of legitimate owner: Change the account email to a HYDRA SWARM-controlled address (<random>@mailhub.example.com), change the password, and remove any recovery phone numbers
2. Point redemption: Redeem points for digital gift cards (Amazon, Apple, Visa prepaid) — maximum 500,000 points per transaction
3. Gift card laundering: Resell gift cards through secondary marketplaces at 70–80% face value
4. Account cleanup: Delete redemption confirmation emails from the compromised account

Velocity Airlines does not require:

• MFA for login
• Re-authentication for email address changes
• Re-authentication for point redemptions
• Email notification to the original address when the account email is changed
• Cooldown period after email/password changes before high-value transactions

Evidence Artifacts:

Compromised Account → Point Redemption → Digital Gift Card
    → Gift Card Reseller Marketplace (70-80% face value)
    → Buyer purchases gift card → Uses for legitimate purchases
    → Proceeds to HYDRA SWARM via cryptocurrency

2026-01-21 06:00 — Email changes begin (8,720 accounts)
2026-01-21 08:00 — Password changes complete
2026-01-21 12:00 — First gift card redemptions
2026-01-25 23:59 — Last gift card redemption
2026-01-23 09:00 — First customer complaints to call center
2026-01-24 14:30 — Call center escalates to security team
2026-01-24 16:00 — Security team begins investigation
2026-01-24 18:00 — Emergency: freeze all gift card redemptions

Detection & Hunting¶

KQL Detection Queries¶

// Detect credential stuffing — high login failure rate on a single endpoint
SigninLogs
| where TimeGenerated > ago(1h)
| where AppDisplayName == "VelocityRewards Portal"
| summarize TotalAttempts = count(),
            FailedAttempts = countif(ResultType != "0"),
            SuccessAttempts = countif(ResultType == "0"),
            UniqueIPs = dcount(IPAddress),
            UniqueAccounts = dcount(UserPrincipalName)
  by bin(TimeGenerated, 10m)
| extend FailureRate = round(FailedAttempts * 100.0 / TotalAttempts, 2)
| where FailureRate > 80 and TotalAttempts > 1000
| project TimeGenerated, TotalAttempts, FailedAttempts, FailureRate, UniqueIPs, UniqueAccounts

// Detect mass email changes to a single domain
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Update user"
| where TargetResources has "email"
| extend NewEmail = tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)
| extend NewDomain = tostring(split(NewEmail, "@")[1])
| summarize AccountsChanged = count(), Accounts = make_set(TargetResources[0].userPrincipalName) by NewDomain
| where AccountsChanged > 10
| sort by AccountsChanged desc

// Detect distributed credential stuffing — low per-IP but high aggregate
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| summarize AttemptsPerIP = count() by IPAddress
| where AttemptsPerIP between (1 .. 50)
| summarize SuspiciousIPs = count(), TotalAttempts = sum(AttemptsPerIP)
| where SuspiciousIPs > 500 and TotalAttempts > 10000

SPL Detection Queries¶

// Detect credential stuffing via login failure spike
index=web sourcetype=access_combined uri_path="/api/v2/auth/login" method=POST
| bin _time span=10m
| stats count as total_attempts,
        count(eval(status=401)) as failed,
        count(eval(status=200)) as success,
        dc(clientip) as unique_ips,
        dc(form_username) as unique_accounts by _time
| eval failure_rate = round((failed/total_attempts)*100, 2)
| where failure_rate > 80 AND total_attempts > 1000
| table _time, total_attempts, failed, failure_rate, unique_ips, unique_accounts

// Detect gift card redemption anomaly
index=application sourcetype=rewards_transactions action=redeem product_type=gift_card
| bin _time span=1h
| stats count as redemptions, sum(point_value) as total_points, dc(account_id) as unique_accounts by _time
| eventstats avg(redemptions) as avg_redemptions, stdev(redemptions) as stdev_redemptions
| eval z_score = (redemptions - avg_redemptions) / stdev_redemptions
| where z_score > 3
| table _time, redemptions, total_points, unique_accounts, z_score

// Detect distributed login attempts below per-IP rate limits
index=web sourcetype=access_combined uri_path="/api/v2/auth/login" status=401
| stats count as attempts by clientip
| where attempts >= 1 AND attempts <= 50
| stats count as suspicious_ips, sum(attempts) as total_attempts
| where suspicious_ips > 500 AND total_attempts > 10000

Indicators of Compromise (IOCs)¶

Full Attack Timeline¶

Lessons Learned¶

Critical Failures¶

1. No MFA on loyalty accounts: The VelocityRewards portal relied solely on email/password authentication. MFA would have rendered 99%+ of credential stuffing attempts useless, even with valid credentials.

2. Per-IP rate limiting is insufficient: The WAF rate limit (100 req/10 min per IP) was trivially bypassed by distributing requests across 40,000 residential IPs. Effective defense requires per-account rate limiting, global failure rate monitoring, and behavioral analysis.

3. No re-authentication for high-risk actions: Email changes, password changes, and point redemptions required no re-authentication or step-up verification. An attacker with valid credentials could fully take over and monetize an account in a single session.

4. No customer support-to-SOC feedback loop: Hundreds of "locked out" complaints arrived 2 days before security was notified. Customer support had no process to escalate security-relevant patterns.

5. No breach credential monitoring: Velocity Airlines did not monitor for employee or customer credentials appearing in breach databases. Early detection of the ShopEZ breach data could have triggered proactive password resets.

Recommended Controls¶

Cross-References¶

• Chapter 33: Identity Chapter 11: Identity & Access Management Access Security](../chapters/ch33-identity-access-security.md) — MFA, credential management, and authentication controls
• Chapter 30: Application Security — Bot management, rate limiting, and application-layer defenses
• Chapter 30: Application Security — Business logic security, API abuse prevention, and secure authentication design