Thai and Indonesian online gambling operators are running casino sites on forgotten subdomains of legitimate companies.
Key findings
- The typical compromised company deleted a cloud app without updating the DNS records that pointed to it. Threat actors can reclaim that app or IP address and effectively serve their content through the original website.
- Online gambling is illegal in both countries, so the operators have to host behind whatever subdomains they can claim. This lowers the search and domain reputation of the host companies.
- These operators have a level of sophistication. Finding and claiming forgotten subdomains is not hard but the threat actors are evasive. Many of them go dark for a while to avoid detection or when they think they are being investigated to mislead casual responders.
Impact
Hosting a casino on a forgotten subdomain degrades the parent domain’s reputation which drags on everything from search engine rankings to email delivery. These sites can go undetected for months, giving Google plenty of time to crawl the subdomain and start associating the parent company with gambling content. Once that happens, search results for the parent company start coming with a "this site may be hacked" label that follows the domain around.
Mail providers and domain blocklists key off the parent domain, not the forgotten subdomain, so email sent from the real company like invoices, password resets, and sales outreach starts landing in spam folders. Web filters like Cisco Umbrella recategorize the domain as gambling, which means the company's own prospects and customers, sitting behind corporate filters, can get blocked from viewing the legitimate parts of the site. For a business that sells to other businesses, that is lost revenue from a cause almost nobody thinks to check because the subdomain in question is one they believed they deleted months ago.
Attack Chain
Every version of this starts with a DNS record pointing at something the company no longer owns. Finding vulnerable domains is the easy part. Public certificate logs list subdomain names in seconds, and a resolver tells the operator whether the destination is serving traffic. From there the move depends on what the record points at. For an A record aimed at a cloud IP the company released, the operator provisions instances in that same cloud until the provider hands back that exact address which means the subdomain now resolves to them. If it is a name pointing at a deleted cloud resource like an Azure app, they simply re-create a resource with the orphaned name and inherit the hostname. And if the domain's delegation still points at a cloud DNS provider but the hosted zone is gone, they create zones until the nameservers they are assigned line up with the ones the domain still trusts, which hands them control of the record outright. Once the name is theirs, they stand up the gambling site and let the company's own reputation do the work of making it look legitimate.
The main goal is to be found so these operators don't tend to hide or evade, except when they think they are being investigated. I have watched several stop serving content as a means of avoiding detection by a casual observer. The DNS records still point to them even if the page doesn't load which is the tell. Many share the same IP address which is another giveaway.
Recovery
The active phase stops when DNS is fixed. Remove the orphaned record, or point it back at infrastructure you actually control, and the operator loses the name. Then the reputational recovery can begin. Google will keep showing the gambling pages until it re-crawls, so the domain has to be resubmitted for review. If web content filtering vendors recategorized the domain as gambling, each one needs a recategorization request. Blocklist entries will also need to be appealed. Certificates also need to be revoked after proving to whatever authority issued them that you are the rightful owner of the domain. The response playbook should also include steps to check that other subdomains are not similarly claimable.
Guardrails should also be put into place to prevent the same kind of thing from happening again. In the case of an Azure app, that name will remain controlled by the casino site until they release it, so you want some CI/CD checks to make sure that name never gets reused. Managing the resource and domain record as one unit in infrastructure-as-code means that an orphan cannot be created in the first place.