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 close to a hundred 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 close to a hundred 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, processes pretending to be something they are not, and a server program (a web server, a database, a mail server) that suddenly starts a shell.
• 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, an account's password hash being read on a domain controller, 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.
• Remote access and tunnels. A remote logon by an account from a network it has never signed in from on that host, a remote-screen session served to the internet, a remote-administration port reached through a held outside connection (ngrok or cloudflared exposing RDP, a reverse SSH tunnel, a relay agent), port forwarding added to Windows itself, and remote-management tools showing up where they were not 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.
• Published indicators. The hub reads CISA's advisories as they come out, keeps the addresses, domains, URLs and file hashes they publish, and every sensor matches them against its own connections, lookups and programs, including the history it already recorded, so an advisory published today can name something that happened last week. An indicator can only add an alert. Nothing in a feed can silence a rule.
• 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.

• Incidents. An intrusion is not one alert. A dropped file runs, spawns PowerShell, reaches a new address, and the account it runs as signs in somewhere else. The sensor ties alerts into one story at birth, from the evidence they already carry (process lineage, the account, the logon source, the destination, the file), never from a model's opinion, so you see the timeline instead of five rows.
• 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. When the alert belongs to an incident, the analyst judges the whole story at once and says which member drives its verdict, so one intrusion gets one answer instead of a different opinion per alert. The verdict is context. It never changes the alert or its severity.

Doing something about it

Finding it is half the job. The other half is working the case without handing a machine's fate to an algorithm.

• Every alert has a place in its life. Open, Acknowledged, Contained, Resolved, with a resolution and a note when it ends. Severity sets the clock: Critical means act within fifteen minutes, High within the hour, Medium today, and an alert past its window reads as overdue. Every change is recorded with who made it and which door it came through.
• A response card for every rule. Each rule ships with a hand-written card: how to contain it, how to verify it was real, how to remediate, and what all-clear looks like, with the alert's own facts filled into the blanks.
• A Respond page. One console page with the queue of everything still waiting on a person on the left and the case on the right: the card, the analyst's verdict, the process, the host, the history, the evidence, and every action that applies in one row.
• Guarded actions with a human tap. Isolate a host from the network, suspend or end a process, block a destination, disable an account. A person asks, the hub relays, and the sensor decides whether it is safe before it acts: a domain controller and the hub's own host refuse to be isolated by default, isolation always keeps the sensor's own link and your management addresses open, the firewall state is captured first and restored exactly on release, and a process is checked to still be the same process before it is touched. Nothing here is automatic.

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 Critical tier catches a newly published critical CVE in something you run before it reaches the exploited list.
• The software that never registers. Runtimes, servers, libraries and web apps that no installer lists: PHP, Java, .NET, Node, Python, Apache, nginx, Tomcat, Log4j, WordPress, Jenkins and more, found where they actually live (what the machine has run, the folders the web servers serve, the folders running Java apps load from), with a warning when one is past its end of life.
• 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.
• Reading the advisories so you do not have to. Every day the hub reads the new CISA advisories and checks the behavior they describe against the rules the sensor has. A gap becomes a work item with the advisory that showed it, which is where several of the rules above came from.

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, it never moves an alert's status, 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. No shipped rule trusts a program by its name.
• Learn the host, not the installation. What a machine normally does (which programs resolve names themselves, which networks an account signs in from, which programs serve the network) is learned per host and survives restarts, so the sensor fits any machine without a tuning file written for it.
• 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, which incidents are open, 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. The same tools take the guarded actions, with the same human in the loop.
• Reports that write themselves. The same MCP tools drive scheduled, headless runs: a short daily email of what changed, led by the open incidents, 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. Anything broader than that is a person's tap.
• 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.

On your phone

An iPhone app for the hub, for the hours you are not at a console.

• Pushed, not polled. A High or Critical alert on any host reaches the phone within seconds of firing, and so does a sensor going quiet. The app icon carries the count of alerts you have not looked at.
• The case in your hand. Alerts, incidents, hosts and fleet stats, each alert with its facts, its response card and the analyst's verdict. You can ask the analyst a question, change an alert's status, acknowledge a whole incident, and take the guarded actions from the alert, with the same sensor-side checks as everywhere else.
• Paired, not logged in. A phone is paired by scanning a one-time code that lives fifteen minutes, and gets its own token the hub stores only as a hash. Revoke it from the hub and the phone is out. The hub can push to Android phones too; the Android app is next.

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 and incidents, a Respond page for working the queue, 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.
• An iPhone app for the fleet, with push notifications.
• 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