HTB Crocodile — The Credential Chain

Part of the OSAI Prep series → — HTB writeups mapped to OWASP LLM Top 10.

Machine Summary

Reconnaissance

We run a default nmap scan against the target.

nmap -sC -sV -oN nmap.txt 10.129.43.115

Two open ports come back:

• Port 21 (FTP) — anonymous login allowed (flagged by nmap’s default scripts)
• Port 80 (HTTP) — a webpage

Anonymous FTP plus an exposed webpage on the same host is a classic combination — anything FTP leaks is going to be useful against the web service.

Initial Foothold

We log into the FTP server anonymously and list the directory.

Two files are sitting in the share. Both look like credential material — exactly the kind of file that should never be reachable through anonymous FTP.

We download them with get:

This is good information for us to have. Now we go enumerate port 80.

The webpage is a brand site with no obvious login link. We use gobuster to find directories or files of interest, including .php extensions:

gobuster dir -u http://10.129.43.115 -w /usr/share/wordlists/dirb/common.txt -x .php

Gobuster surfaces a login.php page that wasn’t linked from public navigation.

We log in using the credentials from the FTP files.

Authenticated access. Flag retrieved.

Privilege Escalation

Not required. The objective was authenticated access to the web admin panel, achieved entirely via reused credentials harvested from FTP. No shell, no kernel work, no lateral movement.

Root Cause

This box is a chain of two misconfigurations that compound:

1. anonymous_enable=YES on the FTP service exposed credential files to anyone on the network.
2. Hidden does not mean protected — the admin panel was unlinked from public navigation, but credentials harvested elsewhere unlocked it instantly.

Anonymous FTP shouldn’t be on a server holding sensitive files. Beyond that, an admin panel that depends solely on a single set of credentials to gate access — with no second factor, no IP allowlist, no out-of-band check — accepts any caller who can present those credentials, regardless of how they got them.

The AI Equivalent

Here we see two things — first the anonymous login, which we’ve seen on other machines, ties to LLM06 Sensitive Information Disclosure: open models in dev that don’t require authentication, where an attacker can extract relevant info or poison the models.

The second is using that information to legitimately log in on an admin page — in the agentic world, that’s an exposed /v1/chat/completions endpoint with a default API token (or no token at all) that lets any caller send arbitrary instructions to the model, modify its system prompt, or extract its configuration. The attacker, with the initial information obtained, can cause real problems.

OWASP LLM Top 10 Mapping: LLM06 (Sensitive Information Disclosure) chained into LLM08 (Excessive Agency)

The Crocodile chain is two distinct failures stitched together — and the second is the more dangerous one in production AI deployments. Stage one, anonymous FTP, is the classic LLM06 pattern: a development debug endpoint, an unauthenticated telemetry pipe, or an open RAG corpus accidentally leaking API keys, system prompts, or vector store credentials embedded in indexed documents.

Stage two — and this is where it gets ugly — is that those leaked credentials legitimately authenticate into the production agent’s tool-use endpoints. From the control plane’s perspective, every privileged call from there looks like a real operator: the API key is valid, the request is well-formed, the actions are within scope. There’s no out-of-band verification of who is holding the key.

This is structurally the same failure as Crocodile’s login.php — valid credentials equal full trust, regardless of provenance. The defense, for both web admin panels and agentic systems, is the same: treat credentials as one factor, not the whole authentication story.

Lessons Learned

• Disable anonymous FTP everywhere. vsftpd ships with anonymous_enable=NO by default. If it’s on, someone turned it on; revert it and audit anything else that may have been relying on it.
• Never store plaintext credentials in shared storage. Even on internal-only file shares, plaintext userlist files are an enumeration aid. Use a secrets manager (Vault, AWS Secrets Manager, Doppler) — not text files.
• Hidden ≠ secured. Admin panels not linked from public navigation are still found by gobuster, ffuf, dirb, and Wayback Machine in seconds. Treat every endpoint as discoverable.
• Add a second factor to admin panels. Single-credential authentication is the same trust model as Crocodile’s login form. TOTP, WebAuthn, or a strict IP allowlist breaks the credential-chain attack — leaked creds become useless without the second factor.
• Audit which credentials live where. The FTP files contained credentials valid for the web app. That’s a reuse problem. Run periodic scans for credential material across every storage system you operate; the goal is “no one set of creds opens two doors.”