How can security teams detect IIS components?

What IIS component detection is actually looking for

For Windows servers, IIS detection is about spotting when the web platform is present, enabled, extended, or abused in ways that create attacker execution paths. The strongest signals are not just the IIS service itself, but the supporting modules, handlers, scripts, configuration changes, and file-system artefacts that make web content executable.

That means teams should correlate multiple weak indicators instead of relying on a single name or process. A new web directory, an unusual extension mapping, or a modified web.config file may matter more than whether the server is formally documented as a web host. On the process side, web service activity that starts a shell, scripting host, or other admin tool is often the clearest sign that IIS is being used as a launch point rather than simply as a server role.

Because these artefacts are operational as well as malicious, baseline matters. A legitimate application can install handlers or write content under web roots, so the question is whether the change is expected, approved, and consistent with the server’s role. When the change enables remote management or code execution, it becomes a security event, not just a configuration event.

What to monitor on the server and in the file system

The most useful detection points are the places IIS leaves durable traces: module registration, handler mappings, application pools, virtual directories, web roots, and configuration files. Unexpected creation or modification in these areas can indicate that a host has been turned into a web execution environment or that an attacker is establishing a foothold through the web stack.

Review for new or altered script mappings, added extensions, and any change that allows content to be interpreted rather than served as static files. Also watch for writable web directories that should not exist on a production server, especially if they appear alongside suspicious scripts, droppers, or encoded payloads. If the server normally serves only a known application, a new content path is a stronger signal than a generic Windows change.

Process behaviour adds the next layer of confidence. When IIS-related services spawn cmd.exe, powershell.exe, wscript.exe, cscript.exe, or similar tooling, that often shows the web tier has crossed from serving requests into executing commands. Those child processes are particularly important when they appear outside maintenance windows or from accounts that should not be doing interactive work.

For hosts that run ASP.NET applications, it is also worth checking whether the web configuration has been changed to enable features that were previously disabled. That includes remote administration, dynamic script execution, or any setting that expands the server’s ability to interpret uploaded content. In practice, the detection value comes from the combination of configuration drift and process ancestry, not from any one log entry.

How to distinguish expected IIS activity from abuse

A useful detection program separates normal web application churn from infrastructure changes that materially alter the server’s attack surface. Deployment pipelines may add files or update configuration, but they should do so through known paths, signed packages, and approved change records. Anything else deserves scrutiny, especially if it creates a new execution surface or exposes administrative functions.

One practical approach is to establish a role profile for each server: what applications it should host, which directories it should expose, which modules it should load, and which processes it should never spawn. If a box that should only serve static content starts loading ASP.NET components or writing scriptable files into a public directory, the server has drifted outside its expected role. That role drift is often what exposes hidden IIS use.

Security teams should also treat internet-facing web servers as high-value monitoring targets because attackers frequently pivot through them to gain persistence or execute follow-on commands. The Persistence Techniques Guide is useful here because IIS changes often overlap with broader host persistence patterns such as service modification, web shells, and execution-flow hijacking. When a web server behaves like a persistence anchor, detection should expand beyond the web root to the whole host.

For ASP.NET-specific abuse, the article ASP.NET machine key attacks 2025 is a reminder that IIS exposure can extend into secret handling and request integrity, not just file drops. If the environment uses ASP.NET, detection should include whether configuration secrets are reused, exposed, or deployed in ways that let an attacker tamper with server-side execution.

Practitioner Guidance

What to verify: Confirm whether iis components are expected on the host before alerting. A real finding usually combines at least two signals, such as a new handler mapping plus suspicious child processes, or a new web directory plus a modified configuration file.

What to prioritise: Prioritise servers with public exposure, administrative interfaces, or recent configuration changes. Those are the hosts where IIS drift is most likely to become direct execution, persistence, or lateral movement.

Common mistake: Do not stop at the IIS service name in inventory. The more important question is whether the server is now capable of executing web content, accepting remote management changes, or launching operating-system tools from the web tier.

Practitioner takeaway: Strong IIS detection is behavioural, not inventory-only, so the most reliable alerts come from configuration drift plus execution evidence, especially when a web process spawns commands or gains new content-execution paths.

Related resources from NHI Mgmt Group

• How should security teams detect token theft if MFA was already completed?
• What should security teams monitor to detect SaaS supply chain abuse?
• How should security teams detect password spraying in Active Directory?
• How should security teams detect lateral movement across SaaS applications?