FAQ - CTF Wordlists for XML-RPC

What is XML-RPC and why target it?

XML-RPC is a remote procedure call protocol that encodes its calls in XML and sends them over HTTP. WordPress exposes an XML-RPC endpoint at xmlrpc.php to support features such as remote publishing, the WordPress mobile app, and Jetpack integrations.From a security perspective, xmlrpc.php is an attractive target because:

It accepts wp.getUsersBlogs and similar method calls that validate a username and password on every request.
It is enabled by default on most WordPress installations and is often forgotten by administrators.
It does not enforce the same brute-force lockout policies that protect the standard wp-login.php endpoint in many configurations.
A single HTTP POST can attempt one credential pair, making it straightforward to automate at scale.

In a lab or CTF context, the XML-RPC endpoint is commonly configured as the intended attack surface specifically because of these properties.

Can I use these wordlists on any website?

No. You may only use these wordlists against systems you are explicitly authorized to test.Authorized targets include:

Your own local virtual machines or containers
CTF challenge machines on platforms such as Hack The Box or TryHackMe
Lab environments set up by an instructor who has granted written permission
Systems named in a signed penetration testing scope-of-work document

Running a brute-force attack against any website without authorization — even a small personal blog — is illegal under computer misuse and unauthorized access laws in most countries. See the Legal Notice for details.

What is the difference between WPScan and Hydra for this task?

Both tools can perform credential brute-force attacks against WordPress XML-RPC, but they differ in design and behavior:

Aspect	WPScan	Hydra
Purpose	WordPress-specific scanner	Generic network login brute-forcer
XML-RPC support	Native `--password-attack xmlrpc` mode	Requires a custom POST form template
WordPress awareness	Enumerates users, plugins, themes automatically	No WordPress-specific logic
Output	Structured report with vulnerability context	Raw credential hits
Typical use	Full WordPress audit in a lab	Targeted credential testing on any HTTP form

WPScan is the preferred tool for WordPress lab exercises because it understands the application and handles the XML-RPC protocol details for you. Use it with --password-attack xmlrpc to keep requests well-formed.Hydra is useful when you need fine-grained control over the HTTP POST body, want to reuse the same toolchain across non-WordPress targets, or need to test a customized XML-RPC method name.

Start with WPScan. Switch to Hydra if you need to modify the raw XML payload or if WPScan is unavailable in your lab environment.

How do I verify XML-RPC is enabled on my lab target?

Send a system.listMethods request with curl. A properly enabled endpoint returns an XML response listing all available methods.

curl -s -X POST http://TARGET/lab/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Enabled and listing methods — the response body starts with:

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <params>
    <param><value><array>...

Enabled but GET not accepted — a plain GET request to xmlrpc.php returns:

XML-RPC server accepts POST requests only.

This message still means XML-RPC is enabled — it just requires a POST. Use the curl -X POST command above to confirm the endpoint responds to valid requests.Disabled or blocked — you receive a 403, 404, or a redirect away from xmlrpc.php. Double-check the WordPress installation subdirectory (e.g., /lab/, /wordpress/, or the root /).

Replace TARGET with the IP address or hostname of your lab machine and adjust the path to match your installation.

Why are there both real names and numbered usernames in users.txt?

users.txt covers two distinct categories of WordPress usernames commonly found in lab and CTF scenarios:Real-name usernames — Common first names and role-based names (e.g., admin, john, alice, developer, sysadmin, webmaster). These reflect realistic corporate or personal WordPress deployments where site owners use recognizable identifiers.Numbered usernames — Patterns such as user1, user2, test01, student10. These are typical of CTF challenge machines and educational lab setups where an instructor created accounts programmatically or used a simple naming scheme.Including both categories increases coverage across the two most common target types you will encounter: realistic simulated environments and purpose-built challenge boxes.

How do I add my own entries to the wordlists?

Both users.txt and passwords.txt are plain text files with one entry per line. Open either file in any text editor and append your entries.

# Add a single username
echo "ctfplayer" >> users.txt

# Add multiple passwords at once
cat >> passwords.txt << 'EOF'
LabPass2024
Summer@Lab1
P@ssw0rd!
EOF

After editing, verify there are no blank lines at the end of the file that could cause tools to send empty credential attempts:

wc -l users.txt passwords.txt

If you discover the target has a custom username during enumeration (e.g., from an author page or a WPScan user scan), prepend it to the top of users.txt so it is tried first and you save time on subsequent runs.

The attack is finding too many false positives or running too slow — what should I do?

Too slowIncrease the thread count. Both WPScan and Hydra default to conservative concurrency. Start lower if the lab VM is underpowered, then increase until you hit the VM’s limit:

# WPScan — increase threads
wpscan --url http://TARGET/lab/ \
  --passwords passwords.txt \
  --usernames users.txt \
  --password-attack xmlrpc \
  --max-threads 100

# Hydra — increase tasks (-t)
hydra -L users.txt -P passwords.txt TARGET http-post-form \
  "/lab/xmlrpc.php:...PAYLOAD...:Incorrect username or password" \
  -t 100

Too many false positives (Hydra)Hydra identifies a “hit” by the absence of the failure string. If your failure string does not exactly match the XML-RPC error message on your target, every request looks like a success.

Run a single known-bad attempt manually and capture the response:

curl -s -X POST http://TARGET/lab/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value><string>wronguser</string></value></param><param><value><string>wrongpass</string></value></param></params></methodCall>'

Copy the exact error text from the response (e.g., Incorrect username or password.) and paste it as the failure string in your Hydra command.

Never raise thread counts beyond what your lab environment can handle. Flooding the VM with requests may crash it and require a reset, which wastes your testing time.

What should I do after finding valid credentials in a lab?

Finding valid credentials is the end of the brute-force phase, not the end of the exercise. Follow these steps to complete the lab properly:

Document the finding

Record the exact username and password you found, the time of discovery, the command you used, and the number of attempts it took. This information belongs in your lab report.

Verify access

Use the credentials to log in to the WordPress admin panel (/wp-admin/) and confirm the level of access granted. Note the user role (subscriber, editor, administrator) as it determines what you can do next in the exercise.

Complete the lab objective

Follow the CTF challenge or lab instructions to capture the flag or demonstrate impact (e.g., post a page, access a protected area, retrieve a file). Do not perform actions beyond the defined scope.

Write your report

Summarize the attack path: target identification, XML-RPC enumeration, brute-force approach, credentials found, and impact. Good lab reports form the basis of professional penetration testing deliverables.

Reset and clean up

Remove any accounts, posts, or files you created during the exercise. If the lab provides a reset function, use it. Leave the environment in the same state you found it so the next user starts fresh.

In a real engagement, you would stop immediately after confirming access and report the finding to the client. Never use discovered credentials to explore beyond the agreed scope, even in a professional context.

Documentation Index