Building a Safe Windows Hardening Tool: A Post-Mortem and Deep Dive

I recently shared my free Windows hardening tool, WinSystemHarden, on Indie Hackers. This post is a post-mortem of that discussion.

There’s no shortage of one-size-fits-all PowerShell scripts floating around, and they often end up breaking local printers or network shares. My goal was to build a simple GUI tool with 29 core rules. It captures snapshots of the registry and ACL permissions before making any changes, with one-click rollback.

V1.3 is live right now. After posting, I got some incredibly sharp feedback from other engineers. A handful of comments laid out blind spots I hadn’t considered at all. This is my unfiltered take on what I missed, and how I plan to fix it.

Deep Dive 1: The "Half-Bricked" State on Crash

One person asked a really good question: what happens if the machine crashes or loses power mid-rule application? Does rollback still work?

Honest answer: in the current V1.3 build, snapshots only live in memory until all rules finish applying successfully. If power cuts out halfway through, that snapshot is gone. The system gets stuck in a dirty, partially hardened state.

The fix I’m working on: a session.lock workflow. I’ll write the snapshot to disk before running each rule and create a lock file. Next time the app opens and sees that lock, it prompts the user to roll back the interrupted session.

// Planned transaction logic public void ApplyHardeningRule(Rule rule) { CreateLockFile(); // Mark session as active SaveSnapshotToDisk(rule.CurrentState); // Persist state before making changes try { rule.Apply(); } catch (Exception ex) { // Log error, lock remains so rollback can trigger on next launch LogError(ex); } } 

Deep Dive 2: The Edge Case That Leaves "Stray Keys"

Another question got me thinking: does rollback restore back to Windows defaults, or the exact state of the machine before hardening?

My approach is to back up the exact pre-hardening state with Registry.GetValue. It reverts to the user's original state, not a generic Windows baseline.

Then came the bug report. What if the registry key didn't exist at all before the change? My old rollback logic used reg add to write a fallback value, which creates a leftover key that wasn't there originally. That breaks clean snapshot restoration.

They were completely right. I'm adding null checks. If the snapshot value is null on restore, rollback deletes the key instead of writing a value.

// Old flawed logic: creates stray keys when original value is null if (originalSnapshot == null) { Registry.SetValue(keyPath, valueName, defaultValue); } // Fixed logic: delete the value if it didn't exist before if (originalSnapshot == null) { using (var baseKey = GetBaseKey(hive)) // e.g., LocalMachine or CurrentUser using (var key = baseKey.OpenSubKey(keyPath, true)) { if (key != null && key.GetValue(valueName) != null) { key.DeleteValue(valueName); // Physically remove the stray key } } } 

Deep Dive 3: LSA Protection (RunAsPPL) and Legacy Drivers

Someone suggested adding LSA Protection (RunAsPPL) to block credential dumping from memory. But they flagged a big compatibility risk: it can break older antivirus software and smart card drivers.

I agree. If I ship this rule, it will live only under Deep mode, with a prominent warning in the UI. They also shared a neat trick: run Windows Audit mode in the background and watch Event IDs 3065/3066 to spot blocked drivers before locking in the setting.

Deep Dive 4: The Dilemma of Blocking Port 445 (SMB)

Blocking port 445 is a classic hardening step to stop ransomware lateral movement (like WannaCry). But here is the catch: many scripts just disable the LanmanServer service entirely to block it.

While this secures the machine, it immediately kills local file sharing. If you are in a small office with a NAS or a shared printer, your network is broken.

The fix: Instead of killing the service, WinSystemHarden takes a more surgical approach. It applies a specific firewall rule that blocks inbound SMB traffic from external networks, while leaving the local subnet traffic untouched. This gives you both security and functionality, but it's highly dependent on accurate ACL and firewall state restoration if things go wrong.

Deep Dive 5: "Might Break" Notes and UX Transparency

Another commenter liked the safety-first direction and suggested hover tooltips for risky rules, like disabling SMBv1.

I'm on board with this. If a user doesn't know disabling a service will take out their home NAS or shared printer, they'll easily assume the tool is harmful. I'm adding these warnings now.

Deep Dive 6: The Demand for Enterprise CIS Audits

One MSP pointed out that many IT providers would want CIS control ID export logs, to show clients proof of hardening.

It's a solid feature idea, but I'm holding off for the free version. Implementing it requires hitting the Windows Event Log extensively and correlating it with specific CIS control IDs, which is a massive performance hit. I don't want to bloat the free tool. This will likely land in a future Pro / Enterprise release.

Final Thoughts

For me, the best part of posting on IH wasn't traffic. It was getting a blunt, high-quality code review from people who actually work in this space.

These bugs and UX gaps aren't discouraging. They lay out exactly what I need to build next.

WinSystemHarden is a free tool. You can grab the current build here: https://www.nisse-sec.com/free-tools.html