How to detect cloaking on a compromised website

For cybersecurity professionals, system administrators, and webmasters, a resource breach is a critical incident. However, the worst-case scenario is a compromise that remains unnoticed for months. Attackers have learned to monetize the reputation of legitimate corporate websites to promote spam and phishing in such a way that business owners see no signs of a problem during normal browsing.

This concealment technique is called cloaking. It allows displaying a perfectly clean, functional site to administrators and auditors, while malicious content is served to search bots (e.g., Googlebot). In this article, we will analyze the mechanics of cloaking, the logic of its implementation at the web server level, and the detection methodology via Google Search Console (GSC) with subsequent analysis of HTTP headers.

Anatomy of cloaking: why a standard browser does not see a site breach

The cloaking mechanism is based on dynamic content separation on the server side. When a client sends an HTTP request to a web server, a malicious script analyzes the request metadata before generating the page. Attackers configure conditional rules based on the following parameters:

• User-Agent: The server checks whether the request header contains signatures of search bots (specifically, Googlebot). A request from a standard browser receives a legitimate page, while a request from a search bot receives spam.
• HTTP Referer or device type: Attackers configure redirects that trigger only when a user navigates to the page from Google search results or uses a mobile device. If an administrator enters the address directly into the browser bar, the malicious script does not activate.

According to Google Search Central guidelines, content added to a site without the owner's permission through a vulnerability is classified as "hacked content." In the case of cloaking, this most often manifests in two forms:

1. Content Injection: The insertion of hidden links or text into legitimate pages. Visually, they are invisible to the user, but a search bot indexes them.
2. Page Injection: The creation of new, unauthorized spam pages on a compromised site by an attacker. During a standard CMS audit, such pages may not physically exist in the file system structure because they are generated "on the fly."

According to the ENISA Threat Landscape 2025 study, phishing remains one of the key vectors for gaining initial access. After compromising credentials or exploiting vulnerabilities, attackers implement masking mechanisms, making it almost impossible to detect a breach without emulating search engine behavior.

Google Search Console as a primary incident diagnostic tool

Although Google Search Console is a tool for managing search results rather than a full-fledged antivirus scanner, it acts as an effective indicator of compromise (IoC). Since Googlebot scans the site from the outside, it can "see" what is hidden from the internal administrator.

The main marker is the Security Issues report. Here, Google displays warnings about the presence of hacked content. At the same time, it is important to remember that the list of URLs in the Security Issues report is often incomplete. This list should be viewed solely as examples of infected pages, not as an exhaustive array of compromised objects.

Step-by-step: how to detect discrepancies via the URL Inspection Tool

To compare page rendering, the URL Inspection tool is used. This allows you to view the resource from the perspective of Googlebot.

Verification algorithm:

1. Copy the suspicious URL from the Security Issues report or the page where abnormal traffic was recorded.
2. Paste the address into the search bar at the top of the GSC panel.
3. Click Test Live URL to initiate a real-time request.
4. Once completed, click View Tested Page.
5. Go to the HTML tab. This is the exact source code that your server generated for Googlebot.
6. Compare the received code with the source code of the same page opened in your standard desktop browser.

If the code in GSC contains blocks of foreign text, third-party links to suspicious resources, or scripts missing from the original, you are dealing with cloaking.

Analysis of HTTP headers and conditional redirects: where to look for malicious rules

If the incident is confirmed, it is necessary to localize the malicious code. Attackers most often implement request verification at the level of web server configuration files or global CMS scripts.

At the web server level (e.g., in the .htaccess file for Apache or nginx.conf for Nginx), RewriteCond rules may be placed to check the HTTP_USER_AGENT for googlebot signatures. If server-level rules are absent, the cloaking logic is likely implemented in the application initialization files (e.g., index.php). In the code, one should look for eval(), base64_decode(), and gzinflate() functions, which are often used to obfuscate malicious scripts.

Evidence preservation and localization of injection points

For incident response, a specialist must capture the exact HTTP server responses before making any changes.

Use the curl utility to simulate a request from Googlebot and capture HTTP headers (using the -I flag):

curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://your-site.com/suspicious-page

Carefully analyze the status code (e.g., the server may return 200 OK for pages that should normally return 404), as well as redirection headers (Location). This allows for the collection of evidence of the malicious code's direct operation.

Why cleaning Search Console does not equal closing a vulnerability

A typical mistake during response is to delete spam files and simply request a review in GSC. A warning in Google Search Console is only a symptom of a compromise. If you have addressed the consequences but have not closed the structural backend vulnerability (e.g., left an outdated plugin or compromised access), attackers will automatically restore the cloaking scripts.

According to the Cisco Cybersecurity Readiness Index 2025, only 27.7% of organizations have a sufficient level of readiness for modern cyber threats. Building resilient protection requires a comprehensive approach, not just a simple reaction to search engine warnings.

For businesses that need more than just targeted CMS cleaning, the Intecracy Group alliance of independent companies offers comprehensive cybersecurity audit services and the implementation of secure development processes (DevSecOps) through specialized teams, including Softengi. This allows for the design of secure architectures and proactive elimination of structural vulnerabilities in web resources.

Algorithm for checking and documenting cloaking on a compromised site

Remember that effective incident response includes a full cycle: from detection using GSC tools and evidence preservation to root cause analysis and security architecture review.

FAQ

How to check a site page as Googlebot without Search Console?

This can be done using a terminal and the curl utility by changing the User-Agent header. For example: curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://your-site.com/. You can also use browser DevTools by enabling network condition emulation.

Why does Google still show a breach warning after removing malicious code?

Google Search Console does not update in real-time after local changes on your server. After fully cleaning the site and closing the vulnerability, you must go to the Security Issues report and submit a Request Review. The search engine verification process can take several days.

How do attackers set up redirects only for mobile users from search?

The mechanism is based on checking two HTTP headers: HTTP_REFERER (to determine that the transition occurred from google.com, bing.com, etc.) and HTTP_USER_AGENT (presence of mobile device signatures such as Android or iPhone). If both conditions match, the server script or web server configuration forcibly returns an HTTP redirect status to the target spam resource.

Data sources

• Google Search Central: Security issues report: hacked content
• Google Search Central: Spam policies: hacked content and cloaking
• ENISA Threat Landscape 2025
• Cisco Cybersecurity Readiness Index 2025
• NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• FCC First Caller ID Authentication Report and Order