5 Windows security findings your clients don't know about (but attackers do)

After enough assessments the same handful of issues show up again and again. None of them are exotic. All of them are trivially exploitable, well-documented, and years old. Here are the five we find most often — and why they are still everywhere.

1. SMBv1 still enabled

SMBv1 is the protocol WannaCry and NotPetya rode in on. Microsoft deprecated it in 2014 and removes it by default on new installs, yet it lingers on servers that were imaged years ago or that once talked to an old NAS or MFP. It is a one-line fix (Disable-WindowsOptionalFeature) and a genuine remote-code-execution surface. Always check for it; you will find it.

2. BitLocker off — or TPM-only

Laptops leave buildings. An unencrypted drive is a data breach the moment the device is lost. Even where BitLocker is on, TPM-only mode protects against offline theft but not against an attacker who has the running machine. The recommendation is TPM + PIN, with the recovery key escrowed. The finding you actually see most is "encryption off entirely" on machines everyone assumed were covered.

3. LLMNR and NBT-NS left on

Link-Local Multicast Name Resolution is on by default and is the fuel for the single most common internal attack: an attacker on the LAN responds to name-resolution broadcasts, captures NetNTLM hashes, and relays or cracks them. Disabling LLMNR and NBT-NS closes it. Almost no SMB has done it, because nothing appears to break when it is on.

4. The same local admin password everywhere

When a fleet is imaged from one golden image, every machine often ships with the same local Administrator password. Compromise one, and pass-the-hash gives you all of them — the textbook lateral-movement path. Windows LAPS randomises per-device local passwords and fixes it for free, but adoption is low. It is worth auditing for directly, and deploying LAPS to eliminate.

5. Stale privileged and service accounts

Enabled accounts that have not logged in for 90+ days, service accounts with PasswordNeverExpires, an old krbtgt password — each is a standing credential an attacker would love to inherit. They accumulate because offboarding rarely reaches into AD. A scan that lists them with their last-logon date turns a vague "we should clean up AD" into a concrete work item.

Why they persist

None of these break anything when they are wrong, so nobody notices. They only surface when someone looks — which is the whole argument for a recurring, automated assessment. Find them once, fix them, and prove they stay fixed on the next scan.