What your subdomains say about you.

A week watching the DNS of fifty Balkan SMEs. Patterns, leaks, and the forgotten corners that still answer on port 443.

We pointed our surface agent at fifty small and mid-sized enterprises across the Western Balkans. Banks, telcos, retailers, a few government bodies. The scan was passive: DNS enumeration, certificate transparency logs, public records. Nothing intrusive. Nothing that required permission. Everything an attacker would do in the first ten minutes of reconnaissance.

The results were worse than expected. Not because of any single catastrophic finding, but because of the pattern. Nearly every organisation had subdomains they did not know about, services they thought were decommissioned, and configurations that told an attacker exactly where to look next.

The forgotten subdomain problem

Of the fifty organisations we scanned, forty-three had at least one subdomain pointing to infrastructure that was either abandoned or misconfigured. The most common offenders were staging environments. Names like staging.company.com, test-api.company.com, dev.portal.company.com. Created for a project, pointed at a server, and then forgotten when the project moved to production.

These subdomains are not a theoretical risk. They are the first thing any attacker enumerates. Automated tools like Subfinder, Amass, and dozens of others will discover them in seconds. A forgotten staging server running an unpatched version of your application is not an edge case. It is the most common initial access vector we see in the region.

The problem is organisational, not technical. Nobody owns the DNS. The developer who created the subdomain left two years ago. The IT team inherited the zone file but has no documentation. The server still answers because nobody told it to stop.

What certificates reveal

Certificate Transparency logs are public. Every SSL certificate issued for your domain is recorded and searchable. This is by design, for security. But it also means that every internal service name you have ever issued a certificate for is visible to anyone who looks.

In our scan, we found internal service names exposed through CT logs in thirty-one of fifty organisations. Names like jenkins.internal.company.com, grafana-prod.company.com, vpn-admin.company.com. Each of these tells an attacker what software you run, what your internal naming conventions look like, and where your administrative interfaces live.

None of these organisations intended to publish this information. They simply issued certificates for internal services through public certificate authorities, not realising that the issuance itself is a disclosure event.

Port 443 and the things behind it

We checked every discovered subdomain for services responding on port 443. The results broke down into four categories:

• Default pages and error messagesServers responding with default Apache, Nginx, or IIS pages. These confirm the server exists and identify the software stack. Fourteen organisations had at least one.
• Login panelsAdministrative interfaces for CMS platforms, database tools, monitoring dashboards, and remote access portals. Exposed to the internet, protected only by a username and password. Twenty-two organisations.
• API endpoints with verbose errorsDevelopment APIs returning stack traces, database connection strings, or internal IP addresses in error responses. Nine organisations. This is not a misconfiguration anyone notices until someone exploits it.
• Decommissioned applications still serving contentOld versions of web applications, legacy portals, and retired products still running on subdomains that nobody monitors. Seventeen organisations. Several were running software with known, published vulnerabilities.

The pattern across all fifty

The common thread is not negligence. These are competent organisations with real IT teams. The problem is that attack surface management is not part of the workflow. Nobody runs a subdomain audit on a schedule. Nobody checks CT logs for new certificate issuances. Nobody asks "what is still responding on this domain?" after a project ends.

The result is drift. Slow, invisible, cumulative. Every month, the gap between what the organisation thinks its surface looks like and what it actually looks like grows a little wider. An attacker scanning that surface sees the real picture. The organisation sees only what it remembers deploying.

What you can do about it

Enumerate your own surface before someone else does. This is not optional and it is not a one-time exercise. Run subdomain discovery against your own domains on a regular schedule. Check CT logs for certificates you did not expect. Scan your own assets for services that should not be public.

If a subdomain points to nothing, remove the DNS record. If a staging server has served its purpose, shut it down and delete the certificate. If an admin panel is exposed to the internet, put it behind a VPN or remove it entirely. These are not complex fixes. They are the maintenance that prevents the breach.

Or automate it. That is what our surface agent does. Continuous enumeration, continuous monitoring, continuous comparison between what should be there and what actually is. The machine does not forget to check. It does not inherit a zone file and shrug. It watches, and it tells you when the picture changes.