Ce que les identifiants SIP révèlent des scanners

10/09/2026 :: fr :: SIP, honeypot, VoIP, scan, securite

Dans les deux premiers articles, j’ai présenté l’architecture du honeypot SIP, puis les grands comportements observés : sources très actives, sous-réseaux, durées d’observation, User-Agents et scans reconnaissables. Il restait un angle naturel à explorer : les identifiants placés dans les en-têtes From et To.

Ces valeurs ne sont pas des identités vérifiées. Sur Internet, un client SIP peut écrire presque n’importe quoi dans ces champs. Elles restent néanmoins intéressantes, car elles révèlent la stratégie d’un outil : tester une extension courante, parcourir une plage numérique, appeler une destination internationale ou simplement vérifier qu’un service SIP répond.

L’analyse porte sur la même table MariaDB que les articles précédents : 12 634 617 signatures, représentant 48 721 111 requêtes reconnues comme des messages SIP valides par Kamailio, entre le 30 novembre 2021 et le 9 septembre 2026. Une signature regroupe l’IP source, la méthode, le User-Agent, le From et le To; son compteur hits indique combien de fois cette combinaison a été reçue.

Presque tout ressemble à un numéro

La base contient 618 429 valeurs From distinctes et 2 440 955 valeurs To distinctes. Cette différence est logique : un même identifiant appelant peut être réutilisé pour essayer un très grand nombre de destinations.

Le résultat le plus marquant est la symétrie : près de 71 % des requêtes utilisent le même identifiant des deux côtés. Les couples les plus fréquents sont 100 -> 100, 101 -> 101, 1001 -> 1001, 201 -> 201 et 1000 -> 1000. Ce comportement est compatible avec l’énumération d’extensions SIP : l’outil place l’extension testée dans plusieurs parties de la requête et observe la réponse du serveur.

Dans ce graphique, les catégories numériques indiquent la longueur de l’identifiant To en nombre de chiffres ; texte regroupe les valeurs non purement numériques. Les 42 311 requêtes dont le To est absent sont exclues du graphique, mais incluses dans le total du corpus. Les extensions courtes de trois ou quatre chiffres représentent à elles seules 26 918 525 requêtes, soit 55,25 % de tout le corpus. À l’autre extrémité, les identifiants numériques de treize chiffres ou plus représentent 11 497 767 requêtes. Cette seconde famille correspond davantage à des variations de préfixes et à des tentatives d’appels qu’à la recherche d’une extension locale.

Les extensions les plus essayées

Les couples les plus fréquents sont très classiques : 100 -> 100 dépasse 341 000 requêtes, 101 -> 101 dépasse 284 000, puis viennent 1001, 201, 1000, 200, 2001 et 2000. Ce classement ne désigne pas un outil unique : ces valeurs figurent dans les habitudes de nombreux téléphones, PBX, scripts maison et dictionnaires.

La présence de ces extensions sur plusieurs milliers d’IP montre surtout que les scanners privilégient un petit vocabulaire commun. Les outils comme Nmap, SIPVicious ou SIPPTS permettent justement de parcourir des plages numériques, d’utiliser des dictionnaires ou de tester des valeurs de départ très courantes.

User-Agent et identifiant : un indice plus utile

Le croisement avec le User-Agent rend certains comportements plus lisibles. Pour les requêtes REGISTER dont le From numérique est identique au To, les familles les plus volumineuses sont les suivantes :

Les noms de téléphones ne prouvent pas que ces appareils ont réellement émis les paquets : le User-Agent est tout aussi facile à usurper que le From. Un scanner peut imiter un téléphone Polycom ou Avaya pour ressembler à un client ordinaire. À l’inverse, pplsip correspond au User-Agent par défaut de SIPPTS, et friendly-scanner est historiquement associé à SIPVicious. Ces deux chaînes sont donc beaucoup plus parlantes que PBX ou ims, même si elles restent modifiables.

Le couple pplsip + 125 671 identifiants essayés est cohérent avec des campagnes lancées avec SIPPTS ou avec un outil qui en reprend les valeurs par défaut. Le couple friendly-scanner + parcours de 166 390 identifiants correspond de son côté au mode opératoire de SIPVicious.

test, admin et cisco ne sont pas des signatures d’outil

Les identifiants textuels sont dominés par quelques mots très prévisibles. test apparaît comme From dans 4 029 133 requêtes, cisco dans 398 785, admin dans 71 023 et GLOVO dans 68 014.

Le détail de test montre pourquoi une attribution fondée sur ce seul champ serait fragile :

Ici, test sert surtout d’identité appelante générique pendant des campagnes qui balaient des centaines de milliers de destinations. Les User-Agents, les périodes et le nombre d’IP diffèrent suffisamment pour indiquer plusieurs implémentations ou plusieurs configurations.

Le cas cisco est similaire. Une campagne utilisant pplsip a produit 376 409 requêtes INVITE depuis seulement 31 IP vers 54 619 cibles. Certaines séries font varier méthodiquement les préfixes devant une même racine de numéro. Cela ressemble davantage à un générateur de routes ou à une campagne de fraude téléphonique qu’au comportement d’un équipement Cisco authentique.

GLOVO est encore plus concentré : 68 014 requêtes, quatre IP et 63 199 destinations, principalement avec un User-Agent imitant un Linksys SPA942 entre avril et mai 2023. Le mot est distinctif dans ce corpus, mais rien ne permet d’en déduire un lien avec l’entreprise du même nom.

Quelques signatures outillées

Certaines combinaisons sont plus parlantes qu’un identifiant isolé. Le couple nm -> nm2, presque toujours envoyé en OPTIONS sans User-Agent, représente 2 385 signatures, 4 275 requêtes et 2 350 IP distinctes. Il correspond à la forme de la sonde SIPOptions publiée dans nmap-service-probes, mais la base ne conserve pas assez d’en-têtes pour en faire une preuve formelle.

Même prudence avec pplsip. Ce User-Agent est la valeur par défaut de SIPPTS, et il apparaît avec 6 791 909 requêtes REGISTER dans le sous-ensemble From = To numérique, 383 IP et 125 671 identifiants essayés. C’est cohérent avec SIPPTS ou avec des outils qui reprennent ses valeurs par défaut, mais la chaîne reste configurable.

Ce que l’on peut conclure

Cette analyse fait apparaître trois profils principaux :

1. L’énumération d’extensions, dominée par les valeurs de trois ou quatre chiffres et par les couples symétriques From=To.
2. Le balayage de destinations téléphoniques, avec un From fixe comme test, cisco ou GLOVO et des dizaines ou centaines de milliers de To différents.
3. Le profilage de service, dont la sonde nm -> nm2 de Nmap est l’exemple le plus clairement attribuable.

Les identifiants SIP sont donc utiles pour reconnaître une intention et regrouper des campagnes. Ils sont moins fiables pour nommer un outil, sauf lorsqu’un ensemble de constantes correspond précisément à une sonde publiée. Une attribution sérieuse doit combiner autant que possible la méthode, le From, le To, le User-Agent, le Call-ID, le CSeq, la branche Via, l’ordre des en-têtes et le rythme d’émission.

La dernière partie de la série change d’échelle : au lieu de regarder ce que le honeypot sait seul, elle compare ses sources avec une liste externe spécialisée. C’est l’objet de l’article suivant : Comparer un honeypot SIP avec APIBAN.

Limites

• Le honeypot ne conserve que les messages que Kamailio a reconnus comme du SIP valide. Il ne mesure pas le fuzzing du transport, les sockets incorrectes ni les messages rejetés avant parsing.
• La base enregistre les noms d’utilisateur extraits des URI, pas l’intégralité des en-têtes SIP. Certaines empreintes utiles à l’attribution ont donc été perdues.
• Les champs From, To et User-Agent sont déclaratifs et facilement falsifiables.
• Les compteurs sont agrégés par signature. Une signature apparue une année peut continuer à accumuler des hits les années suivantes.
• Le VPS était hébergé chez OVHcloud. Un filtrage ou une protection en amont a pu modifier la population de paquets réellement arrivée au serveur.

Malgré ces limites, les données montrent bien la différence entre scanner un service SIP, énumérer ses extensions et tenter des routes téléphoniques. C’est précisément l’intérêt de conserver plusieurs attributs par requête : aucune valeur n’est décisive seule, mais leur combinaison finit par dessiner des comportements très reconnaissables.