How do subdomains get discovered by adversaries?

[Michael De Roover]

On Thu, 2022-12-22 at 05:19 +0000, Michael De Roover wrote:
> Hello,
> 
> I have been running BIND 9 on my external and internal networks for a
> few years now -- as such I have a basic understanding of the most
> common RR types and activities such as zone transfers. However, I
> have been seeing something that's been baffling me for quite a while
> now. Somehow there are services like c99.nl [1] and Criminal IP [2],
> which can enumerate various subdomains on a given target domain. I am
> confused as to how they can enumerate this information.
> 
> As far as I know, a NS record returns the name servers authoritative
> for a domain. Alright, now you've got authoritative information when
> querying these domains. No useful information about the zone data
> they are responsible for though.
> 
> Then there is an A record, which returns an IPv4 address of a server
> responsible for a domain. Alright, now you can talk to a server.
> Maybe that would be a webserver, and now you may perform a HTTP
> exchange to that server (GET /whatever, with a given Host header).
> You still have to guess what the Host: header would have to be.
> 
> Maybe it would be an MX record. Brilliant, now you could talk to a
> mail server. Its EHLO message (sometimes called a "banner" in
> security circles) would contain a domain, alright. It would also only
> be one of them -- AFAICT only one domain that the organization wants
> to actually primarily send from.
> 
> Another interesting record would be the CNAME record. As far as I
> know, this is used to redirect to another domain from within the DNS,
> with its own bespoke entries (bringing us back to A records). Getting
> from a CNAME to an A record seems easy enough, but what about getting
> these CNAME records in the first place?
> 
> This is what I am thinking of so far, but it may well be that I've
> been talking crap in all of the above and know nothing about the DNS.
> That's fine, and in that case please correct me where necessary.
> Either way, I'm very confused on how these services can actually
> enumerate these subdomains, and find most -- if not all -- reliably.
> This seems a bit concerning to me with regards to unwanted
> information disclosure, hence my curiosity. If it is at all possible
> to mitigate, I would of course also appreciate discourse on this
> matter. Thank you!
> 
> [1] https://subdomainfinder.c99.nl
> [2] https://criminalip.io/domain
> 
> Best regards,
> Michael
> 
On an unrelated note, I found that Apple Mail (which I checked for on
various ISC employees' email headers in the past due to curiosity,
several seem to use it) is unable to deal very well with text emails
and its formatting (particularly regarding new lines). Which format is
preferred on this list? For now, I have set my email client to default
to HTML messages, and edited my original message to remove these
newlines. Chances are that it would send a text-only message too. But
in modern clients, I find text-only emails to insert a lot of unwanted
newlines, going back to the 80-column terminals which I don't think
anyone uses anymore (though I most certainly approve of the efficiency-
driven sentiment these people tend to hold).

Back on topic, I forgot about PTR records. But at least in a VPS
instance (or a multiple thereof), it would only be configurable to one
domain in the hosting provider's configuration panel, no? I am aware of
PTR delegation, but that seems to be only for entire public network
ranges (which at this point are only /24 and beyond in IPv4 afaict).
While my hosting provider is very friendly to me, I certainly do not
consider them a party who's willing to delegate it to me. With that
tangent out of the way -- one record, configured by them on my behalf.
And that's it. Not much information to get subdomains from there.
Meanwhile, larger organizations are very likely to delegate every
service that cares about PTR records to others. Their PTR records would
just point to those instead.

So PTR records don't seem to be very useful in getting this information
either. As such, I am still stranded.

Thanks again for your attention,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221222/625b9793/attachment.htm>