Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchIf you suspect an attack against an IIS-hosted application, an HTTP status code cannot by itself tell you whether the hack worked. A 1xx response is only an interim signal, while a 2xx response confirms HTTP-level handling—not authorization, code execution, persistence, or data access. Determine the outcome by correlating IIS and HTTP.sys logs with host, network, and security telemetry.
What an IIS status code actually tells you
Microsoft’s IIS status overview states that the first digit defines the response class. That class describes HTTP processing, not the attacker’s intent or the security impact of a request.
As an Amazon Associate I earn from qualifying purchases.
| Class or code | HTTP meaning | What it does not prove |
|---|---|---|
| 1xx | Informational; the request was received and processing may continue. IIS lists 100 Continue and 101 Switching Protocols. | That the operation finished, succeeded, or gave an attacker access. |
| 2xx | The server successfully received and accepted the request at the HTTP layer. | That the caller was authorized, code executed, persistence was created, or data was obtained. |
| 200 | The request was processed. | That the requested action was safe or legitimate. |
| 201 | One or more resources were created. | That the created resource was authorized or harmless. |
| 202 | The request was accepted, but processing is not complete. | That the eventual operation will succeed or fail in a particular way. |
| 204 | The request was fulfilled without response content. | That no security-relevant change occurred. |
| 206 | A range request was fulfilled. | That the transfer was benign or authorized. |
| 304 | A conditional request found an unchanged representation, so content was not resent. | That the request failed. |
| 3xx | Further action, such as a redirect, is required. | Whether the redirected sequence was malicious or successful. |
| 4xx | The client request could not be fulfilled as submitted. | That an intrusion attempt had no effect; application-side changes may still require separate checking. |
| 5xx | The server encountered an error while handling the request. | Whether an exploit partially ran before the error. |
A successful-looking response can therefore be a normal page request, a rejected operation that still returned a custom 200 page, or an unauthorized action that the application failed to protect. Conversely, an error response does not automatically rule out partial execution.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Start with the IIS request record
Locate the relevant site-log entries using the suspected time window, target, and client address. The fields available depend on the site’s logging configuration, but Microsoft documents fields such as:
#1 Best Overall
- client IP address and username, when available;
- date, time, and time taken;
- bytes sent and received;
- service status and Windows status;
- request verb, target, and parameters.
Read the status together with any recorded substatus and Windows status. In Microsoft’s IIS logging context, service status 200 and Windows status 0 indicate successful fulfillment of that HTTP request. They still do not establish that the request was authorized or that an exploit achieved its objective.
Look for a sequence, not one line
Record the method, full target, timestamp, source address, authenticated identity, status/substatus, Windows status, response size, and processing time. Then inspect neighboring requests from the same source and session. A sequence such as reconnaissance, authentication attempts, upload or configuration changes, and follow-up retrieval is more informative than an isolated 200 or 500. Preserve the original logs and normalize timestamps before comparing systems.
Rank #2
Include HTTPERR when IIS logs are incomplete
HTTP.sys can generate some 4xx responses before IIS processes a request. Those events may not appear in the IIS site log. When investigating errors, examine the HTTPERR logs as well as the site logs so that a front-end rejection is not mistaken for a missing event.
For errors that IIS did record, use the status and substatus to narrow the failure. Microsoft recommends Failed Request Tracing (FRT) to identify the IIS module or handler involved. FRT can show where processing stopped and which component produced the response; it is diagnostic evidence, not proof of compromise.
Test the security outcome separately from the HTTP outcome
To decide whether a suspected hack succeeded, check for evidence of the claimed objective. Match web requests against host and network artifacts covering the same time period.
Host evidence
- Unexpected files, especially newly written scripts, binaries, scheduled tasks, services, startup entries, or web-accessible content.
- New or modified IIS configuration, application-pool settings, identities, accounts, permissions, or authentication rules.
- Processes spawned by the web worker process that are unusual for the application, including unexpected command interpreters or download utilities.
- File, registry, authentication, and endpoint-security events that align with the request time.
Network and application evidence
- Outbound connections from the server to unfamiliar addresses or domains after the suspicious request.
- Requests that retrieved uploaded content, invoked a new endpoint, or returned data not normally exposed by the application.
- Database, cloud-storage, identity-provider, or API audit records showing reads, writes, token use, or account changes.
- Repeated callbacks, beacon-like traffic, or transfer volumes inconsistent with the application’s normal behavior.
Microsoft defines an indicator of compromise (IoC) as an observable forensic artifact on a host or network that indicates an intrusion with high confidence. Examples include known-malware hashes, malicious traffic signatures, and URLs or domains known to distribute malware. A single suspicious URL or hash is a lead; confidence comes from validating it against the affected system and timeline.
Use security alerts within their product scope
Security-product detections can add corroboration, but their wording and coverage depend on the product and deployment. Microsoft’s Azure App Service guidance describes suspicious web requests, possible unauthorized code execution or logic manipulation, compromise indicators, and web-shell activity detection for that service. Microsoft Defender for IoT documentation gives possible web-shell detection as a high-severity alert and advises verifying whether the activity was expected. These examples should not be treated as universal detections for every self-hosted IIS server.
Validate an alert by identifying the affected host, process, file, account, request, and time. An alert that maps to a file created by the IIS worker process and is followed by execution or outbound communication is materially stronger than an alert with no matching artifact.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical investigation workflow
- Define the suspected objective. Decide whether the concern is unauthorized login, file upload, command execution, web-shell installation, data access, persistence, or service disruption.
- Fix the timeline. Convert IIS, HTTPERR, endpoint, firewall, proxy, identity, and application records to one time zone and preserve a copy before rotating logs.
- Extract request context. Record source address, identity, method, target, parameters, status, substatus, Windows status, response size, and time taken.
- Expand to adjacent events. Review preceding reconnaissance and subsequent requests from the same source, account, session, or network path.
- Check HTTPERR and FRT. Use HTTPERR for responses generated by HTTP.sys and Failed Request Tracing for IIS-recorded errors whose handling path is unclear.
- Correlate host and network telemetry. Look for file, process, configuration, account, outbound-connection, and data-access evidence that matches the web timeline.
- Assess confidence. Classify the result as an attempted request, HTTP-level success, suspected application impact, or confirmed compromise only when corroborating artifacts support that stronger conclusion.
- Contain carefully. If compromise is plausible, preserve volatile evidence, restrict the affected endpoint or host according to your incident plan, rotate exposed credentials, and investigate persistence before returning the service.
Common misreadings to avoid
- “It returned 200, so the hack worked.” A 200 only describes HTTP processing.
- “It returned 500, so the exploit failed.” An application can error after partially processing input.
- “There is no IIS entry, so nothing happened.” HTTP.sys may have generated the response first, and other controls may log the event elsewhere.
- “A 304 means the request was blocked.” It means an unchanged representation was not resent.
- “A security alert proves this exact server is compromised.” Confirm the product’s scope and match the alert to local artifacts.
When can you call the hack successful?
Use the narrowest conclusion supported by the evidence. You can say the request was observed when logs show it; you can say it achieved HTTP-level success when the response and logging context support that; and you can say compromise is confirmed only when independent artifacts demonstrate the suspected objective—for example, unauthorized code execution accompanied by a resulting process, a web shell that was written and subsequently invoked, or data access corroborated by application and host records. Keep the status code in the timeline, but never use it as the verdict.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
