Operator On The Wire
Waitlist
← Back to Knowledge Base
OOTW / Chapter III - Web / Web Servers / Servers

IIS

Internet Information Services is Microsoft's web server for Windows.

IIS is built around sites, bindings, applications, virtual directories, handler mappings, modules, and application pools. The important security boundary is often not just the URL. It is the application pool identity, the handler map, the filesystem ACL, and the web.config policy for that directory.

Core Architecture

Important components:

HTTP.sys                 Kernel-mode HTTP listener
WAS                      Windows Process Activation Service
W3SVC                    World Wide Web Publishing Service
w3wp.exe                 Worker process
Application Pool         Isolation boundary for one or more apps
ApplicationPoolIdentity  Common worker identity
web.config               Per-application configuration
applicationHost.config   Machine-level IIS configuration

Common deployment patterns:

IIS -> static files
IIS -> ASP.NET Framework
IIS -> ASP.NET Core through ANCM
IIS -> classic ASP
IIS -> PHP through FastCGI
IIS -> reverse proxy through ARR

Important Paths

Webroot and logs:

C:\inetpub\wwwroot\
C:\inetpub\logs\LogFiles\
C:\Windows\System32\LogFiles\HTTPERR\

Configuration:

C:\Windows\System32\inetsrv\config\applicationHost.config
C:\Windows\System32\inetsrv\config\administration.config
web.config

IIS tools:

C:\Windows\System32\inetsrv\appcmd.exe

Useful local commands when we have shell access:

Import-Module WebAdministration
Get-Website
Get-WebBinding
Get-WebApplication
Get-ChildItem IIS:\AppPools
Get-WebConfiguration

Using appcmd:

%windir%\system32\inetsrv\appcmd.exe list site
%windir%\system32\inetsrv\appcmd.exe list apppool
%windir%\system32\inetsrv\appcmd.exe list app
%windir%\system32\inetsrv\appcmd.exe list config

Sites, Bindings, And Applications

An IIS site binds a hostname, IP, port, and optional certificate to content.

Bindings include:

IP address
Port
Hostname
TLS certificate

Applications and virtual directories can map subpaths to different physical directories.

Example:

Default Web Site
  /
    physical path: C:\inetpub\wwwroot
  /portal
    physical path: D:\Apps\Portal
  /uploads
    physical path: D:\Shared\Uploads

This matters because /uploads might not live under the main webroot. We need the physical path, not only the URL.

Application Pools

Application pools isolate worker processes.

Important review points:

  • Which site uses which app pool?
  • Which identity runs the app pool?
  • Does the app pool identity have write access to the webroot?
  • Do multiple apps share one app pool?
  • Is the app running as a privileged domain or local account?

Common identities:

ApplicationPoolIdentity
NetworkService
LocalService
LocalSystem
Custom domain user

LocalSystem is highly privileged and should not run normal web applications.

web.config

web.config controls IIS and ASP.NET behavior for an application or directory.

It can define:

  • Handlers
  • Modules
  • Static content MIME types
  • Request filtering
  • Authentication
  • Authorization
  • Custom errors
  • Rewrite rules
  • Connection strings
  • App settings

Example:

<configuration>
  <system.webServer>
    <directoryBrowse enabled="false" />
    <security>
      <requestFiltering>
        <hiddenSegments>
          <add segment="bin" />
        </hiddenSegments>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

If an attacker can upload or modify web.config, the server behavior for that directory can change. This is the IIS equivalent of many .htaccess abuse scenarios on Apache.

Handler Mappings

Handler mappings decide what executes.

Examples:

.aspx   -> ASP.NET
.ashx   -> ASP.NET handler
.asmx   -> ASP.NET web service
.asp    -> Classic ASP
.php    -> FastCGI PHP
static  -> StaticFile handler

Review:

  • Which extensions execute?
  • Are uploads placed in a directory with executable handlers?
  • Can web.config add or change handlers?
  • Are dangerous legacy handlers enabled?
  • Are static-only directories configured as static-only?

Enumeration

Remote checks:

curl -i http://target/
curl -i http://target/nonexistent
curl -I http://target/
whatweb http://target/
nikto -h http://target/

Interesting paths:

/aspnet_client/
/trace.axd
/elmah.axd
/web.config
/bin/
/App_Data/
/admin/
/uploads/

Interesting methods:

curl -i -X OPTIONS http://target/

Watch for:

OPTIONS
TRACE
PROPFIND
PUT
MOVE
COPY
DELETE

If LFI exists, try:

C:\inetpub\wwwroot\web.config
C:\inetpub\logs\LogFiles\
C:\Windows\System32\inetsrv\config\applicationHost.config
C:\Windows\System32\LogFiles\HTTPERR\

IIS Short Name / Tilde Enumeration

IIS tilde enumeration abuses NTFS 8.3 short filenames.

On some IIS/Windows configurations, requests containing ~1 and wildcard-style patterns produce different responses when a matching short filename exists. That difference can leak hidden file and directory names.

This does not directly read files.

It helps us discover names that should be hidden, such as:

backup archives
old admin panels
configuration files
source directories
staging folders

Concept:

Long name:  SecretDocuments
Short name: SECRET~1

If the server leaks whether SEC*~1* exists, we can brute force the short name and then guess the full name.

Manual checks are noisy and awkward, so this is normally automated.

Common tools:

IIS-ShortName-Scanner
shortscan
sns
Metasploit iis_shortname_scanner

Example follow-up after a short name is found:

DISCOV~1.ASP

Generate likely full names:

discover.asp
discovery.asp
discovered.asp

Then fuzz those candidates with relevant extensions:

gobuster dir -u http://target/ -w candidates.txt -x asp,aspx,config,txt,zip,bak

Defensive notes:

  • Disable NTFS 8.3 short names where operationally safe.
  • Patch IIS and ASP.NET components.
  • Normalize error responses.
  • Block suspicious ~1 probing at the edge.
  • Monitor bursts of requests containing ~, *, and numbered short-name patterns.

Common Weaknesses

Directory Browsing

Directory browsing should be disabled unless intentionally required.

Risk in web.config:

<system.webServer>
  <directoryBrowse enabled="true" />
</system.webServer>

WebDAV Writes

WebDAV can expose file-management methods.

Check:

curl -i -X OPTIONS http://target/
curl -i -X PROPFIND http://target/

If PUT or MOVE is allowed into an executable directory, upload impact can become severe.

web.config Upload

If uploads allow web.config, attackers may change behavior for that directory.

Abuse examples:

  • Add MIME mappings to serve blocked extensions.
  • Change handlers.
  • Loosen request filtering.
  • Expose normally hidden content.

This depends on permissions and IIS configuration.

Exposed Debug Handlers

High-value paths:

/trace.axd
/elmah.axd

These can leak stack traces, request history, exceptions, headers, cookies, paths, and application internals when misconfigured.

Request Filtering Gaps

IIS request filtering can block dangerous extensions, hidden segments, double escaping, and large bodies.

Review:

blocked extensions
hidden segments
allowed verbs
maximum content length
double escaping

Weak filtering allows hidden files, dangerous extensions, or unusual encodings to reach handlers.

NTLM And Windows Authentication

IIS often uses Windows authentication on internal applications.

Review:

  • Is anonymous access disabled where expected?
  • Is NTLM exposed externally?
  • Does the application reflect or relay credentials?
  • Are admin panels protected only by network location?
  • Are intranet trust assumptions present?

NTLM exposure is not automatically exploitable, but it is important in internal assessments because it can chain with relay and coercion attacks.

Logs

IIS logs commonly live under:

C:\inetpub\logs\LogFiles\

HTTP.sys error logs:

C:\Windows\System32\LogFiles\HTTPERR\

Log poisoning principles are the same as Linux servers: the log must be writable with controlled input and later interpreted by an executable runtime. On IIS, this is less commonly a direct PHP include chain unless PHP is deployed, but logs still reveal paths, methods, status codes, usernames, user agents, and internal routing behavior.

Defensive Checklist

  • Keep application pools isolated per app.
  • Run app pools with least privilege.
  • Avoid LocalSystem for web applications.
  • Keep uploads outside executable directories.
  • Deny script execution in upload directories.
  • Block direct access to web.config, bin, and App_Data.
  • Disable directory browsing.
  • Disable WebDAV unless required.
  • Restrict dangerous HTTP verbs.
  • Restrict or remove debug handlers.
  • Normalize error responses.
  • Review handler mappings.
  • Review request filtering.
  • Monitor tilde enumeration patterns.
  • Protect IIS logs and machine-level configuration.