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

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:

------+--------------------------+------------------------------- File | Description | Syntax ------+--------------------------+------------------------------- b | SirVic's B flood | ./b 127.0.0.1 {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:

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}

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.

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.

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