MMD-0061-2016 - EnergyMech 2.8 overkill mod

Background

This is a new threat analysis report I wrote in MalwareMustDie blog (this) after we moved out our blog 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: Pattern B: In the pattern A the start.sh will lead to the execution of autostart and run executable script. The start.sh is like this:

./autorun
./run

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: 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: Pattern D:

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:

And this is the update script generated and dropped afterward: 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=.
httpd

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/mech.pid; then
pid=\$(cat $dir/mech.pid)

This is actually giving much hint on what we are dealing with, mech.pid 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:

 22,983 mech.help
  1,064 mech.levels
      5 mech.pid
    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/ld-linux.so.2, 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/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
b2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
f:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
f4:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
j:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.0.0, not stripped
j2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
s:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
sl:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.0.0, not stripped
std:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
stream: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
tty:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
v:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.0.0, not stripped
v2:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, 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:

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:

b2:

std:

f4:

x:

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:

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;
{"NOSHELLCMD",cfg_noshellcmd,0}


/* snip 2*/

if (!will.shellcmd)
tofile(sf,"noshellcmd\n");

// 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 127.0.0.1 {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}

Additional on January 4th 2017

The more recent existence of the Linux/Overkill (EnergyMech 2.8 overkill mod) which were informed nicely (thank you, to a good sir) and uploaded to the VirusTotal. In this subsection I will summarize important significant information spotted. These new details are:

1. Newer ELF DoS modules in x64 architecture
2. Newer proxy, DNS amplification database and SOCKS addresses used for Linux/OverKill malicious operations
3. The access information of the abused host.
4. The abused host used for the botnet CNC

The Newer DoS Modules is as per below file types:

ghp: ELF 64-bit LSB executable, x86-64, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
skype: ELF 64-bit LSB executable, x86-64, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
tcp: ELF 32-bit LSB executable, Intel 80386, dynamically linked, interpreter /lib/ld-linux.so.2, not stripped
udp: ELF 64-bit LSB executable, x86-64, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

The more description on each binary is shown as per below table, the more detail analysis is available in the comment section for each binary report I posted in VirusTotal (please search by hash), and the snippet part will show you some proof of the malicious verdict of each of these binaries:

RE snippets of these newer binaries are:

ghp:

skype:

udp:

tcp:

In this set of samples it was also detected previous binaries mentioned in previous analysis too, along with additional new ones. Trace of the compilation for the newer version is pointed to one compiler environment, and using the same method, that can only lead us to the newer actor added the modules of the original malicious Linux/OverKill mod package.

In the package. It uses two list of newer host database contains of the 13,054 abused hosts for the DNS Amp ..and 6,774 used addresses of SOCKS4 and SOCKS5; I don’t think it is good to openly publishing these addresses (exceptions are to CERT and LEA). But I’d share its distribution statistic in graphical as per below:

Utilized DNS Amplification:

Socks4 and Socks5 IP used:

If we compare this new lists to the “original” proxy list used/included in the initial Linux/OverKill package (see the graphic below) we can obviously see the modification that has been made to support the newer four binaries:

And this is supporting to the previous statements that the Linux/Overkill user was also shifted from the original group of blackhat to others, with the different operation by adding the new modules. Since the original package is also intact as per it is, there is also a good odd to state that newer actor doesn’t have source code of EnergyMech 2.8 overkill mod itself.

As additional, I think it is safe to say that the newer actor was using OVH as his basis of operation as per shown by the common Emech configuration spotted below:

NICK          biz
USERFILE      1
CMDCHAR       @
LOGIN	      X 
IRCNAME       12rup tot !
MODES         +ix-ws
TOG CC        1
TOG CLOAK     1
TOG SPY       1
SET OPMODES   4
SET BANMODES  6
SET AAWAY     0
TOG NOIDLE    1

CHANNEL       #kid
TOG PUB       1
TOG MASS      1
TOG SHIT      1
TOG PROT      1
TOG ENFM      1
SET ENFM      +nts
SET MDL       4
SET MKL       4
SET MBL       4
SET MPL       1

SERVER 37.187.141.104 8080 <==== THIS

GeoIP:

{
  "ip": "37.187.141.104",
  "hostname": "ns412200.ip-37-187-141.eu",
  "prefix": "37.187.0.0/16",
  "region": "",
  "country": "FR",
  "loc": "48.8582,2.3387",
  "org": "AS16276 OVH SAS"
}

The Good Code vs the Bad Code

Back to the original flow of the post; 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.

Mitigation

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.

Analysis conclusion 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 original package of Linux/OverKill and ELF module 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.

Uptime, statistic and risk of Linux/OverkillMod botnet

Currently Emech 2.8 OverkillMod package (along with their flood functions) are spotted running in public and private IRC servers. With the help from the EggDrop community friends, we can identify the OverkillMod botnet listed that are having uptime more than 100days, with the amount of 305 BotID. Some of them are being duplicated, but the overall up and alive BotID amount for the running bots is still significantly big. In average each OverkillMod is having uptime around 30days, but that thank’s to the good and stability of EnergyMech code and functions.

If EMech in overall versions as the Bot IRC tool is having share statistically around 37% of the current detected bots, the OverkillMod nodes share is almost the half of it, so we can say currently that Linux/OverkillMod it is running on number between 2,000 to 3,000 nodes in the internet. With this amount, roughly predicted, if they want, Linux OverkillMod botnet can make a DDoS damage to any targeted site of an entity with the direct internet line without protection.

For that purpose, I grepped as many OverkillMod BotID that I can fetch and listed them sorted in their uptime as per below table. (You can ping me directly for the network origin used by each bot.)

Detection date: Sun Dec 4 06:15:45 JST 2016

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.

MalwareMustDie!!

• This post is dedicated to radare.org great folks, malwaremustdie.org 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