HTML smuggling : détection et réponse à incident

Les passerelles savent analyser les fichiers qu’elles voient. Le HTML smuggling change le modèle : le navigateur reçoit du HTML ou du JavaScript qui reconstruit la charge localement, souvent grâce aux objets Blob, Data URLs et API de téléchargement.

L’archive ou l’exécutable final ne traverse parfois jamais le réseau sous une forme reconnaissable. Il faut relier comportement de page, création de fichier et exécution endpoint.

Fonctionnement du HTML smuggling

MITRE ATT&CK référence HTML Smuggling sous T1027.006. Une campagne :

1. livre une pièce jointe HTML ou un lien ;
2. embarque ou récupère des fragments encodés ;
3. les décode dans le navigateur ;
4. crée un Blob ou une object URL ;
5. déclenche un téléchargement ;
6. pousse l’utilisateur à ouvrir le fichier.

La technique ne constitue que la livraison. L’exécution, la persistance et le C2 offrent encore des occasions de détection.

Signaux e-mail et réseau

Inspectez les pièces HTML pour blocs encodés volumineux, API Blob, object URLs, attributs download et JavaScript obfusqué. Les signatures aident, mais les attaquants changent variables et encodage.

Pour une livraison par lien, enrichissez URL d’entrée, redirections, âge, certificat et hébergement. Utilisez le scanner d’URL en environnement isolé et préservez chaque saut.

Une anomalie importante est l’apparition d’un fichier volumineux sans téléchargement réseau correspondant : elle suggère un assemblage local.

Corrélation endpoint

Collectez création de fichier par navigateur ou client e-mail, Mark-of-the-Web, extraction d’archive, lignée des processus et connexions. Les séquences fortes incluent :

• navigateur écrit une archive dans Téléchargements ;
• utilitaire extrait script, raccourci ou image disque ;
• utilisateur lance le contenu ;
• interpréteur ou binaire système démarre ;
• le nouveau processus contacte un domaine rare.

Corrélez sur une fenêtre courte avec utilisateur, appareil, URL et hash. Vérifiez l’artefact via la réputation de fichier et les destinations via l’intelligence domaine/IP.

Contrôles préventifs

Bloquez ou mettez en quarantaine les pièces HTML actives si leur usage métier est faible. Ouvrez le contenu risqué dans un navigateur isolé. Restreignez interpréteurs et processus enfants suspects par politique endpoint.

L’application control peut arrêter les binaires non signés dans les répertoires utilisateur. Limitez aussi les sorties réseau des interpréteurs et déployez une authentification résistante au phishing.

Réponse à incident

Lorsqu’une alerte se déclenche :

1. isolez l’endpoint si le fichier a été exécuté ;
2. conservez HTML original, charge décodée et historique ;
3. hashez chaque étape et documentez la lignée ;
4. collectez processus, persistance et réseau ;
5. bloquez domaines, URL, IP et hashes confirmés ;
6. recherchez pièces et artefacts identiques dans le parc.

Ne vous contentez pas de supprimer le fichier. Déterminez s’il a créé des enfants, une persistance ou volé des identifiants.

Faux positifs

Des applications légitimes utilisent Blob pour exporter rapports et documents côté client. Liez la détection à la réputation de l’origine, au type, à la taille, à l’action et à l’exécution suivante. Un portail finance approuvé exportant un PDF diffère d’un domaine récent assemblant une archive chiffrée.

Maintenez les exceptions par application et artefact attendus, avec propriétaire et expiration.

Métriques

Suivez pièces HTML bloquées, fichiers assemblés localement, détections avant exécution, incidents confirmés, délai d’isolement et destinataires associés. Identifiez la couche qui détecte en premier pour repérer les lacunes e-mail, navigateur ou endpoint.

Conclusion

Le HTML smuggling exploite l’écart entre analyse réseau et exécution navigateur. Fermez-le par corrélation page, fichier, processus et destination. Associez les preuves endpoint à la réputation des hashes à grande échelle afin que l’assemblage local ne masque ni la charge ni sa campagne.