Entpacken des BADBOX-Botnetzes mit Censys
Teilen Sie
Zusammenfassung: BADBOX ist ein neu entdecktes Botnet, das sowohl auf markenfremde als auch auf bekannte Android-Geräte abzielt - häufig mit Malware, die möglicherweise bereits ab Werk oder in der Lieferkette vorinstalliert war. Bislang wurden über 190.000 infizierte Geräte beobachtet, darunter auch höherwertige Modelle wie Yandex 4K QLED TVs. Mithilfe von Censys habe ich ein verdächtiges SSL/TLS-Zertifikat identifiziert, das der BADBOX-Infrastruktur gemeinsam ist und fünf IPs und zahlreiche Domänen offenbart, die alle dasselbe Zertifikat und denselben SSH-Hostschlüssel verwenden. Dies deutet stark darauf hin, dass ein einziger Akteur eine vordefinierte Umgebung kontrolliert. Der schiere Umfang und die Heimlichkeit von BADBOX unterstreichen die Notwendigkeit, die Integrität der Lieferkette und den Netzwerkverkehr zu überwachen.
Ich beobachte diese aufkommende Bedrohung schon seit einer Weile, und oberflächlich betrachtet klingt sie wie eine weitere Android-Malware-Kampagne. Der Clou? BADBOX ist oft in die Firmware integriert, so dass die Leute neue Geräte auspacken, die bereits kompromittiert sind, bevor sie überhaupt einem Netzwerk beitreten. Forscher von BitSight haben vor kurzem die große Anzahl von Geräten hervorgehoben, die mit BADBOX-Servern kommunizieren, was darauf hindeutet, dass es sich um eine umfassende Kompromittierung der Lieferkette handelt, die weit über einen typischen Sideloaded-Malware-Vorfall hinausgeht. Im Folgenden erkläre ich Ihnen, wie ich Censys verwendet habe, um das fragliche Zertifikat aufzuspüren und die zugehörigen IPs und Domänen zu ermitteln.
Diese Skala machte mich neugierig - vor allem der Teil über ein gemeinsames Zertifikat, das in freier Wildbahn gesichtet wurde. Mit diesen Informationen über die Aussteller-DN des Zertifikats wandte ich mich an die Internet Intelligence PlatformCensys , um zu sehen, ob ich weitere Beweise aufspüren konnte. Die fragliche Aussteller-DN lautet: "C=65, ST=singapore, L=singapore, O=singapre, OU=sall, CN=saee", die ich in die folgende Zertifikatsabfrage umgewandelt habe, um das genaue von den BADBOX-Betreibern verwendete Zertifikat zu finden.
cert.parsed.issuer_dn="C=65, ST=singapur, L=singapur, O=singapre, OU=sall, CN=saee"
Es gab ein einziges Ergebnis, das diesen Kriterien entsprach, was ein deutliches Indiz dafür ist, dass eine einzelne Einheit (oder eine kleine Gruppe) hinter der weit verbreiteten Malware-Injektion steckt.
Das machte mich neugierig, auf welchen Hosts dieses Zertifikat ausgestellt wird, und so rief ich das Pivot-Menü auf.
Dieser Pivot ergab die folgende Abfrage, die nach dem SHA-256-Fingerabdruck des Zertifikats sucht.
host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623"
Dies ergab fünf IP-Adressen, die dieses Zertifikat präsentieren, alle aus Singapur und alle aus dem Akamai ASN. Ich war neugierig, welche anderen Attribute sie gemeinsam haben, und stellte fest, dass sie alle Port 22 SSH geöffnet haben. Hier ist einer dieser Dienste.
Um festzustellen, ob dieselben SSH-Host-Schlüssel verwendet werden, können wir einen Bericht über das Feld "host.services.ssh.server_host_key.fingerprint_sha256" des Host-Schlüssels erstellen. Um einen Bericht zu erstellen, klicken Sie auf die Registerkarte "Report Builder".
Wie Sie sehen können, haben alle fünf IPs denselben SSH-Host-Schlüssel, was darauf hindeutet, dass diese Instanzen nach einem Muster erstellt wurden. Wenn ich auf die Tabelle des Berichts klicke, kann ich in diese Abfrage hineinpivotieren.
(host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623") und host.services.ssh.server_host_key.fingerprint_sha256 = "a885b892e4820b90fd05e45eda6bdd5983170cba6da23fb3610ed1a61726bd14"
Ich würde die Abfrage wie folgt bereinigen:
host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623" or host.services.ssh.server_host_key.fingerprint_sha256 = "a885b892e4820b90fd05e45eda6bdd5983170cba6da23fb3610ed1a61726bd14"
Mich interessierte aber auch die Anzahl der Domains, die dieses Zertifikat ebenfalls aufweisen.
web.cert.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623"
Interessanterweise scheinen alle 25 nginx 1.20.1 unter CentOS zu verwenden. Von hier aus könnte ich entweder eine Sammlung erstellen, um alle diese Indikatoren zu verfolgen, oder einfach die aktuellen Instanzen extrahieren. Nachfolgend finden Sie die endgültige Abfrage mit allen oben genannten Indikatoren
host.services.tls.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623" or host.services.ssh.server_host_key.fingerprint_sha256 = "a885b892e4820b90fd05e45eda6bdd5983170cba6da23fb3610ed1a61726bd14" or web.cert.fingerprint_sha256 = "61609d67762922a390bf4c5ccc2b5ed43c1980a6777a0152e9a49c5b96d0d623"
Indikatoren
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 gerüttelt[.]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.jutux[.]vip
Über den Autor
