Dismantling a Ransomware Collective's Dark Web Leak Site
Event: Sisterhood of the Travelling Packets CTF | Flare, SANS, and WiCyS
Flag: flare{...} (redacted)
Overview
This weekend I participated in the Sisterhood of the Travelling Packets CTF, a beginner-friendly capture-the-flag challenge built by Flare, SANS, and WiCyS. The premise: a careless ransomware collective called pantalones got sloppy, and it was our job to expose their OPSEC failures through forensics, exploitation, and decoding.
The entire challenge was browser-based, conducted through the Tor browser against a simulated dark web ransomware leak site. No paid tools or prior CTF experience were required, just curiosity and persistence.
Phase 1: Reconnaissance
The challenge began with a .onion URL leading to the pantalones leak site. The site featured a dark, intimidating interface with a tagline: “stealing your files since ‘26.”
The main page listed several victim companies, some with active countdown timers and others already marked as LEAKED:
- Sisterhood of the Travelling Packets — NEW (with countdown)
- NexaVista Solutions — countdown active
- StratifyTech Inc. — countdown active
- Lumenisys Global — countdown active
- QuantumCore Systems — LEAKED
- AetherFlow Enterprises — LEAKED
The two leaked victims had downloadable data archives containing SQL dumps, internal communications, API keys, and proprietary algorithm data.
I started by exploring the site structure. The navigation bar had three visible links: LEAKS, CREW, and ABOUT.
Phase 2: OSINT on the Crew
The CREW page revealed four members of the collective:
| Handle | Role |
|---|---|
| vex | operator / panel dev |
| crypt | payload engineer |
| mora | negotiations |
| skid | initial access |
The ABOUT page described the group as “a collective of four best friend hackers, united in 2026.” Notably, vex was responsible for building and maintaining the panel, making their development shortcuts the primary attack surface.
Phase 3: Analyzing the Exfiltrated Data
I downloaded the leaked data from both QuantumCore Systems and AetherFlow Enterprises. The archives contained six files total:
customers.sql— Customer contracts and contact infoemployees.sql— Full employee records including salary and SSN hashesfinancial_summary_q1_2026.sql— Detailed financial transactionsroute_algorithms_PROPRIETARY.sql— Proprietary ML model hyperparametersapi_keys_internal.yaml— Plaintext API keys, database credentials, and secretsinternal_comms.csv— Internal Slack-style chat logs
OPSEC Failure #1: Mixed Victim Data
The API keys file referenced AetherFlow (aetherflow.ctf) as the company, but the employee database contained records for QuantumCore (quantumcore.ctf). The ransomware group had carelessly mixed data from two separate victims into overlapping archives, a significant OPSEC failure that could help law enforcement correlate their operations.
OPSEC Failure #2: Suspicious Internal Comms
In the internal communications CSV, an out-of-place message appeared from i.mccarthy (the victim company’s IT Director):
“stein. i really don’t care at all. can you please stop pinging me.”
This message appeared at the exact same timestamp (2026-05-08 16:30) as an urgent security alert about unauthorized login attempts from Tor exit nodes. The message was chronologically out of order and read like something sent to the wrong channel, a potential indicator that the threat actor had compromised McCarthy’s account and accidentally sent a personal message through it.
Phase 4: Discovering Hidden Endpoints
Next, I checked for a robots.txt file by navigating to /robots.txt on the .onion site. The response revealed two disallowed paths:
1
2
3
User-agent: *
Disallow: /api.php
Disallow: /admin.php
Classic mistake. Using robots.txt to hide sensitive paths actually advertises them to anyone who checks. This immediately gave me two new targets: the API and the admin panel.
Phase 5: Exploiting the Unauthenticated API
Navigating to /api.php returned:
1
2
3
4
{
"error": "missing required parameter: action",
"valid_actions": ["upload", "status", "messages", "decrypt", "wallets", "payloads", "exfil"]
}
The API was completely unauthenticated. No tokens, no keys, no session validation. I enumerated every endpoint:
/api.php?action=status— Revealed panel version, uptime (14 days), 3 active nodes, and two operators currently online (vex and crypt)./api.php?action=wallets— Exposed their primary Bitcoin wallet address, total received (27.84 BTC), rotation schedule, and mixer configuration./api.php?action=payloads— Listed staged ransomware payloads targeting StratifyTech and Lumenisys, including dropper types and file hashes./api.php?action=exfil— Showed completed exfiltration jobs with sizes and timestamps for all three compromised organizations./api.php?action=decrypt— Required avictim_idparameter with a specific format (e.g.,NXV-2026-041)./api.php?action=messages— Required aconversation_idparameter.
Phase 6: Enumerating Internal Chat Logs
The messages endpoint accepted sequential integer conversation_id values. By iterating through IDs (conversation_id=0, 1, 2, etc.), I was able to dump the crew’s entire internal chat history. This revealed a treasure trove of OPSEC failures:
OPSEC Failure #3: No Auth on the Admin Panel
In conversation 1, crypt directly called out vex:
crypt: “cool. did you at least put auth on admin.php this time????!!????????!!!????”
vex: “its behind tor who cares. nobody is finding it”
Security through obscurity at its finest.
OPSEC Failure #4: Exfil Script Left in Published Data
Crypt warned the crew that vex had accidentally left their .exfil.sh script inside the AetherFlow data archive, complete with the panel URL and API endpoint. Vex dismissed it because “its a dotfile tho so nobody will see it probably.”
OPSEC Failure #5: Base64-Encoded Password in Chat
This was the critical find. In conversation 3, mora asked crypt for their FTP password:
crypt:
UGFudGFsMG4zc19SdWwzeiE=— thats YOUR password mora. i encoded it this time, figure it out yourself.
mora: “ive been using this password since 2011 and nobody has cracked it yet so i think im good lol”
Decoding the Base64 string:
1
echo "UGFudGFsMG4zc19SdWwzeiE=" | base64 -d
Result: Pantal0n3s_Rul3z!
A password reused since 2011, shared in plaintext (barely obscured with Base64), in a chat log exposed by an unauthenticated API. Multiple OPSEC failures stacked on top of each other.
Phase 7: Accessing the Admin Panel
With mora’s credentials in hand, I navigated to /admin.php and logged in:
- Username:
mora - Password:
Pantal0n3s_Rul3z!
Access granted. The admin panel contained the flag and confirmed the full compromise of the pantalones collective’s infrastructure.
Summary of OPSEC Failures
| # | Failure | Severity |
|---|---|---|
| 1 | Mixed victim data across archives | Medium |
| 2 | robots.txt exposed hidden endpoints |
High |
| 3 | API completely unauthenticated | Critical |
| 4 | Admin panel exposed with no access controls | Critical |
| 5 | Internal chat logs accessible via API enumeration | Critical |
| 6 | Credentials shared (Base64 “encoded”) in chat | Critical |
| 7 | Password reused since 2011 across all services | High |
| 8 | Exfil script left in published victim data | Medium |
Lessons Learned
This challenge was a great hands-on exercise in thinking like a threat intelligence analyst. The pantalones collective made mistakes that real ransomware groups make every day:
- Obscurity is not security. Hiding paths in
robots.txtor relying on Tor for access control is not authentication. - APIs need authentication. Exposing internal endpoints without any form of access control is an invitation for enumeration.
- Credential hygiene matters, even for attackers. Sharing passwords in chat, reusing them for over a decade, and using Base64 as “encryption” are failures that law enforcement and researchers routinely exploit during takedowns.
- Operational security is a team sport. One careless member (vex) undermined the entire operation despite crypt’s repeated warnings. The weakest link defines the group’s security posture.
Tools Used
- Tor Browser
- Terminal (Base64 decoding)
- Manual API enumeration
This writeup documents my participation in the Sisterhood of the Travelling Packets CTF (August 17-19, 2026), organized by Flare, SANS, and WiCyS.