Saturday, December 3, 2016

MMD-0061-2016 - EnergyMech 2.8 overkill mod

This is a new threat analysis report I wrote in MalwareMustDie blog (this) after we moved out from blogger, I hope you like the new blog system and design, and enjoy the post!

An unattended or abandoned Linux/UNIX system with its web service online (specially with the CGI function intact) with not having recent updates can be soon be exploited and infected by Linux malware. Scanner for seeking these system’s flaws is running every day by the attackers throughout the internet, seeking their target possibilities to perform malicious acivity. This is a story about the set of Linux malware injected to such compromised system causing by this flaw..

Threat summary

We received several reports of the same incidents from several sources within a year period, and it is very understandable if the sysadmins involved were not wilingly to disclose more details of the attackers in their system’s side, and for that I have to investigate myself to get more informative values of the threat, and fortunately we received some samples of the same attack pattern.

The last sample set was received from Brazil on November 11th, 2016 (thank you dear Brazillian friends!), and it contains the most recent used toolset of this context, so this analysis report is based on it. I frankly was not expected this tool to be still in circulation nowadays, indeed it is, so it would be good to have this case written in ELF / Linux malware threat library as additional reference, specially when we are in the period where attention for ELF DDoS malware threat is on spotlight.

ELF Linux malware is the threat that evolves, previous spotted bad codes keep on coming back, either being merged into other *badness form* or *incarnated* by new code scheme by the same old concepts, and each comeback they always bring more improvement along with adjustment made for its usage to adapt the capability to create more damage in the recent vulnerable Linux/UNIX vectors, since the people who use these codes are having good skill in networking and hacking on blackhat sides. This is why I think it is important to make a good library to analyze each ELF/Linux malware case, for the future reference. - unixfreaxjp, Dec 2016 -

To summarize the threat info itself: The actors are script kiddies hackers (likely), from a place in Europe that is famous for its vampire story. The modus operation and custom toolset used are actually known, but not as new as recent threats we detected/found/wrote before (i.e.: PnScan, Mirai, LuaBot, NyaDrop, IRCTelnet or UDPFker, and etc previous ones..), nor also popular ones (at least between the whitehats people), yet the tool’s activity is still exist (surprisingly). I categorized this threat as a customized Linux DDoS botnet via IRC protocol (aha!..not again..). And currently the spotted samples was compiled to aim Linux or Linux compatible systems (read: UNIX that can execute ELF file) under x86-32, x86-64 or amd64 processor architectures.

The malware itself, I call it as Linux/OverkillMod, for the reason that I will be explained in the following sections.

Threat attack vector: the buggy PHP

A pretty old version of a CGI scripting language: PHP was installed in a not-so-well-managed PHP powered web server that is having a CGI query handling vulnerability, in example like this one can trigger a remote code execution commands, is being spotted up and alive. Upon several common attack techniques used, one attacker was successfully compromising the system after sending the url-encoded POST command to exploit the buggy cgi_main.c in the target’s PHP binary to then execute a series of malicious shell-script via execution of PHP’s system() command.

system() is a PHP command to execute as well as any arguments you wish passed to that command and immediately displaying the result in the output stream, best used in i.e. system command line Web GUI coded in PHP. It is not wise to have this command activated for the security prevention, and if we must use it, we have to make sure to have extra secure precaution, including the PHP regular version update. Yes, this is a cliche’ exploitation scheme..but it still happens.

The shell-script command executed by the used system() is having a couple possibilities of one liner shell script to download, install, execute and then self-delete, to:

  • directly install and run a Linux malware, or..
  • download the installation shell script to be executed to install and run a Linux malware

..and the Linux malware mentioned above is our topic of the day.

The two possibilities, let’s call it as Possibility one and two, of spotted one-liner shell script codes I breakdown as per below structure, again..there is nothing new too, since we see many similar kind of codes fired by hacker script kiddies in daily basis.

Possibility one - direct installation and malware execution, it has two patterns:

Pattern A: php system shell script to infectA Pattern B: php system shell script to infectB
In the pattern A the will lead to the execution of autostart and run executable script. The is like this:


As per seen in the above system() injected shell script code, the wget and (alternatively) curl was used to fetch a remotely served payload archive file to be extracted in the /tmp directory. The extracted directory is having the same name as payload’s name, but for the OPSEC purpose let’s call it as DIRBLAH. The installation of the malware is started by the execution of the ./autorun.

Possibility two - a downloader for malware’s installation and execution script: Possibility two - downloader In this Possibility two, works a bit similar to the first possibility, but it downloads, executes and delete BUH file. The executed BUH file itself is actually another better coded bash shell script contains installation (infection) and execution commands as per shown below, which is similar as direct installer show in Possibility one, and also it has two patterns:

Pattern C: Possibility two - installerC Pattern D: Possibility two - installerD

To be very honest. It wasn't easy to collect all of these installation details, since either the involved hacker(s) can manage to delete the files afterwards, or, the stuff was `crond` cleaned up in the `/tmp` directory, or all malware was detected and then deleted. But in several particular cases, with thank's to the good cooperation from site's sysadmins, we managed to forensics data needed to figure the scheme.

The malware’s persistency installation process

In very end of the installer scripts we can see the autorun or run file was executed. both of them are actually shell scripts components of the malware package. Together with the rest of files of the tar package, these files can be found in the extracted malware directory.

The autorun is the installer module of the malware, to be used to create a malware persistent starting scheme, with the process as as per follow:

  • creating schedule for malware’s auto-update $dir/update command in crontab
  • generating and dropping the $dir/update as auto-update file, a persistency script.
  • setting auto-update file into executable This way the persistent scheme ala “watchdog” for the malware tool can be performed.

Below is the autorun script itself: autorun

And this is the update script generated and dropped afterward: update
You can see the Linux crontab scheduling part was done under this command:

* * * * * $dir/update >/dev/null 2>&1

Which means to execute the generated update shell script file every minute, to check whether the Linux malware is running, and if the malware is not running the malware “starter” executable component (also a script file) run will be executed.

The run file contains a simple script to execute the Linux ELF malware binary file named "httpd" :

export PATH=.

This httpd ELF binary is the malware that will be discussed in the next sections..

The other vector: via ssh/telnet login brute-force

This is the additional part of the initial analysis. After the analysis blog was posted I received additional information from our friends (thank’s to “Wp”), about the existence of infection cases via shell login compromising vectors too. One sample case can be viewed in a blog posted here or here, which is snipped as per below: It is obviously the same badware package “bogus httpd” was used for the above compromising method too, but at that time the flood components was fewer than the recent reports we received. Additionally, as the same type of malware used, the analysis explained in next sections will be applied for this vector of the attack too (under the same sample hash of the bogus httpd, if you need to be sure).

To be noted: In the mentioned shell compromised case, there is no persistency installation was executed.

The trace of EnergyMech codes

In the autorun or update file, you can find the below lines:

if test -r $dir/; then
pid=\$(cat $dir/

This is actually giving much hint on what we are dealing with, is part of the C coded IRC tool called EnergyMech (in sort: emech). An remote bot software, not a malware, similar to the EggDrop). Quoting from their web site:

The EnergyMech is a UNIX compatible IRC bot programmed in the C language, freely distributable under GNU General Public License (GPL)

Seeking the further overall collected and received samples we can find these files resides in the compromised system, proofing the EnergyMech existency:

  1,064 mech.levels
    295 mech.session
    480 mech.set

(NOTE: inside of these files there are written the setting on how to connect to IRC server used for this bad purpose, nothing special on these, except if you would be kindly help to stop the bad guys together with us, please ping me)

The problem now is, which kind of EnergyMech (emech) used, by whom, why EnergyMech (emech), what for, and how. To answer these questions I guess we need to reverse the httpd a bit.

The bogus “httpd” = EnergyMech (emech) 2.8 overkill mod May 31st, 2001

The ELF:

httpd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically \
linked, interpreter /lib/, for GNU/Linux 2.0.0, stripped

After you see bundle instruction of the common older version of EnergyMech, the modified version information of this package can be seen in the several parts, for example: That stated a modified EnergyMech version and build of:

"EnergyMech 2.8 overkill mod May 31st, 2001 Compiled on Jun  1 2001 14:09:42"

Further, the below undecent messages used is obviously not being included in official emech build too: More of these “original exotic messages” are in example:

0x806d619 21 20 // I m not on %s stupid
0x806d62e 21 20 // Cant fucking open %s
0x806d643 15 14 // init: Warning:
0x806d652 18 17 // This nick sux: %s
0x806d680 35 34 // Put me on some channels first punk
0x806d6c0 36 35 // Lists could not be saved to file %s
0x806d6e4 28 27 // I m not opped on %s asshole

This explains much of what kind of attackers we are dealing with.

So now we know these answers from our questions:

  • WHAT is the binary => a modded version of EnergyMech
  • by WHOM => hacker skiddies..

What is the purpose of using EnergyMech in this hack case? WHY emech?

This is acually a good question. To answer this, let’s see some of the accompanied files:

b:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
b2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
f:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
f4:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
j:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.0.0, not stripped
j2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
s:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
sl:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.0.0, not stripped
std:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
stream: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
tty:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.2.5, not stripped
v:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.0.0, not stripped
v2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 2.0.0, not stripped
x:      Perl script, ASCII text executable

These are actually the ELF files (and one Perl script file) used for executable module for DDoS attack. Each one of them can act as stand-alone and also as modular, thus each of them has the each specific packet flood generation and sending method that needes specific arguments/parameters to perform the attack.

A bit of reversing of each “module” is explaining their origin, so I made a quick list to explain each of them, and how they are executed, as per follows:

File  | Description              | Syntax
b     | SirVic's B flood         | ./b {hosts} 999
b2    | reflection dos           | ./b2 {target} {file} {seconds}
      | by Jabrick & DrBIOS      | 
f     | SirVic's_Fuck.c flood    | ./f {ip} {port}
f4    | FUDEDOR4.C (v4.0) by -   |
      | Alexander - PRIVATE!@#!  | ./f4 {host} {size} {time}
j     | Juno flood               | ./j {ip} {port}
j2    | Juno flood ver 2         | ./j2 {ip} {port (0=rnd)} [ns (1s/10^9) delay] [threads (dfl:1)]
s     | Stealth flood            | ./s {ip} {port}
sl    | anti-foonet (by blizzard)| ./sl {srcaddr} {dstaddr} low high
std   | STD2.C (STDv2) BY STACKD | ./std {host} {port}
stream| jess_stream.c v1.0 TCPZ  | ./stream {ip} {port} {pktsize} {pps}
tty   | SirVic's flood2.c        | ./tty {ip} {port}
v1    | Vadim I                  | ./v1 {ip} {port} {ip_spoof}
v2    | Vadim II / Vadim -       |
      | patched by paxi          | ./v2 {ip} {port} 10 0
x     | SirVic's Random flood    | ./x {ip} {port} {seconds}

It will be boring to show all codes in assembly, so I picked some of reversed codes and the perl snippet for the reader to have better idea of what these stuff are:

vadim2: vadim2

b2: reflection whatever



x: Random Flood SirVic's

The interesting points of the executables above is, having similarities in:

  • compilation method
  • modular design
  • arguments that can supports command line and/or reading from files

The above points is showing these binaries are ment to be used in EnergyMech, and for that it should have a kind of API that can support file execution to run a script or binary. The best way to seek is reversing the sample, and in this below function the answer is found: Emech 2.8 mod executional function

So now we know it executes those files, but how?

I traced each suspected names and symbols that can trigger the expected action, and after some elimination these are the three left candidates that can support the execution of the file:

0x8064d67 11 10 NOSHELLCMD
0x806537d 8 7 STOPCMD
0x80653e9 9 8 SHELLCMD

I went also to the every good EnergyMech source code for the same purpose and could not find what I seek, so I guess I have not so much luck on that.

Then I went back to the samples in hand and disassembly all of the codes for each available sample, to then seek possible API that is actually used for this malicious EnergyMech version aka the +bogus httpd*.

And, to make it short, finally found a good clear trace on the effort from certain compilation trace:

/* snip 1*/

cfg_noshellcmd(char *args)
will.shellcmd = FALSE;

/* snip 2*/

if (!will.shellcmd)

// which is finally leading me into...

/* snip 3 */

tofile(sf,"cmdchar %c\n",bot->cmdchar);
tofile(sf,"userfile %s\n\n",bot->Userfile);

This is the additional updated info: After I released the analysis, under helps from MMD mates, we seek the overall nutshell for the source code of this badness, and confirming the bad codes that is responsible and was used to make this bogus httpd aka “EnergyMech (emech) Overkill mod 2.8” and the execution part can be seen in the snippet picture below:

So, by adding all of these detail, I can figure the command for execution the file via this version of EnergyMech exists actually, under the formulation syntax of:

{!} shellcmd [PATH_TO] [FILENAME] {ARGS}

To make it clear, all of the executables found together in the package of the bogus httpd can be executed after that bogus httpd connect to the IRC channel using the commands as per below:

shellcmd ./b {hosts} 999
shellcmd ./b2 {target} {file} {seconds}
shellcmd ./f {ip} {port} 
shellcmd ./f4 {host} {size} {time}
shellcmd ./j {ip} {port}
shellcmd ./j2 {ip} {port (0=rnd)} [ns (1s/10^9) delay] [threads (dfl:1)]
shellcmd ./s {ip} {port}
shellcmd ./sl {srcaddr} {dstaddr} low high
shellcmd ./std {host} {port}
shellcmd ./stream  {ip} {port} {pktsize} {pps}
shellcmd ./tty {ip} {port} 
shellcmd ./v1 {ip} {port} {ip_spoof}
shellcmd ./v2 {ip} {port} 10 0
shellcmd ./x {ip} {port} {seconds}

Under curiosity, I re-checked the EnergyMech web site again for the latest version to seek for any code related to these execution logic, and I can not find any of this API enabled anymore from the latest sources that I can get, so this is explaining why the “mod’ed version” for the emech was built, for this malicious purpose.

For the note, the bogus httpd, which is the “EnergyMech 2.8 overkill mod May 31st, 2001 Compiled on Jun 1 2001 14:09:42” is a malicious ELF Linux malware, but EnergyMech original distribution is not, just like the EggDrop for example, EnergyMech is a good IRC tool, I am currently running several tests on it too.

It will not be fair for the EnergyMech decent development folks to call their project as malware, this is why I call the mod’ed malware version one as Linux/OverkillMod.


Several mitigation advisory for the threat:

  • For the current IR case, you will have to ask to update the PHP, web server and frankly said, the OS distribution too, it is too old and obsolete to serve an outdated web acessible service in this period of time, upgrading the platform will be easier and faster to prevent similar happening in the future.
  • Since Intel compatible platform is the current aim for the threat, the malware signature detection for the samples can prevent this infection, see the next section for the sample hash detail.
  • Furthermore, for the fellow sysadmins, please regularly monitor the unusual traffic inbound/outbound from the services (if possible), and also check for the bad code resides in the commonly hacker’s aimed directory like /tmp/ or /var/run/tmp or /var/run or /mnt or /root or / or var or /dev/shm, etc.

Epilogue and samples

So now we perfectly know now about: WHY the EnergyMech (emech) was used for several hacking incidents, and WHAT the purpose of the hackers were using it, aiming to WHICH systems and platforms, by WHOM (only specific community culture in a known IRC server is using these), and and HOW the attackers are/were using it. The malicious scheme like this case, which is performed via IRC protocol botnet and used splitting attack modules saved in hacked nodes into several ELF executables, is a bad sign. But, since the actual working source code for this threat is a bit hard to find so can hope this threat will not migrate to the other platform soon.

I hope this post will help fellow incident response team and sysadmins friends. Since I don’t provide the comment section for this blog anymore, if you have any questions or opinion to be shared about tis analysis, you are welcome to write to us your advise/suggestion/questions/opinion in /r/LinuxMalware on reddit (the posts are moderated).

For the samples, the hashes is as per below table, I will make sure all of the samples are uploaded in the VirusTotal, but please bear for some delay for I need time to clean up the analysis “pad”.

For the source code of the bad emech that has finally collected, let this code to be a dead end, so we can kill this threat for good.

Malware file SHA1 hash
b 67ccc3866b13d10f5f7106b7580b7cbc8dc8a470
b2 b85a7130bbf77b4c237e0bf915f6ce672792e47e
f 1ed59a0dc45d4b744df58999a18f987183b2e4ee
f4 8238b054ea6eafd97898835052c7c01053a5c7b2
j 1527118dfa541b2aa99132a48bcde22f57d971e0
j2 2f40fb39d5082db49dbbfbf48a2b20fdb4a0946d
s 9d58bfb07d85483049f1d22bc02cfa3737706865
sl 971b6f93b15c28dd72e8fdada7ddc0449b8bfeca
std 34323bf56af2fc7105da5f64c1171aa28ebd5c4a
stream e2011b15fe673b40af2c72492d86214a5c9c917c
tty 5d2ed29211c04e0941584e26c9e5ce858628451d
v1 4e587b64d26cf46cf91d3ad145e0897d366f451a
v2 0a7661a038f21a98fcc75e7e04d828b4c2fef114
x 31f17179477c2a4eb13b87793a558ade271e12ad
httpd c34597af2f63be4214a1b63ca7915229e0578a93

A note about radare2 and gcc compatibility

I am sorry for I was using r2 older version for this analysis, my BSD clusters is using gcc version 4.2.1 (the recent version now is gcc 4.9.x) ports and gcc 4.2.1 and it looks incompatible with the recent r2 git version (Linux is unaffected since they always renew gcc binset packages in distro updates). As much as I want to upgrade the gcc to the newest release one, it is much work to be done actually since the development and reversing tool I build and/or use were compiled with same gcc version, so I think I just have to plan to migrate overall stuff to the new platform.

Yeah, gcc version is always be a problem in development. This is my two cents/personal opinion of the issue: If we want to support the client workstation only then it maybe good to use the very recent version of gcc, but if we want our tool to work in servers or embedded platforms too, the older gcc` version compatibility should be put in consideration too.

Production servers are often used for development, and they tend to have compilers that can support software for longer period, hence older version of gcc sometimes still in use. As of the embedded platform, it is mostly built on older gcc version (by my experience) for the minimalistic and hardware driver’s program compatibility.

In my work or in my personal UNIX development I am still compiling some software using older version of gcc just for supporting this compatibility matter. For the wide-used tools, maybe, it would be a good idea to be tested during the last development stage with considering older compiler compatibility check factor, or by restriction or rules in coding policy, or maybe, as the easiest workaround, it is good too to clearly state supported/unsupported gcc versions if somehow the incompatibility can not be avoided for the future road map or development.

But it is always easier said than done. As the follow up for this particular case, I had tested a list on r2 previous versions, which notifying which one was supported or unsupported to older gcc users in the github. Therefore, during the bug time the r2 previously released version that is supporting gcc 4.2.1 can be fetched from radare2’s site. During the test and a little bit of reading the code, the source of the current incompatibility problem can be found and viewed in here.

This is the update information: The r2 developer team was fixing this problem in only by several hours to eliminate the anonymous union usage in the libr/anal/p/anal_avr.c, and released the fix for the issue in this commit, thank you!

Stay safe friends! Thank you for your reading.


  • This post is dedicated to great folks, loyal friends and the open source community in Linux/UNIX platform.

  • Reversed, written and analyzed by @unixfreaxjp on November 28th 2016.

  • Tags used for the post: linux unix elf malware emech mech energymech overkill mod overkillmod irc botnet ddos undernet whitehat romania hacktool hacking

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.