Les données en ligne sur ZoomEye sont en mode écrasement et mise à jour, ce qui signifie que si les données ne sont pas numérisées lors de la deuxième numérisation, les données mises à jour ne seront pas écrasées. Les données sur ZoomEye conserveront les données de bannière obtenues lors de la première numérisation. Ce type de traçabilité des attaques malveillantes s'adapte en fait bien : les serveurs de téléchargement utilisés par des attaques malveillantes telles que Botnet, APT et d'autres attaques sont généralement directement désactivés et abandonnés après avoir été découverts. Bien sûr, certains sont des cibles de piratage, et. ils sont aussi très violents directement hors ligne ! Par conséquent, de nombreux sites d’attaque sont susceptibles d’être mis en cache en ligne par ZoomEye.
Bien sûr, les données fournies dans l'API d'historique ZoomEye peuvent être interrogées pour les données de bannière obtenues par chaque analyse, qu'elles soient couvertes ou non. Cependant, l'API d'historique ZoomEye actuellement fournie ne peut être interrogée que via IP et ne peut pas l'être. recherché via la correspondance de mots clés, nous devons donc l'utiliser en conjonction avec la recherche et le positionnement des données du cache en ligne ZoomEye mentionnés ci-dessus.
En fait, j'en ai parlé dans le Knowledge Planet "Black Technology" il y a quelques jours, mais il me reste juste à corriger un "bug" : l'IE 0day utilisé par Darkhotel cette fois devrait être CVE -2019-1367 au lieu de CVE-2020-0674 (Merci à 勋肉丁@奇安信 Bien entendu, ce "bug" n'affecte pas le thème de cet article).
Comme vous pouvez le voir sur l'image ci-dessus, nous avons utilisé les données en ligne ZoomEye pour localiser l'adresse IP d'un site d'attaque de flaque d'eau Darkhotel à ce moment-là. Nous avons utilisé le SDK ZoomEye pour interroger l'historique de cette IP :
╭─heige@404Team ~╰─$python Python 2.7.16 (default, Mar 15 2019, 21:13:51)[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)] on darwinType "help", "copyright", "credits" or "license" for more information. import zoomeye zm = zoomeye.ZoomEye(username="xxxxx", password="xxxx") zm.login() u'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpX...' data = zm.history_ip("202.x.x.x") 22
List. l'adresse IP incluse dans les données historiques de ZoomEye Le nœud temporel des données et le service de port correspondant
... >>>for i in data['data']: ... print(i['timestamp'],i['portinfo']['port']) ... (u'2020-01-28T10:58:02', 80) (u'2020-01-05T18:33:17', 80) (u'2019-11-25T05:27:58', 80) (u'2019-11-02T16:10:40', 80) (u'2019-10-31T11:39:02', 80) (u'2019-10-06T05:24:44', 80) (u'2019-08-02T09:52:27', 80) (u'2019-07-27T19:22:11', 80) (u'2019-05-18T10:38:59', 8181) (u'2019-05-02T19:37:20', 8181) (u'2019-05-01T00:48:05', 8009) (u'2019-04-09T16:29:58', 8181) (u'2019-03-24T20:46:31', 8181) (u'2018-05-18T18:22:21', 137) (u'2018-02-22T20:50:01', 8181) (u'2017-03-13T03:11:39', 8181) (u'2017-03-12T16:43:54', 8181) (u'2017-02-25T09:56:28', 137) (u'2016-11-01T00:22:30', 137) (u'2015-12-30T22:53:17', 8181) (u'2015-03-13T20:17:45', 8080) (u'2015-03-13T19:33:15', 21)
Jetons un coup d'œil au nœud temporel et au port de l'attaque du point d'eau implantée dans IE 0day :
>>> for i in data['data']: ... if "164.js" in i['raw_data']: ... print(i['timestamp'],i['portinfo']['port']) ... (u'2020-01-28T10:58:02', 80) (u'2020-01-05T18:33:17', 80) (u'2019-11-25T05:27:58', 80) (u'2019-11-02T16:10:40', 80) (u'2019-10-31T11:39:02', 80) (u'2019-10-06T05:24:44', 80)
Évidemment, la plage horaire approximative de cette attaque de point d'eau date du 2019-10-06 05:24:44 au 2020-01-28 10:58:02 De plus, cette IP n'est évidemment pas un VPS acheté par l'attaquant, mais attaque directement un site Web spécifique comme. un "point d'eau" pour les attaques, il est certain que ce site IP a été envahi dès le 06/10/2019 ! De la nature du site Web de cette flaque d’eau, nous pouvons essentiellement déduire que la cible principale de l’attaque de Darkhotel sont les utilisateurs qui visitent ce site Web !
Nous continuons à lister quels services de port ont été ouverts par cette IP en 2019 pour nous aider à analyser les points d'intrusion possibles :
>>> for i in data['data']: ... if "2019" in i['timestamp']: ... print(i['timestamp'],i['portinfo']['port'],i['portinfo']['service'],i['portinfo']['product']) ... (u'2019-11-25T05:27:58', 80, u'http', u'nginx') (u'2019-11-02T16:10:40', 80, u'http', u'nginx') (u'2019-10-31T11:39:02', 80, u'http', u'nginx') (u'2019-10-06T05:24:44', 80, u'http', u'nginx') (u'2019-08-02T09:52:27', 80, u'http', u'nginx') (u'2019-07-27T19:22:11', 80, u'http', u'nginx') (u'2019-05-18T10:38:59', 8181, u'http', u'Apache Tomcat/Coyote JSP engine') (u'2019-05-02T19:37:20', 8181, u'http', u'Apache Tomcat/Coyote JSP engine') (u'2019-05-01T00:48:05', 8009, u'ajp13', u'Apache Jserv') (u'2019-04-09T16:29:58', 8181, u'http', u'Apache httpd') (u'2019-03-24T20:46:31', 8181, u'http', u'Apache Tomcat/Coyote JSP engine')
Un environnement d'exploitation JSP très typique, le port 8009 a été ouvert en mai 2019, et l'arrière-plan Tomcat Gérer des problèmes tels que les mots de passe faibles ont toujours été un moyen de pénétration courant ~~
D'ailleurs, en fait, cette attaque impliquait également une autre adresse IP, car la bannière du port liée à l'IP a été écrasée en raison des mises à jour, j'ai donc effectué une recherche en ligne directement via ZoomEye, cela ne peut pas être recherché, mais si vous connaissez cette IP, vous pouvez également utiliser l'API de données historiques ZoomEye pour interroger les données historiques de cette IP. Je n'entrerai pas dans les détails ici.
Veuillez vous référer au rapport détaillé sur Poison Ivy (APT-C-01) https://ti.qianxin.com/uploads/2018/09/20/6f8ad451646c9eda1f75c5d31f39f668.pdf Nous nous concentrons directement sur
"Un nom de domaine de contrôle utilisé par l'organisation Poison Ivy pour contrôler et distribuer les charges utiles d'attaque" http://updateinfo.servegame.org"
"Téléchargez ensuite le payload depuis
hxxp://updateinfo.servegame.org/tiny1detvghrt.tmp
"
URL. Nous essayons d'abord de trouver l'IP correspondant à ce nom de domaine. Évidemment, nous n'avons pas gagné grand chose pour le moment :
╭─heige@404Team ~╰─$ping updateinfo.servegame.orgping: cannot resolve updateinfo.servegame.org: Unknown host
Dans le rapport de Qi Anxin, nous pouvons voir que le répertoire du service WEB du serveur de téléchargement utilisé peut être parcouru
Nous devrions donc pouvoir essayer directement de rechercher le nom de fichier "tiny1detvghrt.tmp", et bien sûr, nous l'avons trouvé
Ici, nous pouvons essentiellement confirmer que l'adresse IP correspondant à updateinfo.servegame.org est 165.227.220.223. Ensuite, nous commençons l'ancienne routine d'interrogation des données historiques :
>>> data = zm.history_ip("165.227.220.223") >>> 9 >>> for i in data['data']: ... print(i['timestamp'],i['portinfo']['port']) ... (u'2019-06-18T19:02:22', 22) (u'2018-09-02T08:13:58', 22) (u'2018-07-31T05:58:44', 22) (u'2018-05-20T00:55:48', 80) (u'2018-05-16T20:42:35', 22) (u'2018-04-08T07:53:00', 80) (u'2018-02-22T19:04:29', 22) (u'2017-11-21T19:09:14', 80) (u'2017-10-04T05:17:38', 80)
Continuez à regarder l'heure. intervalle de ce déploiement tiny1detvghrt.tmp :
>>> for i in data['data']: ... if "tiny1detvghrt.tmp" in i['raw_data']: ... print(i['timestamp'],i['portinfo']['port']) ... (u'2018-05-20T00:55:48', 80) (u'2018-04-08T07:53:00', 80) (u'2017-11-21T19:09:14', 80)
Au moins c'est OK Il est déterminé que l'attaque a été déployée depuis fin novembre 2017. Ensuite, il y a un autre nœud temporel avant ce nœud temporel 2017-10-04 05:17 : 38. Jetons un coup d'œil aux données de sa bannière :
>>> for i in data['data']: ... if "2017-10-04" in i['timestamp']: ... print(i['raw_data']) ... HTTP/1.1 200 OK Date: Tue, 03 Oct 2017 21:17:37 GMT Server: Apache Vary: Accept-Encoding Content-Length: 1757 Connection: close Content-Type: text/html;charset=UTF-8nbsp;HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <title>Index of /</title> <h2>Index of /</h2>
Name a> | Last modified a> | Size a> | Description a> | |
---|---|---|---|---|
doajksdlfsadk.tmp a> | 2017-09-15 08:21 | 4.9K | ||
doajksdlfsadk.tmp.1 a> | 2017-09-15 08:21 | 4.9K | ||
doajksdlrfadk.tmp a> | 2017-09-27 06:36 | 4.9K | ||
dvhrksdlfsadk.tmp a> | 2017-09-27 06:38 | 4.9K | ||
vfajksdlfsadk.tmp a> | 2017-09-27 06:37 | 4.9K | ||
wget-log a> | 2017-09-20 07:24 | 572 | ||
À partir de ces données de bannière, on peut conclure qu'il s'agit d'une flaque d'implant post-intrusion bien ciblée dans le premier cas. Il devrait s'agir d'un serveur contrôlable indépendamment. par l'attaquant. À partir de la méthode de dénomination et de la taille du fichier doajksdlfsadk.tmp (les deux font 4,9 Ko), on peut en déduire que ce moment devrait être l'exercice de combat réel avant que l'attaquant ne lance l'attaque. Ce serveur IP a donc été préparé pour ! l'attaque APT depuis le début, et a été abandonnée immédiatement après sa découverte !
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!