Journaux IIS : fiche forensique

Présentation

Internet Information Services (IIS) est le serveur web de Microsoft derrière de nombreux serveurs Windows exposés : applications intranet, SharePoint et Exchange (OWA, ECP, EWS, Autodiscover). Par défaut, il écrit un journal texte W3C par site et par jour. Sur un serveur web compromis, ces journaux sont souvent la seule trace de l'exploitation initiale et des requêtes qui ont piloté un webshell.

Emplacement

Version	Chemin par défaut	Remarques
IIS 5.1 / 6 (XP, Server 2003)	`%SystemRoot%\System32\LogFiles\W3SVC<siteID>\exYYMMDD.log`
IIS 7 et suivants (Vista et suivants)	`%SystemDrive%\inetpub\logs\LogFiles\W3SVC<siteID>\u_exYYMMDD.log`	`u_` signifie UTF-8
Erreurs HTTP.sys	`%SystemRoot%\System32\LogFiles\HTTPERR\httperr*.log`	Requêtes rejetées avant IIS (requêtes invalides, timeouts, 503)
Configuration du serveur	`%SystemRoot%\System32\inetsrv\config\applicationHost.config`	Sites, liaisons, chemins physiques, réglages de journalisation
Configuration du site	`web.config` dans chaque racine web	Handlers, modules, authentification

<siteID> correspond à un site déclaré dans applicationHost.config (Default Web Site vaut 1). Les administrateurs déplacent souvent les journaux sur un autre disque : lisez toujours d'abord l'attribut logFile directory.

Ce que l'artefact prouve

Une IP cliente a envoyé une requête HTTP précise (méthode, chemin, query string) à un moment donné, et ce que le serveur a répondu (statut, sous-statut, statut Win32, durée).
Des requêtes répétées vers un même fichier .aspx depuis peu d'IP, typiquement en POST, évoquent l'utilisation d'un webshell.

Il ne consigne pas par défaut le corps des requêtes ou des réponses, les paramètres POST ni les cookies. Derrière un répartiteur de charge ou un reverse proxy, c-ip est celle du proxy ; le vrai client n'apparaît que si un champ personnalisé X-Forwarded-For a été configuré. Une réponse 200 ne prouve pas que la commande de l'attaquant a réussi.

Champs clés

Champ	Signification	Par défaut
`date`, `time`	Heure de la requête (écrite à la fin de la réponse ; soustrayez `time-taken` pour les requêtes longues)	Oui
`s-ip`, `s-port`	IP et port du serveur	Oui
`cs-method`	GET, POST, etc.	Oui
`cs-uri-stem`, `cs-uri-query`	Chemin et query string	Oui
`cs-username`	Utilisateur authentifié (`-` si anonyme)	Oui
`c-ip`	IP du client	Oui
`cs(User-Agent)`, `cs(Referer)`	En-têtes du client	Oui
`sc-status`, `sc-substatus`, `sc-win32-status`	Statut de la réponse	Oui
`time-taken`	Millisecondes	Oui
`cs-host`, `sc-bytes`, `cs-bytes`	En-tête Host, octets envoyés/reçus	Non, à activer

La ligne d'en-tête #Fields: de chaque fichier donne les colonnes réelles ; elles peuvent changer en cours de fichier après une modification de configuration.

Horodatages

Horodatage	Format	Pièges
`date` + `time`	`AAAA-MM-JJ HH:MM:SS`, UTC pour le W3C	Les autres formats (IIS, NCSA) utilisent l'heure locale ; voir UTC et heure locale
`AAMMJJ` du nom de fichier	Jour UTC, sauf si « Use local time for file naming and rollover » est coché	Une journée en heure locale peut couvrir deux fichiers
Horodatages des fichiers de la racine web	NTFS, UTC	Date de création d'un webshell : vérifiez la $MFT et le journal USN pour détecter le timestomping

Rétention et effacement

La rotation est quotidienne par défaut ; IIS n'a aucune suppression intégrée, si bien que des mois voire des années de journaux subsistent souvent, sauf script de nettoyage planifié.
Les entrées sont mises en tampon en mémoire et écrites périodiquement ; sur un serveur en production, lancez netsh http flush logbuffer avant la collecte.
Les attaquants suppriment ou tronquent les fichiers, ou désactivent la journalisation dans applicationHost.config ; des jours manquants comme un élément logFile modifié sont des constats en soi.

Collecte

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

La cible KAPE IISLogFiles ne collecte que les emplacements par défaut ; ajoutez manuellement les répertoires personnalisés. Copiez aussi les racines web (valeurs physicalPath) pour hacher et relire les scripts.

Outils d'analyse

Log Parser 2.2 / Log Parser Studio : requêtes SQL sur les journaux W3C.

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 : recherches de chaînes rapides sur de nombreux fichiers.
Velociraptor : collecte et analyse des journaux IIS à grande échelle.
Timeline Explorer : après conversion des journaux en CSV.

Conseils d'investigation

Webshells : cherchez des fichiers .aspx, .ashx, .asmx ou .config récemment créés dans les racines web, des pages rarement demandées et appelées uniquement en POST depuis une seule IP, et des user agents inhabituels. Les pages compilées laissent des App_Web_*.dll sous Temporary ASP.NET Files dans le dossier du .NET Framework.
Filiation des processus : w3wp.exe qui lance cmd.exe, powershell.exe, whoami.exe ou d'autres LOLBins est un signal majeur. Corrélez l'heure de la requête avec le 4688 du journal Security ou l'événement 1 de Sysmon, où User est l'identité du pool d'applications (IIS APPPOOL\<nom>).
Exchange : les chaînes ProxyLogon et ProxyShell de 2021 ont laissé des motifs comme des requêtes inhabituelles vers /ecp/ ou /autodiscover/autodiscover.json avec une adresse e-mail dans la query string, suivies de webshells dans les dossiers OWA/ECP. Exchange tient aussi ses propres journaux dans le dossier Logging de son chemin d'installation (HttpProxy, ECP, OWA). Reportez-vous aux publications de l'éditeur et de la CISA pour les indicateurs exacts.
Pivotez sur les IP de l'attaquant dans tous les sites et dans HTTPERR, puis sur la fenêtre de temps dans le Prefetch et Amcache pour retrouver les outils déposés.

Journaux du serveur web IIS

Outils