Injected scam and scareware content that steals attention and trust rather than card numbers, which is exactly why it survives on a page longer than a skimmer would.
Published 15 July 2026
Updated 24 August 2026
Client-side security discussion is dominated by card skimming, because that is where the direct financial loss is. It is not the only thing that gets injected into a compromised page, and the rest is worth attention for a reason that has nothing to do with what it steals.
The hosts we track here serve scams. One is a fake-antivirus scareware CDN whose only asset is a banner script impersonating a well-known security vendor, on a month-old domain fronted by a CDN whose apex returns 403 to anyone looking. Another is an AI-trading investment scam that asks for a deposit to get started, and is one node in a farm of clones across several top-level domains and languages.
We found both in customer CSP violation reports and confirmed them from public sources.
A skimmer converts a compromise directly into card numbers. A scam overlay converts it into the visitor's attention while they are on a site they trust — the padlock, the domain and the brand are all yours and all correct, which is exactly what makes the scam work better there than on a domain the attacker registered.
The visitor does not distinguish. They saw a virus warning, or an investment offer, on your site.
A skimmer discovered on a checkout page produces an incident. A fake antivirus banner produces a support ticket about a dodgy ad, and gets routed to whoever handles advertising.
That routing is the problem. Nobody looks at how the content got onto the page, so the injection stays open. The next thing to arrive through it might be a skimmer, and by then the compromise has been in place for months with a plausible explanation attached to it.
Treating an unexplained third-party host as a compromise regardless of what it serves is the difference between finding this in July and finding out in December.
The investment-scam host we track is not a single site. The same operation runs the same content across multiple top-level domains, with hyphenated variants and localised versions for different languages.
That shape matters for how you respond. Blocking the one host in your reports stops that node and nothing else, and the operator has more. It is the injection point on your own page that is worth your time; the domain is the part they can replace cheaply.
An unfamiliar host in your reports on a page with no advertising and no third-party interface is the signal, whatever it turns out to be serving.
Two things make these easy to miss. The volume is usually low, because campaigns are often geo-targeted or shown to a fraction of visitors, so the reports arrive as a trickle rather than a spike. And the host frequently sits behind a large CDN, so a reverse lookup tells you nothing useful and the domain itself may refuse to answer anyone who goes looking.
These are the entries in our threat intelligence feed for this campaign, shown exactly as we match them. An entry starting *. covers that domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do that when the attacker registered the domain themselves.
The feed changes as we go. We add hosts when they show up and pull them out when the evidence no longer holds, so this is what we're matching today rather than a permanent record.
cdn.redgarto.comryplonsyncgpt.comwww.ryplonsyncgpt.comObserved in Report URI report telemetry. We classify these on what we saw them doing, not on any claim about who runs them.
We flag these hosts in your own reports automatically, so you hear about it from us instead of from your customers.
← All threat intelligence research · Read this page as Markdown