FileFix – Encore un tour de magie signé Microsoft : un fichier web soi-disant « local » qui exécute du code sans lever le moindre drapeau rouge. Spoiler : ce n’est pas un bug, c’est une fonctionnalité héritée.
🎬 Intro : Bienvenue dans l’ère des failles rétrocompatibles
Alors qu’on pensait l’époque des .hta
, .js
, et .vbs
révolue, une nouvelle attaque baptisée FileFix vient rappeler que l’enfer est pavé de bonnes intentions… et de moteurs de script obsolètes.
Cette fois-ci, les attaquants exploitent un trou béant dans la gestion des fichiers HTML enregistrés depuis un navigateur. Résultat ? Un script malveillant peut être exécuté sans le moindre avertissement de Windows, en échappant au Mark of the Web (MoTW), ce marqueur censé protéger les utilisateurs contre les contenus distants.
Oui, même en 2025, une simple double-clique sur un .html
téléchargé peut transformer un poste Windows en cible parfaite.
🧠 Mark of the Web : ce garde-fou que personne ne respecte
Le MoTW est un flux alternatif (Zone.Identifier
) ajouté par Windows à tout fichier téléchargé depuis Internet. Il indique sa provenance (zone Internet, Intranet, local, etc.) et déclenche :
- des boîtes d’alerte à l’ouverture de documents,
- l’affichage en mode protégé (ex: Word ou Excel),
- et un traitement spécial dans certains outils (ex: Windows Defender, SmartScreen).
Mais voici la subtilité : quand vous enregistrez une page web depuis un navigateur, le fichier HTML et ses dépendances peuvent perdre tout ou partie de ce marquage. Et devine quoi ? Windows les considère alors comme « locaux », même si le contenu exécutable est tout sauf inoffensif.
🧪 L’attaque FileFix, en 3 étapes dignes d’un magicien
- Création d’un fichier HTML malveillant contenant un simple appel
<script src="payload.jse">
. - Distribution du fichier via mail, site, ou outil collaboratif, avec une instruction classique : « ouvrez le fichier HTML en local ».
- Exécution automatique du fichier
.jse
(JScript Encoded) sans alerte MoTW, via un moteur de script rétro (Internet Explorer,wscript.exe
,mshta.exe
…).
Le système ne fait pas la différence entre une ressource locale légitime et un code distant déguisé en local. Bravo l’illusionniste.
🧪 Exemple simplifié du fichier HTML piégé :
<html> <head> <script src="payload.jse"></script> </head> <body> <h1>Bienvenue</h1> </body> </html>
Une fois enregistré localement puis ouvert, ce fichier exécute le fichier payload.jse
, même s’il provient d’Internet.
🧨 Pourquoi ça marche (encore) en 2025 ?
- Parce que les navigateurs modernes laissent passer : Chrome, Edge ou Firefox enregistrent les pages sans toujours propager le MoTW à chaque ressource incluse.
- Parce que Internet Explorer, bien que mort sur le papier, reste présent sous le capot (via
mshtml.dll
,mshta.exe
ou d’autres composants hérités). - Parce que le système de sécurité de Windows ne contrôle pas en profondeur ce genre d’exécution scriptée si elle semble « locale ».
- Parce que le format
.jse
(encodé, donc plus difficilement inspectable par les antivirus) n’est quasiment plus surveillé.
Et surtout, parce que la compatibilité ascendante chez Microsoft est souvent un cheval de Troie en costard.
🔒 Contre-mesures : ce que vous devriez avoir fait hier
🛡️ 1. Bloquez les scripts anciens
Interdisez l’exécution des .js
, .jse
, .vbs
, .hta
via les filtres d’email, les serveurs proxy et les règles GPO :
reg [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings] "Enabled"=dword:00000000
🔒 2. Appliquez des règles Applocker ou WDAC
Bloquez tous les exécutables suivants :
wscript.exe
cscript.exe
mshta.exe
powershell.exe
(avec discernement)
📦 3. Surveillez les fichiers HTML et MHT en pièces jointes
Ces formats sont parfaits pour camoufler du code actif.
📚 4. Formez vos utilisateurs
Expliquez que “ouvrir un fichier HTML local” n’est pas anodin. Même un .html
enregistré depuis un site de confiance peut devenir toxique.
📉 En conclusion : HTML ≠ inoffensif
Ce type d’attaque est sournois car il n’exploite aucune vulnérabilité de type buffer overflow ou zero-day noyée dans du code assembleur. Non, ici, l’attaque repose simplement sur une mauvaise gestion des zones de sécurité, une faiblesse d’héritage… et une confiance naïve dans la logique Windows.
FileFix ne casse pas la porte — il profite juste du fait qu’elle était déjà entrouverte.
📌 TL;DR pour RSSI pressé :
- Une page HTML locale peut exécuter du JScript sans alerte,
- Le MoTW ne protège pas les scripts inclus dans ce cas,
- L’attaque est triviale, furtive, et exploitable à grande échelle,
- Mettez à jour vos politiques de blocage, et sensibilisez vos équipes.
Voir aussi : bleeping computer