LurkerLock — Source library
Public documentation snapshot: 2026-10-17
Host-based intrusion detection: watch, trap and block attackers on Windows and Linux
LurkerLock is host security for Windows PCs and Linux servers. A sensor on each machine watches sign-ins, accounts, services and connections, sets decoys, and reports to a LurkerLock Server you host yourself.
Host-based intrusion detection: watch, trap and block attackers on Windows and Linux
Host security for Windows PCs and Linux servers. It watches each machine, sets decoys, blocks attackers when you allow it, and keeps the record on a server you run.
Host-based intrusion detection: watch, trap and block attackers on Windows and Linux
Built for: Small businesses with a few Windows PCs and Linux servers and no security team to watch them · IT providers who look after many clients' machines and need one place to see what happened on each · Organizations whose security data has to stay in-house, on machines they run · Anyone who wants blocking that cannot lock them out of their own network
LurkerLock exists because of this.
Most break-ins are quiet. Someone guesses a password or uses one that leaked, signs in, creates an account or a scheduled task, adds it to the administrators, and waits. On a small network nobody reads the sign-in records of every PC and server, so the first sign of it can come weeks later, or not at all.
LurkerLock exists because of this.
The tools that do watch usually want something in return. Many send everything they see to someone else's cloud. Others block on their own, and the first address they block can be yours: the office, the VPN, the machine you were using to fix the problem.
LurkerLock exists because of this.
A business with a handful of machines needs to know when an account appears, a service is installed, Microsoft Defender is switched off or a machine talks to a known-bad address, and it needs a record it can read and keep. It needs to be able to push back without betting its own access on it, and without handing its security data to a vendor.
LurkerLock exists because of this.
Self-hosted from end to end. Findings, records and alerts stay on machines you run; there is no telemetry, no license server and no update check, and licenses are verified offline.
LurkerLock exists because of this.
Decoys as well as detection: decoy account names, bait files with made-up passwords and decoy ports, which nothing legitimate touches.
LurkerLock exists because of this.
Blocking that is built not to lock you out: off by default, a dry run first, and fixed gates that never block your own network, your management addresses or the machine itself.
LurkerLock exists because of this.
One STOP switch removes every block, including any it lost track of, and every block expires on its own.
LurkerLock exists because of this.
On Windows the part that reads attacker-controlled input runs with restricted rights; a separate minimal helper makes the firewall changes and checks every request against your settings first.
LurkerLock exists because of this.
Windows PCs and Linux servers in one console, with named users, two roles and two-factor sign-in.
LurkerLock exists because of this.
A single machine can run the sensor with no server at all and keep its findings to itself.
How LurkerLock works, start to finish.
LurkerLock has two parts. The LurkerLock Sensor runs on each Windows PC or Linux server and watches that machine. The LurkerLock Server is a server you run yourself, on Windows or Linux, with a web console: every machine on one page, findings search and export, named users with two-factor sign-in, alerts, and one address list that reaches every sensor. A single machine can also run the sensor with no server at all and keep its findings to itself.
How LurkerLock works, start to finish.
On Windows the sensor watches sign-ins and password guessing, new accounts and changes to administrator groups, new services and scheduled tasks, a cleared audit log, Microsoft Defender detections and Defender being switched off, programs reading the sign-in process's memory, Office documents starting command shells, unsigned drivers, and restarts that Windows Update has planned. When Sysmon is installed it adds process, network and driver detail.
How LurkerLock works, start to finish.
On Linux it watches SSH password guessing and sign-ins from addresses it has never seen, sudo and su failures, new users and administrator-group changes, new service units, timers, cron and at jobs, changes to SSH authorized keys, sudoers and the library preload file, kernel modules loaded after start-up, new listening ports, and updates waiting for a restart. The first run records how the machine looks, so nothing that was already there is reported as new.
How LurkerLock works, start to finish.
On both, the sensor checks the machine's outbound connections against public threat lists and your own list. Spamhaus DROP, Emerging Threats compromised hosts and CINS Army can lead to a block; the Tor exit relays are only recorded and never blocked. A standalone sensor downloads the lists once a day. A sensor that reports to your LurkerLock Server takes them from it, so a site with many machines asks each publisher once a day. A download sends nothing about your machines, and you can turn the lists off.
How LurkerLock works, start to finish.
Decoys catch what watching can miss. Decoy account names are names that password-guessing tools try first, such as admin or test; a sign-in tried with one is reported at once with the address it came from, and a name that is a real account is never a decoy. Bait files are three believable credential files with made-up passwords; opening, changing or deleting one is reported with the program and the account that did it, and the file is put back. Decoy ports are network ports nothing real listens on, so any connection to one is reported with its address. Nothing legitimate touches a decoy, so a touch is worth reading.
How LurkerLock works, start to finish.
Blocking is off until you turn it on, and then it starts as a dry run that only records what it would block. When you let it act, it blocks single addresses that attacked the machine or that it should never talk to: a password-guessing burst, a decoy sign-in or decoy port, a connection to a block-list address, or an address on your server's list. Every request passes the same gates in order. It never blocks the machine's own addresses, private ranges unless you allow them, anything on your allowlist or in your management addresses, or an address an administrator is signed in from. Blocks expire on their own, and a STOP file removes every block at the next cycle.
How LurkerLock works, start to finish.
On Windows the sensor runs under a restricted account; a separate minimal helper service running as LocalSystem makes the firewall changes and checks every request against your settings before it acts.
How LurkerLock works, start to finish.
Every finding, block and decision is recorded with what happened, when, and on which machine, on the machine and on your server. Alerts go by email, text message or webhook, with quiet hours and daily caps, and each one carries a plain-English summary rather than an event number. A doctor command checks the whole setup, one line per check with how to fix it, and a support bundle collects what support needs into one private file with keys and secrets left out. Nothing is sent to us: there is no telemetry, no license server and no update check, and licenses are verified offline.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
Watches every Windows PC.
On each PC the sensor reports new services and scheduled tasks, new accounts and administrators, a cleared audit log, Microsoft Defender detections and Defender being switched off, password guessing, programs reading the sign-in process's memory, Office documents starting command shells, connections to known-bad addresses, unsigned drivers, and restarts Windows Update has planned. With Sysmon installed it adds process, network and driver detail. Findings appear in a tray icon, in Event Viewer and on your server.
Watches every Linux server.
On each server it reports SSH password guessing and sign-ins from addresses it has never seen, sudo and su failures, new users and administrator-group changes, new service units, timers, cron and at jobs, changes to SSH authorized keys, sudoers and the library preload file, kernel modules loaded after start-up, new listening ports, connections to known-bad addresses, and updates waiting for a restart. The first run records how the machine looks, so nothing already there is reported as new.
Public threat lists, checked against their terms.
Outbound connections are matched against Spamhaus DROP, Emerging Threats compromised hosts and CINS Army, where a match is a high finding that can lead to a block, and against the Tor exit relays, where a match is a low finding that is never blocked. Your own list of addresses works the same way. A standalone sensor downloads the lists once a day; enrolled sensors take them from your server. A download sends nothing about your machines, and the lists can be turned off.
Decoy account names.
Password-guessing tools try names such as admin, test and backup first. LurkerLock treats those names as traps: a sign-in or SSH login tried with one is reported at once, with the address it came from, instead of waiting for a burst of failures. A name that is a real account on the machine or its domain is never used as a decoy, and that is checked again before each report. You can add your own names.
Bait files with made-up passwords.
Three believable credential files with made-up contents sit in a backup-looking folder. Opening, changing or deleting one is reported with the program and the account that did it, and a changed or deleted file is put back. On Windows this uses file auditing on that folder only; on Linux the program that opens a bait file is always let through. Backup agents and other programs that read every file can be listed so they are ignored.
Decoy ports.
You can list network ports that nothing real listens on. A connection to one is accepted, closed at once and reported with the address it came from. There are none by default. With blocking on, the address behind a decoy port or a decoy sign-in can be blocked like any other attacker, behind the same safety gates.
Blocking starts as a dry run.
Blocking is off by default. When you turn it on, it first runs as a dry run that records each address it would block and changes nothing, so you can check for a week that none of them is yours, a partner's or a monitoring service's. Going live is a separate setting, and dry-run entries are discarded rather than applied. Blocking is a licensed feature.
Built not to lock you out.
Every block request passes the same gates in a fixed order. LurkerLock never blocks the machine's own addresses, private ranges unless you allow them, anything on your allowlist or in your management addresses, or an address an administrator is signed in from right now; if it cannot read who is signed in, it blocks nothing new. It blocks single addresses only, never networks, domains, processes, accounts or ports, and it stops at the maximum number of blocks you set.
One STOP switch.
Creating a STOP file stops new blocks at once and, at the next cycle, removes every block LurkerLock made and anything else it ever added to the firewall, including entries it lost track of. Turning blocking off, or back to a dry run, also removes its blocks. Every block expires on its own: after an hour by default, and never later than the maximum you set, which defaults to seven days.
Restricted rights on Windows.
The sensor reads what attackers control all day: event logs, decoy ports and downloads. So on Windows it runs under its own restricted account, and a separate minimal helper service running as LocalSystem makes the firewall changes on its request. The helper accepts one exact address per request, builds every rule itself, and refuses on its own anything your settings do not allow: blocking off, a dry run, the STOP file, or a protected, private, management or own address.
Your own server and web console.
The LurkerLock Server runs on a Windows or Linux machine you choose. Its console shows every machine on one page and a page per host, with findings search, filters and export to CSV or JSON lines. Users are named, each with their own password, two-factor sign-in and sessions, in two roles: administrator and read-only viewer. One address list, with a reason and an expiry per entry, reaches every sensor, which reports or blocks it behind the usual gates.
Rolls out to many machines.
One enrollment code covers up to 10,000 machines for up to 30 days and can be revoked. Windows PCs install silently with the code through Intune, Configuration Manager or a Group Policy startup script; Linux servers read a one-time enrollment file when the package installs, for example from Ansible. Each machine enrolls under its own name and keeps retrying if the server is briefly unreachable. Sensors only connect out, so they work behind NAT, carrier-grade NAT and host firewalls.
Alerts you can live with.
Findings can go by email through your own mail server, by text message through your own Twilio account, or to a webhook for Slack, Microsoft Teams or any system that takes JSON. Each channel has its own minimum severity, quiet hours that still let critical alerts through, and a daily cap. Alerts due together go as one message with a plain-English summary, the same finding is never sent twice on a channel, and unsent alerts survive a restart.
A doctor and support bundles.
One doctor command checks a sensor or the server and prints one line per check, pass, warn, fail or skip, with how to fix it: the service, the configuration, the link to your server, the certificate, the license, the firewall helper, the decoys and more. A support bundle is one private zip for support, with keys, passwords, two-factor secrets, enrollment codes and license signatures left out and secrets in settings redacted. Findings go in only if you ask.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
Free public threat lists, each checked against its publisher's terms; the Tor exit list is recorded only and never blocked.
Numbers we can stand behind.
A doctor that says how to fix what it finds, and support bundles with keys and secrets left out.
Surfaces and status.
The product took the LurkerLock name on 2026-10-16 and opened for early access. The 0.4 release line, from October 2026, is the first built for customers: Windows and Linux sensors, a self-hosted server with a multi-user console, enrollment for many machines, a doctor and support bundles. Access is by request through the contact form; the product site offers no download, and prices are not published. Windows 11 and Ubuntu 24.04 are the tested systems.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with LurkerLock.
Network Sentinel
Network Sentinel keeps a record of every device on your home or office network and tells you when a new one joins; LurkerLock watches what happens on each PC and server. One covers the network, the other the machines on it.
ASL Scan
ASL Scan assesses a server or web app inside a scope your client signs; LurkerLock watches the machines every day afterwards and records who comes looking, with decoys that show when someone does.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-10-16 The product is now called LurkerLock. The LurkerLock Sensor and LurkerLock Server installers upgrade an installed sensor or server from the earlier release in place and keep every setting, key and license, and alert emails and texts now start with LurkerLock. The LurkerLock release also carries decoys (decoy account names, bait files and decoy ports), a separate firewall helper for blocking on Windows, and two more public threat lists, CINS Army and the Tor exit relays. They join the 0.4.0 release from earlier in October, the first built for customers, which added enrollment codes for many machines, sensors that sync through NAT and firewalls, and a console with named users and two-factor sign-in.
Recent progress.
2026-10-15 Each public threat list was checked against its publisher's terms (Spamhaus DROP, Emerging Threats, CINS Army and the Tor exit relays), and the sources, terms and credits are part of the product documentation.
Recent progress.
Pricing for LurkerLock is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
Will it lock me out of my own network?
It is built not to. Blocking is off until you turn it on, and then it runs as a dry run that only records what it would block. When you go live, every request passes fixed gates: it never blocks the machine's own addresses, private ranges unless you allow them, your allowlist, your management addresses, or an address an administrator is signed in from. Blocks expire on their own, and creating the STOP file removes every block at the next cycle. One caveat: on Windows the signed-in check does not see Remote Desktop sessions yet, so list the addresses you connect from as management addresses before you go live.
Does any of our data leave our network?
Not to us. There is no telemetry, no license server and no update check, and licenses are verified offline. Findings stay on each machine and on your own LurkerLock Server. The other outside connections are the ones you set up, your mail server, your text-message provider and your webhook targets for alerts, plus the daily downloads of the public threat lists. Those downloads are on by default, send nothing about your machines, and can be turned off.
Do we have to run a server?
No. A single PC or server can run the sensor on its own and keep its findings to itself, with its own alerts. The LurkerLock Server adds what many machines need: every machine on one page, findings search and export, named users with two-factor sign-in, one address list that reaches every sensor, and one place that downloads the threat lists for all of them.
What are the decoys, and can they cause trouble?
There are three kinds. Decoy account names are names such as admin or test that password-guessing tools try first; a name that is a real account on the machine or its domain is never a decoy. Bait files are three credential files with made-up contents; a file that is changed or deleted is put back, and uninstalling removes them. Decoy ports are ports nothing real listens on, and there are none until you list some. Programs that read every file, such as a backup agent, can be listed so they do not set off the bait files.
How do we put it on many machines?
Make one enrollment code on the server for up to 10,000 machines, valid for up to 30 days. Install the Windows sensor silently with the code through Intune, Configuration Manager or a Group Policy startup script. On Linux, place the one-time enrollment file before installing the package, for example from Ansible; the package reads it and deletes it. Each machine enrolls under its own name and retries if the server is briefly unreachable. When the rollout is done, revoke the code; machines it enrolled stay enrolled.
What does it cost?
Prices are not published. LurkerLock is in early access, and what a license includes depends on its edition: blocking and text and webhook alerts are licensed features, while detection, findings and email alerts never need a license. Ask for early access and tell us how many machines you run and what they run, and we will answer with a quote.
Is it ready, or still being built?
It works on Windows and Linux today, and it is in early access. The 0.4 release line is the first built for customers, with enrollment for many machines, a multi-user console, a doctor and support bundles. Windows 11 and Ubuntu 24.04 are tested; the other supported systems are expected to work and are not yet tested. Single sign-on is not available yet, the console has two roles, one server supports up to 1,024 sensors, and the installers are not yet code-signed.
What happens if we stop using it?
Uninstalling a sensor removes its services, every firewall block it made and the bait files, and on Windows its decoy-port firewall rule. Its configuration and records are kept unless you delete them, so the evidence stays yours. An expired license stops new enrollments on the server and never stops monitoring.
Can we upgrade an installation of the earlier release?
Yes. The LurkerLock Sensor and LurkerLock Server installers upgrade an installed sensor or server from the earlier release in place and keep every setting, key and license. Some technical names, such as the Windows service names, still use the product's former name in this release, and a later release renames them.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-10-16:
What should I know before I rely on it?
It is in early access: access is by request, there is no public download, and the 0.4 release line is the first built for customers, so you would be an early customer.
What should I know before I rely on it?
Tested on Windows 11 (64-bit) and Ubuntu 24.04. Windows 10, Windows Server, Debian, the Red Hat family, SUSE and Amazon Linux 2023 are expected to work and are not yet tested; Amazon Linux 2, CentOS 7 and Alpine are not supported.
What should I know before I rely on it?
The installers are not yet code-signed.
What should I know before I rely on it?
Single sign-on (SAML or OpenID Connect) is not available yet, and the console has two roles only: administrator and viewer.
What should I know before I rely on it?
One LurkerLock Server supports at most 1,024 sensors.
What should I know before I rely on it?
Blocking acts on single addresses only: no networks, ranges, domain names, processes, accounts or ports. Everything else LurkerLock finds is reported, not blocked.
What should I know before I rely on it?
On Windows, the check that refuses to block an address an administrator is signed in from does not see Remote Desktop sessions yet, so list the addresses you connect from as management addresses.
What should I know before I rely on it?
On Linux, only SSH attempts that the system journal recorded from the real SSH service can trigger a block; attempts seen only in a plain log file are reported, never blocked.
What should I know before I rely on it?
Text and webhook alerts and blocking are licensed features. Detection, findings and email alerts never need a license.
What should I know before I rely on it?
Findings can contain account names, program paths, network addresses and, from Sysmon on Windows, command lines, which can identify people. Where your rules or employment law require it, tell users their computers are monitored and limit who can read findings.
Find what's lurking. Lock it out. Keep the proof.
Prefer email? contact@autosecurelogin.com
Read the guide
What Is an Intrusion Detection System? IDS Types and IPS
Read the guide
A practical guide that uses public, official sources and explains where this product fits and where it does not.
Host-based intrusion detection for Windows PCs and Linux servers
LurkerLock is host-based intrusion detection for small businesses and IT providers who look after Windows PCs and Linux servers without a security team. In HIDS vs NIDS terms it is a host-based IDS: a sensor on each machine reads that machine's own sign-ins, accounts, services, scheduled jobs and outbound connections, rather than one device watching all network traffic.
Host-based intrusion detection for Windows PCs and Linux servers
Suspicious activity such as password guessing, a new administrator account, a cleared audit log or a touched decoy becomes a finding that records what happened, when and on which machine. Those security events stay on the machine and on a LurkerLock Server you host yourself, and nothing is sent to us. Blocking is off by default and starts as a dry run.
Host-based intrusion detection for Windows PCs and Linux servers
You request access to LurkerLock, and prices are not published. Know the limits of this intrusion detection software before you plan a rollout: it supports Windows 11 and Ubuntu 24.04, blocking acts on single addresses only, and the installers are not code-signed. For background, read what an intrusion detection system is .
Host-based or network-based intrusion detection: which do you need?
NIST's SP 800-94 , a guide to intrusion detection and prevention systems, describes several kinds of tools. Two matter most for a small business.
Host-based or network-based intrusion detection: which do you need?
Network-based intrusion detection systems (NIDS) monitor network traffic from sensors at key points on a network. They see many machines at once, but not what happens inside each one, and encryption limits what they can read.
Host-based or network-based intrusion detection: which do you need?
A host-based intrusion detection system (HIDS) runs on each computer. It watches host activity such as sign-ins, new accounts, new services, scheduled jobs and that machine's own connections.
Host-based or network-based intrusion detection: which do you need?
An intrusion prevention system goes a step further and tries to stop what it detects. That helps, but a wrong block can cut off your own staff. Host and network security tools see different things, and SP 800-94 suggests considering more than one type. Intrusion detection is one layer of information security, not a whole security strategy.
Questions to ask before you choose
Where do findings and records live, and who can read them?
Questions to ask before you choose
Does it block on its own, or only after you allow it? Can you undo every block quickly?
Questions to ask before you choose
Which operating systems has it been tested on?
Questions to ask before you choose
Will its records hold IP addresses, account names and program paths that identify people? If so, do you need to tell staff?
Where LurkerLock fits
LurkerLock is host-based intrusion detection for Windows PCs and Linux servers. It is not a network sensor. Each machine checks its own outbound connections against public threat lists and your own list. Findings stay on the machine and on a LurkerLock Server you run. Blocking is off by default, starts as a dry run and acts only on single IP addresses. It is in early access, and Windows 11 and Ubuntu 24.04 are the tested systems.
Choosing among HIDS solutions for a small security strategy
HIDS solutions differ in three ways that matter to a small team: where the records live, how alerts reach you, and whether the tool can block on its own. Network-based intrusion detection systems watch traffic between machines in real time, but they cannot see inside each one.
Choosing among HIDS solutions for a small security strategy
LurkerLock keeps findings, records and alerts on machines you run, with no telemetry. Alerts go by email, text message or webhook, with quiet hours and daily caps. It blocks attackers only when you allow it.
Choosing among HIDS solutions for a small security strategy
A sound security strategy layers these parts. Put a host sensor on the machines that matter most, keep firewall and sign-in logs, and add a network sensor where you need to watch devices that cannot run an agent.