Background
On Mon, Aug 29, 2016 at 5:07 PM I received this ELF malware sample from a good person, with thank you very much! There wasn't any details or comment what so ever just one cute little ELF binary with following detail:
This is a cleanly GCC: (GNU) 5.3.x compiled ARM arch ELF binary:
All of the sections and headers are all there:
With a nice ARM attribute too:
The binary is signed with Sample Matrix RSA-4096 Certificate:
And it is having the libraries for encryption operation.
Well, a signed ELF binary with encryption is absolutely okay right? Unless .. if along with the that you see the binary is having the below hardcoded coder's message:
It seems the sender of the sample was finding this malware already infected a system, since I figured the self-copied name on post infection is as per the sample name sent:
And this is why this "adventure" was started..
What is this ELF?
This is a new ELF botnet malware, coded in Lua language ( @$LuaVersion: Lua 5.3.0). It is the first time to find an lua language ELF compiled malware, so let's call it as "Linux/LuaBot".
Below is the summary for this verdict:
The lua language used details can be seen in these viewable .lua source files traced, along with the lua runtime libaries and some botnet commands used:
The botnet commands can be traced in these called functions:
The binary is still in undetected state as per I wrote this analysis:
At the time I reverse-engineered this ELF I made an announcement & awareness about this new threat:
But there are a lot of things in this malware that can not be explained on one picture. The following parts will explain about more details on the threat.
How Linux/LuaBot infects us (initial steps)
It will be a lie to say that I know how this sample firstly infected a Linux host, since I only received the sample. But don't worry, by some ELF analysis I can explain a bit on how it works as per followings:
After trying to increase limit on open files via setrlimit(RLIMIT_NOFILE, &foo), the malware during the startup will fork itself to two new processes. In some Linux system that is secured well, and if the malware is not getting the uid zero (root), the setrlimit() can't be executed, and the coder forgot to avoid stderr(perror) for it. So if you see error message of "Setting RLIMIT_NOFILE failed, errno 1".
Just right before forking is done, the malware will send you message:
And then open the file socket bound to the mutex formed by:
which 203508 is hard-coded mutex in this ELF (see screenshot of arm_lsb filename).
After the first forked process is started, the main process will be terminated. This new first process will assign a PID with gettid & setsid, and then fork() its process one more time to launch the malware main process. Noted the initial process will be dead this time. This process will be bound to the file socket with the mutex created previously and will sit there and launched wait() syscall, is practically a useless process for analysis.
The second forked process is the main activity of this malware, and does malicious activities:
Checking the active (file) sockets in /proc/net/unix and network sockets /proc/net/tcp*
Reading all processes & PID in /proc with getidents64
Checking the current user privilege by getuid32, geteuid32, getgid32, getegid32
checking the interface name and its IP via open() to /proc/net/route. opened check socket and ioctl()
Assemble BotID & writing it on stdout:
with the lua script traces:
The malware then run test_domain() lua function to load lookup domains:
which are google.com, facebook.com, baidu.com, amazon.com and wikipedia.org.
The domains will be looked up to the below DNS servers:
At this point the malware will connect to the CNC in 217.23.3.47 and send an HTTP/1.1 GET command. This Linux/LuaBot was firstly coket connecting to 217.23.3.47 by port TCP/1085, there's no further activity in this connected port, assuming the checking purpose.
And followed by the HTTP request to port TCP/80:
The origin of this CNC:
Also recorded this in PCAP with its encrypted form replies from 217.23.3.47
As you can see the reply traffic contains the data of specific format of:
The thing is, maybe LuaBot coder doesn't think reverser can decode this data, well..
A simple reversing can decode this hard-coded CNC easily:
At this point data fetched is process (decrypted), this is when we can receive some "goodies", like:
To be beautified into:
These are the data to be passed to the CNC sending function coded in Lua.
The IP are all nodes of AS4998 from 109.236.80.0/20, 217.23.0.0/20 and 93.190.140.0/22 belong to a dedicated server hosting service WorldStream.NL, the customer layer service IP, in Netherlands. It looks like these IP is reserved by the botnet coder for a purpose.
There is another interesting data found, a botnet management protocol?
There are also some botnet monitoring status like:
Following the decoder trail a bit further, to find these IP to be connected just once and cleaned those up later on...this doesn't look good..
Which leads to the different IP info of:
These IP are involved to the botnet activity, it is maybe wise to check those further..
Okay, so far we found many network infrastructure were actually prepared by this botnet...
The malware changes the setting of iptables (Linux firewall) by following method:
And finally Linux/LuaBot is opening backdoor & listening to all inbound network traffic that uses port TCP/11833:
The infected state of a linux box by the Linux/LuaBot is as per tested case:
Noted, the UDP/41029 is outbound DNS request, is insignificant and can be changed.
CNC traffic and Lua coded botnet functions
I guess all of the related data for the CNC traffic already being explained much in the above section, so in this part I just paste the overall CNC traffic monitored during the initial infection of Linux/LuaBot, which hoping can be used as reference on the infection.
There are plenty trace of lua can be found in this tiny ARM ELF, but my favorite is the way this botnet is sending HTTP request to the remote sites, for the CNC purpose or proxy purpose. The stub contains IP are data that is parsed to the hardcoded lua XMLHttpRequest function. The reversing data shows below API in lua "pseudo function". is used for the purpose:
Below are some nice catches that's maybe worth to dig more :)
Let's ping Sucuri team for this:
The coder loves bad vocabulary.. :)
What is the purpose of Linux/LuaBot?
In the function at 0x07E2E0 on the reversed code, there are code that usually can be found in the DNS query handling tool, or name server resolver, as per snips below:
The code is interacted with the udp.lua, as per its name suggesting a lua library of User Datagram Protocol function and struct, This is showing the malware has its own lua resolver code for the DNS query, and has ability to form its own UDP packet to be sent to any destination.
There's also the telnet.lua codes compiled in this ELF, which is after being reversed it seems to be a simple telnet basic communication functions interpreted in lua language (that can be found many references in the internet) that may allow Linux/LuaBot to communicate remotely through this protocol.
And, so far...this is it, I can't proof any code that triggered the above mentioned functions in a hostile action, like, being called for flooding or DDoS for example. But, what I have now is only one tiny cute ARM file sample here, I may miss something with only so few reference.
The only thing that I don't seek deeper is the "penetrate_sucuri" part, a symbol (suggested a reversed function) traced to be coded in the lua source file: *cough* "checkanus_sucuranus.lua" and "checkanus.lua", which I took only a peek into it, forming action to a defined target. I'll leave the engineer experts on Sucuri team friends to analyze this part deeper, but by its name it may suggested to penetration into their product's protection scheme.
So what is the purpose of this malware? I'd say this malware is used as botnet, for sure. If you see carefully in the description I wrote, there is a "cmdline", and "cmdline args" is spotted in several parts in the ELF reversed code too. The hacker can do a lot of things by the remote command line pushed to his bots with this command interface.
There is a part that I can not explain openly in here for security purpose too, but there are also some mystery stays, like the HTTPS authentication for the remote site. Please take the rain check for those functions, I will add those information after rest.
Epilogue
There are new ELF malware coming & lurking our network, let's watch for unusual hazards for the security of our 24/7 running Linux nodes, they are as important as the personal computers that we all use.
The traffic filtration for this threat is proposed to ET Labs friends, the status will be updated.
Lua is a good language, and using it for compiling ELF ARM binaries is good too, but the usage for making botnet is never good.
Stay safe friends!
#MalwareMustDie
