The Quiet Takeover: How Your Forgotten Cloud Resources End Up Selling Slot Machines

Picture a global telecom company. Three years ago, a marketing team launched a campaign microsite on a cloud platform and pointed a company hostname at it. The campaign ended and the team deleted the app. Nobody deleted the DNS record.

A few years ago, that mistake could sit there for a decade. No one was looking. Today, attackers run automated sweeps across millions of domains, resolving every DNS record and checking whether the resource behind it still exists. Tooling, and increasingly AI, has made reconnaissance cheap enough that no hostname is too obscure to be checked. The forgotten record is found within hours of the resource disappearing, and the abandoned cloud name is re-registered by a stranger.

The result is a hostname on the company’s own domain, with a valid certificate, selling online slot machines. It borrows the brand’s search ranking and its trust. Nothing was hacked, and no alert fired.

At IONIX, we map everything an organization exposes to the internet, including the assets its own teams have forgotten, and look for weaknesses an attacker could use. In a recent snapshot of the organizations we monitor, we found hundreds of hostnames across dozens of enterprises serving casinos, fake pharmacies and adult content. Most belonged to household-name brands in media, telecom, energy, pharma, financial services and technology.

Below is how this happens, why it’s so hard to spot, and three ways to deal with it: see it coming before an attacker does, find it when it has already happened, and claim the abandoned name first.

How a trusted hostname ends up selling slot machines

The attack needs no exploit and no stolen credentials. It needs only a DNS record that outlived the thing it pointed to.

The pattern we saw repeatedly was the same few steps. A team spins up a marketing site, a QA environment or a conference microsite on a cloud platform and points a company hostname at it. Months or years later the resource is deleted, but nobody removes the DNS record. The name the record points to goes back into a shared pool, and anyone can claim it.

Attackers run automated sweeps for exactly these leftovers. The variants we found:

• Released cloud app names. Deleted web apps whose names were re-registered by a third party, often in a completely different cloud region, then bound to the victim’s hostname with a freshly issued certificate.
• Deleted storage buckets. Static-website buckets deleted by the owner and re-created with the same name.
• Unclaimed code-hosting pages. A hostname pointing to a project page nobody owns anymore.
• Recycled IP addresses. Records pointing at cloud IPs the company released, now handed to someone else.

The payoff is search ranking and trust. A gambling page on a well-known brand’s domain inherits that domain’s reputation with search engines and users. Some of the pages we found even cloaked themselves: they showed spam only to search-engine crawlers and looked broken to everyone else.

The business risk goes beyond embarrassment. The attacker controls a page on your domain, with a valid certificate for your hostname. That can be enough for phishing, cookie theft on sibling subdomains, or bypassing security controls that trust your domain.

Layer 1: See it coming, before an attacker does

The cheapest takeover to handle is the one that never happens. IONIX spots the dangling record while the name is still unclaimed, and tells the security team exactly what to delete.

That starts with knowing the hostname exists at all. Many of the hijacked hostnames we found lived on legacy brand domains, acquired companies and old campaign sites that no longer appear in any internal inventory. IONIX discovery connects them back to the organization through WHOIS records, shared nameservers, certificates, redirects and page content. It then resolves every DNS record it finds, every scan.

For each record that points at a cloud or SaaS resource, IONIX asks one question: does that resource still exist, and could someone else claim it? If the answer is yes, the security team gets a prioritized action item that names:

• the hostname and the dangling record,
• the service it points to,
• why it is exploitable, and
• the one-line fix, usually deleting or updating the record.

Coverage spans more than 20 takeover types across the major clouds and SaaS platforms. They include Azure App Service, Traffic Manager, CDN, Front Door, Blob Storage and VMs; Amazon S3, Elastic Beanstalk and released EC2 addresses; Google Cloud addresses; delegated DNS zones in Route 53 and Azure DNS; and various hosted platforms.

Layer 2: Finding the needle in the haystack with Spark

Some organizations come to IONIX after the damage is done. Their hostnames were claimed months ago and have been serving spam ever since. Spark, the IONIX AI analyst, finds those cases automatically, with no one having to go looking, because it reads the attack surface the way a human analyst would.

Why rules and keyword lists fail here

On paper this looks like a keyword search for “casino” or “slot” in page titles. Our sweep shows it fails in both directions.

Too broad. “Casino” appears on hotel and restaurant pages and in publishers’ legitimate affiliate reviews. “Situs Resmi”, a staple of Indonesian slot spam, literally means “official site” and titles real companies’ Indonesian homepages. A naive “cialis” match fires on “Specialists”.

Too narrow. The spam is written mostly in Indonesian, Thai and Chinese, in slang (“gacor”, “maxwin”, “anti rungkad”) and under brand names that change weekly (ASIA100, SIS4D, nova555). Some pages carry no telltale words at all: a betting portal written entirely in Thai script, or a clean title on a page that shows spam only to search-engine crawlers.

A keyword list is either too narrow to catch it or too broad to trust.

How Spark does it

Spark isn’t a chatbot, and it isn’t a single prompt to a language model. It is a full agentic harness, powered by frontier models, that plans and runs long investigations on its own: it breaks a question into tasks, works through the IONIX data behind each one, and reviews each and every asset in depth before it reports back. It is grounded in two things IONIX already knows: the organization’s full attack surface, and its entire corporate structure, including subsidiaries, acquired brands, franchises and regional entities. It runs this check on its own as part of the platform, and a security team can also ask it directly:

“Are any of our web assets serving content that doesn’t belong to us, like gambling, adult, crypto scams or fake pharmacies?”

Spark then works through the attack surface like an analyst, asset by asset, for as long as the job takes:

1. Reads every page title and content signal across the organization’s web assets, in any language, and understands what each page is about.
2. Separates abuse from look-alikes. A casino review on a media site is editorial; a slot portal on a QA subdomain of a manufacturer is not. An “official site” in Indonesian is not spam by itself.
3. Checks context that a rule can’t. Does the content match the brand, or the subsidiary or franchise that owns this hostname? Does a dev or QA hostname suddenly serve a consumer storefront? Did a dangling-record finding close right before new content appeared?
4. Confirms ownership against the corporate map. Spark knows which subsidiaries, franchisees and acquired brands belong to the organization, so spam on a franchisee’s regional domain or a forgotten acquisition’s site is still traced to the right entity. For each suspect it walks the IONIX attribution evidence (registrant, nameservers, certificates, seed domains) so the team knows the hostname is really theirs, and which business unit owns the fix.
5. Explains the likely cause and the fix. For example: this hostname points to a cloud app name that now belongs to someone else, so delete the record.

Across the monitored attack surface, Spark continuously narrows tens of thousands of distinct page titles down to a few hundred confirmed abusive hostnames, discarding along the way the look-alikes that trip every keyword rule.

That is the point of putting an agent, not just a model, on the attack surface. The hard part isn’t collecting the data; IONIX already has it. The hard part is reviewing tens of thousands of pages in a dozen languages, one by one, and knowing which handful matter. A chatbot answers a question; Spark runs the whole investigation.

Layer 3: Get there first with Active Protection

An alert is only as fast as the team that acts on it. Change tickets wait, DNS owners go on vacation, and attackers’ sweeps run around the clock. So IONIX doesn’t just warn: with Active Protection, it claims the abandoned name first.

When IONIX finds a record pointing at a cloud resource anyone could register, Active Protection registers that resource in an IONIX-controlled account before an attacker can. The customer’s hostname stays out of hostile hands, with no change needed on their side. IONIX holds the name until the customer removes or fixes the record, then releases it.

This isn’t theoretical. In the last few months, Active Protection claimed hundreds of abandoned resources before attackers could.

A few examples from the past few weeks, anonymized:

• A global software company retired three apps on a PaaS platform but kept the hostnames pointing at them. Active Protection claimed all three freed app names.
• A global media company left four DNS zones delegated to cloud nameservers after deleting the hosted zones. That setup lets an attacker hijack every name under those subdomains. Active Protection re-created and locked all four zones.
• A global restaurant brand was in the same position with four delegated zones during its IONIX trial. They were claimed immediately after the trial started.
• A European industrial manufacturer deleted three Traffic Manager profiles while its DNS still pointed at them. All three were claimed before anyone else could stand up a look-alike site.

Every name Active Protection holds is a hostname that can’t end up serving slot machines.

What security teams should do now

Dangling records are a hygiene problem that attackers have turned into an industrial process. Closing the gap takes multiple layers working together:

1. Know every hostname you own, including legacy brands, acquisitions and campaign domains that fell out of your inventory.
2. Treat decommissioning as a DNS change. When a cloud app, bucket or zone is deleted, the record that points to it goes in the same change ticket.
3. Watch for content that isn’t yours. A QA hostname that suddenly sells slot games is a takeover, even if every scanner says the record now “resolves fine.”
4. Don’t race attackers by hand. Automated claiming closes the window between “the resource was deleted” and “someone else registered it.”

IONIX covers the whole lifecycle. Discovery finds the hostnames you forgot you had. Continuous takeover detection flags every dangling record before it is exploited. Spark reads your entire web presence, in any language, to surface the handful of pages that no longer belong to you. And Active Protection claims abandoned names before attackers can.