{
  "ip": "46.172.91.20",
  "hostname": "No Hostname",
  "country": "RU",
  "loc": "55.7386,37.6068",
  "org": "AS35390 PE Masyuk Natalya"
}

nyadrop: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped

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  

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. < 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 not Linux/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 in reversing 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.