An SEO fraud crew is now shipping kernel rootkits and BYOVD, and that is the story

Cisco Talos has documented SPECTRE, a cross-platform backdoor written in C and used by an intrusion set it tracks as UAT-10147, a Chinese-speaking actor that targets internet-facing IIS and Linux servers ^[1][6]. The detail worth acting on is not the implant itself but its owner: this is a crew that monetizes access through search engine optimization fraud ^[1], and it is carrying kernel-level EDR bypass, Bring Your Own Vulnerable Driver neutralization and Linux kernel rootkits ^[2][3].

Talos describes the group as running a multi-platform post-exploitation ecosystem that pairs SEO fraud monetization with persistence and defense evasion tradecraft ^[1]. The arsenal spans SEO fraud utilities, local privilege escalation tools, and both off-the-shelf and custom backdoors ^[5], alongside open-source offensive tooling and in-memory web shell deployment ^[3]. SPECTRE itself carries cross-platform command-and-control, process injection, credential theft, anti-analysis protection and kernel-level EDR bypass ^[2]. Talos named it after a debug log recovered from a sample that prints the malware's name in its header ^[7].

The Windows build is a modified Havoc payload, with custom post-exploitation and evasion functionality compiled directly into the binary rather than bolted on at runtime ^[8]. Two layers of obfuscation matter for anyone writing detections. API resolution happens entirely at runtime through PEB hash walking using a DJB2 variant ^[9]. Strings are encrypted at compile time with per-string xorshift32 seeds, decrypted into thread local storage immediately before use, and never held in plaintext in the .text or .rdata sections ^[10]. Talos' conclusion is blunt: static detection methods are largely ineffective against the implant's indicators ^[11]. The implant also runs a weighted anti-analysis scoring routine that checks process name blocklists, RAM capacity, CPU core count and disk characteristics before proceeding ^[12].

On provenance, Talos assesses with medium confidence that several SEO fraud components tie to a handle it renders as "xshen," based on development artifacts embedded in the BadIIS malware and related tooling ^[15]. The BadIIS samples carry PDB paths from build directories dated 2025-11-21 that include that handle ^[16], and the BadIIS installer embeds a service installer whose PDB string references it as well ^[17]. Elsewhere the campaign leans on the same initial: the ASHX SEO engine configuration includes a string named "X-seo," and the web shell authenticates via an "X-ID" HTTP header carrying a token, which Talos reads as covert authentication blended into routine HTTP traffic ^[18].

Talos also says its analysis of recovered source code suggests portions of the Linux rootkit may have been built with AI-assisted code generation ^[4], and that both SPECTRE and the custom rootkit it calls Specter show indications of AI-assisted development ^[13]. That follows earlier Talos reporting that the same actor operationalized AI-assisted exploitation workflows to compromise IIS and Linux servers at scale ^[14]. Treat the AI attribution as an assessment from code artifacts, not a proven build pipeline.

The operational read: driver load controls and kernel module integrity monitoring have been filed under nation-state defense in a lot of shops, justified by the assumption that the crews hitting your public web tier want credentials and crypto, not ring 0. A group whose revenue model is ranking manipulation now brings both ^[1][3]. If your Linux server fleet has no baseline for loaded kernel modules and your Windows estate does not enforce a vulnerable driver blocklist, this is the campaign that makes that gap ordinary rather than exotic.

Watch for the rest of the Talos writeup, particularly the Specter rootkit internals and the specific driver abused for BYOVD, since the driver hash is what turns this from reading into a blocklist entry ^[3]. Also watch whether the anti-analysis scoring routine's thresholds get published; process name blocklists and core count checks are exactly the sort of logic that makes sandbox verdicts unreliable ^[12].