I had the opportunity to present on Windows Operating System Hardening at MMS togather with Michael Niehaus , and if you attended, here is a recap of the session we did.

This session was built around a simple but uncomfortable reality: most Windows compromises in 2026 don’t start with exotic zero‑days. They start with perfectly legitimate credentials, perfectly legitimate tools, and environments that quietly allow attackers to move far too freely once they get a foothold.

The goal of the session was not to scare anyone, but to ground the conversation in how attacks actually unfold today—and how operating system hardening, done well, meaningfully changes the outcome.

If you want the official session listing and abstract, you can find it here:
Windows Operating System Hardening – MMS 2026
https://mms2026atmoa.sched.com/event/2HHHr/windows-operating-system-hardening

The Modern Reality: Less Exploitation, More Abuse

We started by resetting expectations.

Modern attacks are less about exploiting vulnerabilities and more about abusing what already exists:

• Phishing and social engineering for initial access
• Token and credential theft instead of kernel exploits
• Built‑in Windows tools for persistence and movement
• Legitimate admin protocols to move laterally

The uncomfortable assumption we asked everyone to adopt was this:

Credentials will be stolen, but we can slow that down
Hardening is about limiting what stolen credentials can do and we can make it harder to use them

Once you accept that premise, the role of OS hardening becomes very clear. It is not about building an impenetrable system—it’s about removing paths, shrinking blast radius, and buying time.

A Walk Through a Realistic Attack Chain

Rather than listing controls upfront, the session followed a realistic attack path from start to finish.

An attacker lands on a workstation through social engineering. Maybe it’s a Teams call. Maybe it’s a trusted tool misused. From there, built‑in binaries and scripting engines provide persistence. Nothing fancy. Nothing obviously “malicious.”, more like “hiding in plain site”.

Next comes credential access. Cached credentials. Tokens. Browser secrets. Local admin passwords reused somewhere they shouldn’t be. This is still one of the most reliable pivots attackers have.

From there, lateral movement is almost boring in its consistency:

• SMB and RPC
• RDP and WinRM
• Scheduled tasks and remote services

And finally, privilege escalation and domain impact—often by abusing delegation, service accounts, or certificate services rather than exploiting anything new.

What matters is not the exact tooling. Tools change every year. The path does not.

Where Hardening Actually Breaks the Chain

The core of the session focused on where operating system hardening disrupts this attack flow.

Hardening works when it:

• Removes unnecessary attack surface
• Reduces standing privilege
• Protects credentials at rest and in memory
• Constrains what code is allowed to run
• Limits where admin protocols can be used
• Makes drift visible instead of silent

This is why controls like Credential Guard, LSASS protections, Windows LAPS, firewall default‑deny for admin protocols, and application control keep showing up—they directly interfere with the attacker’s ability to move forward.

Hardening doesn’t need to stop the first step. It just needs to stop enough steps.

The Controls That Actually Matter

One of the key takeaways from the session was prioritization.

There are hundreds of settings you can configure. Very few that you must.

If you only remember a short list, it should look something like this:

• Eliminate standing local admin and deploy Windows LAPS
• Enable Credential Guard where the platform supports it
• Protect LSASS and remove legacy credential exposure
• Constrain execution with WDAC (starting in audit mode) or use Applocker
• Apply Attack Surface Reduction rules and tune them
• Default‑deny inbound admin protocols and restrict management paths
• Reduce NTLM and legacy SMB usage over time
• Treat logging and verification as first‑class requirements

These controls work because they compound. Each one increases attacker effort and decreases reliability of the attack chain.

Clients and Servers Are Different—for a Reason

We also spent time separating client and server thinking.

Workstations are your entry point problem. They need aggressive surface reduction, strong credential protection, and constrained execution—without breaking user productivity.

Servers are your amplifier problem. A lightly hardened server accelerates lateral movement and privilege escalation. Server hardening is about restricting interactive use, protecting service credentials, and being ruthless about admin channels.

The most common failure pattern we see is treating servers like “just another Windows box.” Attackers love that.

Hardening Is Not a One‑Time Project

The final part of the session focused on making hardening operational.

Hardening without verification is just hope.

Effective programs:

• Start from security baselines
• Use audit → pilot → enforce rings
• Track exceptions with owners and expiry
• Verify continuously using telemetry and logs
• Accept that some wins are quick, and others take months

If you leave with nothing else, leave with this mindset:
Hardening is a system, not a checklist.

Closing Thoughts

The reason we keep coming back to OS hardening is simple—it works.

Not because it’s flashy, but because it quietly removes attacker options. It slows them down. It forces mistakes. And it gives defenders time to respond.

That’s what we tried to show in this session, and that’s what I hope this recap reinforced.

If you want more details, references, and context around the session, the official MMS page is here:
https://mms2026atmoa.sched.com/event/2HHHr/windows-operating-system-hardening

During the session I did a short demo of a pretty little tool, and here is the link for that tool
Windows Client Security Baseline Toolkit – The Deployment Bunny

Thanks to everyone who attended—and especially to those who stayed for the long Q&A.

Until next time

/DeploymentBunny