Linux/NyaDrop - a linux MIPS IoT bad news

2016/12/27 0 Comment 2,086 Views 0 Times

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 ELFLinux/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:

2016-10-13|20:33:11| sid/ip=701,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|22:33:04| sid/ip=825,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|23:58:45| sid/ip=996,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-14|00:32:03| sid/ip=993,'46.172.91.20'|SHELL|echo -n -e  '\x74\x65\x73\x74'

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 hisspreader/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 previouslyLinux/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 andstripped, 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 libccompiled 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 wasLinux/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 theLinux/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. < read between the line.

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] Linux/NyaDrop differences to other recent ELF backdoor (s_malware)

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 personal opinions between whitehat 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 traps 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 it..this just “can’t wait!” (..so I did, opening my OSX and checked the sample in a bus halt afterward).
So I replied with below:

With further elaboration:

…with an extra “howler” from r2 leader for being cought-in-the-act using r2 older version…cry :-P

Twitter is never enough to explain the stuff correctly, and I am not active in twitter anymore, 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 notLinux/NyaDrop nor coded in similar way as Linux/NyaDrop, so it could be made by different coder or actor behind the scene.

In in short explanation about how s_malware works is like this: Aiming as smallest size ARM ELF binary as possibly made, it uses syscall socket() to open a connection, and uses socket() again for listening via AF_INET, and then use socket syscall,one more time, to receive data from the remote and to then using write() syscall to save the payload with syscall write() if the stream of data is still in there, or exit. It is a smarter and smaller way to code since it seems only uses two linux syscalls for the overall operation.

See the above picture and please compare to how Linux/NyaDrop was coded inreversing section. The reason that s_malware ELF is not the Linux/NyaDrop is:
(1) Linux/NyaDrop is specifically using syscall connect() and syscall recv(), instead using syscall socket() to listen for incoming and receiving the data.
(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.
(3) The “nya” filename is only found in 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:

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!

#MalwareMustDie!
Reversed, written and analyzed by @unixfreaxjp [link] on October 13th 2016.