IIS Web Server Logs

What it is

Internet Information Services (IIS) is the Microsoft web server behind many internet-facing Windows hosts: intranet apps, SharePoint, and Exchange (OWA, ECP, EWS, Autodiscover). By default it writes one W3C text log per site per day. On a compromised web server these logs are often the only record of the initial exploit and of the requests that drove a webshell.

Location

<siteID> maps to a site in applicationHost.config (Default Web Site is 1). Admins frequently move logs to another drive: always read the logFile directory attribute there first.

What it proves

• A client IP sent a specific HTTP request (method, path, query string) at a given time, and what the server answered (status, substatus, Win32 status, time taken).
• Repeated requests to one .aspx file from few IPs, typically POST, suggest webshell use.

It does not record request or response bodies, POST parameters, or cookies by default. Behind a load balancer or reverse proxy, c-ip is the proxy; the real client appears only if an X-Forwarded-For custom field was configured. A 200 response does not prove the attacker's command succeeded.

Key fields

The #Fields: header line in each file lists the actual columns; they can change mid-file after a config change.

Timestamps

Retention and clearing

• Default rollover is daily; IIS has no built-in deletion, so months or years of logs often exist unless a scheduled cleanup script runs.
• Entries are buffered in memory and flushed periodically; on a live server run netsh http flush logbuffer before collecting.
• Attackers delete or truncate log files or disable logging in applicationHost.config; missing days and a changed logFile element are both findings.

Collection

Get-Content C:\Windows\System32\inetsrv\config\applicationHost.config | Select-String "logFile|physicalPath|<site "
netsh http flush logbuffer
robocopy C:\inetpub\logs\LogFiles E:\case\IIS /E /COPY:DAT /DCOPY:T
robocopy C:\Windows\System32\LogFiles\HTTPERR E:\case\HTTPERR /COPY:DAT

KAPE IISLogFiles collects the default locations only; add custom log directories manually. Also copy the web roots (physicalPath values) to hash and review scripts.

Parsing tools

• Log Parser 2.2 / Log Parser Studio: SQL over W3C logs.

LogParser.exe -i:IISW3C "SELECT c-ip, cs-method, cs-uri-stem, COUNT(*) AS hits FROM u_ex*.log WHERE cs-uri-stem LIKE '%.aspx' GROUP BY c-ip, cs-method, cs-uri-stem ORDER BY hits DESC"

• PowerShell / grep: fast string hunts across many files.
• Velociraptor: collection and parsing of IIS logs at scale.
• Timeline Explorer: after converting logs to CSV.

Investigation tips

• Webshells: look for .aspx, .ashx, .asmx or .config files recently created in web roots, rarely requested pages hit only by POST from one IP, and odd user agents. Compiled pages leave App_Web_*.dll under Temporary ASP.NET Files in the .NET Framework folder.
• Process lineage: w3wp.exe spawning cmd.exe, powershell.exe, whoami.exe or other LOLBins is a top signal. Correlate the request time with Security 4688 or Sysmon event 1, where the User is the application pool identity (IIS APPPOOL\<name>).
• Exchange: the 2021 ProxyLogon and ProxyShell chains left patterns such as unusual requests to /ecp/ or /autodiscover/autodiscover.json with an email address in the query, followed by webshells in OWA/ECP folders. Exchange also keeps its own logs under the install path Logging folder (HttpProxy, ECP, OWA). Use vendor and CISA guidance for exact indicators.
• Pivot on attacker IPs across all sites and HTTPERR, then on the time window across Prefetch and Amcache for tools they dropped.