How do you detect IIS HTTP logging being disabled on Windows servers?

Detect IIS HTTP logging being disabled by alerting on configuration changes that stop IIS from writing request logs and by checking for sudden gaps in web server log collection. Investigate changes made from administrative sessions outside change control, especially on internet-facing servers. Correlate the logging change with suspicious web requests, new files, or web shell activity.

How IIS HTTP logging fails in practice

IIS HTTP logging is the server-side record of web requests, response codes, user agents, and other request context. When it is disabled, the server may still serve traffic normally, which is why the failure is easy to miss until a detection gap appears. The key signal is not just “logging is off”, but that request visibility has changed on a live server that should still be producing logs.

On Windows servers, the most reliable way to spot the condition is to compare expected log continuity against actual collection. If a site that normally emits daily or hourly logs suddenly stops writing, or the log file pattern changes without an approved change, you should treat that as a control-state change rather than a routine outage. That distinction matters because attackers often remove logging to reduce traceability after they touch web content or administrative settings.

For defenders, the important observation is that IIS logging is a configuration control, not just an operational preference. A change to that control can be made through administrative sessions, scripts, configuration management, or remote management tooling, so detection should focus on the state change itself and the context around it. When the logging gap aligns with new files under a web root, suspicious requests, or web shell indicators, the case for hostile tampering becomes much stronger.

What to monitor for when request logs go missing

Monitor for configuration changes that alter IIS logging settings, including changes to site-level logging, log format, or the destination where logs are written. Pair that with a file-level check that confirms logs are still being created at the expected interval and location. The most useful detections are those that compare normal log volume against what the application or site should generate, because silent suppression is often more important than a loud service failure.

It also helps to correlate web logging changes with Windows administrative activity. If an administrator session, scheduled task, or remote management action changes the logging state shortly before log collection drops, that sequence deserves priority review. A clean change record should explain the timing, the actor, and the reason. If it does not, treat the event as suspicious until proven otherwise.

Use the absence of logs as a clue, not a conclusion. A gap can result from benign maintenance, full disks, path changes, or log rotation issues, but those explanations should be validated against the server’s normal behavior and the surrounding system events. If you also see IIS worker process anomalies, unexpected configuration edits, or signs of content tampering, you should widen the investigation beyond logging alone.

Why this matters on internet-facing Windows servers

When IIS logging is disabled on a public server, defenders lose one of the fastest ways to reconstruct attacker activity. That makes it harder to answer basic questions such as which URL was hit, whether the attacker probed for a vulnerable endpoint, and whether a follow-on action succeeded. On exposed servers, that missing evidence can delay containment and let an intrusion persist longer than it otherwise would.

This is especially relevant when the same server hosts content that can be modified by an attacker. If logging disappears around the same time as a new ASPX file, unexpected script content, or another web-accessible artifact, the logging change may be part of the concealment step rather than a standalone configuration issue. For teams that already watch for web shell activity, a sudden logging gap should be treated as a possible blind spot created by the intrusion itself.

For broader detection engineering context, the patterns that matter are request visibility loss, configuration tampering, and post-change suspicious activity. A useful reference point for those operational signals is the Windows Event Log Guide, which helps teams anchor web logging changes to Windows-side evidence. For response work that includes remediation and verification, the Patch Management Guide is also relevant when the logging change is part of a broader emergency change or recovery action.

How to investigate and confirm compromise

Start by verifying whether logging was intentionally changed, and if so, by whom, when, and under what approval. Then compare the server’s file system, IIS configuration, and Windows event history to see whether the change aligns with other administrative actions. A legitimate maintenance window should usually leave a traceable story across change tickets, operator actions, and system logs. If that story is missing, inconsistent, or too narrow, escalate the review.

Next, check whether the logging gap overlaps with suspicious HTTP activity, unusual requests to admin paths, or evidence of staging and persistence. If the server is internet-facing, assume the attacker may have been trying to reduce telemetry before or after placing a web shell or modifying site content. Even when the logging change is reversible, you still need to know what happened while visibility was lost.

Because IIS logging can fail as part of a larger defensive impairment pattern, it is worth validating the server’s other telemetry sources as well. Correlate application logs, Windows event logs, EDR alerts, and file integrity findings so you can distinguish a misconfiguration from deliberate tampering. If the server stops logging requests and also stops producing other expected signals, treat the system as having reduced trust until revalidated.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1562.002 — Impair Defenses: Disable or Modify Tools	Logging disablement is a defense-impairment pattern on Windows servers.
	T1505.003 — Server Software Component: Web Shell	Missing IIS logs often coincides with web shell placement or use on exposed servers.
Recommendation — Hunt for log suppression and correlated post-change activity that indicates defense impairment. Correlate log loss with web-root changes and web shell indicators during triage.
CIS Controls v8	CIS-8 — Audit Log Management	IIS request logging and collection are audit logging controls that need continuous monitoring.
Recommendation — Monitor audit log enablement, retention, and collection for IIS servers.
NIST SP 800-53 Rev 5	AU-2 — Event Logging	IIS logging is event logging that must be defined and maintained for accountability.
	AU-6 — Audit Record Review, Analysis, and Reporting	Sudden gaps in IIS logs require review and correlation with other server activity.
Recommendation — Define required IIS events and validate that request logging remains enabled. Review missing logs as an anomalous audit condition and correlate them with other evidence.

Practitioner Guidance

What to verify: Confirm that request logging is still enabled on every production IIS site, and verify that logs are being written at the expected cadence and path. If the site is public-facing, treat any unexplained gap as a visibility incident, not just a configuration drift issue.

Decision rule: If logging disabled coincides with unscheduled administrative activity or web content changes, prioritize containment and forensic review before making the change “look normal” by simply turning logging back on.

Common mistake: Teams often check only whether IIS is running, not whether it is still producing usable logs. That misses the cases where the service remains healthy while the evidence trail has been quietly removed.

Practitioner takeaway: The real signal is not the setting alone, but the combination of logging loss, who changed it, and what else changed on the server at the same time.