The audit that ran no tests
Nine machines were carrying a Linux hardening score built from zero measurements, and nothing failed. Wegweiser now checks whether its own readings mean anything, and can watch an account that exists only to never be used.
A Lynis audit on one of our own Linux boxes reported a hardening index of 66. Perfectly ordinary number. Middle of the range. Underneath it, the audit's own payload said it had performed zero tests.
Nothing had failed. The audit completed, the parser parsed it, the score was written, the page rendered it, and that 66 went into the machine's health average exactly as though something had been measured. Eight more devices were in the same state.
This release is about that gap: Wegweiser has always been good at scoring what it collects, and blind to whether the collection still means anything.
Three new checks on Wegweiser's own readings
The device doctor already asked four questions about every stored reading - is this a score our own rules forbid, has this check failed three times running, has it ever worked here when it works everywhere else, is it older than the cadence promised. Three more now:
An analysis that measured nothing. If a payload's own count of what it examined is zero and a score was written anyway, that score has nothing behind it. Nine devices, immediately.
A payload that is not the shape it should be. Stored data occasionally comes back in the wrong form - a chunk of text where structured data belongs. Everything downstream still works, which is exactly why it survives: the score is right, the page renders, and only a query that tries to read a field out of it comes back empty. Three devices.
A score that never moves while the data does. Five runs, five different collections, the same number and the same wording each time. Our analyses are written by a model, and a model does not produce byte-identical prose five times by chance. If it does, the analysis is not reading its input any more.
Two rules we measured and did not build
This is worth saying out loud, because a monitoring product that reports things that are not problems is worse than one that reports nothing.
The plan included a rule for any score of exactly 100. On paper it is the mirror of the zero rule: both look like "nothing was measured". On the actual data it is nothing of the sort. 649 stored readings score exactly 100 and every one is honest - a malware scan with no detections, a machine with no faulty hardware, a day with no application crashes. Zero is a claim our own rules forbid an analyser from making. One hundred is a clean bill of health, and those happen.
The stuck-score rule started at 120 hits, which would have been unusable. Adding the byte-identical-prose test brought it to 31. Excluding the checks whose wording is supposed to repeat - the deterministic ones that never call a model at all, and the ones that short-circuit an empty collection to a fixed sentence - brought it to one. It ships in that narrow form.
Both of those cuts cost more effort than shipping the rules would have. They are the difference between a page an MSP reads and a page an MSP learns to scroll past.
Honey accounts
Everything above is Wegweiser being more careful about inference. This is the opposite: the first detection in the product that is not an inference at all.
A honey account is an account created for the sole purpose of never being used. Nothing legitimate signs in as it. No service runs under it. Nobody on the team knows it. So if it ever appears in a logon event, that is not a risk score and not a pattern that resembles an attack - somebody is working through credentials they should not have, on that machine, now.
You name the accounts in Settings and your endpoints pick them up on their next check-in. Any logon event naming one is raised as a critical alert, carrying the full event, the moment it reaches us. It never enters a health score: averaging a yes-or-no compromise signal into a number between one and a hundred would bury the most important thing we will ever tell you.
Be clear about the timing, because a security control that oversells its own speed is worse than one that is honest about it. Windows event logs are collected once a day. So a trip is found within a day of happening, not within minutes. What the alert does not do is wait for an analysis cycle on top of that - it is raised on arrival rather than when the next analysis runs, which is the difference between a day and three. Against an industry average dwell time measured in months, a day is a good answer; it is not the same as real time, and we would rather say so.
Two details worth knowing before you use it.
Wegweiser does not create the account. There is no write path into your directory and there is not going to be one. Create the account yourself, leave it disabled or give it a long random password, and never sign in as it. A name typed into the setting with no account behind it is a detector that can never fire.
Pick a name nothing already uses. Built-in names like Administrator and Guest are refused outright, because an alert that fires every time somebody logs in normally is an alert you will switch off within a day. The right name looks worth stealing and appears nowhere else on the estate.
The detection matches on the account name rather than on a particular kind of Kerberos event, and that was a deliberate change from the original design. Across the Windows machines we have visibility of, the Kerberos events that design relied on appear once and never respectively - most of these estates are not domain-joined, and neither are a great many of the small-business networks an MSP looks after. Failed and successful logons are the events that actually exist, on a workgroup and a domain alike.
The endpoint side is agent 0.3.99, released alongside this.