Auto Secure Login
Watch, trap and block attackers on your Windows and Linux machines
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 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.
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
The problem
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. 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. 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.
What changes
- 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.
- Decoys as well as detection: decoy account names, bait files with made-up passwords and decoy ports, which nothing legitimate touches.
- 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.
- One STOP switch removes every block, including any it lost track of, and every block expires on its own.
- 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.
- Windows PCs and Linux servers in one console, with named users, two roles and two-factor sign-in.
- A single machine can run the sensor with no server at all and keep its findings to itself.
What it does
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.
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.
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.
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.
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.
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.
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.
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.
Features
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.
Proof
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
- Free public threat lists, each checked against its publisher's terms; the Tor exit list is recorded only and never blocked.
- A doctor that says how to fix what it finds, and support bundles with keys and secrets left out.
Where it runs
Surfaces and status.
Status as of 2026-10-16. 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.
Works with
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.
Explore →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.
Explore →What is new
Recent progress.
This product ships often. The most recent verified changes, newest first.
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.
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.
Pricing
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.
Ask about pricingQuestions buyers ask
Straight answers.
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:
- 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.
- 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.
- The installers are not yet code-signed.
- Single sign-on (SAML or OpenID Connect) is not available yet, and the console has two roles only: administrator and viewer.
- One LurkerLock Server supports at most 1,024 sensors.
- Blocking acts on single addresses only: no networks, ranges, domain names, processes, accounts or ports. Everything else LurkerLock finds is reported, not blocked.
- 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.
- 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.
- Text and webhook alerts and blocking are licensed features. Detection, findings and email alerts never need a license.
- 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.
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.
Prefer email? contact@autosecurelogin.com