A charity once used a third-party service to handle event registration. To make it look like part of the charity's own site, the volunteer who set it up pointed a subdomain at the service with a CNAME record. People signed up for spring fun runs and autumn quiz nights at an address on the charity's own domain, and nobody thought about it again.
After the event series ended, the charity cancelled the account with the service. The DNS record stayed exactly where it was. It cost nothing, it did no visible harm, and nobody had a reason to open the DNS panel.
Some months later a visitor wrote to say that the registration address was showing a gambling page, and that it carried the charity's name in the browser bar. This is the story of how that happened, why it was so easy, and what the charity changed afterwards. The names and details are a composite, but the mechanism is entirely real and turns up in hosting support more often than it should.
What the charity had set up
The setup was ordinary. The charity owned a domain, call it example.com, and its main site lived on a normal shared hosting plan. Event registration was a different matter: the charity did not want to build a booking system, so it paid a monthly fee to a company that provided one as a hosted service.
The service offered custom hostnames. You told the platform you wanted to use events.example.com, and then you created a CNAME record at your own DNS provider pointing that name at an address on the platform. When a browser asked for events.example.com, DNS answered "that is really the platform's name, go and ask there", and the platform looked at the hostname in the request, found the charity's account, and served the charity's registration pages.
events.example.com. 3600 IN CNAME charity-signups.reg-platform.example.net.Notice where the knowledge sits. The charity's DNS says only "this name is an alias of that name". Which customer owns events.example.com is recorded inside the platform's own database, not in DNS. That detail is the whole story.
What went wrong, step by step
When the event series finished, the committee cancelled the subscription. The account was closed and its custom hostname released, which is what most platforms do: a hostname is only reserved while the account that claimed it exists.
The CNAME, however, still said that events.example.com was an alias for the platform. So the DNS side of the arrangement was intact while the platform side was empty. Anyone visiting the address got an error page from the platform for a while, and since the old events were over, nobody visited much.
Then somebody else opened an account with the same platform. Many such services only check that a hostname is not already claimed by another customer. Some do not ask the new customer to prove they control the domain, because the usual route to a working site is exactly that CNAME, which the new customer cannot create without access to the DNS. In this case the DNS record was already there, so the platform saw a hostname that resolved correctly to itself and accepted the claim. Within minutes, the new account owner had a working page at events.example.com.
How it was noticed
Nobody at the charity found it. A member who had bookmarked the old registration page clicked it out of curiosity, and sent a short email to the general inbox saying that the charity's events page "seems to have been hacked". The message sat for two days, because the inbox was read on Sundays.
The IT volunteer, who looked after the website in his spare time, opened the address on his phone and saw a page in a different language, full of casino banners, with the charity's domain in the address bar and a valid padlock. The padlock was the part that unsettled him most. The platform issued certificates automatically for any hostname that pointed to it, so the new owner's page was served over HTTPS under the charity's name.
His first assumption was that the main website had been compromised. That is the usual reading of "my site shows something it should not", and it sent him in the wrong direction for the first hour.
Wrong turns and the diagnosis
He logged into the hosting control panel and checked the main site's files for recently modified PHP, looked through the WordPress user list, and reset the administrator password. All of that was reasonable on the evidence and none of it was relevant. The main site at www.example.com was clean. Only one hostname was affected.
The clue was that the gambling page loaded even when he temporarily renamed the charity's web folders. That could not happen if the content were coming from the charity's server. He ran two commands from his laptop:
dig +short events.example.com
dig +short CNAME events.example.comThe second returned the platform's hostname, and the first returned addresses belonging to the platform, not to the charity's hosting. The content was never on the charity's server at all. He then checked the account he had cancelled, found it closed, and the penny dropped: the CNAME was still doing its job, sending traffic to a company where the charity no longer had any standing.
This pattern is usually called a dangling DNS record, and when someone else takes advantage of it, a subdomain takeover. The attacker needs no access to the charity's hosting or DNS. They only need the platform to hand over the hostname.
The timeline
Laid out in order, the event looked like this. The dates are examples, but the gaps between them are typical.
Months went by between cancellation and takeover, which is the usual shape. Automated scanners look for exactly these records across large numbers of domains, so a dangling CNAME rarely goes unnoticed for long.
The fix and the aftermath
The fix took about a minute. He logged into the DNS panel, deleted the events CNAME, and waited. Because the record had a one-hour TTL, most resolvers dropped it within the hour, and the casino page stopped appearing under the charity's name. Before deleting, he took a screenshot of the page and its address bar, which turned out to be useful when the charity needed to explain what had happened.
The page had been up for some weeks, and that was the harder part. Search engines had already indexed it, and for a time a search for the charity's name offered the subdomain as a result, with a snippet about betting. The charity filed a removal request through the search engine's webmaster tools, asked the platform to take the account down, and posted a short note on its social channels. The listing disappeared over the following fortnight, but a few supporters had already seen it, and one local newspaper contact asked, politely, what was going on.
Nothing was stolen. A page on a subdomain can sometimes read or set cookies scoped to the parent domain, and a fake sign-in page on a trusted subdomain is a classic way to harvest passwords, so the risk was real even though no harm followed.
The volunteer then did something more lasting. He exported the whole DNS zone into a spreadsheet, and next to every record wrote what it was for, which service it pointed at, who paid for that service, and when it was last used. Three more records turned up that pointed at things nobody could identify. Two were deleted after a week of asking around; one was a mail verification record that was still needed.
Verifying it
You do not need special tools. List every subdomain you have in your DNS panel, then for each one that is a CNAME, try the address in a browser and look at what comes back. A platform-branded error such as "no site configured here" or "this domain is not connected" on a name you still list in DNS is the warning sign.
From a terminal, this shows where each name goes:
dig +short CNAME events.example.com
curl -sI https://events.example.com | head -5If the CNAME answers but the page is an error, a placeholder or something that is not yours, treat it as urgent. If you also keep old A records pointing at a server that was shut down, apply the same thinking: an IP address that once belonged to you can be handed to a stranger by the provider. The DNS cheatsheet explains the record types, and the TTL planner helps you judge how long a change will take to spread.