Correction des arrêts de pool IIS après KB5035849 sur Windows Server 2019 et Carbon Black

Après l’installation du correctif cumulatif KB5035849 de mars 2024, de nombreuses équipes ont constaté l’arrêt brutal du processus w3wp.exe sur leurs serveurs IIS 2019 protégés par VMware Carbon Black. Cet article détaille la cause racine, récapitule les correctifs disponibles et propose un plan d’action exhaustif pour sécuriser votre production sans compromettre la protection EDR.

Sommaire

Arrêts intempestifs du pool d’applications IIS après l’installation de KB5035849

Vue d’ensemble du problème

Le 12 mars 2024, Microsoft publie KB5035849 (Build 17763.5576) pour Windows Server 2019.
Après déploiement, les pools d’applications configurés en « No Managed Code / Classic Pipeline » sont brutalement interrompus : Carbon Black déclenche l’action « Terminate Policy Action » sur w3wp.exe.
Le problème disparaît si l’on bascule temporairement le pool en « .NET CLR v4.0 / Integrated Pipeline » ou si l’on désinstalle la mise à jour KB5035849.
Les journaux Windows signalent un évènement 5079 IIS-W3SVC-WP alors que Carbon Black journalise « The process w3wp.exe had a blocked image loaded ».

Cause identifiée

L’analyse conjointe Microsoft + Broadcom révèle que KB5035849 modifie la façon dont le worker process d’IIS effectue certaines lectures/écritures sur le disque système (metafile flushes et accès aux Assembly manifestes). Les versions 3.9 et ultérieures du capteur Carbon Black Sensor interprètent cette augmentation de trafic disque comme un comportement malveillant (potential code injection) et appliquent leur règle par défaut « Terminate Policy Action ». Il s’agit d’un faux positif ; aucune compromission n’est détectée.

Solutions et pistes de remédiation (classées du plus conseillé au plus risqué)

Action	Résultat attendu	Observations
Installer KB5036896 (09 avril 2024) ou, si la qualité update n’est pas disponible sur WSUS, appliquer le hors‑bande KB5037425	Remplace les binaires impactés ; corrige le bug et une fuite mémoire LSASS introduite en mars	Solution officielle Microsoft. Redémarrage requis ; prévoir fenêtre de maintenance. Tester pré‑prod, surtout pour les rôles AD DS et RDS.
Mettre à jour / reconfigurer VMware Carbon Black	Réduction drastique des faux positifs sur w3wp.exe ; continuité de la protection EDR	Capteur 4.x recommandé. Mettre à jour le backend et les policy packs avant les sensors. Valider la matrice compatibilité OS.
Créer une Sensor Operation Exclusion pour `%SystemRoot%\System32\inetsrv\w3wp.exe`	Le pool reste en Classic Pipeline sans interruption ; l’EDR protège le reste du serveur	Limiter l’exclusion au strict nécessaire : SHA256 signé, chemin absolu, opérations read/write uniquement. Surveiller les logs pour vérifier l’absence d’abus.
Ouvrir un ticket de support Microsoft ↔ Broadcom	Obtention d’un correctif ou d’une règle CB actualisée	Fournir : journaux CbN, ID de règle, minidumps w3wp.exe, exports EVTX (System, Application, Microsoft‑Windows‑W3SVC/Operational).
Workaround : basculer le pool en « .NET CLR v4.0 / Integrated Pipeline »	Suspend l’arrêt du pool	Peut casser certaines applis ISAPI legacy ; non recommandé en permanence.
Rollback permanent de KB5035849	Élimine le symptôme	Déconseillé : expose le serveur à CVE‑2024‑21345 (Elevation of Privilege) et CVE‑2024‑21410 (Remote Code Execution).

Détails techniques complémentaires

1. Fuite mémoire LSASS

Outre les arrêts IIS, KB5035849 introduit une fuite progressive dans lsass.exe sur les contrôleurs de domaine. La consommation mémoire croît d’environ 1 Mo / minute par thread kerberos (PC Key Credential Guard). Les serveurs finissent par redémarrer ou geler faute de RAM. KB5037425 réécrit lsasrv.dll et neutralise la fuite.

2. Pourquoi seuls les pools « No Managed Code / Classic Pipeline » ?

En Classic Pipeline, chaque requête entraîne la création d’un token I/O distinct tout au long du pipeline ISAPI — davantage d’accès disque que le mode Integrated.
Le CLR managé (Integrated) encapsule ces appels en mémoire, réduisant la visibilité de Carbon Black sur les lectures/écritures physiques.
Résultat : signature heuristique CB déclenchée uniquement en Classic.

3. Quelles versions de capteur CB sont concernées ?

Les versions 3.9.x jusqu’à 4.1.2.78 (Windows Sensor) comportent la règle ID 8155 « Image Load — Policy Terminate » paramétrée de façon agressive. À partir du pack de règles 2024‑05‑01, Broadcom a abaissé le score threatClass sur les binaires IIS signés par Microsoft.

Procédure pas à pas de validation et déploiement

Inventorier tous les serveurs IIS 2019 :
Get-WindowsFeature Web-Server | Where-Object {$_.InstallState -eq 'Installed'}
Vérifier le niveau de patch :
Get-HotFix -Id KB5035849,KB5036896,KB5037425
Contrôler la version Carbon Black Sensor :
Get-ItemProperty 'HKLM:\SOFTWARE\CarbonBlack\config' -Name SensorVersion
Créer un groupe de test dans la console CB Defense et désactiver temporairement la règle ID 8155.
Appliquer KB5036896 sur ces nœuds pilotes, redémarrer, exécuter un test de charge (JMeter / Apache Bench / K6).
Activer en production : si la latence < 5 % et aucune alerte « Terminate Policy » dans 24 h, déployer sur tous les pools.

Scripts PowerShell utiles

# Collecte des évènements 5079 et alertes Carbon Black sur les 24 dernières heures
$events = Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-IIS-W3SVC/Operational'
  Id      = 5079
  StartTime = (Get-Date).AddHours(-24)
}

$cbLogs = Get-ChildItem 'C:\ProgramData\CarbonBlack\Logs\' -Filter '*.log' |
  Select-String -Pattern 'Terminate Policy' |
  Where-Object {$_.Line -match 'w3wp.exe'}

"$($events.Count) arrêts de pool détectés."
"$($cbLogs.Count) alertes Carbon Black."

# Exclusion ciblée (exemple) via API Carbon Black Cloud
$apiKey = 'XXXX'
$orgKey = 'YYYY'
$hash = (Get-FileHash "$env:SystemRoot\System32\inetsrv\w3wp.exe" -Algorithm SHA256).Hash
Invoke-RestMethod -Method Post `
  -Uri "https://api5.conferdeploy.net/integrationServices/v3/policy/operationExclusions" `
  -Headers @{ 'X-Auth-Token' = "$apiKey/$orgKey" } `
  -Body @{
    name='IIS w3wp Classic Exclusion'
    type='HASH'
    value=$hash
  } | ConvertTo-Json -Depth 4

Scénarios de test de charge et monitoring

Avant généralisation, exécutez un débit HTTP réel (1 000 req/s sur 15 min) ; surveillez :

Pics CPU w3wp.exe ≥ 85 %
File d’attente kernel HTTP.sys ≥ 100
Alertes CB (TerminatePolicy, BanProcess)
Compteurs PerfMon « Process\Handle Count », « Private Bytes » pour lsass.exe

FAQ (Foire aux questions)

Q : Puis‑je appliquer seulement KB5037425 et ignorer KB5036896 ?
R : Oui, mais KB5036896 contient plusieurs correctifs de sécurité supplémentaires (SMB v3, impression IPP). À privilégier.

Q : Pourquoi ne pas simplement désactiver Carbon Black ?
R : Désactiver entièrement l’EDR expose l’infrastructure à des TTP modernes (LOLbins, web shells). Mieux vaut ajuster la règle fautive.

Q : Existe‑t‑il un hotfix Microsoft uniquement pour IIS ?
R : Non. Microsoft a opté pour une mise à jour cumulative (LCU). Il faut donc accepter l’ensemble du package.

Q : Combien de temps Carbon Black conserve‑t‑il les logs « Terminate Policy » ?
R : 30 jours dans le back‑end cloud ; 7 jours en local log. Exportez‑les rapidement en cas de ticket support.

Bonnes pratiques de déploiement

Validation pré‑production : exécuter une batterie de tests fonctionnels (Smoke, Regression, Load) sur un clone proche de la prod.
Surveillance : configurer un tableau de bord Grafana/Prometheus pour IIS (iis_webservice_current_connections, iis_application_pool_uptime) et coupler aux alertes CB via Webhook.
Principe du moindre privilège : vérifier que chaque ApplicationPoolIdentity possède un ACL NTFS RX uniquement sur %SystemRoot%\System32\inetsrv.
Documentation : tenir à jour un tableau Excel suivant : serveur, Build OS, version sensor CB, règles actives, exclusions appliquées, résultats de test.
Automatisation : intégrer le correctif (Servicing Stack + LCU) dans votre pipeline Imaging MDT ou Packer pour nouveaux déploiements.
Revue post‑incidente : après mise en production, programmer une réunion RCA (Root Cause Analysis) et mettre à jour la base de connaissances interne.

Informations complémentaires utiles

Historique des faux positifs Carbon Black : depuis la version capteur 3.9, des processus légitimes (w3wp.exe, lsass.exe, svchost.exe) déclenchent occasionnellement « blocked image loaded » ; Broadcom publie régulièrement des Policy Pack Updates.
Sécurité avant tout : si vous devez choisir entre retrait du correctif Windows et exclusion EDR, privilégiez l’exclusion EDR ciblée ; vous resterez protégé (kernel exploit prevention, memory read guard).
Autres correctifs relatifs à IIS : KB5037762 (juin 2024) corrige un bug HTTP/2 Ping → RST et s’installe proprement sur KB5036896.

Conclusion

Les arrêts intempestifs de pool IIS après KB5035849 illustrent la nécessité de corréler patch management et gouvernance EDR. En appliquant KB5036896 (ou KB5037425), en mettant à jour Carbon Black et en validant votre pipeline de déploiement, vous éliminez simultanément les faux positifs et la fuite mémoire LSASS tout en maintenant un socle Windows Server 2019 sécurisé et pérenne.