Defang et refang : traiter hxxp et les IOC sans erreur

Un IOC transmis sous la forme hxxps://portail[.]example/connexion n’est pas directement comparable à l’URL produite par un navigateur. Cette écriture, appelée defang, sert à réduire les activations accidentelles lors du partage. L’opération inverse, le refang, restaure une représentation exploitable pour l’analyse.

Le risque vient des conversions implicites. Un outil peut modifier l’indicateur, créer un lien cliquable ou déclencher une prévisualisation avant que l’analyste ait décidé de consulter la destination. Une procédure fiable traite séparément le texte reçu, la conversion et toute action réseau.

Conserver trois représentations distinctes

Gardez d’abord la valeur reçue, exactement comme elle apparaît dans le rapport ou le message. Ajoutez sa source, son emplacement dans le document et sa date de collecte. Cette version permet de vérifier si une erreur provient du producteur, de l’extraction ou de votre propre traitement.

Créez ensuite une valeur technique destinée à la validation et à la comparaison. Elle porte le type attendu, la recette appliquée et les éventuels avertissements. Enfin, générez une représentation d’affichage neutralisée pour les tickets, les notifications ou les documents destinés à être lus.

Ces trois formes peuvent se ressembler, mais elles remplissent des fonctions différentes. Copier celle d’affichage dans une règle de détection peut empêcher le matching. Afficher la valeur technique dans un outil qui transforme automatiquement les URL en liens peut déclencher des actions que le rédacteur n’avait pas prévues.

Reconnaître une convention avant de convertir

Les formes courantes comprennent hxxp, hxxps et [.] pour un point. D’autres rapports utilisent des parenthèses ou des mots. Ne supposez pas que tous les producteurs suivent la même convention, ni qu’une chaîne contenant des crochets est nécessairement neutralisée.

L’opération Defang URL de CyberChef illustre une implémentation avec des transformations et options définies. Pour votre pipeline, documentez de la même façon les formes acceptées. Une recette précise se teste ; une succession de remplacements improvisés ne fournit pas cette garantie.

Dans cet exemple fictif, le schéma et le séparateur du domaine suivent une convention identifiée :

reçu     : hxxps://portail[.]example/connexion
restauré : https://portail.example/connexion
affiché  : hxxps://portail[.]example/connexion

La conversion conserve le chemin. Elle ne décide pas si le site est malveillant, accessible ou même existant. Le domaine .example sert uniquement à l’illustration et ne représente aucun service à visiter.

Limiter les remplacements à leur position attendue

Un remplacement global de hxxp peut toucher une valeur dans un chemin ou un paramètre alors que seule la position du schéma devait changer. Un effacement global des crochets peut casser une URL IPv6. Repérez d’abord la structure attendue, puis appliquez les transformations reconnues.

Après conversion, utilisez un parseur adapté au type d’IOC. Une adresse IP, un domaine et une URL ne se valident pas avec la même expression régulière. Une URL relative ne devient pas absolue tant que sa base n’est pas connue ; ne lui attribuez pas un domaine par commodité.

Un échec de parsing doit arrêter l’export automatique et produire un état à examiner. Ne corrigez pas successivement la chaîne jusqu’à obtenir quelque chose que le parseur accepte. Cette pratique peut fabriquer un indicateur différent de celui publié.

Le guide de construction des pipelines IOC situe cette validation dans l’ingestion. La neutralisation, elle, reste une convention de représentation ; elle ne doit pas devenir une classification de menace.

Séparer le refang de toute action réseau

Une conversion de texte peut se faire sans requête DNS ni connexion HTTP. Gardez cette propriété dans vos outils : désactivez les prévisualisations sur les champs d’indicateurs et évitez les enrichissements automatiques avant les vérifications nécessaires.

Vérifiez notamment si l’URL contient un identifiant de destinataire, un jeton de connexion ou une ressource interne. Une soumission à un service externe peut révéler cette information ou entraîner une visite par son analyseur. Remplacer http par hxxp n’a retiré aucun de ces éléments.

Le guide sur l’analyse des URL confidentielles détaille cette décision de partage. Dans un ticket courant, montrez une version neutralisée et expurgée si nécessaire, tout en conservant la preuve complète dans l’emplacement autorisé par votre politique.

Décrire correctement les données dans les échanges structurés

Un format d’échange ne devine pas votre convention de présentation. Si vous utilisez STIX, la propriété defanged concerne les objets observables concernés par le modèle. La spécification STIX 2.1 la définit pour les Cyber-observable Objects, avec false comme valeur par défaut, et ne l’applique pas indistinctement à tous les objets.

Vérifiez donc l’objet réellement envoyé et les attentes du consommateur. Poser ce champ sur un objet Indicator qui ne le prévoit pas ne remplace pas une stratégie d’encodage correcte du pattern. Testez l’export avec le validateur et le système destinataire utilisés par votre équipe.

Lorsque vous échangez un simple CSV, ajoutez explicitement un type et un état de représentation plutôt que de demander au destinataire de les deviner. Un fichier mélangeant IP brutes, domaines neutralisés et URL partiellement restaurées doit être identifié comme tel avant import.

Tester les erreurs qui passent inaperçues

Préparez des cas positifs et négatifs à partir de conventions autorisées. Vérifiez une URL déjà exploitable, une URL neutralisée connue, une adresse IPv6 entre crochets et une chaîne ambiguë. Ajoutez les liens contenant des paramètres sensibles pour vérifier leur traitement à l’affichage.

Une seconde application de la même conversion ne doit pas continuer à modifier une valeur déjà traitée. Testez aussi le trajet complet : ingestion, validation, export et import dans un environnement d’essai. Un affichage correct dans le premier outil ne garantit pas que le second retrouvera le même indicateur.

Conservez les cas qui ont causé des incidents de parsing, avec des données fictives ou expurgées. Ils forment un corpus utile lors d’une mise à jour de bibliothèque. Mesurez séparément les entrées converties, rejetées et examinées manuellement ; les rejets silencieux cachent les pertes de renseignement.

Conclure sur la valeur réellement analysée

Le dossier doit permettre de relier l’indicateur publié à la valeur validée puis à la recherche réalisée. Notez toute transformation qui a changé sa représentation. Si une ambiguïté demeure, demandez une clarification au producteur avant de déployer une règle large.

Pour un domaine ou une IP publique validée, vous pouvez ouvrir un rapport IsMalicious comme étape distincte d’enrichissement. La conversion préalable n’a effectué aucune vérification de réputation. C’est cette séparation qui permet de partager un IOC lisible tout en gardant le contrôle sur son interprétation et son utilisation.