how undetected are "undetected" spoofers?

There is a funny pattern with cheat and spoofer developers. The louder the word "undetected" gets, the less it tends to mean. In this case the chat had the usual confidence, the usual "ud ud" energy, and then the driver itself showed up. After a little tracing, the claim aged about as well as milk on a hot dashboard.

The interesting part is not that the driver spoofs identifiers. That is expected. The interesting part is how it does it. This thing is not some invisible kernel ghost. It creates filter devices, attaches them to public Windows device stacks, rewrites a pile of registry identifiers, deletes cached hardware data when it can, and drops a completion marker under a Microsoft key. That is not stealth. That is a checklist.

The Short Version

The driver resolves a lot of kernel exports at runtime, queries loaded kernel modules through SystemModuleInformation, creates unnamed device objects, and repeatedly calls IoAttachDeviceToDeviceStackSafe to insert itself into existing stacks.

That is the core problem. This is not a clean one shot spoof. It is a driver trying to sit in the middle of normal Windows I/O paths. Once it does that, it becomes part of the evidence.

The Loud Part: IoAttachDeviceToDeviceStackSafe

The main attachment primitive here is IoAttachDeviceToDeviceStackSafe. Legitimate drivers can use this API. That does not make this usage clean. The context matters: an obfuscated spoofer driver is creating device objects and inserting them above networking and NDMP device objects.

The kernel side of the API is not mysterious. It gets the current top of the target device stack, checks whether the stack can accept another device, copies stack related metadata like alignment and sector size, increments the source stack size, and links the new object into the attached device chain. In other words, it creates a visible relationship inside the kernel object model.

That relationship is exactly what defenders can inspect. Walk the attached device chain for \Device\Nsi, \Device\NetIo, \Device\Tcp, or \Device\NDMP0, then ask a few boring questions:

• Is there an unexpected device object attached above the normal stack?
• Which driver object owns it?
• Does the driver name, image path, timestamp, section layout, and certificate chain match a normal Windows or vendor driver?
• Are the major function pointers backed by a known image?
• Did the stack size change after the suspicious driver loaded?

This is why calling it "undetected" is funny. The attachment is not hidden inside some private allocator. It is literally wired into a device stack that Windows and security software already know how to walk. You can virtualize functions all day, but if the behavior creates a new attached device object, the behavior is still there.

What It Tries To Spoof

The registry pass is broad. It does not focus on one clean identifier. It touches the usual Windows identity garden and hopes enough values change that whatever banned the machine loses its match.

It also tries to remove cached hardware blobs. The trace shows attempts to delete values such as SMBiosData and AcpiData, along with attempts to delete or clean other registry branches. Several of those operations fail with access or invalid object style statuses. That is useful too. Failed cleanup is still telemetry.

The Registry "Validation" Trick

Near the end, the driver writes HKLM\SOFTWARE\Microsoft\Cryptography\CryptoDone. That looks like its completion flag. In plain English, it is marking that the spoofing pass ran, or at least that it reached the point where it wanted to say it ran.

That is not a trustworthy validation system. It does not prove the driver loaded cleanly, it does not prove the spoof worked, and it does not prove anything is undetected. It is just registry state. Worse, it creates a stable artifact under a Microsoft looking path. A defender can watch for that value, compare it against normal Windows baselines, and correlate it with the rest of the registry churn.

The same applies to the later writes under Cryptography\Providers\MachineGuid and SYSTEM\CurrentControlSet\Control\Power\DeviceId. The driver is trying to make state look new, but every write is still an event, and the group of writes is stranger than any single value.

The ETW Problem

This is where the method gets worse for them. A lot of people talk about kernel spoofers like the only question is "can I hide the driver bytes?" That is the wrong question. The driver is doing work inside Windows, and Windows is extremely chatty about system work. Anti cheats do not have to rely on one static signature when the operating system is already producing telemetry around the behavior.

Event Tracing for Windows, or ETW, is built into the OS. It records events from kernel and user mode providers. Normal software uses it for diagnostics. EDRs and anti cheats use it for correlation. If a driver loads, opens registry keys, writes values, deletes values, interacts with device stacks, or causes weird network path behavior, those actions can become part of an ETW-backed trail.

The ugly part for this spoofer is that its behavior is clustered. It does not make one quiet change and leave. It creates device objects, attaches to sensitive stacks, resolves exports, touches a large number of hardware and machine identity keys, tries to delete cached firmware data, then writes a done marker. That sequence is much more valuable than a single event.

There is also a direct Windows internals angle here. The routine behind IoAttachDeviceToDeviceStackSafe has ETW write paths for certain blocked legacy filter situations. That does not mean every network stack attachment creates the same neat public event. It means the I/O manager already treats suspicious or policy-blocked attachment behavior as something worth reporting. A spoofer building its core communication and interception model around device stack attachment is choosing a surface Windows already instruments.

From an anti cheat point of view, this is a gift. The detector can start an ETW session, watch high value providers, and then join those events with its own kernel view. Did an unknown driver load? Did it immediately write MachineGuid, HwProfileGuid, ComputerHardwareId, and Dhcpv6DUID? Did the device stack for TCP or NSI change in the same window? Did it drop CryptoDone afterward? That is not one weak signature. That is a behavior graph.

This is why the method is horrible in itself. It creates high confidence evidence at three layers at once: kernel object state, registry mutation, and ETW-backed timing. You can pack the binary. You can virtualize the function bodies. You can rename the file. None of that makes the operating system forget that a driver touched exactly the things spoofers touch.

Why This Is Detectable

Detection here does not need to be clever. It can be boring and still win.

• Device stack integrity: enumerate the attached device chain for the target stacks and flag unknown filter devices.
• Driver object provenance: inspect the owning driver object, image base, dispatch table, section names, signer, timestamp, and memory protections.
• Registry burst behavior: look for many hardware and telemetry identifiers being rewritten by kernel code in one session.
• Cleanup artifacts: record failed deletes of SMBIOS, ACPI, Bluetooth, network, and class registry paths.
• Completion marker: watch for CryptoDone under the Cryptography key or any clone of that marker in nearby paths.
• Runtime export resolving: correlate calls to MmGetSystemRoutineAddress, ZwSetValueKey, ZwDeleteValueKey, and IoAttachDeviceToDeviceStackSafe from the same suspicious image.

The chat tried to frame the old build as not fully protected, which is a convenient escape hatch. But protecting every function does not erase the behavior. It may make static reversal slower. It does not make an attached device vanish from the object manager, and it does not make a burst of registry writes become normal.

Where The Ego Falls Apart

A lot of cheat security talk confuses "not detected by my quick test" with "undetected." Those are not the same claim. A spoofer that attaches to network stacks, rewrites known identity keys, deletes cached hardware blobs, and leaves a registry done flag is not invisible. It is just waiting for someone to care enough to look at the right layer.

The funniest part is that the driver does not need one perfect signature to lose. It loses by correlation. One unknown attached filter might be explainable. One changed registry GUID might be explainable. One runtime export resolver might be explainable. All of them together, inside a VMP protected spoofer that was literally dropped to disk, are not a stealth story. They are a report.

So, how undetected are "undetected" spoofers? Usually about as undetected as the detector budget allows. This one left enough surface that the honest answer is simple: not very.