PrintNightmare et durcissement Print Spooler¶

CVE-2021-1675 / CVE-2021-34527 : PrintNightmare en 5 minutes¶

Le vecteur d'attaque à retenir¶

PrintNightmare repose sur un mélange toxique :

• une surface RPC exposée par le service Print Spooler
• la capacité d'ajouter ou de charger un driver d'impression
• des contrôles de privilèges insuffisants ou contournables selon le contexte

L'appel souvent cité est RpcAddPrinterDriverEx().

Dans les scénarios vulnérables, l'attaquant force ou détourne l'installation d'un driver via un chemin ou un répertoire de spool contrôlé.

Le résultat n'est pas juste un incident d'impression.

Le résultat peut être de l'exécution de code en SYSTEM.

Pourquoi c'était critique¶

Ce bug a fait très mal pour une raison simple :

un service historiquement banal s'exécutait avec des privilèges élevés.

Un utilisateur standard de domaine pouvait, dans certains cas, s'en servir pour obtenir davantage de privilèges qu'il n'aurait jamais dû en avoir.

Le sujet n'était donc pas seulement la disponibilité de l'impression.

Le sujet était la rupture de frontière de privilèges.

Sur un serveur sensible, et pire sur un DC, le risque devenait immédiatement structurel.

Timeline des correctifs : de juillet 2021 à l'état actuel¶

Le message opérationnel important :

on ne "sort" pas de PrintNightmare parce qu'un patch est installé.

On sort de PrintNightmare quand :

• le niveau de patch est correct
• le service Spooler est coupé là où il est inutile
• Point and Print est réellement restreint
• les serveurs autorisés sont explicitement définis

Ce que l'attaque vise vraiment dans votre architecture¶

Réflexe d'analyse¶

Quand vous voyez "PrintNightmare", ne partez pas d'abord sur le patch.

Partez sur ces trois questions :

1. où Spooler tourne-t-il encore ?
2. qui peut installer des drivers ?
3. quels serveurs Point and Print sont implicitement autorisés ?

Inventaire de l'exposition : qui fait tourner Spooler ?¶

La première question à poser¶

Avant toute GPO, mesurez l'exposition.

Vous devez savoir :

• quels DC font encore tourner Spooler
• quels serveurs d'infrastructure l'exécutent encore sans justification
• quels postes d'administration ont encore des pilotes ou files inutiles

L'erreur la plus fréquente est de traiter l'impression comme un "petit sujet annexe".

En réalité, c'est un service système qui ouvre une surface supplémentaire.

PowerShell : détecter les DC avec Spooler actif¶

Get-ADDomainController -Filter * | ForEach-Object {
    $svc = Get-Service -ComputerName $_.HostName -Name Spooler -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        DC = $_.HostName
        SpoolerStatus = $svc.Status
    }
}

Si ce tableau vous retourne autre chose que Stopped ou Disabled sur vos DC, vous avez déjà un axe de remédiation prioritaire.

Étendre l'inventaire au-delà des DC¶

Les DC sont le point rouge.

Mais ils ne sont pas la seule surface.

Il faut aussi classer les actifs en trois catégories :

Règle absolue pour les DC¶

Il n'y a pas d'ambiguïté utile ici.

Spooler désactivé sur tous les contrôleurs de domaine.

S'il existe une exception, elle doit être :

• documentée
• temporaire
• compensée par des contrôles supplémentaires

Et surtout, elle doit être challengée.

Un DC n'est pas un serveur d'impression d'appoint.

Script complémentaire : statut et mode de démarrage¶

$targets = Get-ADComputer -Filter { OperatingSystem -like "*Server*" } |
    Select-Object -ExpandProperty Name

foreach ($computer in $targets) {
    try {
        $service = Get-CimInstance -ClassName Win32_Service -ComputerName $computer `
            -Filter "Name='Spooler'"

        [PSCustomObject]@{
            ComputerName = $computer
            State        = $service.State
            StartMode    = $service.StartMode
            Status       = $service.Status
        }
    } catch {
        [PSCustomObject]@{
            ComputerName = $computer
            State        = "UNREACHABLE"
            StartMode    = "UNREACHABLE"
            Status       = $_.Exception.Message
        }
    }
}

Ce que vous cherchez dans les résultats¶

GPO de durcissement Print Spooler¶

Chemin GPMC exact¶

Le nœud à retenir est :

Computer Configuration
  > Policies
    > Administrative Templates
      > Printers

Le danger vient souvent d'un durcissement partiel.

On désactive une option.

On en oublie trois.

Et l'équipe pense que "le sujet est traité".

Les 5 paramètres critiques¶

Ce que chaque paramètre change réellement¶

Allow Print Spooler to accept client connections

Sur un DC, la valeur recommandée est Disabled.

Cela réduit l'exposition réseau du service.

Sur un serveur d'impression dédié, la décision est différente parce que le service existe pour servir des clients.

Point and Print Restrictions

C'est le paramètre qui évite qu'un utilisateur standard fasse installer n'importe quel pilote depuis n'importe quel serveur.

Activez-le avec une logique "admins only".

Package Point and Print - Approved servers

Ce paramètre transforme la posture.

Au lieu de faire confiance implicitement au réseau, vous faites confiance explicitement à une courte liste de serveurs d'impression approuvés.

Limits print driver installation to Administrators

Si vous n'activez pas ce réglage, vous laissez une voie trop large à l'installation de drivers.

Configure RPC listener settings

Réduisez la souplesse inutile.

Moins de canaux exposés signifie moins de surface de mouvement latéral.

Stratégie de déploiement recommandée¶

Pièges de mise en œuvre¶

Vérification locale après application¶

gpupdate /force
gpresult /r /scope computer

Get-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows NT\Printers" -ErrorAction SilentlyContinue
Get-Service -Name Spooler

Le but n'est pas seulement de voir la GPO "applied".

Le but est de vérifier :

• la valeur de registre écrite
• l'état du service
• le comportement réel d'installation de driver

Déploiement des imprimantes sans Spooler universel¶

GPP Printers : oui, mais sans Point and Print permissif¶

Le sujet n'est pas d'arrêter de déployer les imprimantes.

Le sujet est d'arrêter de les déployer n'importe comment.

Les GPP Printers restent utiles si :

• vous maîtrisez les serveurs sources
• vous savez quels pilotes sont autorisés
• vous n'ouvrez pas Point and Print à tout le monde

Le bon pattern :

1. serveurs d'impression dédiés
2. liste d'Approved servers
3. droits d'installation limités
4. ciblage GPP propre

Universal Print : alternative cloud¶

Quand l'objectif est de sortir de l'héritage des print servers classiques, Universal Print peut réduire la dépendance au modèle Spooler traditionnel côté serveur Windows.

Ce n'est pas une baguette magique.

Mais dans une architecture déjà orientée Entra ID / Intune, c'est une alternative crédible pour certains usages bureautiques.

Serveur d'impression dédié : architecture recommandée¶

Le compromis réaliste pour beaucoup d'entreprises reste :

• un serveur d'impression dédié
• aucun DC ni serveur critique polyvalent qui héberge Spooler
• un flux clair entre client, print server et imprimante

flowchart LR
    A[Client utilisateur] --> B[Serveur d'impression dédié]
    B --> C[Imprimante réseau]
    D[GPO Printers + Approved servers] --> A
    E[DC / serveurs critiques] -. Spooler désactivé .-> A

Pourquoi isoler le serveur d'impression¶

Le serveur d'impression dédié concentre le risque au bon endroit.

Il permet :

• une journalisation dédiée
• une liste de pilotes connue
• une maintenance ciblée
• un périmètre de durcissement clair

Il ne rend pas Spooler "sûr".

Il rend le risque confiné et administrable.

Matrice de décision simple¶

Audit et détection¶

Événements Windows à surveiller¶

Deux événements minimum doivent entrer dans votre routine :

• Event ID 316 dans PrintService/Admin pour les installations ou changements suspects de drivers
• Event ID 808 pour les erreurs de Spooler à corréler avec une activité inhabituelle

Ces événements ne racontent pas tout à eux seuls.

Mais ils donnent un point d'entrée rapide pour distinguer un incident banal d'impression d'un comportement anormal.

Script d'audit hebdomadaire des drivers installés¶

$servers = @("print01", "print02")

foreach ($server in $servers) {
    Invoke-Command -ComputerName $server -ScriptBlock {
        Get-PrinterDriver |
            Select-Object Name, Manufacturer, MajorVersion, DriverPath, InfPath |
            Sort-Object Manufacturer, Name
    } | Export-Csv -Path "C:\Temp\$server-printer-drivers.csv" -NoTypeInformation
}

Ce script n'est pas là pour être élégant.

Il est là pour produire un baseline diffable.

Si un pilote apparaît soudainement sans ticket, sans changement approuvé et sans fenêtre de maintenance, vous avez un signal.

Journal PowerShell rapide¶

Get-WinEvent -LogName "Microsoft-Windows-PrintService/Admin" -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Exemple KQL simplifié pour Sentinel / Defender¶

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType in ("DriverLoad", "ServiceInstalled", "RegistryValueSet")
| where AdditionalFields has_any ("Spooler", "Print", "RpcAddPrinterDriverEx", "PointAndPrint")
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName, AccountName, AdditionalFields
| order by Timestamp desc

Cette requête est volontairement simple.

Elle ne remplace pas une détection ingénierée.

Elle donne un point de départ pour voir remonter :

• des chargements de drivers
• des services liés à l'impression
• des traces associées à Point and Print

Routine de revue hebdomadaire¶

Ce qui transforme l'audit en valeur¶

L'audit ne sert à rien si personne ne sait quoi faire d'une anomalie.

Documentez une action simple :

1. geler l'installation de nouveaux pilotes
2. isoler le serveur ou le poste concerné si nécessaire
3. extraire la liste des pilotes et événements
4. comparer au baseline approuvé
5. corriger la GPO ou la configuration fautive