Website Redirects SEO Cloaking and Recovered PHP Tools

Executive Summary

Spaling Advisory received a referral for apparent website defacement. A separate visual defacement of legitimate pages was not independently established in the reviewed material. The investigation verified a JavaScript redirect, active SEO cloaking, and malicious PHP tools. Chrome DevTools established how the redirect worked; comparing browser content with Google’s crawler response exposed a separate manipulation of search-engine content.

The findings came from three sites. The redirect on Site A had a confirmed source file. Active cloaking on Site B remains under investigation with the hosting provider. NOX was recovered from Site C and was not shown to cause Site B’s cloaking. Review relied on website dumps and recorded observations, without full server access.

Trace the redirect in Chrome DevTools

Site A intermittently sent visitors to an advertising destination. Spaling Advisory captured the browsing session in Chrome DevTools and examined the request sequence in the Network tab. The first question was whether the website returned an HTTP redirect or delivered code that redirected the browser after loading.

The initial homepage request returned HTTP 200. Its response began with an external script reference, followed by a hosting control panel’s default test page. DevTools captured the external JavaScript as well: it assigned an advertising URL to window.location.href.

The relevant response fragments are shown below with domains replaced by reserved placeholders.

<script src="//script.example/"></script>

window.location.href = "https://redirect.example/";

Follow the browser evidence back to the file

The script hostname provided a concrete search term. Review of Site A’s document root found the same script at the start of index.html, followed by the default test page seen in DevTools. This connected the browser’s response to a malicious file within the website content. The site was reachable and serving that file; why the default test page was present was not established. The same script appeared in a historical archive of Site C, but that archive was not shown to cause Site A’s live redirect.

Compare what visitors and Google received

Google search results displayed page code, while Bing results included gambling terms. Historical indexing was initially plausible. However, Search Console’s crawled HTML contained gambling links absent from the ordinary browser source of Site B.

The important distinction was between the content delivered in a response and what the browser displayed after processing it. The DevTools investigation had already shown why a page’s appearance alone was insufficient. Here, the discrepancy between browser source and crawler HTML made the requesting user agent the next variable to test.

Spaling Advisory fetched the Site B homepage twice, saving the responses separately. The first request used curl’s default user agent. The second supplied a Googlebot user agent. Both saved files were searched for the same wl-main marker and gambling terms.

Figure 1 Site B PowerShell response comparison. Target URLs and local account names are redacted. The default request returned no matches for the selected patterns; the Googlebot request returned gambling links.

Changing the user agent was enough to reproduce the gambling content from Spaling Advisory’s own connection. This moved the assessment beyond an old search result: the live website was still returning malicious content selectively. Reindexing alone could not correct search results while those responses continued.

The negative result applied to the selected patterns in that response. It did not establish that every page, request condition, or website file was clean.

Search the files and review the PHP tools

Spaling Advisory did not have full server access. File searches used the full Site B website dump and the related Site C dump; Site A’s redirect was assessed from its browser capture, source file and selected configuration. These materials did not provide complete visibility into the provider’s server runtime. Identification of Site B’s active cloaking implementation is ongoing with the hosting provider.

Searches for response markers, gambling terms, crawler handling, and PHP obfuscation did not locate the active cloaking implementation. A negative file search therefore did not rule out configuration, loaders, or delivery layers outside the reviewed material.

The recursive YARA scan covered the Site B and Site C dumps. Core returned no reported matches; Full produced 10 matches across eight files: six matches in six Site B files, and four in two Site C files. Review identified Site B’s Late.php handler, which appears unauthenticated, and Site C’s NOX panel.

Case notes recorded live inspection of Site C’s NOX panel displaying passive or absent cloaking vectors and absent loader files. This point-in-time panel observation did not establish that every delivery path was inactive. The views below were prepared for analysis and contain illustrative runtime values.

Figure 2 NOX setup view and dashboard preview. Identifying values and the access token are redacted. Dashboard runtime values are illustrative.

Validate removal against the original symptoms

The investigation produced two different validation requirements. For Site A’s redirect, the delivered HTML must no longer reference the malicious script and the browser must no longer follow that navigation chain. For Site B’s SEO cloaking, repeated visitor and crawler requests must return the intended content through the public delivery path.

File removal and signature scans support that work, but response testing determines whether the original symptoms remain. PHP configuration, loaders, must-use plugins, hidden content, and search-engine ownership artifacts also require review. Complete eradication was not established in the available evidence.

Appendix Hunting artifacts and indicators

Client identifiers are withheld. Site labels match the summary table. NOX-derived markers are search leads; deployment of the listed components was not confirmed. Filenames and configuration directives alone do not establish maliciousness.

SHA-256 of the single uploaded nox.php sample associated with Site C:

97ba51d7819b1c41bf79f931197659a027936a644904bd8bbfd89beae04c1214