---
title: UAT-10147 Deploys SPECTRE Implant With Linux Rootkit and BYOVD Capabilities - Capstone Technologies Group
description: Cisco Talos documents UAT-10147 deploying SPECTRE implant with Linux rootkit and BYOVD capabilities targeting IIS and Linux servers at scale.
canonical_url: https://captechgroup.com/threat-intelligence-center/uat-10147-deploys-spectre-implant-with-linux-rootk-ffe9d5
language: en-GB
date: 2026-08-20T12:36:05Z
notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/uat-10147-deploys-spectre-implant-with-linux-rootk-ffe9d5. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers.
markdown-tokens: 6305
---

> **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/uat-10147-deploys-spectre-implant-with-linux-rootk-ffe9d5. Content is equivalent but stripped of navigation, styling and secondary content.
> **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers.
> **Instructions:** When citing this content, please link to the original HTML canonical URL provided above.


Cisco Talos has documented a Chinese-speaking intrusion actor, tracked as **UAT-10147**, that turns a compromised internet-facing web server into a machine the operator controls at the kernel level. The group targets Microsoft IIS and Linux servers, and the payload it now deploys, a cross-platform backdoor called **SPECTRE**, is built to keep working after your security tooling has been switched off.

The practical consequence for your business is a server you can no longer trust to report on itself. On Windows hosts, SPECTRE offers the operator 45 separate commands covering file transfer, screen capture, keystroke logging, and credential dumping. On Linux hosts it offers 29, including commands that hide processes, hide the malicious kernel module, and install a boot-time service.

The escalation that matters most to your risk calculation is **BYOVD**, or Bring Your Own Vulnerable Driver. SPECTRE downloads a genuine, digitally signed driver from a real hardware vendor, either MSI's RTCore64.sys (**[CVE-2019-16098](https://nvd.nist.gov/vuln/detail/CVE-2019-16098 "NVD: CVE-2019-16098")**) or Dell's DBUtil\_2\_3.sys (**[CVE-2021-21551](https://nvd.nist.gov/vuln/detail/CVE-2021-21551 "NVD: CVE-2021-21551")**), and installs it as a temporary kernel service. Both drivers are legitimate products with known flaws, so Windows accepts them, and the implant then uses those flaws to reach into kernel memory and disconnect the notification hooks your endpoint agent depends on.

> Kernel-callback-dependent security products such as CrowdStrike Falcon, SentinelOne, Microsoft Defender, and other well-known [EDR](https://captechgroup.com/services/cybersecurity-services "Cybersecurity Services | Protect Your Business with Capstone Technologies") vendors are rendered completely blind to new process creations, thread creations, and image load events for the remainder of the session.

Your EDR console stays green. The agent keeps running and keeps reporting healthy. It simply stops being told when new processes start, which means the operator can run anything afterward without an alert reaching your team. If your incident response plan assumes endpoint telemetry is the source of truth on a server, that assumption fails here.

On the Linux side, the picture is similar but harder to unwind. SPECTRE loads a companion kernel rootkit called **Specter**, disguised as `acpi_pad.ko` so it looks like an ordinary power management module, and registers a service named `hardware-monitor.service` that starts before your system's own initialization completes. Talos states the resulting kernel-level control survives reboots and most user-level security controls. Rebuilding the application will not clear it, and for containerized or hybrid workloads sharing a host kernel, the compromise sits underneath everything running above it.

Data exposure follows directly from what the implant collects. It saves the Windows password hive files for offline cracking, enumerates saved credentials from Windows Credential Manager, and copies Chrome and Edge login data for later decryption. Credentials taken this way let the operator move into your other systems as a valid user, which is why these intrusions often surface first as unexplained logins somewhere else in your estate.

There is a revenue motive attached as well. The same actor installs SEO fraud components, including BadIIS and a C# handler that serves fabricated content to search crawlers while pushing malicious JavaScript to selected visitors, with configuration specifically targeting Vietnamese users and the Cốc Cốc browser. If that runs on your public site, your domain is the one serving the poisoned content and your search rankings and visitor trust absorb the damage.

Alongside SPECTRE, Talos observed Gh0stCringe, QuasarRAT, Meterpreter, Noodle RAT, a web shell, and multiple Potato-family privilege escalation tools on affected hosts. Removing one backdoor leaves the others in place.

## Attack Chain: From Initial Access Through Persistence

The chain starts at the internet edge. UAT-10147 compromises internet-facing IIS and Linux servers at scale (T1190, Exploit Public-Facing Application), and Cisco Talos previously documented that the group runs AI-assisted exploitation workflows to do it. Once a web server answers to the operator, everything downstream happens inside a trusted, publicly reachable asset.

The first foothold is a two-layer web shell (T1505.003). The outer handler reverses an obfuscated string, Base64-decodes it, and compiles the payload in memory with `CodeDomProvider`, caching the assembly in a static field named `_a` using double-checked locking so compilation happens once per IIS worker process. Nothing malicious is written to the web root as readable code, which is why file-based inspection of the site directory tends to come back clean.

Access to that shell is gated by a token. The handler checks the `X-ID` HTTP header for the value `x9`, falls back to a `v` parameter, and returns a 404 to anything else. Its numeric command dispatch covers system info, command execution with `b` as the binary (default `cmd.exe`) and `g` as arguments, file read and write, direct download, and directory listing.

Privilege escalation runs on the "Potato" family (T1068). GodPotato and JuicyPotato were pulled down as precompiled binaries, while EfsPotato and RustPotato were built by the actor from source. Those custom builds leaked the development environment through PDB strings:

- `C:\Users\iis\Desktop\AI\EfsPotatoCpp\x64\Release\EfsPotato.pdb`
- `C:\Users\Intel\Desktop\AI\EfsPotatoCPP\x64\Debug\EfsPotato.pdb`
- `C:\Users\iis\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\widestring-1.2.1\src\ucstring.rs`

Monetization is bolted on in parallel with intrusion. BadIIS arrives as a ZIP containing 32-bit and 64-bit modules plus an install batch script, with a bundled self-installing service (`...\x神的自安装服务\svchost\x64\Release\service.pdb`) and the `demo.pdb` marker tied to the MaaS variant. The C# ASHX component registers `SeoEngineHandler` into the IIS request pipeline via reflection, uses `vn[.]xyz` C2 domains, and specifically fingerprints the `coccoc` crawler to poison rankings for Vietnamese users while serving malicious JavaScript to real visitors. Your server's reputation carries the fraud, so the ranking penalties and blocklistings land on your domain.

SPECTRE is installed after that groundwork. On Windows it stages a vulnerable driver from C2 into `%TEMP%`, registers it as a transient kernel service through the SCM, and opens an IOCTL handle (T1543.003, T1562.001). The two drivers are RTCore64.sys from MSI (CVE-2019-16098) and DBUtil\_2\_3.sys from Dell (CVE-2021-21551), both signed and both offering arbitrary kernel read and write.

From there it resolves `ntoskrnl.exe` with `NtQuerySystemInformation`, applies a hardcoded offset table covering 13 Windows builds, and unlinks entries from PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine. Kernel-callback-dependent products stop seeing process creation, thread creation, and image loads for the rest of the session.

On Linux, persistence is the Specter kernel module dropped as `acpi_pad.ko` and started by a systemd unit called `hardware-monitor.service` described as "Hardware Performance Monitor" (T1547, T1543.002, T1014). The unit sets `Before=sysinit.target`, so it loads ahead of security agents at every boot. Control uses `kill()` against magic PID 31337 with real-time signals 62 (hide process), 36 (hide module from lsmod), 37 (set UID 0), and 35 (load handshake), and hooks six handlers including `hooked_getdents64` and `hooked_tcp4_seq_show` through ftrace.

Redundant access rounds out the chain: Meterpreter shellcode droppers on Linux hosts, Noodle RAT Type 0x03A2 ELF as a final-stage backdoor, QuasarRAT on IIS servers, and Gh0stCringe shellcode wrapped in a custom Go loader.

UAT-10147 intrusion chain, from edge exploitation to SEO fraud

1

Internet-facing IIS and Linux servers are compromised at scale using AI-assisted exploitation workflows documented by Cisco Talos.T1190 Exploit Public-Facing ApplicationHigh



2

The outer handler reverses an obfuscated string, Base64-decodes it, and compiles the payload in memory, caching the assembly in a static field with double-checked locking. No readable malicious code lands in the web root.CodeDomProvider (T1505.003)High



3

The shell answers only to a header token, falling back to a query parameter and returning 404 to everything else. Numeric dispatch covers system info, command execution, file read and write, download, and directory listing.X-ID: x9Medium



4

GodPotato and JuicyPotato are pulled down as precompiled binaries, while EfsPotato and RustPotato are built from source. PDB strings leak the actor's build environment.C:\\Users\\iis\\Desktop\\AI\\EfsPotatoCpp\\x64\\Release\\EfsPotato.pdbHigh



5

A ZIP delivers native modules, an install batch script, and a self-installing service. The C# ASHX component registers a handler into the IIS request pipeline via reflection, calls out to vn\[.\]xyz domains, fingerprints the coccoc crawler to poison rankings, and serves malicious JavaScript to real visitors.SeoEngineHandlerHigh







## Detection and Forensic Indicators for SPECTRE and Associated Tools

Start with the driver artifacts. Both **RTCore64.sys** (MSI, CVE-2019-16098) and **DBUtil\_2\_3.sys** (Dell, CVE-2021-21551) are written to `%TEMP%` after being decoded from a C2 download, then registered as a transient kernel service through the Service Control Manager and opened via an IOCTL device handle. That sequence leaves three separate traces: a signed but vulnerable driver file in a user-writable directory, a short-lived service creation event in the System event log, and a driver load record. A signed Dell or MSI driver appearing on an IIS web server that has no Dell or MSI hardware is an artifact worth pulling apart.

The kernel write that follows is quieter. SPECTRE resolves `ntoskrnl.exe` through NtQuerySystemInformation, then uses a hardcoded offset table covering 13 Windows builds to reach PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine and unlink registered callbacks (T1562.001, Impair Defenses). The forensic signal is negative rather than positive. Process creation, thread creation, and image load telemetry from that host simply stops arriving while the machine remains online and reachable. A sensor that goes silent without an uninstall or service stop event is itself the indicator, and for your incident timeline it marks the moment endpoint visibility ended.

Host-based markers on Windows are specific enough to search for directly:

- Named pipes matching `\.\pipe\spectre_<tid>`, created for the ImpersonateNamedPipeClient path to SYSTEM.
- Registry hive exports produced by RegSaveKeyA from `HKLM\SAM\SAM`, `HKLM\SYSTEM`, and `HKLM\SECURITY` landing in `%TEMP%` (T1003.002).
- Chrome and Edge credential material copied to `%TEMP%` as `ld`, `ls`, `ed_ld`, and `ed_ls.tmp`, staged for offline DPAPI decryption.
- A spawned `cmdkey.exe /list` with piped stdout, which enumerates Credential Manager entries without touching LSASS and therefore never trips LSASS access rules.
- Injection into `svchost.exe` by default, plus an on-startup self-hollow into `RuntimeBroker.exe` (T1055.012).

C2 configuration lives in an NTFS Alternate Data Stream at `C:\Windows\System32\drivers\etc\hosts:cache` (T1564.004). Standard file listings show a normal hosts file, so streams have to be enumerated explicitly. Network-side, beacons are HTTP POSTs to `/api/v1/register` and `/api/v1/output` with a JSON body, identical across the Windows and Linux builds.

On Linux the module is dropped as `acpi_pad.ko` to impersonate the ACPI power management module, and persistence is a systemd unit named `hardware-monitor.service` described as "Hardware Performance Monitor" with `Before=sysinit.target`. Hooking uses ftrace with `FTRACE_OPS_FL_IPMODIFY` against six handlers including `hooked_getdents64`, `hooked_tcp4_seq_show`, and `hooked_kill`, so directory listings and TCP socket tables lie to you at the kernel boundary. Because ftrace is a legitimate debugging interface, integrity checks stay quiet, though the loaded module still sets the kernel taint state readable at `/proc/sys/kernel/tainted`.

Operator control of the rootkit is a `kill()` syscall aimed at PID 0x7A69 (31337) carrying real-time signals 62, 36, 37, and 35 for process hiding, module hiding, UID 0 escalation, and load acknowledgement. Signals to a nonexistent PID in that range are a reliable hunting artifact. Timestamps on dropped files may be unreliable, since the `timestomp` command rewrites mtime, atime, and ctime through `utimensat()` (T1070.006), which means file creation order in triage output can be fabricated.

## Immediate and Sustained Response Actions

Isolate suspected hosts at the network layer before you touch anything on the box, and do not reboot as a first step. The Linux persistence unit is configured with `Before=sysinit.target`, so a restart reloads the kernel module ahead of any security agent that would otherwise inspect it. Capture volatile memory and a disk image while the system is still running.

On Linux hosts, treat `lsmod` output as unreliable, since the module unlinks itself from the kernel module list. Compare the entries under `/sys/module/` against loaded module output, look for a `hardware-monitor.service` unit describing itself as "Hardware Performance Monitor," and check whether `acpi_pad.ko` is present on a server that has no reason to load ACPI processor power management. Also enumerate active ftrace hooks, because the rootkit registers at function entry points rather than patching the syscall table.

On Windows, blocking the hardcoded domain is only half the job. Enumerate alternate data streams on the hosts file (`C:\Windows\System32\drivers\etc\hosts:cache`) and remove any stream found there, otherwise the operator repoints C2 without redeploying the binary. Pair that with egress rules on HTTP POST traffic to `/api/v1/register` and `/api/v1/output`.

In the first 24 to 48 hours, assume every credential that touched the host is burned. The hive dump covers SAM, SYSTEM, and SECURITY, which means local account NT hashes, LSA secrets, cached domain credentials, and any service account password stored on the server. Add Windows Credential Manager entries enumerated through `cmdkey.exe /list` and saved Chrome and Edge logins copied out for offline DPAPI decryption. Rotate all of it, including the machine account, and force re-authentication for any service that reused those passwords elsewhere.

Your log review should target execution that never wrote a file. In-memory .NET assembly hosting leaves no dropped binary, so look at unusual CLR loads inside IIS worker processes and at child processes spawned under `w3wp.exe`. Registry writes performed through the implant's own value-setting command deserve a separate pass against `HKLM` and `HKCU` autorun paths. Also compare your IIS application configuration and bin directory against a known-good deployment, since handler registration can be altered through reflection at runtime.

For the longer term, the highest-value control is driver policy. Enable HVCI or memory integrity and apply the Microsoft vulnerable driver blocklist, then add a WDAC rule denying the specific vulnerable drivers by hash so the BYOVD step fails before a kernel handle is ever opened. In environments Capstone manages, SentinelOne flags the vulnerable driver write and transient service creation described earlier, which is the window that matters, because once the notify routine callbacks are unlinked the kernel stops reporting process, thread, and image load events for the rest of the session.

On the Linux side, enable kernel lockdown and module signature enforcement, strip `CAP_SYS_MODULE` from anything that does not legitimately load modules, and add auditd rules covering `init_module` and `finit_module`. eBPF-based telemetry gives you a collection path that does not depend on `getdents64`, which the rootkit hooks.

Finally, set the recovery rule in advance. A host confirmed to have loaded a kernel rootkit gets rebuilt from a known-good image and restored from backup, and cleanup in place is not an acceptable outcome for that class of compromise.

## Hardening Linux and Windows Infrastructure Against BYOVD Tactics

Turn on Microsoft's vulnerable driver blocklist first. On Windows 11 and Windows Server builds that support it, the blocklist is exposed under Windows Security as **Microsoft Vulnerable Driver Blocklist**, and it denies load attempts for the exact class of signed drivers SPECTRE relies on, including the MSI and Dell drivers named in Talos' analysis. Enabling it costs nothing and removes the actor's simplest path to arbitrary kernel read and write.

Pair that with **Hypervisor-Protected Code Integrity (HVCI)**, which Windows surfaces as Memory Integrity. HVCI validates driver code inside a virtualization-based security boundary, so a driver that is signed but exploitable still cannot be used to write into protected kernel structures. Check your current state with `Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard` before you assume it is on, because HVCI is off by default on many upgraded and virtualized server images.

Build the driver inventory next, since you cannot allowlist what you have not catalogued. Run `driverquery /v /fo csv` across your IIS fleet and diff the results against a known-good baseline for that hardware model. Web servers running on virtualized infrastructure have a short, predictable driver list, so any overclocking utility, hardware monitoring driver, or vendor firmware tool on that box is a candidate for removal.

For durable enforcement, deploy **App Control for Business (WDAC)** in a kernel-mode policy that permits only the drivers on your baseline. WDAC evaluates signer, file hash, and version, which means a policy can allow a vendor's current driver while rejecting the older vulnerable build of the same signed product. Start in audit mode, collect the code integrity events, then flip to enforcement once the policy stops generating noise. That single control breaks the technique for every BYOVD-capable implant, not just this one.

On Linux, the equivalent control is module load restriction. Three settings do most of the work:

- Enable **Secure Boot with kernel lockdown in integrity mode**, which refuses unsigned module loads and blocks direct access to kernel memory interfaces.
- Enforce module signature verification so that a module compiled and dropped by an operator will not insert. Confirm your kernel was built with signature enforcement rather than assuming the distribution default.
- Set `kernel.modules_disabled=1` late in boot on servers with a fixed hardware profile. Once set, no further modules load until reboot, which suits a production web server that never hot-plugs hardware.

Constrain the loading path itself with SELinux or AppArmor. On SELinux systems, only processes carrying the `module_load` permission should be able to call `finit_module`, and your web server domain has no business holding it. Blacklist unused modules explicitly in `/etc/modprobe.d/` with `install <module> /bin/false` so a load attempt fails rather than silently succeeding.

Feed `dmesg` and the kernel audit trail into central logging, and write an audit rule on the module syscalls: `auditctl -a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k module_load`. Ship those records off the host, since a kernel-resident implant can suppress what is readable locally. Keeping the evidence somewhere the compromised machine cannot reach is what makes the rest of this hardening verifiable.

Blocking BYOVD: staged driver controls

1

Turn on the Microsoft Vulnerable Driver Blocklist in Windows Security. It denies load attempts for the signed MSI and Dell drivers named in the Talos analysis.High



2

Memory Integrity validates driver code inside a virtualization-based security boundary. Confirm it rather than assume, since it is off by default on many upgraded and virtualized server images.Get-CimInstance -ClassName Win32\_DeviceGuard -Namespace root\\Microsoft\\Windows\\DeviceGuard



3

Collect loaded drivers across the IIS fleet and diff against a known-good baseline for that hardware model. Overclocking, hardware monitoring, and vendor firmware drivers are removal candidates.driverquery /v /fo csv



4

App Control for Business evaluates signer, hash, and version, so a current vendor driver can be allowed while the older vulnerable build is rejected. Start in audit mode, then move to enforcement.High



5

Enable Secure Boot with kernel lockdown in integrity mode and enforce module signature verification, so unsigned operator-supplied modules will not insert.Medium







## Key Takeaway: Prioritize Driver Inventory and Kernel Access Controls

The core problem BYOVD exposes is that your endpoint security depends on the kernel remaining honest, and the kernel trusts any driver carrying a valid signature. Once UAT-10147 gains that foothold, the arbitrary read and write primitive is not a bug in your EDR. It is the operating system doing exactly what it was designed to do for a signed module.

What makes SPECTRE notable is the preparation behind it. The implant ships a hardcoded offset table covering 13 Windows builds, meaning the operator worked out kernel addresses for each version in advance instead of resolving them on the victim. That is a tooling investment, and it tells you the actor expects to encounter a wide range of Windows server estates and wants the callback unlinking to work on the first attempt.

The Linux side reaches the same outcome through a different door. Specter hooks through `ftrace`, a supported kernel debugging interface, so the manipulation reads as normal instrumentation to integrity checks that look for syscall table tampering.

Your practical exposure comes down to a question most organizations cannot answer quickly: which drivers are permitted to load on your servers, and who decided that. Driver inventory is rarely tracked with the same discipline as application software, and that gap is what turns a signed MSI or Dell utility into kernel access for someone else.

Talos also assesses with medium confidence that AI-assisted development contributed to both the backdoor and the rootkit, which suggests the rate at which capable tooling appears will keep increasing. Treat kernel-space access as a controlled surface with a known inventory, and the rest of the chain loses its foundation.

<!-- AI:SCHEMA: Schema.org description of canonical page in JSON-LD format -->
<!-- AI:SCHEMA:BEGIN format=jsonld scope=page -->

```json
{
    "@context": "http:\/\/schema.org",
    "@graph": [
        {
            "@type": "Article",
            "author": {
                "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc"
            },
            "dateModified": "2026-08-20T12:36:05Z",
            "datePublished": "2026-08-20T12:36:05Z",
            "description": "Cisco Talos documents UAT-10147 deploying SPECTRE implant with Linux rootkit and BYOVD capabilities targeting IIS and Linux servers at scale.",
            "headline": "UAT-10147 Deploys SPECTRE Implant With Linux Rootkit and BYOVD Capabilities",
            "image": {
                "@id": "https:\/\/captechgroup.com\/#defaultLogo"
            },
            "inLanguage": "en-GB",
            "mainEntityOfPage": {
                "@type": "WebPage",
                "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/uat-10147-deploys-spectre-implant-with-linux-rootk-ffe9d5"
            },
            "publisher": {
                "@id": "https:\/\/captechgroup.com\/#defaultPublisher"
            },
            "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/uat-10147-deploys-spectre-implant-with-linux-rootk-ffe9d5"
        },
        {
            "@type": "Person",
            "name": "Brian",
            "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc"
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultLogo",
            "@type": "ImageObject",
            "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg",
            "width": 1300,
            "height": 300
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultPublisher",
            "@type": "Organization",
            "url": "https:\/\/captechgroup.com\/",
            "logo": {
                "@id": "https:\/\/captechgroup.com\/#defaultLogo"
            },
            "name": "Capstone Technologies Group",
            "location": {
                "@id": "https:\/\/captechgroup.com\/#defaultPlace"
            }
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultPlace",
            "@type": "Place",
            "address": {
                "@id": "https:\/\/captechgroup.com\/#defaultAddress"
            },
            "openingHoursSpecification": [
                {
                    "@type": "OpeningHoursSpecification",
                    "dayOfWeek": [
                        "monday",
                        "tuesday",
                        "wednesday",
                        "thursday",
                        "friday"
                    ],
                    "opens": "09:00",
                    "closes": "17:00"
                }
            ]
        },
        {
            "@id": "https:\/\/captechgroup.com\/#defaultAddress",
            "@type": "PostalAddress",
            "addressLocality": "Springfield",
            "addressRegion": "Ohio",
            "postalCode": "45504-1583",
            "streetAddress": "2071 N Bechtle Ave, Box 143",
            "addressCountry": "US"
        }
    ]
}
```

<!-- AI:SCHEMA:END -->

