VK AI Sensor

Voight-Kampff: a host-based EDR for Windows that catches compromise on the machine, including the AI-driven kind.

vk-ai-sensor is a host-based EDR for Windows. It runs as a service on the machine and watches process, file, network, account, and PowerShell activity for the behavior that compromise produces, with more than eighty detection rules mapped to MITRE ATT&CK. All of it runs locally, with no network access and no API keys required for the core to work.

What pushed it into being was a specific worry: attackers using AI to move faster and at scale, autonomous agents that probe and pivot on their own, and AI-generated malware that matches nothing on a signature list. You do not catch those with signatures. You catch them the way you catch a careful human intruder, by watching what actually happens on the host. An optional AI layer can explain and rank what the sensor finds, but the core never depends on it.

The name is a nod to the Voight-Kampff machine from Blade Runner, the device built to tell a human from a machine pretending to be one. That is the job here too.

What it watches for

The sensor ships with more than eighty detection rules, mapped to MITRE ATT&CK. Some of the ground it covers:

• Process attacks. Code injection, process hollowing and image tampering, DLL side-loading, living-off-the-land binaries, and processes pretending to be something they are not.
• Credential theft. Reading LSASS memory by known tool, by dump file, and by direct handle access, plus browser credential stores, Kerberoasting, AS-REP roasting, DCSync, Golden and Silver Ticket forgery, and copying the NTDS.dit domain database off a domain controller, whether through a file copy or a raw read of the disk.
• Pass-the-hash. Both ends of it: a process started with someone else's network identity, graded by whether something wrote to LSASS first, and an NTLM sign-in that arrives without a session key from a device that has never signed in that way before.
• Persistence and privilege. Scheduled tasks, run keys, services, WMI subscriptions, startup folders, UAC-bypass tricks, and accounts added to privileged groups, including Domain Admins.
• Defense evasion. Clearing event logs, turning off auditing, removing security controls, loading known-vulnerable drivers, and anti-forensics like prefetch wiping and timestamp tampering.
• Ransomware and wipers. Mass file encryption and mass deletion, shadow-copy deletion, and canary files. Tuned to fire on real user data, not an installer or a browser clearing its own cache.
• Data theft. Archiving user files ahead of exfiltration, bulk copies to a USB stick after reading your documents, and large uploads to destinations the machine has never used.
• Command and control. Beaconing patterns, suspicious DNS, named pipes left by C2 frameworks, connections to known-bad indicators, and traffic to countries you would not expect.
• Lateral movement and web attacks. Remote execution, a scheduled task or service that is created, run, and deleted within minutes (the Impacket pattern), DNS zone transfers, web shell drops, and IIS configuration tampering.

Digging into what fired

An alert is a starting point, not the end of the story. The sensor pulls extra context so you are not left staring at a process name wondering what it actually did.

• Memory forensics. When a high-severity alert fires, the sensor scans the offending process's own memory, classifies each region, and disassembles anything that looks like injected shellcode. The web console shows you the disassembly, and the optional AI layer can walk through what the code is doing before you have to.
• IP reputation. Outbound destinations and the addresses tied to an alert are checked against public reputation sources (DNSBLs, Team Cymru, Shodan's InternetDB, AbuseIPDB), and each alert captures a point-in-time reputation snapshot so a later cleanup does not erase what the address looked like when it mattered.
• A bundled decompiler. A suspicious binary can be pulled apart in place: native disassembly, .NET decompilation, and a pass for suspicious API combinations, embedded strings, and packer tells, so triage does not mean shipping the sample off to a third-party sandbox.
• An AI analyst. A few minutes after a medium or higher alert fires, the optional AI layer investigates it: it pulls the process's activity, the file and its signature, related events, logons, and other alerts, then writes a verdict where every claim cites the evidence it rests on. The verdict is context. It never changes the alert or its severity.

Before anything fires

• Vulnerable software. The sensor inventories installed software and checks it against CISA's Known Exploited Vulnerabilities list and the NVD, ranked by ransomware use and exploit likelihood, so the programs worth patching first are named before anyone uses them.
• A hardening review. It checks how the machine is configured (LSA protection, Credential Guard, SMB signing, SMBv1, and similar settings) and raises an alert when a check that used to pass starts failing.

Where the signal comes from

Detection does not lean on a single source. The sensor reads several, so an attacker cannot dodge it by avoiding one:

• ETW. A kernel Event Tracing session for process, file, network, and thread activity.
• The Windows Security log. Logons, account and group changes, Kerberos ticket requests, and audit-log clears. This is ground truth Windows records no matter which tool made the change.
• PowerShell script-block logging. The actual deobfuscated script content, not just the command line.
• Sysmon, if you run it. When Sysmon is installed the sensor picks it up on its own and uses it for signals ETW cannot see, such as a process opening a handle to read LSASS memory, raw disk reads, and named pipes. If it runs the sensor's Sysmon config, every install and update keeps that config current; a Sysmon config of your own is never touched, and the sensor reports any rule it leaves without input. If Sysmon is not there, nothing breaks, and the web console shows you how to turn it on.

Design principles

• Local-first, always on. Core detection runs with zero network access and zero API keys. If the AI layer is offline, mis-keyed, or rate-limited, detection is unaffected.
• AI is augmentation, not the engine. The optional AI layer analyzes alerts after the fact. It explains them and ranks what matters. It never suppresses or downgrades an alert, and it is never in the critical path.
• False positives are fixed with evidence, not lists. When a rule misfires, the fix goes into the rule as a better question (was the file signed, did the program read your documents first, has this device signed in this way before), not as an allow-list of trusted names an attacker could borrow.
• Bring your own provider. AI access sits behind an abstraction, so it can point at a cloud model or a fully local model. The AI help can itself stay 100% on-box.
• Explicit opt-in for data leaving the machine. Every feature that phones home is disabled by default and clearly documented.
• Secrets stored properly. API keys are encrypted at rest using Windows DPAPI. Plaintext keys never touch a config file.

Running a fleet

One box or many, the pieces are the same.

• Self-hosted updates. New builds publish to your own update feed, signed with an offline Ed25519 key so a compromised feed cannot push a tampered or downgraded build, and each sensor verifies and installs them. No third-party update service in the path.
• Per-host enrollment. Each machine redeems a single-use code for its own revocable token, bound to its hostname. There is no shared fleet secret to leak, and a self-signed hub works through certificate pinning.
• Ask the fleet in plain language. The hub exposes an MCP server (Model Context Protocol), so an AI assistant like Claude can query every host for you: what fired and where, what a machine is running right now, whether anything touched a known indicator, which Windows events back it up. You ask a question, it pulls the answer from the sensors live.
• Reports that write themselves. The same MCP tools drive scheduled, headless runs: a short daily email of what changed, and a full review of the fleet every Monday.
• Optional automatic response. Off by default. A rule can be wired to suspend or kill the offending process or isolate the machine from the network, and a conviction gate holds the response until independent signals agree, so one noisy rule cannot take a machine offline.
• A watchdog on the watcher. Every sensor reports its own health (collectors running, events dropped, database size, Sysmon inputs), so a host that is online but broken shows up instead of looking quiet. A separate service notices if the sensor stays stopped too long and alerts you, then tells you again when it comes back.

At a glance

• Runs as an elevated Windows Service. Detection comes from ETW, the Windows event logs, and Sysmon when it is present.
• Ships a separate, unelevated Blazor web console for reviewing what the sensor has seen: activity, alerts, network connections, the rules in effect, vulnerable software, hardening findings, and Sysmon setup.
• A system tray app shows the sensor's state at a glance and is where API keys and other secrets are entered and stored.
• A workstation install profile for laptops and gaming PCs: a lighter footprint, and a game mode that defers background work while a full-screen game is running.
• Built on .NET 10, targeting Windows 10 / Server 2016 and later.
• Dual-licensed: AGPL-3.0, with a commercial license available.

Back to home