A museum, a restaurant, a hotel, a university, a government website. Nothing connects them except one anomaly: they all show up in search results related to online gambling, even though their business has nothing whatsoever to do with it.
Their owners are not yet aware of it, but this is a sign that their website has been compromised and that attackers are hijacking its reputation to promote their malicious gambling platforms.
CERT-Wavestone recently observed several cases of this kind. At first glance, nothing suggests a compromise. No defacement, no blank page on a Monday morning, no furious customer on the phone. These sites are up and running. In fact, they are running very well. Except that, on closer inspection, it turns out the attackers made a few specific changes to the source code. Changes that are invisible to visitors, but not to the bots and AI assistants crawling the web.
Tell me who you are and I’ll tell you who I am
Let’s take one of the cases we observed recently. Looking at the source code of the compromised application, the explanation quickly became clear. In the homepage PHP file, the attacker had slipped in a few lines of code, almost negligible among the rest. Here is a pseudo-code version:
The idea is as simple as it is effective. On every request, this small piece of code checks the User-Agent header of whoever is requesting the resource. If it is a search engine crawler (Googlebot, Bingbot, and the like), the server serves it an entirely different page, tailor-made, and then immediately stops execution. If it is a human visitor (with a standard browser User-Agent), the original content of the real site is displayed. And since humans never see the malicious version, no one suspects a thing.
This technique has a name: cloaking. It consists of serving different content depending on whether the request comes from a human user or a search engine crawler. It is a well-known black-hat SEO practice, long used to circumvent search engine rules and manipulate rankings. So the attacker didn’t invent anything: they simply applied an old, tried-and-tested online marketing recipe.
The filtering can also be based on other criteria besides the User-agent, which are even harder to detect:
- the visitor’s IP address range: search engine crawlers use IP addresses belonging to known ranges that can be verified through reverse DNS
- the request’s referrer: to trap only users arriving from a search results page.
There are also variants that involve no modification to the application’s page code, with the branching logic placed in a web server configuration file (a .htaccess file containing a few RewriteCond directives on HTTP_USER_AGENT is enough).
With these methods, even the administrator visiting their own site sees a perfectly clean site. Only search engines see the poisoned version. And it is precisely this version that ends up indexed, ranked, and distributed in search results worldwide.
A matter of stealth
Such stealth may seem surprising. After all, why not simply redirect all visitors to malicious sites?
Because that would be the best way to get caught: the slightest suspicious redirect would immediately alert both users and administrators of the infected site. That would run counter to the attacker’s objectives. And to understand those objectives, we need to go back to what SEO cloaking really is: a malicious technique that aims to manipulate the search ranking of online content in order to push it to the top of the search results. And this ranking relies largely on reputation: a domain’s age, its credibility and the number and quality of links pointing to it.
By serving search engine crawlers content stuffed with keywords and links pointing to their own domains, the attacker pushes their own sites up in the results for those keywords. Then, and above all, they transfer part of the compromised domain’s credibility to their malicious links: a link posted on the website of a trusted hotel, restaurant, or university carries infinitely more weight in the eyes of ranking algorithms than a link posted on a site created the day before. The longer the poisoning lasts, the more effective the ranking boost: hence the value of staying stealthy for as long as possible.
It is a form of digital parasitism, almost elegant in its discretion: the attacker breaks nothing. They simply borrow the trust that others spent years building.
A widespread infection
In our example case, while analyzing the HTML code injected into the PHP page, two terms kept coming up: “slot gacor”. An expression that probably means nothing to you at first glance.
To understand these terms, you first need to know that online gambling has grown at a staggering pace over the past ten years or so, driven by millions of players around the world seeking thrills and potential winnings. In the jargon of this industry, one expression is widely used: “slot gacor”. Popularized within the online gambling community in Southeast Asia, and especially in Indonesia, it has become a true rallying keyword for slot machine enthusiasts. “Gacor” comes from local slang and, in everyday language, refers to something that works exceptionally well or consistently produces positive results. Combined with “slot”, the term refers to a machine perceived as being on a winning streak, paying out frequent and sometimes substantial winnings.
These details may seem trivial, but they help us better understand the attacker’s motivations, since the goal of the attack is to appear in search results when users type these keywords.
By typing these keywords into Google, we came across a large number of results, leading to hundreds of domains that, like our initial victim, have no apparent connection to gambling but host the same type of malicious content:
As you can see, the victim profile is heterogeneous: nonprofits, universities, hotels, stores, restaurants, personal blogs. Organizations whose security and monitoring resources are generally very limited, or even nonexistent. They are more vulnerable, less monitored, and offer ideal ground for a compromise whose sole purpose is to last without being detected.
In addition, other terms from the same world rounded out our mapping of this type of infection:
|
|
|
Other terms identified during the investigations
This list suggests that other keywords could be used to spot compromised sites. The terms we identified all belong to a subcategory of the gambling world, but it is a safe bet that other categories of vocabulary would uncover many more compromises.
Cloaking, one technique among many
The case we handled illustrates just one branch of a much larger tree. SEO poisoning actually encompasses a whole range of techniques that share the same goal (hijacking search engine ranking mechanisms) but differ in their means and their purpose.
- Cloaking, which we have just described: two versions of the content, one for bots, one for humans.
- Conditional redirection: the site remains intact, but any visitor arriving from a Google results page is redirected to the attacker’s platform. Direct access to the domain, on the other hand, triggers nothing (enough to fool an administrator testing their own site).
- Hidden link and text injection (spamdexing): links are added to the footer, comments, or existing articles, then hidden with CSS (display:none, text the same color as the background, off-screen positioning). Here, there is only one version of the page: it is its actual content that gets polluted.
- Doorway pages: rather than modifying existing pages, the attacker generates hundreds of new ones, often placed in a rarely monitored directory (/wp-content/uploads/, for example), sometimes accompanied by a rogue sitemap to speed up their indexing.
- Parasite SEO: without even compromising a server, the attacker exploits open areas of legitimate platforms (forums, comment sections, free subdomains, public document repositories) to host their content and benefit from the host domain’s reputation.
- SEO poisoning for malware distribution: the most offensive variant, where the ranked content is not a gambling platform but a fake download site. By ranking for very specific queries (software utilities, administrative document templates, niche legal questions), families such as Gootloader or SolarMarker lead victims to download the malware themselves.
In our cloaking case, the purpose is purely financial. The aim is not to infect visitors to the compromised site, but to capture search traffic and redirect it to betting platforms. This largely explains the care taken to remain undetected.
How does the attacker get in?
To insert lines of code into a PHP file, you first need to be able to write to the server. Cloaking is not an intrusion vector; it is a payload. Upstream, there is always an intrusion chain and it is not necessarily sophisticated.
The vectors most frequently observed in this type of attack:
- A vulnerable application component: mainstream CMSs (WordPress first and foremost, but also Joomla, Drupal, PrestaShop, Moodle) rely on an ecosystem of extensions and themes whose development quality and security maintenance are not guaranteed. A published vulnerability, an unapplied patch, and exploitation can become trivial. This entry point deserves all the more attention since these CMSs mostly rely on PHP, which has recently been hit by critical vulnerabilities.
- Insufficiently controlled file uploads: Contact form with attachments, photo gallery, résumé upload area: as soon as the check is based on the declared extension rather than the file’s actual type, and the destination directory allows code execution, uploading a webshell gives the attacker persistent write access to the entire directory tree.
- Remote code execution (RCE): Whether it stems from insecure deserialization, local file inclusion combined with log poisoning, or command injection, it immediately provides the required level of access.
- An exposed administration interface: CMS console, phpMyAdmin, hosting panel, deployment interface: if it is accessible from the Internet with no IP address restriction or second factor, it is only as strong as the password protecting it.
- And many others
Whatever the vector, the next step is the same: establishing persistence that will survive a site update. It is this persistence, more than the injection itself, that explains why so many “cleaned” sites end up reinfected a few days later.
Detection and remediation
What makes this compromise particularly interesting is that, under certain conditions, it can be carried out without triggering a single alert in security tools. No abnormal traffic, no malicious binary executed, no known signature: just a few extra lines of code in a source file.
There is no universal method for identifying whether a page is a victim of SEO cloaking. However, one simple method is to query the site while successively presenting the User-Agents of the various search engine crawlers, then compare the result with that of a standard browser. Any content discrepancy can be a potential sign of compromise. If both versions are identical, the technique is probably not present.
Here is an example request to test a site as a standard browser:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" https://example.com/ -o human.html |
The second one replays exactly the same request, posing as Googlebot:
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -o googlebot.html |
All that remains is to compare the two responses:
diff human.html googlebot.html |
On a clean site, diff returns nothing, or only minor variations (CSRF token, timestamp, session ID). On a site affected by cloaking, the difference is usually obvious: two entirely different documents, often of very different sizes and with different entropy. The comparison can be repeated with the user-agents of other search engine crawlers (Bingbot, DuckDuckBot, YandexBot, etc.).
Other good practices can help detect the compromise of a domain more quickly:
- monitor the integrity of application files in production, in order to detect any modification of the source code, including in web server configuration files
- analyze, through a simple search such as site:mydomain.tld, what search engines have actually indexed from your domain
- check search engines’ webmaster tools, which report the appearance of unknown pages, spikes in incongruous keywords, and any manual actions to downrank the site.
Finally, a note that applies to remediation: restoring the modified files is not enough. Without identifying the initial intrusion vector and removing the persistence mechanisms, reinfection is only a matter of time.
The order of operations also matters. Start by removing everything the attacker left behind: injected code, and any added extensions, accounts, and files. Next, rotate all secrets (CMS administration, database, FTP/SSH, etc.), then invalidate all open sessions. Finally, update every outdated component: CMS, themes, extensions.
If the extent of the compromise cannot be established with certainty, reinstalling or restoring from a backup predating the intrusion remain the safest options. On one condition: the necessary hardening must be applied before the site goes back online. Otherwise, it will be compromised again in the same way.
This type of attack illustrates a reality that is sometimes forgotten: an attack is not always meant to make noise or cause damage. Here, stealth is the goal ! The longer the compromise goes undetected, the more it pays off for the attacker.
SEO poisoning was initially aimed solely at search engines. But as AI agents browse the web on behalf of their users, we should expect this strategy to evolve to target them as well. The mechanism is the same: only the list of User-Agents changes. The stakes, however, are no longer the same. Content crafted for a search engine gains a few places in a ranking. Content crafted for an AI agent becomes an answer, passed on to the user with the endorsement of the legitimate domain being consulted, without the user ever having seen the page.
Monitoring a website should not stop at what humans see. Every now and then, we also need to ask what our friends the bots and AI agents see. Because one website can hide another.
