Operational Note — VHost Enumeration, DNS Behavior, and Tooling Discipline

2025-12-02 — Operational Lab Note

By RON1N01

Today I focused on sharpening my understanding of DNS behavior, virtual host discovery, and how enumeration tools behave under different network conditions. These details matter. They form the foundation of disciplined red team execution, and I continue to refine my operational awareness through deliberate practice.

DNS Behavior and NetworkManager

I began the session by troubleshooting why my Kali VM was resolving DNS differently than what was written in /etc/resolv.conf. I confirmed that NetworkManager has priority in this setup. The actual DNS in use is revealed with:

nmcli device show | grep DNS

I tested toggling the ipv4.ignore-auto-dns setting.

  • When set to yes, NetworkManager uses my manually defined DNS.
  • When set to no, it uses what DHCP or the VPN provides.

Resetting to defaults made the system use /etc/resolv.conf again, which confirmed the behavior. Understanding this chain of resolution is essential because enumeration tools rely directly on the system resolver.

Hostname Resolution on TryHackMe

I ran into an issue where offensivetools.thm was not resolving inside my VM. I confirmed that .thm domains do not use DNS. These hostnames are resolved because the OpenVPN config injects them into /etc/hosts. When this fails, manual mapping is required:

10.x.x.x offensivetools.thm

I also confirmed that this method only resolves the exact hostname I add. It does not support wildcards and therefore does not resolve subdomains.

This explains why DNS brute-force returns nothing on TryHackMe machines. The subdomains do not exist in DNS. They exist only as virtual hosts configured on the web server.

Virtual Host Enumeration and Tool Behavior

To enumerate vhosts on THM, I must target the HTTP layer, not the DNS layer. The correct approach is Host header fuzzing. I used FFUF, which is ideal for this because it lets me craft the Host header directly:

ffuf -u http://10.67.133.43/   -H "Host: FUZZ.offensivetools.thm"   -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt   -fs 0

This approach allows me to discover vhosts even when DNS does not expose them. It is the correct methodology for THM.

Gobuster VHost Mode Insight

I validated the behavior of Gobuster’s --domain and --append-domain flags:

  • --domain only sets the base domain.
  • --append-domain actually attaches the domain to each word in the list.

If I omit --append-domain, Gobuster sends Host: admin instead of Host: admin.offensivetools.thm. This makes the scan ineffective on THM boxes, reinforcing the importance of reading tool documentation and testing assumptions.

Managing Gobuster Timeouts

Gobuster produced repeated “word I/O timeout” errors. I confirmed this happens when the target is slow or rate-limited. Reducing thread count and increasing the timeout stabilized the scan:

gobuster dir -u http://TARGET   -w list.txt   -t 10   -to 20s

This aligns with real-world behavior. Small targets and lab machines do not respond well to heavy concurrency.

Commands Practiced Today

Check active DNS

nmcli device show | grep DNS

Force manual DNS usage

nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes

Insert text at the top of a file

sed -i '1isecret' wordlist.txt

Background a running process

Ctrl+Z
bg

FFUF recursive JavaScript enumeration

ffuf -u http://10.67.133.43/FUZZ   -e .js   -w wordlist.txt   -recursion   -recursion-strategy greedy

Reflection

Today was not about running commands but about understanding the mechanisms behind them. I reinforced how DNS, hosts files, and virtual hosts interact, and how enumeration tools rely on those layers. This is the type of depth that builds long-term operational competence. Each session sharpens my craft and improves my precision.

I document these notes intentionally because I take this profession seriously. Mastery is built through repetition, awareness, and deliberate execution.

— RON1N01