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

29 Oct 2016 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..

Summary

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...
[/EDIT]

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=88.250.211.251 AS9121 Turk Telekomunikasyon Anonim Sirketi
2016-10-26 15:21:10| IP=122.54.151.163 AS9299 Philippine Long Distance Telephone Company
2016-10-26 16:28:24| IP=88.250.221.78  AS9121 Turk Telekomunikasyon Anonim Sirketi
2016-10-27 00:14:23| IP=37.233.16.70   AS31252 STARNET S.R.L Moldova
2016-10-27 17:16:05| IP=37.233.19.216  AS31252 STARNET S.R.L Moldova
[additional/new↓]
2016-10-29 14:28:21 IP=88.244.55.193   AS9121 Turk Telekomunikasyon Anonim Sirketi
2016-10-29 22:11:38 IP=88.226.164.201  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: "88.250.221.78",
  region: "Manisa",
  country: "TR",
  org: "AS9121 Turk Telekomunikasyon Anonim Sirketi"

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

  ip: "122.54.151.163",
  hostname: "122.54.151.163.pldt.net",
  country: "PH",
  org: "AS9299 Philippine Long Distance Telephone Company"

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

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

[additional / new]

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

  ip: "88.226.164.201",
  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:

/home/firmware/build/temp-armv5l/gcc-core/gcc/config/arm/

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

main.c
utils.c
irc.c
scan.c
attacks.c

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: 164.132.237.180\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

Passwords:

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
                   superuser

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": "137.74.234.206",
  "country": "FR",
  "loc": "48.8582,2.3387",
  "org": "AS16276 OVH SAS"

  "ip": "164.132.237.180",
  "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 /////////

TCP 127.0.0.1:36040->49.204.1.60:23 (SYN_SENT)
TCP 127.0.0.1:58298->49.204.211.14:23 (SYN_SENT)
TCP 127.0.0.1:58298->49.204.211.14:23 (SYN_SENT)
 :

TCP 127.0.0.1:33637->59.36.224.103:23 (SYN_SENT)
TCP 127.0.0.1:45555->59.36.158.245:23 (SYN_SENT)
 :

TCP 127.0.0.1:47767->219.129.1.113:23 (SYN_SENT)
TCP 127.0.0.1:49476->219.129.110.120:23 (SYN_SENT)
 :

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.. So..it 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 irc.evil.in 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 #hack.it

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 is..no 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 (iotevolution.com) 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.

Salutation

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.