Listen to this Post
Introduction:
The HackTheBox WhiteRabbit machine stands as a quintessential “Insane” rated challenge, presenting a real-world attack chain that pivots from a self-hosted status page to a critical SQL injection, culminating in the compromise of secure backup systems. This intricate simulation exposes how attackers can weaponize common administrative tools—like the monitoring platform Uptime Kuma and the automation tool n8n—against an organization’s own infrastructure. The final prize, accessed by reversing a time-based secret, highlights the delicate balance between operational security and convenience.
Learning Objectives:
- Understand how to enumerate and exploit misconfigured self-hosted services like Uptime Kuma to discover attack surfaces.
- Learn the technique for exploiting an HMAC-signed SQL Injection in an n8n webhook to gain initial access.
- Master the process of locating, accessing, and extracting credentials from a Restic backup repository for privilege escalation.
1. Initial Reconnaissance and Uptime Kuma Enumeration
Step-by-step guide explaining what this does and how to use it.
The attack surface begins with meticulous reconnaissance. After adding the target domain to the local hosts file (echo "10.10.11.63 whiterabbit.htb" | sudo tee -a /etc/hosts), subdomain enumeration is critical. A tool like `ffuf` can discover hidden subdomains, which often host administrative panels.
ffuf -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -u "http://whiterabbit.htb/" -H 'Host: FUZZ.whiterabbit.htb' -fs 0
This command may reveal subdomains like status.whiterabbit.htb, which often points to an Uptime Kuma instance. Uptime Kuma is a popular, open-source, self-hosted monitoring tool that tracks service availability and displays status pages. The key discovery here is that Uptime Kuma’s `/status/` endpoint can sometimes list monitored services or internal subdomains without authentication. Attackers can brute-force this path to find directories like /status/temp/, potentially leaking sensitive internal hostnames used for the next phase of the attack.
2. Discovering and Analyzing the n8n Automation Webhook
Step-by-step guide explaining what this does and how to use it.
The internal subdomains discovered often lead to other services. One common finding is an instance of n8n, a workflow automation platform. The target endpoint is typically a webhook configured to receive data. The core vulnerability lies in how this webhook processes authenticated requests. n8n supports various authentication methods for its HTTP Request nodes, including Header Authentication and Custom Auth with JSON. The target webhook was configured to expect an HMAC (Hash-based Message Authentication Code) signature to verify the request’s integrity and authenticity.
In a secure setup, the server generates an HMAC (e.g., using SHA-256) of the request body with a secret key and compares it to a value provided in the request headers. If the signatures match, the request is considered legitimate. The vulnerability occurs when this verification logic is flawed. An attacker can intercept a legitimate request, analyze its structure, and then manipulate it. The critical step is identifying that the SQL injection payload must be placed within the request body, and the correct `Content-Type` header (like application/json) must be set. The server’s flawed logic might only verify the HMAC if a specific header is present; if that header is removed, the verification is skipped entirely, but the injection point in the body is still processed. This allows the attacker to bypass authentication and pass malicious SQL directly to the backend database.
3. Exploiting the HMAC-Signed SQL Injection
Step-by-step guide explaining what this does and how to use it.
This is a multi-step exploitation process targeting the logic flaw in the webhook.
- Intercept and Analyze: Use a proxy like Burp Suite to capture a legitimate request to the n8n webhook URL. Observe the headers (especially any `X-Signature` or `Authorization` header) and the JSON body structure.
- Craft the Injection: The SQL injection often targets a parameter within the JSON body. A classic test payload is a time-based blind SQL injection. For example, modifying a JSON value:
{"query": "1' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)-- -"} - Bypass HMAC Verification: The crucial attack vector is to remove or alter the signature header. The server’s flawed code may only verify the HMAC if the header exists. By stripping it out, you might bypass verification while the application still processes the malicious body.
- Automate Data Exfiltration: Once confirmed, use `sqlmap` or a custom script to automate data extraction. You can feed the raw request to
sqlmap:sqlmap -r intercepted_request.txt --batch --level=5 --risk=3 --dbms=mysql --dbs
The goal is to extract database credentials, API keys, or—as in WhiteRabbit—credentials for the next target, such as a `backup` user.
4. Establishing Foothold and Hunting for Backups
Step-by-step guide explaining what this does and how to use it.
Credentials obtained from the database (e.g., for a `backup` user) typically grant SSH access. Once on the system, the next objective is privilege escalation. The first step is standard enumeration: checking running processes, scheduled cron jobs, and unusual files.
The discovery is often a Restic backup repository. Restic is a modern, encrypted backup program that deduplicates and secures data. The repository might be found in a user’s home directory (e.g., ~/backups). The attacker needs two things to access it: the repository password and the location. The password might be found in environment variables, configuration files, or shell history. The location is typically a local directory path.
To list snapshots in a found repository:
restic -r /home/backup-user/backups snapshots
If prompted for a password, use the one you’ve discovered. This command lists all backup snapshots, showing you what data is available and when it was captured.
- Restoring and Mining the Restic Backup for Secrets
Step-by-step guide explaining what this does and how to use it.
With access to the Restic repo, the attacker can explore its contents to find the final key to root. Restic provides powerful ways to browse and restore data.
- Explore the Backup: Instead of restoring everything, you can list files in a specific snapshot or search for interesting file names.
Find a specific file across all snapshots restic -r /path/to/repo find "id_rsa" --password-file secret.txt List contents of the latest snapshot restic -r /path/to/repo ls latest
- Targeted Restore: The goal is to find a secure note or script containing the root privilege escalation secret. Once identified, restore only that file.
restic -r /path/to/repo restore latest --target /tmp/restore --include /home/user/important_script.py
The `–include` flag ensures only the specified file is restored to the `/tmp/restore` directory.
-
Extract the Secret: The restored file is often a custom Python script that generates a one-time password based on the current server time. This requires the attacker to reverse-engineer the algorithm. By analyzing the code, you understand how it uses `datetime` or `time` modules to seed a random number generator. You must run the same algorithm on the target server (or simulate its time) to generate the valid current password for the `root` user, which can then be used via
su. -
Defensive Hardening: Securing Your Monitoring and Automation Stack
Step-by-step guide explaining what this does and how to use it.
The attack chain highlights critical defensive failures. Here’s how to secure each component:
Secure Uptime Kuma:
Network Isolation: Never expose Uptime Kuma’s admin interface (default port 3001) to the internet. Place it on a secured management VLAN.
Strong Authentication: Enforce complex passwords and consider placing it behind a VPN or bastion host. Be aware that Uptime Kuma lacks built-in Role-Based Access Control (RBAC) for multiple users, making the admin account a single point of failure.
Audit Public Endpoints: Regularly audit any public `/status` pages to ensure they do not leak internal information.
Secure n8n Webhooks & API Integrations:
Implement HMAC Correctly: If using HMAC verification, the server must recalculate the signature using the shared secret for every request and reject any mismatch unconditionally. The verification logic must be airtight, not dependent on the mere presence of a header.
Use Prepared Statements: All database queries triggered by webhook data must use parameterized queries or prepared statements to make SQL injection impossible.
Input Validation: Strictly validate and sanitize all data entering via webhooks before processing.
Secure Restic Backups:
Password Management: The repository password is the primary key. Store it securely in a enterprise password manager, not on the backup server itself. The forum post cited is a stark lesson: a lost password means lost backups.
Regular Restore Tests: As emphasized by the community, regularly test your ability to restore files from backups in an isolated environment. A backup is only as good as your last successful restore.
Repository Permissions: Ensure the file permissions on the Restic repository directory are restrictive, allowing access only to the necessary service account.
7. Proactive Monitoring for Attackers: A Pentester’s Perspective
Step-by-step guide explaining what this does and how to use it.
Ironically, the very tool exploited in this attack—Uptime Kuma—is also a powerful asset for defenders and penetration testers. Ethical hackers use it to monitor their own infrastructure during engagements.
Setup for Operational Security (OpSec): Pentesters can quickly deploy a personal Uptime Kuma instance using Docker to monitor their critical attack infrastructure (e.g., C2 servers, VPN endpoints).
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1
Configuration for Alerting: Configure monitors for HTTP, TCP, and Ping checks on your servers with short heartbeat intervals (e.g., 60 seconds). Set up notifications via Telegram, Slack, or email to be alerted instantly if your infrastructure is taken down by a defender’s block rule or suffers an outage. This allows for rapid reaction and service continuity, which is crucial during time-sensitive assessments.
What Undercode Say:
The Vulnerability is in the Integration: The most critical flaw is rarely in the core application (Uptime Kuma, n8n, Restic) itself, but in their custom, in-house integration code. The HMAC verification logic in the n8n webhook was a custom script with a fatal logic error.
Backups Are a Tier-0 Asset: A backup system must be considered as critical as your primary authentication system. If an attacker can read your backups, they can eventually control everything. The security of the backup password and the integrity of the restore process are non-negotiable.
The analysis underscores that modern attack chains are increasingly “meta,” exploiting the operational and management tools that organizations deploy for efficiency. The line between administrator and attacker blurs when both use the same tools. Defense, therefore, must shift from just hardening individual services to securing the complex, automated workflows that connect them. This requires treating internal automation scripts with the same security rigor as public-facing applications, implementing strict code review and testing for business logic flaws that can become game-over vulnerabilities.
Prediction:
The WhiteRabbit attack chain foreshadows the future of advanced persistent threats (APTs), where attackers will increasingly target the “puppeteer systems”—the automation, monitoring, and DevOps platforms that orchestrate an enterprise’s digital environment. As organizations rely more on tools like n8n, Apache Airflow, Rundeck, and centralized logging, these systems will become high-value targets because compromising one can often lead to the silent takeover of the entire infrastructure they manage. Future attacks will involve poisoning CI/CD pipelines, injecting malicious steps into automation workflows, and manipulating backup systems not just for data theft but for persistent, undetectable re-entry. Defenders will need to adopt a “zero-trust” approach for machine-to-machine communication within their own networks, rigorously applying authentication, segmentation, and audit logging even for internal administrative traffic.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: 0xdf Htb – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
