IIS server monitoring for BadIIS redirects
BadIIS has shown up as a commodity malware set used through a malware-as-a-service model, which makes the traffic patterns more useful than any neat story about one attacker. The same loader and builder habits can turn up in different campaigns, but the infected IIS server still has to do the work: redirect visitors, proxy requests, or inject content into pages that should not have changed. When that happens, the log shape changes.
Catch the redirect pattern before it looks like ordinary traffic
Selective redirect behaviour is one of the cleaner signs. BadIIS can use browser language or other environment checks to send only some visitors to a malicious destination, which keeps the site looking normal during casual checks. That sort of filtering is awkward for simple uptime monitoring because the homepage still loads and the server still answers.
Compare browser-language moves with normal IIS access logs. A redirect chain that only appears for a narrow set of language headers, or only for requests that come through a particular proxy path, deserves attention. The useful signal is not a single 302 or 301. It is a repeated pattern where the same page behaves differently when the request context changes.
Watch for 503 errors alongside sudden site hijacks. BadIIS deployments have been tied to IIS 503 Service Unavailable errors in some cases, which means a service that suddenly fails while content is also changing is not just a stability issue. It is a compromise signal. If a site starts returning 503s at the same time that visitors are pushed to unfamiliar domains, treat that as one incident, not two separate annoyances.
Build detections around the artefacts BadIIS leaves behind
The most useful hunt clue is not a payload hash. It is the embedded PDB metadata that shows up in multiple builds, especially strings such as demo.pdb and repeated x64 build paths. Those strings are awkward to fake consistently across a long build history. They also help cluster variants that otherwise look like unrelated droppers and DLLs.
Hunt for embedded PDB strings such as demo.pdb and x64 build paths. A stable development pattern has been visible in paths like C:\Users\Administrator\Desktop\...\Release\demo.pdb, with timestamps stretching from late 2021 into 2026. That matters because it shows continuity in tooling, not a one-off payload drop. Folder names such as dll0217, dll0301, dll0315, dll-no503, dll(cur), and J3 point in the same direction: repeated build variants, patched branches, and fixes for particular failures.
Correlate installer activity, service changes, and odd deployment folders. BadIIS has been delivered through service-based installers and droppers, which means the web server can look untouched until the moment a service is created, changed, or restarted with a new binary in place. Deployment folders that do not match the normal IIS layout, especially ones carrying build labels or dated branch names, are worth checking against service creation events and file write times. A neat IIS estate does not usually grow a folder called dll-no503 for no reason.
Practical artefacts that matter
demo.pdb- repeated
x64build paths - branch names such as
2024-05-05-tcp - folder names that look like build cuts, not content directories
- installer activity that lands near service changes
- obfuscated binaries or custom Base64 blobs where plain configuration would normally sit
Turn monitoring into an incident boundary you can act on
A compromised IIS host is only useful if it still serves traffic, so the incident boundary has to be based on trust, not uptime. A live site that proxies requests, injects backlinks, or rewrites content is not a healthy server just because the health check passes. If a reverse proxy, web root, or dump path has been touched, the server should be treated as untrusted until those pieces are checked properly.
Verify the dump path, web root integrity, and reverse proxy behaviour. The web root should match known-good content, not just the version control tree. Reverse proxy behaviour needs particular care because BadIIS can send crawler traffic to one place and normal visitors to another. That split makes casual verification useless. Check whether the server is forwarding requests that should never leave the host, and whether any dump or staging path has been used as a drop location.
Confirm the server is clean enough to trust again. That means checking that the IIS worker process, related services, scheduled tasks, and startup changes no longer point at the malicious files. It also means checking that the redirect logic is gone, not just hidden. If the same box has been used for content injection or SEO fraud, old artefacts can keep the compromise alive even after the obvious payload is removed. A server that still has unexplained service entries or deployment folders is not clean, it is waiting for the next reload.
