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.
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:
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:
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:
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/updatecommand in crontab - generating and dropping the
$dir/updateas 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:
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:
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:
"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:
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/tmpor/var/runor/mntor/rootor/orvaror/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:
linuxunixelfmalwareemechmechenergymechoverkillmodoverkillmodircbotnetddosundernetwhitehatromaniahacktoolhacking
