← all labs

DNS Reconnaissance — Find the Leaked Internal Endpoint

Easy Reconnaissance · 20 min

Flag submissions require login via tc_sso. Reading instructions does not.

DNS Reconnaissance

Scenario

You are in the passive recon phase of an external pentest engagement against acme-corp.example. Your scope is "anything publicly available via DNS — no active scanning."

A dig-style dump of all public DNS records for the apex domain is in the right pane.

One of these records leaks the hostname of an internal infrastructure endpoint that the customer almost certainly didn't intend to expose externally. Find it.

Objective

Submit the fully-qualified hostname of the leaked internal endpoint.

Answer format

<subdomain>.acme-corp.example

All lowercase. Example shape (NOT the answer):

internal-api.acme-corp.example

Tips

  • Don't bother with the obvious public records (www, mail, ftp — those are intentionally public).
  • Look at TXT records carefully — SPF/DKIM/DMARC records often reveal subdomains that the customer uses for outbound mail / API integrations.
  • A subdomain prefixed internal-, staging-, dev-, vpn-, admin- is a strong tell.
  • One DNS record type that is famous for over-disclosure is TXT (SPF specifically — it lists every server allowed to send mail).

Hints

Hint 1 (−10 pts)

Focus on the TXT records. SPF policies list every host allowed to send mail for the domain — and frequently include internal hostnames as `a:<host>` or `include:<host>` directives.

Hint 2 (−10 pts)

The SPF record (v=spf1) contains an `a:` directive pointing at a hostname starting with `internal-`. That's your leak.

Hint 3 (−10 pts)

Full answer: internal-mail-relay.acme-corp.example

Lab environment · sandboxed iframe · auto-resets every 60 min