How are people discovering random subdomains on my server?
from BonkTheAnnoyed@lemmy.blahaj.zone to selfhosted@lemmy.world on 10 Jan 16:03
https://lemmy.blahaj.zone/post/36861104
from BonkTheAnnoyed@lemmy.blahaj.zone to selfhosted@lemmy.world on 10 Jan 16:03
https://lemmy.blahaj.zone/post/36861104
I generated 16 character (upper/lower) subdomain and set up a virtual host for it in Apache, and within an hour was seeing vulnerability scans.
How are folks digging this up? What’s the strategy to avoid this?
I am serving it all with a single wildcard SSL cert, if that’s relevant.
Thanks
Edit:
- I am using a single wildcard cert, with no subdomains attached/embedded/however those work
- I don’t have any subdomains registered with DNS.
- I attempted dig axfr example.com @ns1.example.com returned zone transfer DENIED
Edit 2: I’m left wondering, is there an apache endpoint that returns all configured virtual hosts?
Edit 3: I’m going to go through this hardening guide and try against with a new random subdomain www.tecmint.com/apache-security-tips/
threaded - newest
@BonkTheAnnoyed@lemmy.blahaj.zone are you generating certificates for each of the random subdomains?
I don’t think so? I have a letsencrypt wildcard cert, and reference that in the relevant .conf
@BonkTheAnnoyed@lemmy.blahaj.zone mmm wait your logs show the new domains being targeted specifically?
Yep. They show up in the other_hosts…log
.
Fitting that someone from an instance on a random subdomain commented on this lol
@BonkTheAnnoyed@lemmy.blahaj.zone have you checked on https://crt.sh/ ?
As expected, it doesn’t show up. I had a couple of other subdomains configured before I switched to wildcard, but nothing matches the random one
I believe that some DNS servers are configured to allow zone transfers without any kind of authentication. While properly configured servers will whitelist the IPs of secondaries they trust, for those that don’t, hackers can simply request a zone transfer and get all subdomains at once.
I don’t have any subdomains registered with DNS.
I attempted
dig axfr example.com @ns1.example.comreturned zone transfer DENIEDDid you generate a DNS A record for the subdomain?
Nope
namesilo.com/…/passive-dns-explained-domain-histo…
Yeah, this is interesting, I’ll dig more into this direction.
But the randomly generated subdomain has never seen a DNS registrar.
I do have *.mydomain.com registered though…hmmm
Scans from where? Is it exposed to the internet? What does the scan traffic look like?
Mostly from AWS or the like, with occasional Chinese and Russian origins.
The scans look like requests to various WordPress endpoints, JavaScript files associated with known vulnerabilities etc
Have you sent the URL across any messaging services? Lots of them look up links you share to see if it’s malware (and maybe also to shovel into their AI). Even email services do this.
Nope, but that’s a good suggestion. I set this one up brand new for the experiment.
Are you sure they’re hitting the hostname and not just the IP directly?
Shows up by name in the apache other_hosts…log, so yes
Going to IP directly could redirect to your first domain. This would trigger another request to your domain and could result in your logs.
You need to make sure to 444 drop connection immediately if wrong domain. Redirect to https should be configured after - I suspect ur config redirects
if you use Let’s Encrypt (ACME protocol) AFAIK you can find all domains registered in a directory that even has a search, no matter if it’s wildcard or not.
It was something like this crt.sh but can’t find the site exactly anymore
LE: you can also find some here search.censys.io
Holy shit, this has every cert I’ve ever generated or renewed since 2015.
en.wikipedia.org/wiki/Certificate_Transparency
This.
That’s why temping obscurity for security is not a good idea. Doesn’t take much to be “safe”, at least reasonably safe. But that not much its good practice to be done :)
No. Not this.
Op is doing hidden subdomain pattern. Wildcard dns and wildcard ssl.
This way subdomain acts as a password and application essentially inaccessible for bot crawls.
Works very well
Apparently it doesn’t.
minimal setup is still required 🤷
Hmm. I feel like conflating a subdomain with a password is a particularly sketchy idea, but you do you.
Holy shit… I thought it was DNS resolver selling these data
.
Do post again if you figure it out!
Will do!
We’re always watching.
You say you have a wildcard cert but just to make sure: I don’t suppose you’ve used ACME for Letsencrypt or some other publicly trusted CA to issue a cert including the affected name? If so it will be public in Certificate Transparency Logs.
If not I’d do it again and closely log and monitor every packet leaving the box.
The random name is not in the public log. Someone else suggested that earlier. I checked CRT.sh and while my primary domain is there, the random one isn’t.
My next suspicion from what you’ve shared so far apart from what others suggested would be something out of the http server loop.
Have you used some free public DNS server and inadvertently queried it with the name from a container or something? Developer tooling building some app with analytics not disabled? Any locally connected AI agents having access to it?
if there’s no dns entry do you mean you are getting scans to your ip with these random subdomain headers? so someone would need both pieces of information? curious
Yes, exactly. Super weird, shouldn’t happen. I wonder if I have a compromised box somewhere…
Did you yourself make a request to it or just set it up and not check it? My horrifying guess it that if you use SNI in a request every server in the middle could read the subdomain and some system in the internet routing is untrustworthy.
Previous experiments, yes, I sent a request. The random one, no.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
7 acronyms in this thread; the most compressed thread commented on today has 16 acronyms.
[Thread #990 for this comm, first seen 11th Jan 2026, 01:25] [FAQ] [Full list] [Contact] [Source code]
Good bot
Kudos to the bot.
Inb4 some lucky dude just ran sublist3r or wfuzz on your subdomain and got a hit
I mean, it could be… I’ll try it with a 128 char base 52 name and see what happens
Have you also tried making a subdomain and not making any requests to it yourself? So no browser access or other DNS resolution requests for the new subdomain. That should rule out some of the other possible causes suggested in the other comments.
Dang, it could be the upstream DNS server passing along client queries. Maybe the ISP?
In that case not even curl would be safe unless you could ensure all queries only resolve on your gear. Either use a host file entry or local DNS server.
If you do a port scan on your box, what services are running? Maybe something like email or diagnostics is exposed to the internet and announcing subdomains?
It’s literally just a VM hosting Apache and nothing else.
Following this thread!
Stupid question, but are you somehow publicly exposing your vhost config (or a bak file of it)? Or do you see logs of someone bruteforcing the subdomain?
You need better logging. Try doing a packet capture with tcpdump then decrypt the HTTPS traffic. Because what you've described so far, especially before the edit makes no sense.
If you don't have a DNS record pointing the subdomain to the IP address of the server, it shouldn't be possible to resolve the IP for random Internet users. If this VHOST only exists in your Apache config file and nowhere else, it is private.
For anyone who needs to read it: At the end of the day this is obscurity, not security; however obscurity is a good secondary defense because it buys time.
I too would be interested to learn how this leaked
it’s not even obscurity; it’s logged publicly.
How is it being logged publicly? Like OP said there is no specific subdomain registered in the DNS records (instead using a wildcard). Same for the SSL cert. Only things I can think of is the browser leaking the subdomains (through google or Microsoft) or the DNS queries themselves being logged and leaked. (Possibly by the ISP inspecting the traffic or logging and leaking on their own DNS servers?). I would hardly call either of those public.
It’s not. Wildcard DNS and wildcard cert. Domain is not logged publicly.
People that keep saying logged publicly simply don’t understand setup and technology
Isnt security mostly achieved by heavy obscurity? A password secures because other people dont know what it is, it is obscured.
In cryptography, there’s a difference between “secrets” (like passwords and encryption keys), and hiding / obscuring something (like steganography or changing your web server to run on a different port)
They’re not the same.
Hiding an unlocked treasure chest in the forest is obscurity. Sure, you might be the only one who knows it’s there at first but eventually someone might come across it.
Having a vault at a bank branch is security - everyone knows there’s a vault there, but you’ll be damned if you’re going to get into it when you’re not authorized.
Good passwords, when implemented correctly, use hashing (one way encryption) to provide security. It’s not obscured, people know you need a password to access the thing (in our example)
All the obvious things have been mentioned.
The only way to identify the problem is to share the exact steps youve followed and then others can reproduce.
Based on what youve told us, no one knows how the subdomain is leaked. Without meaning to be derisive, that suggests that something youve told us isn’t quite correct.
Well, the good news is that I at least think I’m doing all the right things.
I’ll spin up a new VM tomorrow and start from scratch.
Reverse DNS? Or vuln scans just hitting IPs. Don’t need DNS for that.
Op is doing hidden subdomain pattern. Wildcard dns and wildcard ssl.
This way subdomain acts as a password and application essentially inaccessible for bot crawls.
Works very well
A long time ago, I turned a PC in my basement into a web server. No DNS. Just a static IP address. Within 15 minutes, the logs showed it was getting scanned.
SSL encrypts traffic in-transit. You need to set up auth/access control. Even better, stick it behind a Web Application Firewall.
Or set up a tunnel. Cloudflare offers a free one: developers.cloudflare.com/…/cloudflare-tunnel/
I run my webservers behind a pfsense firewall with ssl offloading(using a wildcard cert) with a static IP and use Haproxy to have sub-domain’s go to individual servers. Even though I’ve seen my fair share of scans, I only ever expose port 443 and keep things updated.
Recently though someone on here mentioned routing everything over Tailscale via a VPS. I didn’t want to pay for a VPS and frankly can’t even find one that is reasonably priced in the US(bandwidth limits mainly), so I threw Tailscale onto my pfsense, setup split-dns on Tailscale’s admin panel with my domain name, and then reconfigured Haproxy to listen on my Tailscale interface. Even got IPv6 working(huge pain due to a bug it seems). Oh and setup pfblocker.
My current plan is I’m going to run my webservers behind Tailscale and keep my game servers public and probably segment those servers to a different vlan/subnet/dmz/whatever. And maybe just have a www/blog landing page that is read only on 443 and have it’s config/admin panel accessible via my tailscale only.
Anyway, back on topic. I run my game servers and I don’t advertise them out anywhere(wildcard cert) and do whitelist only, yet I still see my minecraft servers get hit constantly on port 25565.
So not much you can do except minimize exposure as much as possible.
Maybe that particular subdomain is getting treated as the default virtual host by Apache? Are the other subdomains receiving scans too?
I don’t use Apache much, but NGINX sometimes surprises on what it uses if the default is not specifically defined.
.
If you have browser with search suggestions enabled, everything you type in URL bar gets sent to a search engine like Google to give you URL suggestions. I would not be surprised if Google uses this data to check what it knows about the domain you entered, and if it sees that it doesn’t know anything, it sends the bot to scan it to get more information.
But in general, you can’t access a domain without using a browser which might send that what you type to some company’s backend and voila, you leaked your data.
What you can do is segregate networks.
If the browser runs in, say, a VM with only access to the intranet and no internet access at all, this risk is greatly reduced.
Easily verified by creating another bunch of domains and using a browser that doesn’t do tracking - like waterfox
Maybe using subfinder?
Crawlers typically crawl by ip.
Are u sure they just not using ip?
U need to expressly configure drop connection if invalid domain.
I use similar pattern and have 0 crawls.
Is this at a webserver level?
It can be both server and DNS provider. For instance, Cloudflare allows you to set rules for what traffic is allowed. And you can set it to automatically drop traffic for everything except your specific subdomains. I also have mine set to ban a IP after 5 failed subdomain attempts. That alone will do a lot of heavy lifting, because it ensures your server is only getting hit with the requests that have already figured out a working subdomain.
Personally, I see a lot of hacking attempts aimed at my main
www.subdomain, for Wordpress. Luckily, I don’t run Wordpress. But the bots are 100% out there, just casually scanning for Wordpress vulnerabilities.+1 for dropped connections on invalid domains. Or hell, redirect them to something stupid like ooo.eeeee.ooo just so you can check your redirect logs and see what kind of BS the bots are up to.
Chrome: Sees new website domain
Google: 👀
My guess would be NSEC zone walking if your DNS provider supports DNSSEC. But that shouldn’t work with unregistered or wildcard domains
The next guess would be during setup, someone somewhere got ahold of your SNI (and/or outgoing DNS requests). Maybe your ISP/VPN service actually logs them and announce it to the world
I suggest next time, try setting up without any over-the-internet traffic at all. E.g. always use
curlwith the–resolveflag on the same VM as Apache to check if it’s workingYou need to look at the DNS server used by whatever client is resolving that name. If it’s going to an external recursive resolver instead of using your own internal DNS server then you could be leaking lookups to the wider internet.
crt.sh
When a CA issues an SSL/TLS certificate, they’re required to submit it to public CT logs (append-only, cryptographically verifiable ledgers). This was designed to detect misissued or malicious certificates.
Red and Blue team alike use this resource (crt.sh) to enumerate subdomains.
TIL
But this still doesn’t explain it. Like OP I also use a wildcard cert. The subdomains are never exposed.
subdomainfinder.c99.nl
I can’t say I know the answer but a few ideas: - did you access it with a browser? Maybe it snitches on you or some extension does? - did you try to resolve it with a public DNS server at any point (are you sure nothing forwarded the request to one)?
You could try it again, create the domain in the config and then do absolutely nothing. Don’t try to confirm it works in any way. If you don’t see the same behaviour you can do one of the above and then the other and see when it kicks in. If it gets picked up without you doing anything..then pass!
If you do a GET / request against the IP (typically http too) does it yield a redirect to your proper fqdn? It shouldn’t return anything and remain stealthy as you likely dont want to expose anything directly on IP connections and rely solely on your vhosts.
Do you use an external DNS when accessing your subdomain? I can only guess that it’s the DNS leaking it.