--- title: "Walter Sentry · Woodshack" description: "Agentless WordPress security monitoring. Walter Sentry installs nothing in the sites it watches, so there is nothing for an intruder to switch off." url: https://woodshack.net/sentry/ site: Woodshack (https://woodshack.net/) about_this_site: https://woodshack.net/for-ai/ --- Walter Sentry # Security monitoring from outside the house. A monitor that lives inside the site it protects can be switched off by whoever compromises it. Walter Sentry installs nothing there at all. [Ask about Walter Sentry](https://woodshack.net/contact/?topic=sentry#form) [How it decides](https://woodshack.net/sentry/#principles) Verified, not claimed 0 Sentry components installed in the site it watches 26 independent checks across files, database, users and settings 1,200+ automated tests Live monitoring production sites on a schedule today The problem ## Two assumptions that stopped being true. Most WordPress security tools are plugins. That means they live inside the attack surface they're supposed to watch, and the same access that lets an attacker install a backdoor lets them deactivate the thing that would report it. A scanner that can be turned off by what it's scanning for has a hole in the middle of it. The second assumption is that malware is a file. It used to be. Now the interesting attacks don't touch a single PHP file: a payment skimmer stored in a database row and injected at render time, or an administrator created by quietly raising the permissions on a real customer's existing account, so no new user ever appears. A file scanner walks straight past both. Built from A store that was compromised for months while name-brand security plugins ran the whole time and caught nothing. Every check Walter Sentry makes maps to something that breach taught us, which is a different design input than a feature list. Mechanism ## How it watches. It logs in the way a developer would: over SSH, running WordPress's own command line tooling from outside, then comparing what it finds against a known-good baseline. ### Connects from outside Every check runs over SSH and WordPress's own command line tooling, driven from Sentry's server. To be exact about it: running a WP-CLI command does boot WordPress for the length of that command, the same as any developer's shell session. What never happens is anything persistent. No plugin, no must-use plugin, no hooks registered, no file written into the attack surface. ### Fingerprints the whole surface Files, database contents, user accounts and capabilities, scheduled tasks, configuration, and the site's public HTTP behavior. Baselines record what pristine looked like, and every later run is a comparison rather than a guess. ### Reconciles what WordPress says against what's stored Anything WordPress's own listing APIs report gets checked against the raw storage underneath. A plugin directory on disk that `wp plugin list` doesn't mention, or an administrator the users screen won't show you, is itself a critical finding. Hiding from the interface is the tell. ### Checks what a visitor actually gets Plenty of compromises show nothing to a logged-in administrator and serve a redirect to everyone else. Sentry requests the site the way a stranger and a search engine crawler would, and treats a difference between those two answers as a finding in its own right. Detection principles ## The rules every check follows. These are enforced in review. A check that violates one doesn't ship, which is the only reason a rule like this means anything. ### Outside looking in If a check would require running code inside WordPress, it gets redesigned rather than shipped. The architecture is the product. Conceding it for one convenient check would concede it entirely. ### No name-based skip lists A scanner that trusts a file because of where it sits is blind by design, and attackers write into popular plugins precisely because everyone skips them. Files are verified against official checksums or an explicitly pinned hash. Never trusted by path. ### Every finding explains itself A finding carries a stable identifier, the rule version that produced it, exactly where it was found, and the surrounding evidence. You triage from the report instead of re-running the scan and hoping. ### Severity is not confidence How bad a thing would be and how sure we are it's real are two different questions, so they're reported as two values. Collapsing them into one number is how scanners end up either crying wolf or staying quiet. ### Rules are versioned Baselines record which rule version wrote them, so when behavior changes it can be traced to the exact change that caused it rather than argued about. Fleet intelligence ## One site is an anecdote. A fleet is a pattern. Watching a single site, you can tell whether it changed. Watching many, you can tell whether the change is interesting. A file that appears on one site in a week is a question. The same file appearing across four unrelated sites in the same week is a campaign, and it deserves a much faster answer. So findings are not judged purely in isolation. What a compromise looked like on one site becomes the shape Sentry looks for everywhere else: the specific paths, the plugin nobody remembers installing, the account created three hours before the payload landed. The useful question ## "If we wanted this site, how would we take it?" Checklists describe attacks that already have names. The ones that hurt don't have names yet. The generative half of this work is sitting down with a site and asking, seriously, how we'd compromise it and then stay. Not which CVEs apply. Where would we hide so a file scan misses us? What could we change that nobody audits? Which piece of this system does everyone trust without checking? Those answers turn into checks, and they tend to be the good ones, because they come from the attacker's side of the problem rather than the vendor's. Hiding in a database row instead of a file. Elevating an existing customer rather than creating a suspicious new admin. Serving clean pages to logged-in staff and something else entirely to everyone arriving from a search engine. And then it sticks Every real incident ends the same way: the mechanism that made it possible gets written down as a check, with the evidence that would have caught it earlier. The tool is an accumulating record of things that actually went wrong, which is why it keeps getting better at a job that keeps changing. In practice ## What it's like to have running. Silent on a clean night. That's the point of a baseline: once a site is fingerprinted, an ordinary week produces nothing, so the alert that does arrive is worth reading. Findings come with evidence attached, so the first question, "is this real," is usually answerable without opening an SSH session. This is a service rather than a download. It runs on our infrastructure, against your site, on a schedule, and we look at what it produces. If a site is compromised, you get the map: what changed, when it changed, and which parts of the system it reached. The longer story of one alert that got lost in the noise: [Three threats, all marked High](https://woodshack.net/notes/we-die-in-the-noise/). ## Worried about a site, or already sure? Both are worth a conversation, and they're different conversations. Tell us which one you're having. [Ask about Walter Sentry](https://woodshack.net/contact/?topic=sentry#form) [Walter Offloads →](https://woodshack.net/tools/)