Case Studies / Hospitality & PCI DSS

Autonomous External Penetration Test

How Prancer SwarmHack mapped an internet-facing perimeter, proved a Redis breach, followed the pivot, and demonstrated where PCI segmentation stopped the attack.

Prove the attack path. Prove the defense.

*How Prancer SwarmHack mapped an internet-facing perimeter, followed the successful pivot, proved what an attacker could actually reach — and proved where the defense stopped it. A scanner finds the vulnerability. Prancer proves what it leads to.*

At a glance

| | |

| --- | --- |

| Client | Harborview Mountains *(name changed for publication; sanitized sample of a lab reproducing a real PCI external test)* |

| Industry | Hospitality (card-present / cardholder data environment) |

| Engagement | Unauthenticated external network penetration test |

| Standard | PCI DSS 4.0 Requirement 11.4.3 (annual external testing evidence) |

| Scope | 39 in-scope addresses (26 responsive) |

| Platform | Prancer SwarmHack (autonomous kill-chain engine, human-reviewed) |

| Time to first breach | Day 1 |

| Overall risk rating | CRITICAL |

| Attack results | 6 findings · 1 Exploited (proven) · 3 Observed · 2 Simulated |

| Defense results | Perimeter → CDE segmentation Control-Blocked; CDE data services Unreachable |

All addresses use the RFC 5737 documentation range 203.0.113.0/24; the client name has been changed for publication, and addresses and credentials are fictional or redacted. Methodology, findings, evidence grades, and remediation are reproduced intact from a representative deliverable.

Executive summary — for the CISO

  • The perimeter fell on day one. An internet-exposed Redis cache accepted unauthenticated connections and allowed arbitrary command execution — the one finding graded Exploited, with captured, reproducible proof. No credentials were required.
  • The remaining exposures are unforced errors: a default vendor credential on an internet-facing MySQL server, a live access token leaking in an unauthenticated event stream, default FTP credentials, and a blind SQL-injection oracle on the corporate site.
  • The defense also produced a result. Segmentation between the perimeter and the cardholder data environment was Control-Blocked — the internal database and directory were Unreachable from the perimeter vantage. Knowing what stopped the attack is as valuable as knowing what worked.
  • Every finding is graded by evidence, not severity theatre. Attacks are graded Exploited → Observed → AttackPathIdentified → Simulated; defenses Proven → Control-Blocked → Unreachable. If it isn't proven, it doesn't publish, and "Critical" is reserved for proven evidence.
  • Compliance outcome: satisfies PCI DSS 4.0 11.4.3, with segmentation testing (11.4.7) and a remediation-retest path (11.4.5) built in.
  • Three actions, in order: (1) take Redis off the internet or enforce auth + ACLs, (2) kill the MySQL default account and restrict its source, (3) close the leaking event stream and rotate the exposed token.

The challenge

Harborview operates a cardholder data environment and must produce annual external penetration-test evidence under PCI DSS 4.0. Like most organizations, its real exposure was not a single dramatic vulnerability but an accumulation of small perimeter mistakes — services that drifted onto the public internet, vendor defaults never rotated, data leaking through modern streaming endpoints nobody thought to authenticate.

Conventional external attack-surface tooling hands back a list of *maybes*: a CVE feed cross-referenced against banner grabs, ranked by a severity number nobody has proven applies to the actual host. The security team then burns scarce hours triaging theory. Harborview needed the opposite — a test that proves what an attacker can actually reach, distinguishes it from what is merely exposed, and reports where the defense held with equal rigor.

The approach

The engagement ran on the SwarmHack autonomous kill-chain platform under operator supervision, from a single external vantage equivalent to an attacker scanning Harborview's public footprint. The output of one attack becomes the input to the next: attack surface → exploit → credential → identity → pivot → security boundary → control-blocked or crossed → critical asset. SwarmHack is a swarm of specialized agents that plan their own path across six phases, split into a web lane and a network lane after an authorization check.

flowchart TD
    A["🔐 Authorization verify<br/>signed envelope · named targets · ≤24h expiry"] --> B["Port & service discovery<br/>nmap + native TCP fallback"]
    B --> C["Host recon"]
    C --> WEB
    C --> NET

    subgraph WEB["WEB LANE"]
        direction TB
        W1["crawler"] --> W2["auth testing"] --> W3["~22 deep vuln scanners<br/><i>each exploits inline</i>"]
    end

    subgraph NET["NETWORK LANE — 6 credential-ordered passes"]
        direction TB
        N1["1 · anonymous discovery"] --> N2["2 · credential production"]
        N2 --> N3["3 · authenticated re-enum"]
        N3 --> N4["4 · authenticated exploitation"]
        N4 --> N5["5 · lateral movement"]
        N5 --> N6["6 · domain dominance"]
    end

    WEB --> J["💎 Crown-jewel extraction"]
    NET --> J
    J --> K["Amplification loop<br/>validate · replay · escalate · re-discover"]
    K --> L["merge · dedup · authenticity grading"]
    L --> M["Evidence Architecture<br/><i>if it isn't proven, it doesn't publish</i>"]
    M --> R["📄 OCSF report · Markdown · interactive HTML graph"]

    classDef gate fill:#1f2a44,stroke:#3b5bdb,color:#dbe4ff;
    class A,M gate;

Two properties of the engine shaped this engagement:

  • Attack, pivot, prove — chaining is real, not narrated. Captured credentials automatically re-seed authenticated re-crawls; SSH lateral movement triggers the instant credentials and internal hosts coexist; discovered internal networks are scanned recursively through the tunnels opened during the run. The Redis foothold became the pivot for internal-segment reachability testing.
  • The Evidence Architecture gates every claim. Fingerprints, enumeration stats, and skip-notices route to an honest intelligence-context block instead of being dressed up as findings. What reaches the report either carries a crown jewel or is genuinely proven — nothing silently deleted, nothing silently promoted.

The whole engagement ran inside a signed authorization envelope (named targets, short expiry, tester identity, contract reference). No destructive techniques were used; credential testing was bounded to known-default and small custom lists — never brute force.

The engagement: attack path

The engine started external and unauthenticated, mapped the perimeter, exploited what it could *prove*, and followed the pivot toward the crown jewels. The full path, colored by evidence grade:

flowchart LR
    V["🛰️ External vantage<br/>203.0.113.99<br/><i>unauthenticated</i>"]

    subgraph PERIM["PERIMETER — exposed services"]
        direction TB
        REDIS["cache · Redis<br/>203.0.113.20:6379"]
        MYSQL["reporting DB · MySQL<br/>203.0.113.19:3306"]
        SSE["booking · web/API + SSE<br/>203.0.113.18"]
        FTP["partner drop box · FTP<br/>203.0.113.21:21"]
        WWW["corporate site · HTTP<br/>203.0.113.17"]
        BASTION["bastion · SSH<br/>203.0.113.14:2222"]
    end

    subgraph CDE["INTERNAL CDE — behind segmentation"]
        direction TB
        DIR["directory · LDAP<br/><i>Unreachable</i>"]
        CDEDB["cardholder DB · MySQL<br/><i>Unreachable</i>"]
        POS["🏆 pos-ctrl · POS controller<br/>CROWN JEWEL"]
    end

    V --> REDIS
    V --> MYSQL
    V --> SSE
    V --> FTP
    V --> WWW
    V --> BASTION

    REDIS -. "foothold / pivot" .-> BASTION
    BASTION == "Control-Blocked<br/>data services unreachable" ==x CDE
    BASTION -. "probable, NOT proven<br/>(weak cred reuse)" .-> CDEDB
    CDEDB -. .-> POS

    classDef exploited fill:#b3261e,stroke:#7a1712,color:#fff;
    classDef observed fill:#b26a00,stroke:#7a4700,color:#fff;
    classDef simulated fill:#4a4f57,stroke:#2f333a,color:#fff;
    classDef jewel fill:#1f6f3a,stroke:#124023,color:#fff;
    classDef held fill:#233b2a,stroke:#1f6f3a,color:#cfe9d6;

    class REDIS exploited;
    class MYSQL,SSE observed;
    class FTP,WWW,BASTION simulated;
    class POS jewel;
    class DIR,CDEDB held;

Red is *proven* (Exploited). Amber is *confirmed by the server's own behavior* (Observed). Grey is *indicated but not confirmed against this host* (Simulated). Green marks the crown jewel and the segmentation boundary that was Control-Blocked — the cardholder database and directory were Unreachable from the perimeter. The dashed bastion→database line is deliberately not red: the same weak password had been seeded on the bastion and internal services in the client's last audit, so the hop is probable — but the SSH credential test couldn't conclusively grade it this round, so it is reported as probable, not proven.

Know what worked. Know what stopped it.

Attack results — graded by evidence

| ID | Finding | Host | Severity | Evidence grade | CWE |

| --- | --- | --- | --- | --- | --- |

| EX-01 | Unauthenticated Redis command execution | 203.0.113.20:6379 | Critical | 🔴 Exploited | CWE-306 |

| EX-02 | Default credentials on exposed MySQL | 203.0.113.19:3306 | High | 🟠 Observed | CWE-798 |

| EX-04 | Access token leaked in SSE event stream | 203.0.113.18 | High | 🟠 Observed | CWE-200 |

| EX-05 | Unattended perimeter devices (IP cam, raw print) | 203.0.113.23/.24 | Medium/Low | 🟠 Observed | CWE-200 / 489 |

| EX-03 | Default credentials on FTP drop box | 203.0.113.21:21 | High | ⚪ Simulated* | CWE-798 |

| EX-06 | Time-based (blind) SQL injection | 203.0.113.17 | High | ⚪ Simulated | CWE-89 |

\* *EX-03's login exchange completed and the default pair was accepted; the captured transcript is being re-graded under an evidence-standard refresh, and is held at Simulated until the grade is settled.*

Findings by evidence grade — only one finding is proven end-to-end, and that ratio is the point:

pie showData
    title Findings by evidence grade
    "Exploited (proven)" : 1
    "Observed (server-confirmed)" : 3
    "Simulated (indicated)" : 2

Findings by severity — one Critical, but a *proven* one:

pie showData
    title Findings by severity
    "Critical" : 1
    "High" : 4
    "Medium / Low" : 1

Defense results — proving the defense is also a result

| Boundary tested | Result | Evidence |

| --- | --- | --- |

| Perimeter → CDE segmentation | 🟢 Control-Blocked | Filtering confirmed by network probes from the foothold |

| CDE cardholder database & directory | 🟢 Unreachable | Not reachable from the perimeter vantage on the tested path |

*Proven / Control-Blocked / Unreachable — within the tested path and authorized scope.*

The finding that mattered: EX-01, Redis

Without any credential, the platform connected to the Redis instance and executed commands in the server's context, with captured output proving execution. A cache holding session data hands an attacker live session tokens — potential account takeover for every guest session present — and a foothold on the perimeter network. Remediation, in order: pull the port off the public internet, enable requirepass + protected-mode, rotate all stored session tokens, and place Redis behind an authenticated application tier.

Why the defense result matters

From the Redis foothold, the platform followed the pivot toward the internal segment. The segmentation boundary was Control-Blocked: the cardholder database and directory were Unreachable from the perimeter vantage, and the network probes confirmed the filtering — exactly the separation PCI DSS 1.2.1 expects.

For a CISO, this is worth as much as the breach. It means the answer to *"did they reach the card data?"* is a defensible no, not on this path — backed by the same evidence discipline that produced the red finding. The full internal chain was not completed this round because the SSH credential test couldn't conclusively grade the bastion; Prancer flags that as a tooling limitation and completes the leg at no additional cost in the remediation-verification round — rather than papering over the gap.

Compliance outcome — PCI DSS 4.0

| Requirement | Status | Evidence |

| --- | --- | --- |

| 11.4.3 external test annually | ✅ Satisfied | This report is the evidence |

| 11.4.4 exploit vulns found in 11.4.3 | ✅ Performed | EX-01 exploited; EX-02/EX-04 confirmed |

| 11.4.5 remediation + retest | ⏳ Pending | Retest window included |

| 11.4.7 segmentation testing | ◐ Partial | Perimeter→CDE Control-Blocked; internal path incomplete |

| 1.2.1 CDE↔untrusted segmentation | ✅ Effective | CDE data services Unreachable from perimeter |

| 2.2.7 / 8.3.x default creds & strong passwords | ❌ Failed on 2 systems | EX-02, EX-03 |

| 6.2.4 / 6.3.1 secure development | ⚠️ Attention | EX-06 (SQLi), EX-04 (token in stream) |

Also mapped in the deliverable: NIST CSF, OWASP Top 10 2021 (EX-06 → A03 Injection, EX-04 → A01 Broken Access Control, EX-02/03 → A07 Auth Failures), and MITRE ATT&CK.

Built to execute. Not just recommend.

The engagement exercised a narrow slice of the engine's 85 registered plugins / 102 agent capabilities — spanning web (SQLi, command injection, SSRF, request smuggling, WAF bypass), network and service handshakes, cloud/container/CI-CD (Jenkins RCE, Docker escape, AWS IAM pivot), Active Directory / Entra, security-service-edge, and robotic/physical surfaces. An IntelligenceBus shares typed discoveries across agents, and learning is local and model-free (deterministic rule tables, an HNSW pattern index, per-run success ledgers) — no cloud models, no data leaving the client environment.

But the load-bearing feature was the Evidence Architecture — model intelligence proposes, Prancer executes, evidence decides:

| Attack grade | Meaning |

| --- | --- |

| Exploited | Attack chain succeeded; captured, reproducible proof |

| Observed | The server's own responses confirm the exposure |

| AttackPathIdentified | Reachability proven; effect not executed (safety doctrine) |

| Simulated | Probe-level indication; always listed with the oracle that fired |

Two automated enforcers back it: an Exploited label without captured output is downgraded, and Critical severity is reserved for proven evidence — a version-match guess can never masquerade as an exploitation. Finding validation uses Byzantine consensus with Ed25519-signed votes, and evidence is bound with SHA-256 for audit replay.

Proof at scale. In a controlled live-fire environment — 200 hosts, 45 findings, 19 exploited, 13 critical, a 4-hop IAM attack path, and 66 crown-jewel objects — the same engine ran the complete unauth web RCE → service credentials → host root → IAM credential holder chain, every exploited claim traced to seeded ground truth, with zero detections by the cloud provider's native threat detector.

Prove it. Fix it. Prove it again.

  • A risk register that can be acted on in priority order — one proven Critical, a handful of server-confirmed exposures, a couple of leads worth a developer's afternoon, and a boundary confirmed Control-Blocked.
  • Audit-ready evidence. Every claim carries its grade and its proof; the deliverable maps cleanly onto PCI DSS 4.0, NIST CSF, OWASP, and MITRE ATT&CK.
  • Trust in both directions. The test is as rigorous about what *stopped* the attack as about what broke through — which is what makes "no, they didn't reach the card data" defensible.
  • Continuous validation. A pentest finding can become a regression test: attack → pivot → prove → remediate → re-run → prove closed.

The perimeter was breached in a day. The more valuable outcome is that Harborview now knows exactly which of its assumptions were true — and can prove it.

*Prepared from a sanitized sample engagement run with Prancer SwarmHack against a lab environment that reproduces the target classes of an external PCI DSS 4.0 11.4.3 test. The client name has been changed for publication; addresses and credentials are fictional or redacted. The evidence-grading model, methodology, finding structure, and remediation guidance are representative of a real deliverable.*

*Prove the attack path. Prove the defense. — Learn more at prancer.io · Autonomous Penetration Testing · Evidence Architecture · SwarmHack · Request a demo.*