What happens inside a Hound pentest?

Follow Hound's agents as they test Aldercrest, an intentionally vulnerable banking app.

First, Hound mapped the app.

Hound deployed analysts to investigate the infrastructure, web security, and banking workflows. Below are three examples from that work.

Infrastructure

An infrastructure analyst mapped the public service, identified its software, and assessed how it was deployed.

Open evidence

Infrastructure analyst transcript

Server header fingerprint (Werkzeug/2.0.1 Python/3.9.25) present on every single response […]
[…]
Production traffic served directly by the Werkzeug development server rather than a hardened WSGI server […]
[…]
Attack surface is concentrated entirely on the single port-443 Flask application; no independent network-service-level findings outside the web application layer

Banking workflows

An application analyst mapped the app's behavior across transfers, balance checks, password resets, cards, loans, and payments.

Open evidence

Application analyst transcript

State changes and transitions: debits sender, credits receiver, appends a transaction row.
[…]
State changes and transitions: create (active, not frozen) → freeze/unfreeze toggle → limit update; each an independent POST keyed by `card_id`.
[…]
Observed behavior / state machine: username submitted to `forgot-password` generates and stores a fresh 3-digit numeric PIN […] the PIN plus a new password are then submitted to `reset-password` to complete the change.

Web security

An OWASP analyst mapped potential attack paths across transfers, file uploads, login, password resets, and browser protections.

Open evidence

OWASP analyst transcript

My plan covers JWT vulnerabilities like alg=none, HS256 secret cracking, algorithm confusion, and claim tampering; […] checking CORS configuration for origin reflection issues.
[…]
I also want to test XSS in fields like transaction descriptions, profile picture filenames, usernames, and the AI chat; SQL injection and path traversal across various IDs and endpoints; and rate limiting on login brute force and the reset-password PIN flow […]

As leads emerged, Hound tested them.

Hound's Breacher agents carried out attacks. Below are three examples from the wider test.

Business logic

Aldercrest accepted negative transfers that credited the sender and debited the recipient.

Open evidence

Breacher transcript

This confirms the vulnerability: […] a negative transfer amount passes the insufficient-funds check and then gets subtracted, actually increasing the sender's balance […]
  "bruce_before": 19797.0,
  "mallory_before": 183.0,
  "amount_sent": -19796.0,
[…]
  "bruce_after": 39593.0,
  "mallory_after": -19613.0

Attack chain

A transfer description exposed a session token; replaying it revealed card data and enabled a transfer.

Open evidence

Breacher transcript

bruce sent mallory an unsolicited $1 transfer with an <img onerror> payload; mallory (real login, real password) viewing her own dashboard exfiltrated her live JWT to a local listener.

Verifier transcript

I replayed the stolen token: 200 on /api/virtual-cards (full PAN/CVV) and used it to execute a money transfer.
Permanence confirmed: no exp claim, no logout endpoint in the 26-path API, and after an in-app logout() the same token still returned 200.

Escalation

A SQL injection in the balance lookup let Hound make its test account an admin.

Open evidence

Breacher transcript

Pre-state confirmed: bruce (id=2) is_admin=false, and full baseline captured for all 6 rows. Now executing the bound write via stacked query.
[…]
Escalated to a real write: UPDATE users SET is_admin=true WHERE id=2; COMMIT flipped only bruce's row (verified via pre/post SELECT across all 6 users — no collateral).
Confirmed live via bruce's own password-reset flow (Hound-owned account) → fresh login → genuine is_admin:true JWT → HTTP 200 on /sup3r_s3cr3t_admin.
Reverted and reconfirmed identical to baseline.

Verifiers tested Hound's conclusions.

Corrected

A Verifier re-tested why the admin panel opened and uncovered a more serious authentication flaw.

Open evidence

Verifier transcript

Important — the wrong-secret control appears to have returned the admin panel too. Let me nail that down precisely.
[…]
But prior analysis never ran the negative control. I did — the same payload signed with a deliberately wrong secret also returned HTTP 200, byte-identical body (diff says IDENTICAL). So did a garbage signature and an empty signature.
The weak secret is not the enabling defect.

Confirmed

A Verifier reproduced an intermittent transfer race that let concurrent payments overdraw an account.

Open evidence

Verifier transcript

Race confirmed but intermittent — 3/5 trials overdrew. Running more trials to establish a reliable rate.
[…]
=== 15 concurrent @ 90% of balance, 5 trials ===
  t1  amt=900.00   successes=5   bruce 1000.00 -> -3500.00  (implied 5.0 debits) <-- OVERDRAFT
[…]
  t3  amt=900.00   successes=1   bruce 1000.00 -> 100.00  (implied 1.0 debits)
[…]
OVERALL: 14/26 trials (54%) produced a real overdraft.

What the findings didn't cover

Safety guardrails blocked certain tests

Testing registration mass assignment required creating a new account. Our guardrails block account creation to ensure testing stays bounded only to approved accounts.

Missed in this run

The forgot-password lookup was also vulnerable to SQL injection, and the app accepted session tokens in URL parameters. Hound missed these instances but found related SQL injection and session-security flaws elsewhere in the app.

See the full report.

These examples are only part of the assessment. The full report documents the business impact, vulnerabilities, hardening recommendations, and testing coverage.

Open the report

View Aldercrest source on GitHub