Thursday, October 13, 2016

MMD-0058-2016 - ELF Linux/NyaDrop - a linux MIPS IoT bad news


Since the end of September 2016 I received a new type of attacks that aims the MIPS platform I provided to detect IoT attacks. I will call this threat as new ELF Linux/NyaDrop as per the name used by threat actor himself, for the "nyadrop" binary that is dropped in the compromised system.

This is not the "really" first time we're seeing this threat actually, in this year, some small events was detected on having these attacks which I ignored for some reasons, and on May 22th, me and hFiref0x of KernelMode was in a convo regarding to the threat which was detected. It was obviously the same threat (proof is as per picture below, thanks to hFiref0x for the ping that time).

On May's event, the attack was so poorly arranged so the infection wasn't occurred due to the lack of UNIX background of the bad actor. And I did not want to post it in anywhere, hopefully he will be always as dumb as per that state.

In the end of September 2016, a wave of attacks using IoT known factory hardcoded default login credential that was recently exposed on some blackhat events, was raising a lot of ELF threat to "come back" and race to infect the known IoT vulnerable sector. And during the session, the Linux/NyaDrop's loader attacks was re-surfacing again, and this time it got better (a bit), so I decided to write in this post as public awareness. For the purpose I made forensic records since early Octtober 2016 for the conducted attacks on specific platform aimed, MIPS CPU architecture, implying routers and similar networking devices, with 32bit clock.

This post is informing you about the information related to the attack, records of several attack pattern, the dropped binary analysis in reverse engineering. You may can get the hazards to be use detect and mitigate the threat, and further precaution. The complete log is shared to law enforcement. Beforehand, I thank FreeBSD foundation to the free & open source platform which I conduct all of my research, radare2 for the one and only reversing platform I use, and Linux for the great OS that is successfully implemented into plenty of IoT, and also Mr.Michel Oosterhof for his effort in improving a good tool.

The detail is in the following sections..

NyaDrop attack indicators

There are some indicators that can be used to detect this attack, the first pattern is the login "Failed attempt" and then followed by the "Success attempt" of login credential of the aimed IoT. The time for getting success attempt is very short, indicated the bruce force work.

The Fail then success attempt can be shown as per below:

In this attack the credential "5up", was used as first brute login.

The one shot attack with a success attempt can be shown as per below:

And below are the several pattern of failed attacks:

I think the last patterns is the most seen pattern by the honeypot users. You have to be as "cameleon" to Linux MIPS IoT system in characteristic to fulfill the herder's checks for then he will "grant" you to the Linux/NyaDrop binary :-)

This attack was keep on coming while I was writing this blog:

2016-10-13|20:33:11| sid/ip=701,''|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|22:33:04| sid/ip=825,''|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-13|23:58:45| sid/ip=996,''|SHELL|echo -n -e  '\x74\x65\x73\x74'
2016-10-14|00:32:03| sid/ip=993,''|SHELL|echo -n -e  '\x74\x65\x73\x74'

Some points to be noticed in these attacks are:

  • Russian IP address as source of threat:
      "ip": "",
      "hostname": "No Hostname",
      "country": "RU",
      "loc": "55.7386,37.6068",
      "org": "AS35390 PE Masyuk Natalya"
  • The specific Dahua IPC-HFWxxx old type vulnerable password was the one used to let this in, but that depends on how we apply our traps.
  • The binary injected during the attack is the ELF malware Linux/NyaDrop:
    nyadrop: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped
  • The attacker is not "greedy" to infect, the herder is starting attacks from his spreader/loader in some session to some specific IP targets to then aim other targets while stopping the previous ones, it goes all over without a rapid rotation. It seems like the herder want to keep distribution of Linux/NyaDrop as "silent mode" as possible..
  • The usage of the string "test" and the ELF injected hex strings via echo -n -e with or without STD_OUT to save is the current active indicator for this infection.
  • Attacker is intentionally aiming MIPS, by checking the "cpuinfo" to be sure which CPU that the device is running, they don't infect my ARM or PPC devices, but yet again, it depends on how you plan to trap them.

    How ELF Linux/Nyadrop works

    The successfully installed malware file in the MIPS system is the Linux malware backdoor and dropper, I call it as ELF Linux/NyaDrop malware, with the function to open an internet socket (AF_INET) to remotely connect to the remote host for receiving data of any Linux executable stream intended to infect the previously Linux/NyaDrop compromised machine. The stream of received data to then be saved as "nya" ELF malware file and then to be executed by Linux/NyaDrop with its permission privilege on the targeted MIPS cpu architecture device.

    The "nya" dropped file will be deleted everytime the next new attacks are successfully logged in to the MIPS machine and then updating the previously saved "nya" malware. This method is so generic and flexible for the attacker to update the botnet component, the backdoor (Linux/NyaDrop) itself, and can be arranged without giving many trace of executables. Further, during unsuccessful attack or the "obviously-detected-honeypot", neither the binary of "nyadrop" will be saved/infected successfully, following also the "nya" binary one. This is why the malware sample is not much spotted.

    Linux/Nyadrop ELF binary analysis

    As per mentioned in the above sections, the ELF binary of MIPS x32, static and stripped, was saved with the name of the "nyadrop" on the targeted MIPS device. The header is as follows:

    SHA1 (nyadrop) = "095bb52056d00f0d93bba78e4b5b56313de7b79f"
    Size = "621 bytes"
    "ELF Header:"
      Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
      Class:                             ELF32
      Data:                              2's complement, big endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           MIPS R3000
      Version:                           0x1
      Entry point address:               0x400090
      Start of program headers:          52 (bytes into file)
      Start of section headers:          500 (bytes into file)
      Flags:                             0x10001004, cpic, o32, mips2
      Size of this header:               52 (bytes)
      Size of program headers:           32 (bytes)
      Number of program headers:         2
      Size of section headers:           40 (bytes)
      Number of section headers:         3
      Section header string table index: 2
    "Section Headers:"
      [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
      [ 0]                   NULL            00000000 000000 000000 00      0   0  0
      [ 1] .text             PROGBITS        00400090 000090 000150 00  AX  0   0 16
      [ 2] .shstrtab         STRTAB          00000000 0001e0 000011 00      0   0  
    If you see the size, we are dealing with a small executable file. It's a clean libc compiled ELF from coded in C in such form that we see much in shellcodes. Insides is filled with the MIPS opcodes. We dealt before with the similar small ELF malware before in the following posts in here [link] and here [link], I will try to deal with this one too :)

    Small size yes? But it is amazing to see what this small malicious ELF can do..

    There's not so much strings that can be extracted by this binary..

    However, the ASCII keyword of "ny4Ba" is a good way to grep for the easy filtration or one of the condition in filtering this malware (current) version for the mitigation / signature purpose.

    Reversing the ELF Linux/Nyadrop

    For the reversing method. I was using my usual way like with previous ELF malware or botnet analysis, with using radare2, some syscall analyzers in skeleton2 and some manual opcode reading.

    Let's see reversing pad with a lot of comments I made in the screenshot below for the details on how this binary works, you'll get the idea better than reading my long explanation.

    PS: Generally, the malicious functions in this ELF malware was reversed well. But please bear for some "bad reading" on some MIPS opcodes or address, which I think I may miss some few minor parts. Switching from Intel to ARM, PPC and MIPS opcodes reading is sometimes a bit hard to adapt quickly. Moreover I had only several hours to translate them to catch my sleeping time.

    Detection, sample and follow-ups

    The detection is bad, and you can expect multiple hash will be created per injected ELF of Linux/NyaDrop due to its nature of infection. Please avoid the hash base signature since it will be very meaningless, just as the Linux/Mayhem case [link](drop-able by spreader via multiple circumstances by script/shell).

    Below is the screenshot I took AFTER I uploaded the sample to the VirusTotal:

    *) You can click the picture for directly viewing the report in VirusTotal.

    I understand that many people may not be as lucky as I am in gaining the sample of this threat. There is a good explanation for it, and that, I can not describe openly in this post for the security reason, since the known very bad actor who involved to this threat are reading this blog too (yeah, by now, I know who you are skiddo, so we meet AGAIN in this threat too).

    My tip for trapping this threat better is: Give the bad actors anything he wants. < read between the line.

    Since I received so many requests from fellow research and IR folks for the sample, I will share the sample to the good vetted close research community. In the mean time please bear with the Virus Total sharing [link]
    If you need the text data of my reversing draft or log as per screenshot ones, or more questions on howto grab this samples better, please contact me, all data is available to be shared to good guys only.

    [additional] Linux/NyaDrop differences to other recent ELF backdoor (s_malware)

    WARNING: This section is a research material in a friendly manners, and it is NOT affected any entities to whom any related individual is working with or working for, these are strictly personal opinions between whitehat malware researchers.

    My friend Mr. Korolev, a good Linux threat researcher & reverser, was bringing this issue to my attention (with thank's). as he informed:

    The first time I saw the tweet, what I had in mind was: Why all of my ARM traps wasn't hit then? Since I have much more ARM devices than MIPS in all over internet now, it should fetch something than just only few of MIPS. The second thought was.. I must get off this bus to check it..this just "can't wait!" ( I did, opening my OSX and checked the sample in a bus halt afterward).
    So I replied with below:

    With further elaboration:

    ...with an extra "howler" from r2 leader for being cought-in-the-act using r2 older version...cry :-P

    Twitter is never enough to explain the stuff correctly, and I am not active in twitter anymore, so allow me to elaborate some details in here:

    Mr. Korolev was not incorrect by saying the s_malware ELF trojan dropped in Dr. Johannes B. Ullrich,Ph.D., of ISC reported case [link] as s_malware, as "similar" in type of trojan to Linux/NyaDrop, which is a backdoor, and a file dropper, however, it is not Linux/NyaDrop nor coded in similar way as Linux/NyaDrop, so it could be made by different coder or actor behind the scene.

    In in short explanation about how s_malware works is like this: Aiming as smallest size ARM ELF binary as possibly made, it uses syscall socket() to open a connection, and uses socket() again for listening via AF_INET, and then use socket syscall,one more time, to receive data from the remote and to then using write() syscall to save the payload with syscall write() if the stream of data is still in there, or exit. It is a smarter and smaller way to code since it seems only uses two linux syscalls for the overall operation.

    See the above picture and please compare to how Linux/NyaDrop was coded in reversing section. The reason that s_malware ELF is not the Linux/NyaDrop is:
    (1) Linux/NyaDrop is specifically using syscall connect() and syscall recv(), instead using syscall socket() to listen for incoming and receiving the data.
    (2) Linux/NyaDrop is using syscall execve() to execute the dropped file after writing data into "nya" file was done, but there's no usage of any execution syscalls is made in the s_malware.
    (3) The "nya" filename is only found in the ELF nyadrop binary.

    There are plenty of small ELF backdoors/backconnect using the similar or even smarter concept in unixland. Linux/NyaDrop was designed as a sophisticated form in a smaller size as possible (621 bytes) with all correct calls coded intact. s_malware is about 484 bytes. There are more ways to make it even smaller, but remember this, that also will reveal the source of the coder well too.

    The s_malware in hex:

    Thank you for the News & Internet Media publishment

    This section is dedicated to the IT threat journalists, who are so kindly help to raise awareness on Linux/NyaDrop threat. Their fast action and the effort in learning the indicators and nature of the NyaDrop threat is just marvellous, we have nothing to give these gents back except our hard work, thank you, and respect. Following are the notification and for others who hasn't been mentioned I am sorry, and will update as soon as I cam. Again, thank you.

    Thank you to "Softpedia" & Mr. Catalin Cimpanu for speedy understanding & grasping the importance of awareness for Linux/NyaDrop in releasing the awareness of the threat by his article-->[link]. You can read a good summary for the threat in here.

    Many thank's for "Odisseus", whitehat researcher and/or Mr. Pierluigi Paganini of "Security Affrair" for the interview arrangement on Linux/NyaDrop, you can see in this article-->[link]. You can read the insights details about the threat information, which was "cleverly" asked by Odisseus in here.

    I thank also Mr. David M. Bisson of "Graham Cluley Blog" article [link], and Mr. Ionut Arghire with summarizing recent updates on Linux/NyaDrop in "Security Week" article [link].

    Stay save friends!

    Reversed, written and analyzed by @unixfreaxjp [link] on October 13th 2016.

  • Monday, September 5, 2016

    MMD-0057-2016 - New ELF botnet: Linux/LuaBot


    On Mon, Aug 29, 2016 at 5:07 PM I received this ELF malware sample from a person (thank you!). There wasn't any detail or comment what so ever just one cute little ARM ELF stripped binary file with following data:

    arm_lsb: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
    hash: a220940db4be6878e47b74403a8079a1

    This is a cleanly GCC: (GNU) 5.3.x compiled ARM arch ELF binary:

    ELF Header:
      Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
      Class:                             ELF32
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           ARM
      Version:                           0x1
      Entry point address:               0x11940
      Start of program headers:          52 (bytes into file)
      Start of section headers:          995912 (bytes into file)
      Flags:                             0x5000202, has entry point, Version5 EABI, 
      Size of this header:               52 (bytes)
      Size of program headers:           32 (bytes)
      Number of program headers:         4
      Size of section headers:           40 (bytes)
      Number of section headers:         15
      Section header string table index: 14
    All of the sections and headers are all there:
    Section Headers:
      [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
      [ 1] .init             PROGBITS        000100b4 0000b4 00000c 00  AX  0   0  4
      [ 2] .text             PROGBITS        000100c0 0000c0 0d3bac 00  AX  0   0  8
      [ 3] .fini             PROGBITS        000e3c6c 0d3c6c 00000c 00  AX  0   0  4
      [ 4] .rodata           PROGBITS        000e3c78 0d3c78 00dde8 00   A  0   0  8
      [ 5] .ARM.exidx        ARM_EXIDX       000f1a60 0e1a60 000008 00  AL  2   0  4
      [ 6] .eh_frame         PROGBITS        000f1a68 0e1a68 000004 00   A  0   0  4
      [ 7] .init_array       INIT_ARRAY      00102000 0e2000 000004 00  WA  0   0  4
      [ 8] .fini_array       FINI_ARRAY      00102004 0e2004 000004 00  WA  0   0  4
      [ 9] .jcr              PROGBITS        00102008 0e2008 000004 00  WA  0   0  4
      [10] .data             PROGBITS        00102010 0e2010 011178 00  WA  0   0  8
      [11] .bss              NOBITS          00113188 0f3188 002850 00  WA  0   0  8
      [12] .comment          PROGBITS        00000000 0f3188 000011 01  MS  0   0  1
      [13] .ARM.attributes   ARM_ATTRIBUTES  00000000 0f3199 000031 00      0   0  1
      [14] .shstrtab         STRTAB          00000000 0f31ca 00007b 00      0   0  1
    Program Headers:
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
      EXIDX          0x0e1a60 0x000f1a60 0x000f1a60 0x00008 0x00008 R   0x4
      LOAD           0x000000 0x00010000 0x00010000 0xe1a6c 0xe1a6c R E 0x10000
      LOAD           0x0e2000 0x00102000 0x00102000 0x11188 0x139d8 RW  0x10000
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
    With a nice ARM attribute too:
    Attribute Section: aeabi
    File Attributes
      Tag_CPU_name: "ARM10TDMI"
      Tag_CPU_arch: v5T
      Tag_ARM_ISA_use: Yes
      Tag_THUMB_ISA_use: Thumb-1
      Tag_ABI_PCS_wchar_t: 4
      Tag_ABI_FP_rounding: Needed
      Tag_ABI_FP_denormal: Needed
      Tag_ABI_FP_exceptions: Needed
      Tag_ABI_FP_number_model: IEEE 754
      Tag_ABI_align_needed: 8-byte
      Tag_ABI_enum_size: int
      Tag_ABI_optimization_goals: Aggressive Size

    The binary seemed to have signature of Sample Matrix RSA-4096 Certificate, trailing this further, I found out it's the trace of the MatrixSSL certification used for the bot client to perform the secure HTTPS connection. I previously wrote this as a signature, corrected after being sure.

    00E9897  |  Sample Matrix RSA-4096 Certificate Authorit
    00E98CF  |  US1
    00E98DC  |  WA1
    00E98E9  |  Seattle1
    00E98FB  |  INSIDE Secure Corporation1
    00E991F  |  Test0
    00E9927  |  140324164110Z
    00E9936  |  170323164110Z0
    00E9946  |  1+0)
    00E9950  |  "Sample Matrix RSA-4096 Certificate1
    00E997E  |  US1
    00E998B  |  WA1
    00E9998  |  Seattle1"0 
    00E99AA  |  INSIDE Secure Corporation1
    00E99CE  |  Test0
    Also the binary is having MatrixSSL's code libraries for encryption operation.

    Well, a signed ELF binary with encryption support is absolutely okay right? Unless .. what if along with that you see a hardcoded coder's message like this? ↓

    View the binary's ASCII in the last part and you'll see the first email address.

    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's filename sent:

    And this is why this "adventure" was started..

    What is this ELF?

    This is a new ELF botnet malware, coded in Lua [link] language ( @$LuaVersion: Lua 5.3.0). It is the first time to find an lua language ELF compiled malware, specifically in ARM cpu architecture, 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 was still in fully undetected (in short: FUD) state when I wrote this analysis:

    At the time I firstly reverse-engineered ELF Linux/Luabot, I was on making short announcement & awareness about this new threat:

    But yet, that report is not enough to explain the threat, there are a lot of things in this malware that can not be explained in one picture....

    The following sections will explain 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 post-infected form of 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. On some Linux system that is secured well, and if the malware is not getting the uid zero (read: root), the setrlimit() syscall can't be executed, and the coder forgot to sanitize stderr(perror) for it. So if you see error message of "Setting RLIMIT_NOFILE failed, errno 1" as output of any suspicious binary, your system is possibly infected.

  • Just right before forking is done, the malware will send you following message:
    "Hi. Mail me if u want:"

    I don't email him but I was checking these email addresses in Yandex Mail, by trying to make new account under using these accounts, and someone is using it already. Meaning, the email addresses are there and we have high possibility owned by the bot coder. Picture? ↓
  • And then open the file socket bound to the mutex formed by:
    which 203508 in the part of mutex is hard-coded number in this ELF (see screenshot of arm_lsb filename) and it is actually the version of this botnet, I'll explain and snip about this version matter in the next part of this post.

  • 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 real deal, the malware main process (Noted that the initial process will be dead at this time). The first fork process, ..will be bound via unix file socket with the mutex created previously and will sit there and launched wait() syscall, 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 system's active process names & PID in /proc/{PID}/* with utilizing getidents64 to enumerate them, practically it's an approach to see what's running and what values are actually can be fetch, i.e.:
    call getdents64(%d, {
    {d_ino=1, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} 
    {d_ino=1, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} 
    {d_ino=4026532032, d_off=11, d_type=DT_REG, d_reclen=24, d_name="kmsg"} 
    {d_ino=4026532031, d_off=12, d_type=DT_REG, d_reclen=32, d_name="softirqs"} 
    {d_ino=4026532030, d_off=13, d_type=DT_REG, d_reclen=32, d_name="version"} 
    {d_ino=4026532029, d_off=14, d_type=DT_REG, d_reclen=32, d_name="uptime"} 
    {d_ino=4026532028, d_off=15, d_type=DT_REG, d_reclen=24, d_name="stat"} 
    {d_ino=4026532027, d_off=16, d_type=DT_REG, d_reclen=32, d_name="meminfo"} 
    {d_ino=4026532026, d_off=17, d_type=DT_REG, d_reclen=32, d_name="loadavg"} 
    {d_ino=4026532025, d_off=18, d_type=DT_REG, d_reclen=32, d_name="interrupts"} 
    {d_ino=4026532024, d_off=19, d_type=DT_REG, d_reclen=32, d_name="devices"} 
    {d_ino=4026532023, d_off=20, d_type=DT_REG, d_reclen=32, d_name="cpuinfo"} 
    {d_ino=4026532022, d_off=21, d_type=DT_REG, d_reclen=32, d_name="consoles"} 
    {d_ino=4026532021, d_off=22, d_type=DT_REG, d_reclen=32, d_name="cmdline"} 
    {d_ino=4026532020, d_off=23, d_type=DT_REG, d_reclen=32, d_name="locks"} 
    {d_ino=4026532019, d_off=24, d_type=DT_REG, d_reclen=32, d_name="filesystems"} 
    {d_ino=4026532018, d_off=25, d_type=DT_REG, d_reclen=32, d_name="slabinfo"} 
    This technique is also very handy to secure your process from some malicious infection, I am doing it myself to analyze some ELF rootkits or kernel modular malware that hooked processes.

    Intermezzo: Some of my ELF malware analysis protip:

    For the crooks who think that I use any kind of *trace scheme for reading your UNIX malcode's work, well.. dream on! You can do harder or hit the school chair once again, because I never trust ptrace for such purpose (except for my NIX related development debugs). For the good folks, please see my previous published presentation in ELF Reversing Workshop, explaining a nice trick I use to beat malcoder's scheme in evading debugging tricks on infecting UNIX systems. This know-how was successfully presented, demo and transferred to senior reversers in my community.

  • Checking the current user's privilege by getuid32, geteuid32, getgid32, getegid32
  • Checking the network interface name and its IP via open() to /proc/net/route. opened a check socket and using ioctl().
  • Assemble BotID & writing the ID as stdout, with the following formulation:
    "Bot id is \t{IFACE-NAME}-{IPADDR}-{NUM}[10-9]{6}:{Version}" 
    The formula can be seen if we hack further, with the lua script traces:
    0000 0000 2240 0000 2028 2564 2b29 2040  ...."@.. (%d+) @
    6262 6f74 5f6d 7574 6578 5f28 2564 2b29  bbot_mutex_(%d+)
    0000 0000 0000 0000 f000 0000 d101 0000  ................
    So it seems that the coder is forming the ID and mutex with the version value intact.
    In relation with the data above, we know how the Luabot will not duplicate the infection. These are lua scripts from the reversed lua script, formed as similar as per below:

    Yes, it checks for the version of the current running botnet platform before it daemonized itself. If it found the current running version is older, LuaBot will exit the current running instance.
  • The malware then run test_domain() lua function to load lookup domains:
    0x012b7390  0000 0000 726f 6375 676f 6f67 6c65 2e63
    0x012b73a0  6f6d 0034 343a 2063 3100 0000 3100 0000  om.44: c1...1...
    0x012b73c0  0000 0000 726d 6973 6661 6365 626f 6f6b  ........facebook
    0x012b73d0  2e63 6f6d 0000 0000 3100 0000 3100 0000  .com....1...1...
    0x012b73f0  0000 0000 c09e 0200 6261 6964 752e 636f
    0x012b7410  e073 2b01 0402 0000 c1c4 d41a 0a00 0000  .s+.............
    0x012b7420  0000 0000 c8af 2c01 616d 617a 6f6e 2e63  ......,.amazon.c
    0x012b7430  6f6d 0001 a076 2b01 c040 2b01 e040 2b01  om...v+..@+..@+.
    0x01296de0  0006 000c 0977 696b 6970 6564 6961 036f  .....wikipedia.o
    0x01296df0  7267 0000 0100 01c0 1600 0200 0100 02a3  rg..............
    which are,,, and
  • The domains will be looked up to the below DNS servers: | |32934 | | FACEBOOK | US | | Facebook Inc. | |36629 | | MGTLD | US | | Verisign Global Registry Services | |36625 | | KGTLD | US | | VeriSign Infrastructure & Operations||4808 | | CHINA169 | CN | | China Unicom Beijing Province Network||12008 | | ULTRADNS | US | | UltraDNS Corp
    The purpose of these checks is understandable, the Linux/Luabot is making sure that after infecting a node it has the intenet connection or not. And to avoid suspicious traffic alert it queries SNS in every possible topology internet location. At this stage we can see that the coder seems has no intention to infect Russia Federation or East Europe related network since there is no SNS services in the territory are in check, like VK or Yandex or others. Even it is clearly made by someone who use Russian language (hint: @yandex.RU). Interesting.
  • Next, the malware will connect to the CNC in and send an HTTP/1.1 GET command. Linux/LuaBot was firstly socket-connecting to by port TCP/1085, there's no further activity in this connected port, assuming the checking scheme to poke the CNC and to make sure the CNC is up.
    connect(8, {sa_family=AF_INET, sin_port=htons("1085"), sin_addr=inet_addr("")}, 16)
    And then, followed by the HTTP request to port TCP/80 of the same IP address:
    GET "/bot?bid={IFACE}-{IPADDR}-{NUM}0123456:{MUTEX} HTTP/1.1\r\n"
    Connection: "close\r\n"
    Host: "\r\n\r\n"
    The origin of this CNC:||49981 | | WORLDSTREAM | NL
    I recorded this CNC connection session in PCAP with its encrypted form replies from
    As you can see in the reply traffic part, it contains data of specific format of:
    script|{Encrypted data}|endscript

    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 the data fetched is processed (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, that's using socket function to communicate with any of those nodes. It is suggested the access to open SOCKS which is specifically bound to those IP.

    The listed IP addresses are all nodes of AS4998 from, and 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, like maybe as a failover for CNC, or open socks for a merchandise. WorldStraem Hosting in Netherlands should be warned for their abusive user, which is possibly originated (strongly) from Russia.

    There is another interesting data found, a botnet management trace

    PS: There are also some passed values like (traced sent from the lua interpreter to C bind commands), which is used to monitor the bot performance like:

    And now we know exactly why Linux/Luabot is using getident64() for reading all of these..

    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 addresses from: | |50673 | | SERVERIUS | NL | | ITL Company |  |34702 | | WAVECOM | EE | | Aktsiaselts WaveCom | |16276 | | OVH | FR | | OVH Hosting Inc
    These IP are involved to the botnet activity, could be the victim for the infection or the attack, it is maybe wise to check or contact these nodes' authority further.. There is more explanation of this code in the "What is the purpose of Linux/LuaBot?" section.

    Okay, so far we found many network infrastructure were actually prepared by this botnet...let's continue with the malware process:

  • 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:
    bind(8, {sa_family=AF_INET, sin_port=htons("11833"), sin_addr=inet_addr("")}
    listen(8, 10240)
  • Below is the snapshot for infected state of a linux box by the Linux/LuaBot is as per tested case:

    Noted, the UDP/41029 is for 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, and proof of the analysis.

    There are plenty trace of lua code can be found in this single cute tiny ARM ELF, but my favorite is the way Linux/LuaBot sends HTTP request to the remote sites, for the CNC purpose or proxy purpose.

    The decrypted stub that contains IP bulk are data that is parsed to the hardcoded lua XMLHttpRequest function. The reversing effort (read: hacks) shows the below coded API in lua "pseudo function" used for the purpose:

    So now we know why the MatrixSSL signature is in there, it is used for having the HTTPS connection to any web server using this API.

    Below are some nice catches that's maybe worth to dig more :)

    You can see the arrays say: "Stop breaking" lol :) ..sorry, it's a bit too late!
    Okay, enough joking, what's this trace? If you ever see how some skid in hackerland trying to bypass Cloudflare protected sites by some javascript, here is one, extracted from this LuaBot. A ping! to Cloudflare to be aware.
    Well, you can easily put anything you want in a botnet if it is based on scripts, can't you?

    Next..let's ping Sucuri team for this:

    This is also the same type as above figure. traces of usage some JS, this part is for Sucuri protection. See the next section for the detail..

    The coder loves bad vocabulary.. :)

    I think he described his coded malware very well in one word above :D

    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 originated from resolver.lua and it is interacted with the udp.lua, as per its name suggesting a lua library used to form User Datagram Protocol function and struct, This is showing the Linux/LuaBot has its own lua resolver function for the DNS query, and has ability to form its own UDP packet to be sent to any destination, so as its capability to act as independent DNS resolver. Keep this finding in mind, and go look deeper into the source codes extracted, you'll find the HTTP connectivity function, SOCKS server, code for creation sockets for performing TCP along with the mentioned UDP, with some supported libraries intact. If you know what I mean: This botnet was designed doesn't need infected system's resource at all to perform its operation!

    There's also the telnet.lua codes compiled after interpreted via lua 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.

    Other functions like encoding/decoding coded in base64, a usage of utilizing json operation with its execution to several purpose (I don't want to disclose this yet), and other lua sources are for supporting the botnet operational activity for this malware.

    And, so far...I can't proof any code that can triggered functions in a hostile action, like, being called for flooding or DDoS for example. But, since what I have now is only a one tiny cute ARM file sample, I may miss something with only so few reference I got..

    Another thing that I don't seek deeper is the "penetrate_sucuri" part, a symbol (a reversed lua function) traced to be coded in the lua source file: *cough* "checkanus_sucuranus.lua" and there's also "checkanus.lua", which I took only a peek for it, it forms (http) action to a defined target. I'll leave the engineer experts on Sucuri team friends to analyze that part deeper, but by its name it may suggested to a penetration or a bypassing method into their protection scheme.
    EDIT: see the below section to see how the Sucuri or Cloudflare cracking script is used by Linux/Luabot.

    Okay..okay..So what's the purpose of this malware??

    This malware is served as botnet aiming ARM architecture IoT Linux machines, and it is built with encrypted C2 communication protocol. The botnet is using MatrixSSL on ed25519 crypto to for the overall CNC communication commands. The communication data is also XOR masked to prevent textual easy readings or leaks. The concept of the encryption used is not that savvy by my personal opinion, but by signing its CNC communication commands is preventing Linux/Luabot CNC communication from being hijacked easily, which is the purpose for usage of MatrixSSL on this botnet.

    If you see carefully in the above description, there are the "cmdline", and "cmdline args" spotted in several parts in ELF reversed code, forensics results and also source code trace too. The hacker can do a lot of things with it via a crypted remote commands pushed to his bots through this command interface, so this bot can be used to execution for the lua script. So one of the botnet functionality is the remote execution via this interface. For instance, you can execute the bot to perform an action by the command of:

    ./LuaBot_filename [path]{Luascript_filename}.lua

    Linux/Luabot works in lua script as modular basis, seeing by the compiling trace and size, it was built from what I suspect from a native Lua compiler (see reference in latest version of Lua) with libc. It is enriched with the possible additional, or modification, and improvement as a framework that can be modified in a snap thus to be pushed to the next infection chain. This is what makes the design for botnet is flexible, and all can be done in scripting mode.

    EDIT: I was just receiving request to PoC the argument execution, and also from other email asked to post some scripts I reversed, for the command argument execution I can share it as per below, these are a reversed code and it goes something like below, you'll get the idea:

    To make a further amazement, the Linux/LuaBot is not only having one interpreter, which is lua, mainly, obviously, but it has the javascript interpreter that can execute the javascript commands that is needed to crack some protected sites like Cloudflare or Sucuri. Some traces I showed above are part of the proof for this concept. For this purpose. the coder seems making much effort to integrate V7 embedded JavaScript engine inside, The JavaScripts integrated in the Lua scripts with, sorry, *cough* "*anus*.lua" scripts part is meant for bypassing Sucuri protected site or to evade Cloudflare protection sites, so show the origin IP location. This is also suggesting offensive function.

    I kept "this" information in secret before being very sure before writing it, but I think I now figured how the coder sells this botnet, by what service. The merchandise of selling is mostly the created or served SOCKS itself. As we are all know that many of the blackhat crooks are using SOCKS for proxy servicing their daily activity like for cushion to send spams, or trafficking for a malware infection, cushion for exploiting a site or device, and so on. And the config pushed to the Linux/LuaBot contains the latest SOCKS data to be served for that purpose.

    In one of pictures previously shown, here I pasted it again below, explaining a great deal on how the coder (which also the herder) is using these socks practically:

    ..this is a nice demonstration for a temporary usage of SOCKS itself for some bad purpose. In the case it's showing the temporary usage for some defined SOCKS to be leaned up afterward. Such command like this that can be pushed by the command from the CNC to each of the Linux/LuaBot client. The shown picture is explaining the attempt to use SOCKS for cushion to illegal activities like: attacking the mentioned IP addresses for the bad purpose or hacking and so on... Linux/LuaBot is capable to serve as a framework providing bad guys with this cushion.

    Another thing that I am quite certain too now is, different to the most ELF malware or Linux botnet spotted before, which are mostly communicating to the remote site via web protocol (to download something, or to fetch some data) is using wget (either busybox or static ones), or maybe using cURL library/command, LuaBot is utilizing the MatrixSSL and XMLHttpRequest to make it possible to communicate to any web remote site on his own native code and with is having full support on SSL encryption (via HTTPS). I'd say this is smart.

    So far we think the coder is making his point that he can create fully undetected ELF botnet with encrypted communication easily from using lua script/language aiming IoT, and he is promoting Linux/LuaBot that can be used for "Botnet As a (malicious) Service" by selling SOCKS connection and also serving the et cetera payloads. That's why he put some of his email contacts openly...he tries to say that "he needs a job".

    There is a serious flaw in this botnet, which made me possible to reverse most of the things, for the security purpose let this be a secret, also, there are plenty of undone and unused parts, along with some unnecessary traced codes too. Our team is now having a strong opinion that parts of the sample is on development stage.
    Please take the rain check for these part as additional information, I will update information upon new reversing result confirmed.

    Update: The "separate" ELF DDoS "module" for Linux/LuaBot

    Linux/Luabot DDoS effort using ELF binary module

    Approximately 4 hours ago the same person was sending another ARM in ELF stripped sample, thank you again.

    This sample [link] is explaining the "missing link" of the DDoS function expected from this botnet. This module was coded in Lua and using the same static compilation environment, with zero detection ratio too. This additional ELF could be "the payload" that we are waiting for. This module is explaining a lot of detail on how the attack is performed, a simple download and execution command executed by the infected nodes from remote access via shell or internal command line interface is enough to trigger this attack.

    Below is the file details:

    :> !file dcc
    dcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
    :> !md5sum dcc
    8e7637d72e522cb52012c02eb8ddfdbe  dcc
    :> date
    Tue, 06 Sep 2016 14:14:09 GMT + 0

    The targeted site is hard coded in this ELF module, as per seen below:

    HTTP (L7) GET headers used for flooding is generated with following composition:

    The attack process are mainly managed in main function at [0x00010ac0] and the loop for flood process can be confirmed between the range of address described below;

    Noted, the binary needs specific "environment", if you're inexperienced with handling it, you may meet a SIGILL (sig 4) during runtime if the condition is unmatched.

    :> dc
    [+] signal 4 aka SIGILL received 0

    The interesting trace found in the DoS module ELF is as per below screenshot, a self explanatory.

    Linux/Luabot DDoS effort using the Lua script module

    As per explained in the previous parts, Lua script can be executed by Linux/LuaBot via argument for the command line execution too. The PoC for it can be reversed from the botnet itself like per following reformed Lua script. I put a lot of comments in the picture for understanding how it does:

    Thank's for requesting me to post this script.. I believe I had all of the malicious aspects and parts reversed well by now.

    Epilogue and follow up

  • There are plenty new ELF malware coming & lurking our network recently & hitting out Linux layer IoT and services badly, 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 protection is available now. If your network is infected with this variant of Linux/LuaBot, the alert will come up under below identifications:
      2023155 - ET TROJAN Linux/LuaBot CnC Beacon
      2023156 - ET TROJAN Linux/LuaBot CnC Beacon Response
    Thank you Emerging Threat Labs [link] engineers!
  • Samples are shared by RCE expert Xylit0l [link] to threat research community in KernelMode [link]
  • Detection ratio from AntiVirus is raised from zero to 20 within 5 days:
  • Sucuri top hacker & his experts is analyzing the reversed code for mitigating evasion:
  • 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.
  • This analysis was done by open source OS (FreeBSD) infrastructure and using plenty of UNIX/Linux sysadmin tools, for RE itself I use only radare [link], I dedicated this post to the R2CON [link]

    If you see the binary that works in similar malicious way in your Linux box please kindly share us the sample by uploading them via our sample uploader-->[link]

    Thank you very much for the internet media awareness

    We, MMD thank our good friends in internet media for your fast awareness of this threat:
    1. Softpedia [link]
    2. SC Magazine [link]
    3. Xakep .RU [link]
    4. Security News .GR [link]
    5. SecurityLab .RU [link]
    6. Information Security News[link]
    7. Infosec Island [link]
    8. ISS Source [link]
    9. Security Affairs [link]
    and others who are not mentioned yet (I am sorry!)

    Stay safe friends!


    Reversed, written and analyzed by @unixfreaxjp [link], September 5th 2016.