J’ai rencontré sur quelques serveurs des messages d’erreurs suite à des tentatives de traitement de scripts VBS, comme quoi le système était incapable de trouver le moteur VBScript : Can’t find script engine « VBScript » for script … étant donné que VBS est utilisé pour des générer des indicateurs, sans le moteur de script il n’y avait donc aucune remontée d’informations.
Le moteur VBS est une vulgaire librairie située dans le répertoire C:\Windows\System32 :
Ensuite, une clef de registre bien planquée permet de faire le lien entre cette DLL et le système ; c’est celle-ci qui sera appelée par Windows lorsqu’un script VBS sera exécuté. Cette clef de registre est la suivante : HKCR\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32 et c’est sa valeur par défaut qui contient le chemin vers la DLL.
Certains programmes – principalement des antivirus – remplacent la valeur par un chemin vers une autre DLL, qui leur permet d’exécuter des scripts VBS mais qui communiquent avec l’antivirus afin de détecter du code malveillant ; ce qui était exactement mon cas :
Seulement, en allant dans le repértoire de cette DLL, elle n’y était pas, d’où le message d’erreur donné plus haut. Il y avait donc trois solutions ou workarounds possibles :
- Réinstaller l’antivirus pour forcer ce dernier à réécrire tous ses fichiers proprement et à recopier la DLL ; ou à défaut copier la DLL d’un serveur qui la possède.
- Modifier la clef de registre pour reprendre sa valeur originale.
- Copier la DLL d’origine et la renommer pour correspondre au nom donné dans la base de registre.
D’emblée, la solution 2 n’est pas envisageable car cela serait trop facile pour un virus ou code malveillant de modifier la clef de registre afin de bypasser les contrôles de l’AV sur les scripts VBS. Même en tant qu’administrateur local de la machine et en ayant shunté l’AV, il m’a été impossible de modifier la valeur dans la clef, ni même de modifier les autorisations sur celles-ci, que ce soit directement ou via un fichier .reg ; la solution 3 fonctionne mais n’est pas la plus sécurisante car de ce fait, les scripts VBS ne sont pas contrôlés par l’antivirus.
J’ai donc choisi la première solution : la réinstallation. Une simple copie de la DLL d’un autre serveur aurait pu suffire mais après avoir comparé les répertoires des AV entre le serveur posant problème et un autre sain, j’ai constaté de belles différences, preuve que l’AV n’avait pas correctement été déployé et que l’installation a été d’une manière ou d’une autre avortée.
Une fois la réinstallation de l’AV effectuée, la DLL était en effet visible dans le répertoire et il m’a été possible d’appeler des scripts VBS sans message d’erreur.