Déballer le réseau de zombies BADBOX avec Censys
Partager
Résumé : BADBOX est un réseau de zombies récemment découvert qui cible à la fois des appareils Android de marque et des appareils connus, souvent avec des logiciels malveillants qui ont pu être préinstallés en usine ou à un stade plus avancé de la chaîne d'approvisionnement. Plus de 190 000 appareils infectés ont été observés jusqu'à présent, y compris des modèles haut de gamme comme les téléviseurs QLED Yandex 4K. En utilisant Censys, j'ai identifié un certificat SSL/TLS suspect commun à l'infrastructure BADBOX, révélant cinq IP et de nombreux domaines, tous utilisant le même certificat et la même clé hôte SSH. Cela indique clairement qu'un seul acteur contrôle un environnement modélisé. L'ampleur et la nature furtive de BADBOX soulignent la nécessité de surveiller l'intégrité de la chaîne d'approvisionnement et le trafic réseau.
Je surveille cette menace émergente depuis un certain temps et, à première vue, il s'agit d'une énième campagne de logiciels malveillants pour Android. Le hic ? BADBOX est souvent intégré au micrologiciel, de sorte que les utilisateurs déballent de nouveaux appareils déjà compromis avant même qu'ils ne rejoignent un réseau. Les chercheurs de BitSight ont récemment mis en évidence le nombre considérable d'appareils communiquant avec les serveurs BADBOX, ce qui suggère une compromission complète de la chaîne d'approvisionnement qui va bien au-delà d'un incident typique de logiciel malveillant à chargement latéral. Ci-dessous, je vais vous expliquer comment j'ai utilisé Censys pour suivre le certificat en question et cartographier les IP et les domaines associés.
Cette échelle a piqué ma curiosité - en particulier la partie concernant un certificat commun qui a été repéré dans la nature. Armé de cette information sur le DN de l'émetteur du certificat, je me suis tourné vers la Censys Internet Intelligence Platform pour voir si je pouvais trouver d'autres preuves. Le DN de l'émetteur en question est : "C=65, ST=singapore, L=singapore, O=singapre, OU=sall, CN=saee" que j'ai converti en la requête de certificat suivante pour trouver le certificat exact utilisé par les opérateurs de BADBOX.
cert.parsed.issuer_dn="C=65, ST=singapore, L=singapore, O=singapre, OU=sall, CN=saee"
Un seul résultat correspondait à ces critères, ce qui indique clairement qu'une seule entité (ou un petit groupe) est à l'origine de l'injection généralisée de logiciels malveillants.
Cela m'a rendu curieux de savoir sur quels hôtes ce certificat est présenté, et j'ai donc accédé au menu pivot.
Ce pivot a produit la requête suivante, qui recherche l'empreinte SHA-256 du certificat.
host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623"
J'ai obtenu cinq adresses IP présentant ce certificat, toutes de Singapour et toutes de l'ASN d'Akamai. J'étais curieux de connaître les autres attributs qu'elles partagent et j'ai remarqué qu'elles ont toutes le port 22 SSH ouvert. Voici l'un de ces services.
Pour savoir si les mêmes clés d'hôte SSH sont utilisées, nous pouvons créer un rapport sur le champ "host.services.ssh.server_host_key.fingerprint_sha256" de l'empreinte digitale de la clé d'hôte. Pour créer un rapport, cliquez sur l'onglet "Report Builder".
Comme vous pouvez le voir, les cinq IP partagent la même clé d'hôte SSH, ce qui suggère que ces instances ont été modelées. En cliquant sur le tableau du rapport, je peux faire pivoter cette requête.
(host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623") et host.services.ssh.server_host_key.fingerprint_sha256 = "a885b892e4820b90fd05e45eda6bdd5983170cba6da23fb3610ed1a61726bd14"
Ce que je nettoierais pour obtenir la requête suivante:
host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623" or host.services.ssh.server_host_key.fingerprint_sha256 = "a885b892e4820b90fd05e45eda6bdd5983170cba6da23fb3610ed1a61726bd14"
Cependant, j'ai également été intéressé par le nombre de domaines qui présentent également ce certificat.
web.cert.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623"
Il est intéressant de noter que les 25 semblent utiliser nginx 1.20.1 sous CentOS. À partir de là, je pourrais soit créer une collection pour suivre tous ces indicateurs, soit simplement extraire les instances actuelles. Voici la requête finale avec tous les indicateurs ci-dessus
host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623" or host.services.ssh.server_host_key.fingerprint_sha256 = "a885b892e4820b90fd05e45eda6bdd5983170cba6da23fb3610ed1a61726bd14" or web.cert.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623"
Indicateurs
139.162.36[.]224 139.162.40[.]221 143.42.75[.]145 172.104.186[.]191 192.46.227[.]25 172.104.178[.]158
bluefish[.]work www.bluefish[.]work cool.hbmc[.]net giddy[.]cc www.giddy[.]cc jolted[.]vip joyfulxx[.]com msohu[.]shop www.msohu[.]shop mtcpuouo[.]com www.mtcpuouo[.]com pasiont[.]com sg100.idcloudhost[.]com www.yydsmb[.]com www.yydsmd[.]com ztword[.]com tvsnapp[.]com pixelscast[.]com swiftcode[.]work old.1ztop[.]work cast.jutux[.]work home.1ztop[.]work www.jolted[.]vip
A propos de l'auteur
