Forgotten Infrastructure and Dangling Records
Subdomain takeover, dangling cloud and DNS records, backup systems, network printers and secrets leaking out through logs and telemetry.
The surfaces here have one thing in common: somebody stopped maintaining them without removing them, and the pointer outlived the thing it pointed at.
Subdomain Takeover
A CNAME pointing to a missing service becomes takeover only when someone else can register the exact resource that hostname expects. Subdomain takeover requires dangling DNS plus the ability to claim the corresponding resource at the provider. Each SaaS or cloud service has different ownership rules. Fingerprints help prioritize but error messages change. Testing must validate whether the resource can actually be reassociated. I confirm DNS, provider, resource state and claim model. During a pentest I use a non-destructive proof or a resource coordinated with the client. Some providers reserve names or require domain verification. A dangling CNAME may be poor hygiene without an exploitable takeover.
1
2
dig +short CNAME old-app.example.com
dig +short old-app.example.com
Dangling Cloud Resources and DNS
Cloud teardown may delete a resource in seconds while DNS survives for months. Risk appears when another account can register the referenced resource again. CNAMEs pointing to app services, storage, CDNs and SaaS depend on provider ownership models. Deleting the resource creates a dangling reference. Some providers reserve old hostnames or require TXT verification. Others allow reclaim in certain regions or namespaces. I confirm the provider, current error and claim process using documentation and a lab environment. Removing DNS before the resource reduces the window. Asset inventory and IaC destroy hooks help keep lifecycles synchronized.
1
2
dig +short CNAME app.example.com
dig +trace app.example.com
Secrets Leakage Through Logs and Telemetry
Logs were created to help operators. When they contain Authorization headers, cookies or private prompts, they become another sensitive database. Applications log requests, errors, traces, metric attributes and debug payloads. APM agents may also capture metadata automatically. Secrets may appear in URLs, headers, stack traces, environment dumps and structured fields. Redaction needs to happen before export. I generate a lab canary secret, exercise a normal flow and search for the value in local logs, APM and export pipelines. Field-name redaction fails when the same secret appears inside free-form strings or serialized bodies. Data minimization is a stronger control.
1
grep -R 'CANARY_SECRET_2026' /var/log app-logs/ 2>/dev/null
Backup Systems
A backup server needs to read servers, databases and shares that few other systems can access. That turns backup itself into concentrated privilege. Backup products use service accounts, agents, repositories, snapshots and credentials to access workloads. A compromised admin console or credential store may expose historical data and keys even when production is hardened. I map identities, repositories, retention, encryption keys and restore permissions without starting restores outside the lab. Immutable backup helps against ransomware, while platform administration and encryption-key access remain critical boundaries.
Keep this stage to inventory: backup server identities, repositories, encryption settings, restore roles and network reach.
Printers and PJL
An enterprise printer may have a filesystem, spooler, LDAP, SMB, firmware and administrative credentials while still being treated like a peripheral. PJL and printing protocols expose status, jobs and on some devices filesystem operations. Web administration adds another embedded application. Address books, scanned documents, LDAP bind credentials and SMB destinations may exist on the device. I identify model, firmware, protocols and authentication before sending read-only commands to a lab device. PJL commands vary widely by vendor. Testing should avoid operations that alter firmware, NVRAM or real print queues.
1
printf '%b' '\x1b%-12345X@PJL INFO ID\r\n\x1b%-12345X' | nc printer.lab.local 9100
Dangling DNS Records
A dangling record may not be claimable and still send traffic to the wrong service, break authentication or preserve an invisible dependency on dead infrastructure. A, AAAA, CNAME, MX, SRV and NS records may outlive the resource they represented. Each type creates a different effect. Dangling NS may delegate a subzone. MX may direct email unexpectedly. SRV may influence service discovery. I classify records by type, destination, ownership and resolver behavior before calling anything a takeover. DNS lifecycle needs to track cloud and SaaS lifecycle. Monitoring NXDOMAIN and orphaned targets reduces drift.
1
2
dig +noall +answer example.com A example.com AAAA example.com MX example.com NS
dig +short SRV _service._tcp.example.com