How to Catch Unauthorized Changes on Your Windows Server Before They Cause Downtime

A server baseline snapshot captures the complete configuration state of a Windows server at a point in time — registry keys, services, installed software, scheduled tasks, startup items, users, firewall rules, and network configuration. Comparing a later snapshot against the baseline produces a drift report showing every change, classified by risk.

Every unplanned outage you've ever investigated started with a change. A registry key was modified. A service was stopped. A firewall rule was added. Software was updated. A new user was created. Something changed, and nobody knew about it until the consequences appeared.

The pattern is always the same: something breaks, the team investigates, and hours later someone discovers the specific change that caused the problem. The change happened days or weeks ago. Nobody documented it. Nobody approved it. The investigation cost was orders of magnitude more than catching the change would have cost.

This guide covers how to establish a server baseline, how to use it to detect unauthorized changes, and how to build baseline comparison into your operational routine so changes are caught when they happen — not when they break something.

---

What "unauthorized change" actually means in practice

Unauthorized changes aren't always malicious. In most IT environments, the majority of unauthorized changes fall into three categories:

Undocumented maintenance. A team member made a change — installed software, modified a registry key, added a firewall rule — without following the change management process. The change may have been completely appropriate, but it wasn't documented. When something breaks later, nobody knows it happened.

Silent automated changes. Windows Update modifies registry keys and service configurations. Software auto-updates change binary paths and versions. Group Policy pushes settings that may conflict with the server's intended configuration. These changes happen without human intervention and without notification.

Malicious modifications. An attacker creates a new user, installs a service for persistence, opens a firewall port for command and control, or modifies a registry Run key to maintain access. These changes are intentionally hidden and designed to look like normal configuration.

All three categories are invisible without a baseline. You can't detect that something changed if you don't know what it was before.

---

The baseline: your server's known-good state

A baseline snapshot captures every aspect of a server's configuration at a specific moment — ideally immediately after a confirmed-good deployment, after a successful maintenance window, or at any point when you're confident the server's configuration is correct and complete.

The baseline becomes the reference. Every future comparison asks: "What's different now compared to the baseline?" If nothing changed, the server is in its known-good state. If something changed, the drift report tells you exactly what — and the risk scoring tells you whether it matters.

What a complete baseline captures

A meaningful baseline covers every configuration category that could indicate an unauthorized change:

Registry keys — HKLM\SOFTWARE (application configuration), HKLM\SYSTEM (service and driver configuration), Run keys (startup persistence). Registry changes are the most common side effect of software installations, malware persistence, and configuration drift.

Services — Every Windows service with its name, state, start type, binary path, and logon account. A new service is the most important single finding in any drift report — especially one running as SYSTEM.

Installed software — The complete software inventory from the registry uninstall keys. Captures name, version, publisher, and install date. Detects unauthorized installations, silent updates, and removed software.

Scheduled tasks — Every task with its status, run-as account, and actions. Complements the Scheduled Task Auditor by adding change-over-time detection to the point-in-time risk scoring.

Startup items — Registry Run keys and startup folder contents. Anything that executes at boot or login.

Local users and groups — Every local account and group membership. The Administrators group is the most sensitive — any change to its membership is a privilege escalation event.

Firewall rules — All enabled inbound and outbound rules. New inbound rules on sensitive ports (RDP 3389, SMB 445, SSH 22) are critical findings.

Network adapters — IP addresses, DNS servers, gateways. Configuration changes here affect connectivity and can indicate unauthorized infrastructure modifications.

---

The comparison: detecting drift

Once the baseline exists, detecting drift is mechanical: capture the current state, compare every field against the baseline, and classify every difference.

The classification is what makes the comparison useful. A drift report with 200 unscored changes is a data dump. A drift report with 3 Critical changes, 7 High changes, and 190 Info changes is an action list — you address the Critical items immediately, investigate the High items this week, and review the Info items when you have time.

What the comparison reveals — real-world examples

A new SYSTEM service appeared. Classification: CRITICAL. This wasn't in the baseline. It's running as the highest-privilege local account. It could be a legitimate software installation that went through change management — or it could be malware persistence. Either way, it needs immediate verification against the change log.

An inbound firewall rule was added for port 3389. Classification: CRITICAL. Someone enabled RDP inbound. If this was planned — a support session, a remote management need — it should have been documented. If it wasn't planned, it's an open door for lateral movement.

The antivirus software was removed. Classification: HIGH. The baseline showed antivirus installed; the current snapshot doesn't. Either the license expired and the software was uninstalled, or someone (or something) disabled the server's primary defense.

A local user account was added to the Administrators group. Classification: HIGH. Privilege escalation. Verify against the access request log.

A service changed from Running to Stopped. Classification: MEDIUM. A service that was running at baseline is now stopped. This could affect functionality. Check whether it's intentional.

Software X updated from version 2.1 to 2.3. Classification: MEDIUM. In a controlled change environment, version changes should be documented. If auto-update is enabled, this may be expected — but it should still be recorded.

---

Building baseline comparison into your operations

The first baseline

Take the first baseline on a server you're confident is in a good state. After a fresh deployment, after a successful maintenance window, or after a thorough review confirms the configuration is correct.

Don't take a baseline on a server you haven't reviewed — you'll be comparing future states against a potentially compromised reference. The baseline should represent what the server is supposed to look like, not just what it happens to look like today.

Comparison cadence

Weekly for critical production servers. A weekly comparison catches changes within days, while the context for why the change happened is still fresh. The drift report for a well-managed server in a normal week should be empty or nearly empty — any findings are worth investigating.

Monthly for less critical servers. Monthly comparisons still catch drift, just with a longer delay. Acceptable for development servers, staging environments, or servers where changes are less impactful.

After every maintenance window. Take a snapshot before the window, make the planned changes, take a snapshot after. The drift report between the two snapshots should show only the planned changes. Any additional differences are unplanned modifications that happened during the window.

After any security incident. Compare the current state against the last known-good baseline. The drift report shows every change the attacker made — or every change that happened while you were focused on the incident.

Updating the baseline

After an authorized change — a planned deployment, a patch cycle, a configuration update — verify the drift report shows only expected changes, then update the baseline. The new baseline incorporates the authorized change, so future comparisons don't flag it.

The old baseline should be archived, not deleted. Maintaining a history of baselines gives you the ability to compare any two points in time — not just current-vs-baseline, but "what changed between January and March?"

---

The cost of not having a baseline

Without a baseline, every investigation starts from zero. "When did this service appear?" Nobody knows. "Who changed this registry key?" Nobody knows. "Was this firewall rule always there?" Nobody knows.

The investigation that could have taken 5 minutes with a drift report — "the report shows a new service was installed on Tuesday, not in the change log, investigate" — takes hours or days of forensic analysis, event log correlation, and guesswork.

For compliance, the cost is even clearer. Auditors ask "how do you detect unauthorized changes?" Without a baseline and comparison process, the honest answer is "we don't." That's a finding.

---

What to do next

If your production servers don't have baselines, every change is invisible until it causes a problem. The cost of establishing baselines is a one-time snapshot per server that takes minutes. The cost of not having them is every unplanned outage investigation and every compliance finding you can't prevent.

Server Change Intelligence captures the complete configuration baseline across 8 categories and produces risk-scored drift reports on every comparison. The trial captures 100 registry keys and 50 services — enough to see the baseline-and-compare workflow in action on a real server.

Take a baseline today. Compare it next week. The drift report will either confirm your server is stable or show you something you didn't know changed.