Nous luttons contre le phishing au mauvais niveau

J’ai chronométré un attaquant une fois. De l’enregistrement d’un domaine à sa délégation, sa certification et la diffusion d’une page de collecte d’informations d’identification en direct, il a fallu moins de 24 minutes, et 12 d’entre elles ont été passées à attendre sur des serveurs de noms.

Je reviens sans cesse sur ce chiffre, car il met discrètement en accusation la plupart de nos actions en matière de phishing. Nous bloquons les domaines. Nous les transmettons à nos passerelles, à nos filtres DNS et à nos plateformes de renseignements sur les menaces ; nous mesurons combien nous en avons bloqué, et nous communiquons le chiffre à un comité qui le trouve rassurant. Pendant ce temps, la chose que nous bloquons coûte à l’attaquant environ un dollar et vingt minutes à remplacer.

Le domaine est la chose la moins chère que possède l’adversaire. C’est également la seule chose que la plupart des programmes voient.

La couche sur laquelle l’attaquant subit réellement des coûts est le serveur. Les serveurs prennent de l’argent et du temps d’installation. Ils persistent au fil des campagnes car leur reconstruction est fastidieuse. Et surtout, un serveur est partagé, ce qui signifie qu’il exécute le reste des opérations avec lui. Trouvez le serveur et vous n’obtenez pas un seul indicateur. Vous obtenez la succession.

C’est précisément pourquoi les kits de phishing modernes sont conçus pour vous empêcher de les trouver.

Le mur et la fissure

Les kits qui comptent désormais sont des proxys d’adversaire au milieu. Plutôt que de servir une fausse page de connexion, ils relaient le trafic de la victime vers le véritable service de connexion Microsoft en temps réel, renvoient les vraies réponses et récupèrent les informations d’identification et le jeton de session au fur et à mesure de leur passage. La victime voit une véritable page, répond à une véritable invite multifactorielle et l’attaquant repart avec une session en direct. Microsoft a documenté une seule campagne de cette forme qui a touché plus de 10 000 organisations, et le modèle n’a fait que se banaliser depuis.

Mettez-en un derrière un réseau de diffusion de contenu et le serveur disparaît. C’est ce que j’ai rencontré le mois dernier. La transparence du certificat m’a montré le certificat du réseau, pas celui de l’origine. Le DNS passif a montré que le domaine n’avait jamais été résolu ailleurs. Les plates-formes d’analyse sur Internet sont revenues vides, ce que j’ai d’abord interprété comme une absence, puis compris comme un refus : l’origine a abandonné toute connexion qui ne présentait pas le nom d’hôte exact qu’elle attendait, en moins d’une demi-seconde, sans servir un octet.

Cette distinction mérite un instant, car c’est une erreur que j’ai vu commettre des analystes compétents. Un résultat nul d’une plate-forme d’analyse sur un serveur contrôlé par le nom d’hôte ne signifie pas qu’il n’y a rien. Cela signifie que vous avez frappé dans la mauvaise langue. Traiter ces deux choses de la même manière est la façon dont une chasse se termine prématurément avec tout le monde satisfait.

L’e-mail n’a pas non plus été d’une grande aide. Le leurre provenait d’une boîte aux lettres véritablement compromise dans une entreprise réelle et chaque contrôle d’authentification avait été réussi. Il n’y avait donc aucune adresse de l’attaquant dans le message. Il ne pouvait pas y en avoir.

Dix approches, dix impasses. Ce qui a finalement fonctionné, c’est un cookie que le propre serveur de l’attaquant avait remis à la victime.

Le mandataire qui signe son propre nom

Le mécanisme est simple, c’est probablement pour cela que je n’avais jamais pensé à le vérifier.

Lorsque le proxy relaie une connexion, Microsoft voit un client se connecter. Ce client n’est pas la victime. C’est le proxy, car le proxy est la chose qui établit la connexion. Et Microsoft, comme de nombreux services, définit un cookie enregistrant l’adresse d’où il a observé l’arrivée du client.

Le proxy fait alors ce qu’un proxy inverse transparent fait à moins que quelqu’un ne l’arrête. Il relaie la réponse à la victime, cookie et tout, car la réécriture des en-têtes de réponse est un travail que personne n’a pris la peine de configurer.

Ainsi, le navigateur de la victime reçoit un cookie estampillé de l’adresse IP du propre serveur relais de l’attaquant. Le mandataire inscrit son adresse de retour sur l’enveloppe et la remet à la personne qu’il vole.

Je l’ai trouvé en train de filtrer une capture déchiffrée pour les cookies définis par le site de phishing, et la valeur n’était ni l’adresse de Microsoft ni celle de mon propre bac à sable. Il appartenait à un petit revendeur d’hébergement du genre qui prend des cryptomonnaies.

Ce que j’ai fait ensuite compte plus que la découverte elle-même, et c’est la partie sur laquelle j’insisterais pour n’importe quelle équipe que je conseille. Je ne l’ai pas traité comme réglé. Un artefact est une piste, pas une conclusion, et le saut du premier au second est la façon dont la recherche est rétractée et comment les programmes de renseignement perdent la crédibilité qui les rend intéressants à financer.

J’ai passé l’heure suivante à essayer de détruire ma propre découverte. L’explication concurrente évidente était que le cookie avait capturé la sortie de mon environnement de détonation plutôt que celle de l’attaquant. J’ai donc examiné l’adresse elle-même : un revendeur de serveurs virtuels à petit budget, et non une route utilisée par un bac à sable commercial. Cela a affaibli l’alternative sans pour autant la fermer. Ce qui l’a clôturé, c’est la corroboration de directions que ma première observation n’aurait pas pu influencer, arrivant de manière indépendante et d’accord. Ce n’est qu’à ce moment-là que je me suis laissé écrire le mot origine.

S’ils n’avaient pas été d’accord, cela serait resté dans mes notes comme non vérifié, et je l’aurais publié de cette façon. Les résultats non prouvés restent des résultats. L’analyste suivant tire davantage parti d’une incertitude déclarée que d’une supposition sûre.

Un email, puis tout le domaine

C’est ce que vous apporte le travail au niveau de la couche serveur, et c’est tout l’argument pour le faire.

L’adresse du serveur menait à un deuxième domaine qui y pointait discrètement depuis des mois sans jamais proposer de contenu, ce qui conduisait à son tour à un bureau d’enregistrement que l’opérateur n’utilisait nulle part ailleurs. La résolution des domaines restants les a regroupés sur une poignée de machines. Et deux de ces machines transportaient des domaines appartenant à des locataires d’identité cloud distincts que l’opérateur s’était donné beaucoup de mal pour séparer.

C’est ce qui a marqué le tournant de l’affaire. Ces locataires n’avaient aucune relation visible les uns avec les autres. Énumérer l’un ou l’autre n’aurait jamais révélé l’autre. Mais l’opérateur avait économisé sur l’hébergement, et l’infrastructure partagée a révélé ce que cachait une identité compartimentée.

Un e-mail de phishing signalé est devenu un ensemble cartographié de dizaines de domaines similaires se faisant passer pour de vrais fabricants, agences de placement de personnel et transporteurs de déchets, assemblés patiemment pendant six mois pour soutenir la fraude sur facture contre leurs clients. Rien de tout cela n’était visible depuis le domaine. Tout cela était visible depuis le serveur.

Je n’aurais rien atteint en bloquant ce qui coûte un dollar.

Signalez le même fait à votre propre locataire

La moitié de ce qui compte le plus pour quiconque gère un programme de sécurité n’est pas la technique de recherche. C’est l’inversion, et cela ne dépend pas de la négligence de l’attaquant.

Si le proxy est ce que Microsoft voit, alors le proxy est ce que voient vos journaux. Lorsqu’un de vos collaborateurs est victime d’un phishing via l’un de ces kits, la connexion réussie enregistrée dans votre locataire porte l’adresse du relais, et non celle de votre employé. Il s’agit d’un événement détectable, et c’est l’un des rares signaux fiables que vous recevez d’une attaque qui autrement laisserait vos contrôles en vert. C’est important parce que le contrôle préventif sur lequel la plupart d’entre nous comptent n’arrête pas cela : une analyse indépendante a révélé que la grande majorité des comptes compromis par ces kits avaient déjà activé l’authentification multifacteur.

Deux choses déterminent si cette détection fonctionne réellement. La première concerne les gammes de fournisseurs d’hébergement et de serveurs virtuels, car ce sont les réseaux à partir desquels votre personnel n’a pas à se connecter et où vivent ces relais. La seconde consiste à se rappeler que le jeton est persistant, car le kit clique sur l’invite qui maintient la session en vie, de sorte que l’activité continue de l’attaquant apparaît comme des événements d’actualisation plutôt que de nouvelles connexions. Une chasse qui interroge uniquement les connexions interactives trouvera le moment de compromis et manquera tout ce qui a suivi. J’ai vu cela se produire.

Et lorsque vous en trouvez un, l’ordre de réponse n’est pas négociable. L’attaquant détient une session, pas un mot de passe. Révoquez d’abord les sessions et réinitialisez ensuite les informations d’identification. Inversé, vous n’avez rien accompli et l’intrus continue de travailler alors que tout le monde croit que l’incident est clos.

J’ai publié la description technique complète de cette affaire, ainsi que les indicateurs et les règles de détection, dans un référentiel public pour tous ceux qui souhaitent examiner eux-mêmes les preuves. Je préférerais que d’autres personnes testent cela plutôt que de me croire sur parole.

Ce que je vous demanderais d’en retenir n’est pas la solution. Le blocage de domaines sera toujours considéré comme un progrès, car le nombre augmente et le reporting est facile. Mais nous consacrons nos efforts à ce que possède l’adversaire le moins cher. C’est sur le serveur que se situent leurs coûts. C’est là que devrait se trouver le nôtre aussi.