Detect Registry, Service, and Firewall Changes: Simple Audits for Sysadmins

Configuration drift is the gradual, undocumented divergence of a server's actual configuration from its intended configuration. It happens on every server, in every environment, without exception. The only variable is whether you detect it or not.

Configuration drift on Windows servers means registry keys modified by silent updates, services added by software installations nobody approved, firewall rules created during troubleshooting and never removed, and scheduled tasks left behind by departed employees. Each change is small. Collectively, they transform a server from a known-good configuration into an unknown state.

---

How configuration drift accumulates

Drift doesn't happen in one event. It's the accumulation of dozens of small changes over months and years, each of which seemed reasonable or went unnoticed at the time.

Registry drift

The Windows registry is the largest single source of configuration drift. Every software installation writes registry keys. Every Windows Update modifies them. Every Group Policy refresh applies settings that may or may not be what you intended.

Common registry drift patterns:

• Windows Update side effects. An update modifies a service's startup parameters, changes a default protocol setting, or adds a new telemetry key. The update log records that a patch was installed, but not every registry key it touched.
• Software installation residue. An application was installed, used, and uninstalled. The uninstaller removed the program files but left 40 registry keys behind. Those keys are now permanent drift — they'll show up in every comparison until someone cleans them up.
• Conflicting Group Policy. A GPO was updated to enforce a setting that conflicts with a local registry value. The GPO wins, but the conflict isn't logged anywhere obvious. The server's effective configuration is now different from what the local registry was set to, and different from what the admin who set the local value intended.
• Run key persistence. A new entry appeared in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. This key executes programs at every login. Legitimate software uses it. Malware uses it. Without a baseline comparison, you can't tell what's new.

Service drift

Windows services are the backbone of server functionality. Every running service consumes resources, has privileges, and potentially accepts network connections. Service drift means the list of services — and their configurations — diverge from the intended state.

Common patterns:

• New service from software installation. A team member installed a monitoring tool, a backup agent, or a vendor diagnostic utility. The installation created a service running as SYSTEM. The tool works. Nobody documented the new service. Three months later, nobody remembers it was installed.
• Service account changes. A service that was running under a dedicated service account is now running as Local System because someone changed it during troubleshooting and didn't change it back. The service works, but it now has higher privileges than intended.
• Disabled services. A service that should be running was stopped or disabled — manually, by a failed update, or by a conflicting policy. The server appears functional because the service's absence doesn't cause an immediate visible failure, but the functionality it provided is quietly gone.

Firewall drift

Firewall rules accumulate the same way permissions do — new rules are added to solve immediate problems and never removed after the problem is resolved.

A production server that starts with 30 firewall rules ends up with 60 after two years of troubleshooting sessions, vendor support calls, and temporary remote access needs. The extra 30 rules each had a reason when they were created. Most of those reasons no longer apply. The rules persist.

The dangerous pattern: an inbound rule allowing RDP (port 3389) or SMB (port 445) that was added for a maintenance session and never removed. That rule is an open door that remains until someone audits the firewall — which, without a baseline to compare against, nobody does systematically.

---

Why Event Viewer doesn't solve this

The instinctive response to "detect changes on a server" is Event Viewer. Windows logs many configuration changes as events — service installations, policy changes, account modifications.

The problem is signal-to-noise. A healthy Windows server generates thousands of events per day. Filtering those events to find the specific configuration changes that matter requires knowing what you're looking for — which is the information you don't have when drift is the problem.

Event logs also have limitations:

• Not all changes generate events. Registry modifications by software installations don't always produce auditable events unless registry auditing is explicitly configured on specific keys.
• Event logs rotate. On servers with default log sizes, events from weeks or months ago may have been overwritten by newer entries. The change you're investigating may no longer exist in the logs.
• Events describe what happened, not what the state is. An event says "Service X was installed at 3:17pm." It doesn't say "here is the complete list of services on the server right now compared to what it was last month." You get individual transactions, not comparative state.

A baseline comparison approach is fundamentally different: it captures the complete state at two points in time and diffs them. It doesn't depend on event logging, doesn't miss silently applied changes, and doesn't require you to know what you're looking for in advance.

---

The baseline-and-compare approach

The concept is simple:

1. Capture a baseline — the complete configuration state at a known-good moment
2. Capture the current state — the same configuration categories at any later time
3. Diff them — every change becomes a row in a report

The execution requires capturing eight categories of configuration, serializing them in a comparable format, performing a field-by-field diff across thousands of data points, and classifying every change by risk.

This is not a five-line PowerShell script. It's a tool. You can build it yourself over several days of scripting, testing, and edge-case handling — or you can use one that already handles the enumeration, comparison, and risk classification.

The output should be:

• A drift report showing every change with category, the baseline value, the current value, the change type (added/removed/modified), and a risk classification
• Both snapshots preserved as files for future reference
• A summary with change counts by category and severity

This output is both your operational action list (what needs investigation) and your compliance evidence (proof that you reviewed the server's configuration and documented the findings).

---

Practical drift detection cadence

Critical production servers (weekly): These are the servers where unauthorized changes cause the most damage — database servers, domain controllers, customer-facing application servers. A weekly comparison keeps the detection window tight enough that changes are caught while the context still exists. Most weekly reports on a well-managed server should be empty.

Standard servers (monthly): File servers, internal application servers, development servers. Monthly comparisons catch drift within a reasonable window and produce documentation for quarterly reviews.

After every change window: Before and after planned maintenance. The drift report between the two snapshots should show only the planned changes. Anything else is scope creep or an unplanned modification.

Post-incident (immediately): Compare the current state against the last known-good baseline. Every change the attacker made — new users, new services, new firewall rules, registry modifications — surfaces in the drift report.

---

What a clean drift detection process looks like over a quarter

Month 1: Establish baselines on all servers in scope. Review the baseline reports to confirm they represent the intended configuration. This is the foundation.

Month 2: First comparison round. For well-managed servers, the drift reports should show minimal changes — maybe some Windows Update side effects. For servers with loose change control, the first comparison reveals the accumulated drift. Remediate critical and high findings. Update baselines after remediation.

Month 3: Second comparison. The drift reports should be cleaner than month 2 because the worst drift was remediated. Any new critical findings indicate either a change management failure or an ongoing issue that needs process improvement, not just technical remediation.

End of quarter: Package all three months of drift reports as compliance evidence. The auditor sees a documented progression: baseline established, drift detected, findings remediated, baselines updated. This is the evidence of an active configuration management process.

---

What to do next

If your servers don't have baselines, configuration drift is invisible. Every undocumented change accumulates silently until it causes a problem or an auditor asks a question you can't answer.

Server Change Intelligence captures the full configuration baseline across 8 categories and produces risk-scored drift reports on demand. The comparison runs in minutes. The output is a timestamped evidence pack you can act on and archive.

The trial captures 100 registry keys and 50 services — enough to see the drift detection workflow on a real server. Take a baseline, make a change, run the comparison, and see the change surface in the drift report. That's the entire value proposition in under five minutes.