En septembre 2021, le groupe de recherche en sécurité Cado Security a identifié une nouvelle vague d'infrastructure de phishing ciblant les clients de plusieurs banques européennes. La détection n'est pas venue d'un signalement de victime, ni d'une analyse de malware : elle est venue de la surveillance des journaux de transparence des certificats SSL. En examinant les certificats nouvellement émis pour des domaines contenant le nom de ces banques, les chercheurs ont identifié plusieurs dizaines de domaines de phishing dans les heures suivant leur configuration, bien avant que les premières campagnes d'emails ne soient lancées. Les journaux de transparence des certificats avaient fourni une fenêtre de détection précoce qui n'aurait pas été disponible autrement.
La transparence des certificats (Certificate Transparency, CT) est un standard introduit par Google en 2013 et devenu obligatoire pour la confiance du navigateur Chrome en 2018. Il exige que chaque certificat TLS émis par une autorité de certification reconnue soit enregistré dans un journal public et auditable avant de pouvoir être utilisé par les navigateurs. Ce mécanisme, conçu pour détecter la fraude dans l'émission de certificats, a eu un effet secondaire précieux pour les défenseurs : il a créé un registre public en temps quasi réel de chaque domaine qui obtient un certificat SSL.
Les journaux de transparence des certificats sont des bases de données append-only, accessibles publiquement, qui enregistrent chaque certificat soumis. Les autorités de certification majeures, dont Let's Encrypt, DigiCert, Sectigo, et Google Trust Services, soumettent leurs certificats à plusieurs journaux CT simultanément avant de les délivrer. Le navigateur vérifie que le certificat présenté est bien enregistré dans au moins deux journaux CT indépendants avant de lui accorder sa confiance.
Pour les défenseurs, les journaux CT fournissent plusieurs sources d'information exploitables. Le domaine couvert par le certificat révèle les nouvelles infrastructures que les acteurs de menace déploient. La date d'émission établit une ligne temporelle des préparatifs d'attaque. L'autorité de certification utilisée peut correspondre à des patterns connus pour certains acteurs. Et les métadonnées du certificat, notamment l'organisation déclarée et la localisation lorsqu'elles sont présentes, peuvent fournir des informations de contexte.
Des services comme crt.sh, maintenu par Sectigo, et le projet Certstream permettent d'accéder aux données des CT logs en temps quasi réel. Certstream diffuse un flux continu de tous les nouveaux certificats émis à travers les logs CT majeurs, permettant à des outils de surveillance de filtrer ce flux pour les domaines correspondant à des patterns d'intérêt, comme les domaines contenant le nom d'une organisation cible.
Au-delà de la détection des domaines de phishing, les CT logs fournissent des informations sur les patterns d'infrastructure des acteurs de menace. Un groupe qui enregistre systématiquement des domaines de phishing avec le même registraire, en utilisant la même autorité de certification, et avec des noms de domaines suivant un pattern de nommage cohérent, laisse une signature dans les CT logs qui peut être utilisée pour identifier de nouveaux domaines appartenant au même groupe avant même qu'ils ne soient activement utilisés dans des attaques.
L'analyse des certificats associés à des acteurs connus permet de développer des règles de détection spécifiques à leur infrastructure. Si un acteur utilise systématiquement des certificats Let's Encrypt pour ses domaines de phishing ciblant des institutions financières françaises et les enregistre via un registraire spécifique, ces caractéristiques combinées peuvent former la base d'une règle d'alerte qui détecte de nouveaux domaines appartenant probablement au même acteur, même si ces domaines n'ont pas encore été observés dans une campagne active.
La surveillance des certificats s'applique également à la propre infrastructure d'une organisation, dans le cadre de la gestion de la surface d'attaque externe. Les certificats émis pour les domaines et sous-domaines d'une organisation révèlent quelle infrastructure est configurée pour le trafic HTTPS, ce qui peut inclure des actifs non inventoriés par les équipes de sécurité.
Des développeurs qui configurent des environnements de développement ou de staging avec des certificats Let's Encrypt créent des entrées dans les CT logs qui révèlent des sous-domaines que l'équipe de sécurité peut ne pas avoir inventoriés. Ces sous-domaines, exposés à internet avec potentiellement des logiciels non mis à jour et des configurations non durcies, représentent des points d'entrée potentiels pour des attaquants qui surveillent les CT logs de l'organisation cible pour exactement ce type de découverte. La surveillance des CT logs pour les certificats émis pour les domaines propres de l'organisation est donc une mesure de découverte d'actifs qui complète l'inventaire interne avec une vue externe objective de l'infrastructure HTTPS déployée.
La mise en place d'une surveillance des CT logs pour détecter les domaines de phishing ciblant une organisation nécessite de définir les patterns de domaines à surveiller et de choisir les outils et services adaptés. Les patterns de détection incluent les variantes du nom de domaine principal (typosquatting, combosquatting), les noms de produits et de services de l'organisation, les noms des dirigeants lorsqu'ils sont utilisés comme identifiants de domaine, et tout autre terme de marque susceptible d'être usurpé dans une campagne de phishing.
Des services commerciaux de surveillance de marque intègrent la surveillance des CT logs dans un programme plus large couvrant également les réseaux sociaux, les marchés d'applications mobiles, et les sources de renseignement sur les menaces. Cette intégration est précieuse car un domaine de phishing détecté dans les CT logs peut être corrélé avec d'autres signaux, comme une mention sur un forum criminel ou un kit de phishing en vente sur Telegram, pour confirmer son usage malveillant et prioriser la réponse.
La rapidité de la surveillance est un facteur critique : les journaux CT sont mis à jour en temps quasi réel, et un domaine de phishing peut passer de l'émission du certificat à la première victime en quelques heures. Un système de surveillance qui traite les nouvelles entrées CT avec un délai de 24 heures manque une fraction significative de la fenêtre de détection précoce. La surveillance en temps quasi réel des CT logs est ce qui transforme cette source d'intelligence en un avantage défensif réel, permettant d'agir avant qu'une campagne de phishing ne produise ses premières victimes.
L'introduction de Let's Encrypt en 2015, offrant des certificats TLS gratuits et automatisés, a transformé le paysage des certificats SSL d'une manière qui a des implications directes pour la surveillance CT. Avant Let's Encrypt, l'obtention d'un certificat SSL représentait un coût et une friction qui limitaient son adoption par des acteurs malveillants pour de l'infrastructure de phishing à courte durée de vie. Après Let's Encrypt, n'importe quel domaine peut obtenir un certificat valide en quelques secondes, gratuitement et sans vérification d'identité.
Cette démocratisation des certificats a rendu le cadenas HTTPS sur un site de phishing un indicateur de sécurité trompeur pour les utilisateurs, qui ont été formés pendant des années à faire confiance aux sites avec HTTPS. Elle a également augmenté le volume de certificats dans les CT logs : Let's Encrypt émet plusieurs centaines de millions de certificats par an, ce qui signifie que la surveillance des CT logs doit traiter un flux continu de millions de nouvelles entrées quotidiennes.
Pour les défenseurs, cette évolution signifie que la surveillance des CT logs doit être automatisée et basée sur des règles de filtrage précises pour extraire les signaux pertinents du volume total. Un analiste humain qui tenterait de surveiller manuellement les CT logs pour les domaines pertinents serait rapidement submergé. L'automatisation avec des règles de correspondance bien calibrées, la déduplication des alertes, et une intégration avec des sources de contexte supplémentaires est la seule approche viable pour une surveillance CT efficace à grande échelle. Defendis gère cette complexité technique et livre des alertes enrichies et contextualisées plutôt qu'un flux brut de correspondances de domaines.
Les certificats wildcard (*.domaine.com) et les certificats multi-SAN (Subject Alternative Names) couvrant plusieurs domaines ou sous-domaines créent des particularités dans la surveillance des CT logs qui méritent attention. Un certificat wildcard *.domaine.com couvre tous les sous-domaines de premier niveau de domaine.com, ce qui signifie qu'une organisation peut déployer un nombre arbitraire de sous-domaines sans qu'aucun nouveau certificat n'apparaisse dans les CT logs pour chaque nouveau sous-domaine. La surveillance des CT logs de la propre infrastructure d'une organisation ne détectera donc pas les nouvelles applications web déployées sur des sous-domaines si un certificat wildcard existant est utilisé.
Pour la surveillance des domaines de phishing ciblant une organisation, les certificats wildcard créent une autre particularité : un attaquant qui obtient un certificat wildcard pour un domaine lookalike peut déployer de multiples sous-domaines de phishing sans que chaque nouveau sous-domaine génère une alerte CT distincte. Une alerte CT pour *.secure-defendis-portail.com indique la préparation d'une infrastructure potentiellement large, et doit déclencher une surveillance active de tous les sous-domaines actifs associés à ce certificat.
Ces caractéristiques des certificats wildcard et multi-SAN soulignent l'importance de combiner la surveillance des CT logs avec la surveillance DNS active : même si un nouveau sous-domaine n'apparaît pas dans les CT logs (parce qu'il utilise un certificat wildcard existant), son activation sera visible dans les données DNS passives lorsqu'il commencera à recevoir des requêtes. La combinaison de ces deux sources de surveillance offre une couverture complète que ni l'une ni l'autre seule ne peut fournir. C'est cette intégration de sources multiples que fournissent les plateformes spécialisées de surveillance de la surface d'attaque, plutôt que de demander aux équipes de sécurité d'intégrer manuellement des flux CT avec des données DNS passives.
Un journal de transparence des certificats (CT log) est une base de données append-only, publiquement accessible, dans laquelle les autorités de certification enregistrent les certificats qu'elles émettent. Les journaux CT sont opérés par plusieurs entités indépendantes pour assurer la redondance et l'indépendance : Google opère plusieurs journaux (Argon, Xenon), Cloudflare opère Nimbus, DigiCert opère Yeti, et Let's Encrypt opère Oak. Pour qu'un certificat soit reconnu par Chrome comme provenant d'un journal CT, il doit être enregistré dans au moins deux journaux de confiance. La liste des journaux de confiance est maintenue par les navigateurs, principalement Chrome et Safari.
Les attaquants ne peuvent pas éviter l'enregistrement dans les CT logs si leur certificat doit être reconnu par les navigateurs modernes : c'est une obligation technique du système de confiance des navigateurs. Certains attaquants utilisent des certificats auto-signés pour de l'infrastructure interne ou des outils qui ne nécessitent pas de validation par navigateur, mais pour du phishing ciblant des utilisateurs normaux, un certificat CT-logged est nécessaire pour avoir un cadenas HTTPS crédible. La seule "évasion" possible est d'utiliser des autorités de certification non reconnues par les principaux journaux CT, mais ces certificats génèrent des avertissements de sécurité qui rendent le phishing moins efficace.
Les journaux CT sont mis à jour en quasi temps réel : les certificats sont typiquement enregistrés dans les minutes suivant leur émission. Les services qui consomment les journaux CT via l'API ou via le projet Certstream (qui diffuse un flux en temps réel des nouvelles entrées CT) peuvent détecter un nouveau certificat dans les minutes suivant son émission. La rapidité de la détection dépend principalement de la fréquence de polling du service de surveillance et du temps de traitement des nouvelles entrées. Les meilleures implémentations atteignent des délais de détection de moins de 10 minutes entre l'émission du certificat et l'alerte à l'analyste.
Oui, et c'est l'une de ses valeurs les plus claires. En configurant des règles de surveillance pour les domaines contenant le nom de l'organisation, les noms de ses produits, les noms de ses dirigeants, ou ses identifiants de marque, un programme de surveillance CT peut détecter des campagnes de phishing préparées spécifiquement contre l'organisation et ses clients bien avant qu'elles ne soient lancées. Un attaquant qui prépare une campagne ciblée contre une organisation spécifique devra enregistrer des domaines qui font référence à cette organisation et obtenir des certificats pour ces domaines, laissant une trace détectable dans les CT logs avant même que le premier email de phishing ne soit envoyé.
La surveillance des CT logs est la composante technique d'une stratégie de protection de marque plus large qui doit également couvrir les réseaux sociaux, les stores d'applications mobiles, et les marchés criminels. Ces différentes dimensions de la protection de marque sont liées : un acteur qui prépare une campagne de phishing contre une marque spécifique peut être visible dans les CT logs (domaine de phishing en cours de création), sur les réseaux sociaux (faux comptes se préparant), et sur les forums criminels (partage de la campagne avec d'autres acteurs), souvent avec des délais différents entre ces signaux. La corrélation entre ces sources produit une intelligence plus riche et une détection plus fiable que n'importe laquelle de ces sources seule.
Les processus de réponse aux alertes CT doivent être calibrés pour fonctionner à la vitesse des phénomènes détectés. Un domaine de phishing peut être opérationnel en 30 à 60 minutes après l'émission de son certificat. Si le processus de réponse interne prend 24 heures pour aller du déclenchement de l'alerte à la notification du registraire, la grande majorité de la fenêtre d'exploitation du domaine sera écoulée avant que la réponse ne soit initiée. Les SLAs de réponse aux alertes CT doivent être définis en heures, pas en jours, et les autorisations nécessaires pour initier des demandes de takedown doivent être pré-établies pour éviter des délais organisationnels qui annulent l'avantage de la détection précoce.
La relation avec les équipes de confiance des registraires et des hébergeurs prioritaires est un actif opérationnel qui se construit dans le temps mais se matérialise au moment des incidents. Une organisation qui a établi une relation avec l'équipe de sécurité de son registraire principal et avec les équipes anti-abus des principaux hébergeurs cloud peut obtenir des takedowns en quelques heures plutôt qu'en plusieurs jours via les processus d'abuse reporting standards. Investir dans ces relations pendant les périodes calmes, par exemple en participant aux programmes de confiance des registraires ou en s'enregistrant comme organisation vérifiée auprès des plateformes, est une activité de préparation qui produit des résultats mesurables lors des incidents réels. Defendis peut accélérer ce processus grâce à ses partenariats établis avec les acteurs de l'écosystème de protection de marque.
Au-delà de la surveillance des CT logs pour détecter des domaines malveillants, la gestion des certificats de l'organisation elle-même est une composante de la sécurité qui bénéficie d'une visibilité améliorée via les CT logs. Les organisations avec de nombreux domaines et sous-domaines peuvent avoir des dizaines ou des centaines de certificats actifs, gérés par différentes équipes avec des cycles de renouvellement différents. Un certificat expiré sur un service en production génère des erreurs pour les utilisateurs et peut révéler des actifs qui n'ont pas été inventoriés par les équipes de sécurité.
La surveillance des CT logs pour les certificats émis par les propres autorités de certification de l'organisation ou pour ses propres domaines révèle des actifs qui n'ont pas été inventoriés, des certificats approchant de l'expiration, et des configurations inhabituelles qui pourraient indiquer une utilisation non autorisée de l'infrastructure de certification. Cette vue externe de son propre certificat landscape est un complément précieux aux inventaires internes, car elle révèle des actifs qui ont été créés sans suivre les procédures d'inventaire standard.
L'automatisation du renouvellement des certificats, via des outils comme Certbot (pour Let's Encrypt) ou ACME clients pour les CAs d'entreprise, réduit le risque d'expiration accidentelle mais crée de nouveaux défis de gouvernance : des certificats renouvellent automatiquement sans revue humaine, ce qui peut perpétuer des configurations incorrectes ou maintenir actifs des certificats pour des services qui devraient être désactivés. La surveillance des CT logs comme mécanisme d'audit externe des activités automatisées de gestion des certificats offre une détection supplémentaire des cas où l'automatisation produit des résultats inattendus. Defendis surveille la surface de certificats externe de votre organisation pour vous alerter des expirations imminentes et des configurations inhabituelles.
Chaque domaine de phishing ciblant votre marque obtient un certificat SSL avant d'être déployé. Chaque vulnérabilité exploitée activement dans vos systèmes est une fenêtre ouverte sur votre infrastructure. Defendis surveille les journaux de transparence des certificats pour détecter ces domaines malveillants en temps quasi réel, et corrèle l'intelligence sur les vulnérabilités avec votre profil d'exposition externe pour identifier les failles qui nécessitent une action immédiate. Les alertes arrivent avant que les attaquants ne frappent.
Réservez une démo pour voir comment Defendis surveille les certificats malveillants et les vulnérabilités exploitables pour votre organisation.
