What does an attacker see of your domain?
Published on May 19, 2026 · Updated on July 21, 2026
Anyone who deliberately tries to break into your organisation first takes a quiet look around. Not from the street, but over the internet. Everything your domain, your servers and your services expose to the outside world together forms your attack surface. The larger and more sprawling that surface, the more opportunities an attacker has. The good news: you can run largely the same reconnaissance yourself, and see sooner what there is to find.
Reconnaissance: what does an attacker actually do?
An attacker starts with reconnaissance: gathering publicly available information. Often no break-in is needed at all. A lot of information is simply out in the open and there for the asking. A weak spot found here is often the starting point for the next step. That first phase is therefore also your best chance to spot problems before someone else does.
The components of your attack surface
DNS and subdomains
Your domain name resolves via DNS to IP addresses and services. Attackers like to map out all your subdomains: test., old., vpn., mail. and so on. Forgotten subdomains that still point somewhere are a classic point of entry. Misconfigured DNS records (such as missing SPF, DKIM and DMARC: the standards that make e-mail on behalf of your domain verifiable and enforceable) also make it easier to phish in your name.
A typical scenario: a company has promo.company.com set up for a campaign, linked to an external platform. The campaign ends, the platform subscription is cancelled, but the DNS record remains. Whoever then claims the same platform name serves content under promo.company.com, your name: a subdomain takeover, and the result is a phishing domain that is hard to tell from the real thing. More scenarios like this, and how to prevent them structurally, in shadow IT and NIS2: managing unknown digital assets.
Open ports and services
Every server has ports: little doors with services running behind them. A web server should listen on ports 80 and 443, but is there also a database port, a management interface or an old FTP service open to the entire internet? That is exactly what an attacker hopes to find.
Querying DNS records and certificates is passive reconnaissance: nobody needs to touch your systems for that. Scanning ports yourself is active. But port information can be looked up passively too: specialised search engines such as Shodan and Censys continuously scan the entire internet and index open ports and software banners. An attacker often does not even need to touch your server to know what is running, and you can look up your own IP addresses there just as easily.
TLS and certificates
The padlock in the browser runs on TLS. But an expired certificate, an outdated protocol or a weak configuration weakens the protection. An interesting detail: Certificate Transparency logs are public. Every certificate from a publicly trusted issuer appears in them, including the (sub)domain name it was requested for. With a wildcard certificate individual subdomains stay out of view, as do subdomains without a public certificate. Attackers read those logs too, to discover your internal names.
Exposed panels
Login screens for management systems, routers, camera systems, database tools or CI/CD environments that hang directly on the internet are gold for an attacker. They often run with default passwords or known vulnerabilities. Such exposed panels belong behind a VPN or IP restriction, not out in the open.
Outdated software and CVEs
Known vulnerabilities get a CVE number (Common Vulnerabilities and Exposures). Attackers scan the internet en masse for software versions with a known CVE for which a ready-made exploit exists. An outdated WordPress installation with a vulnerable plugin is the textbook example: enormously popular, and therefore heavily targeted.
Why a snapshot is not enough
The internet does not stand still. Today your environment is tidy; next week a new CVE appears, a colleague puts a test server online or a certificate expires. One scan a year goes stale quickly: what is accurate today may be different next month. Continuous monitoring keeps your attack surface in view at all times, so new risks stand out the moment they arise, and not only when an incident occurs.
Modular scanning with OpenKAT
Exposentry is built on OpenKAT, the open-source scanner that originates from the Dutch government. OpenKAT works modularly: small, specialised scan modules ("boefjes") each examine a piece of your attack surface, such as DNS, ports, TLS and software versions, and together build an up-to-date picture. Because every finding is traceable to the module that found it, you know not only what was found, but also how. We know those modules from the inside: Edward Hasekamp contributes to OpenKAT himself. More about the tool itself, and the persistent misunderstandings around it, is in what OpenKAT is, and what it is not.
If you want to understand why that substantiated evidence is so valuable, especially towards large customers, read scanning is not NIS2 compliance. But it is a necessary building block. And if you supply a large organisation, the NIS2 supply-chain duty of care is relevant too.
Want to see for yourself?
You can get a first impression for free: look up your domain in the public Certificate Transparency logs (crt.sh) and check your e-mail settings via internet.nl (when such a free check is enough, and when it is not, is covered in internet.nl is free, so when do you need Exposentry?). Knowing for sure what an attacker sees of you is only possible by measuring it yourself. Start with a one-time scan for a snapshot, or choose a plan with continuous monitoring. See the plans and pricing and make your attack surface visible, before someone else does it for you.
Written by Edward Hasekamp, founder of Exposentry and collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.