{"id":602,"date":"2017-06-18T09:03:33","date_gmt":"2017-06-18T17:03:33","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=602"},"modified":"2017-06-18T09:03:33","modified_gmt":"2017-06-18T17:03:33","slug":"automatic-identification-of-mirai-original-code","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/automatic-identification-of-mirai-original-code\/","title":{"rendered":"Automatic Identification of Mirai Original Code"},"content":{"rendered":"

Context<\/span><\/h1>\n

One of the major threat on embedded devices — the so-called \u201cInternet of things\u201d –, is the infamous Mirai malicious software, whose source code was made <\/span>public<\/span><\/a> in September 2016. This malware has the ability to infect devices by brute-forcing Telnet credentials, and is primarily used to launch distributed denial-of-service attacks. <\/span><\/p>\n

Since the source code release, numerous Mirai variants have been deployed in the wild by miscreants, like the one we documented in a recent <\/span>post<\/span><\/a>. <\/span><\/p>\n

In this blog we will first take a quick look at another Mirai-based malware, quite original in its own way, to then introduce our novel signature system that can identify Mirai original code in executables. <\/span><\/p>\n

Yet Another Mirai Variant<\/span><\/h1>\n

On May 18th, ESET’s Michal Mal\u00edk mentioned on <\/span>Twitter<\/span><\/a> a Mirai-based sample for MIPS that grabbed our attention. Michal pointed out new functionalities like a custom update mechanism, and some strange debug routines, so we decided to take a look with our brand new MIPS decompiler. It should be noted that this sample comes with the debug symbols, which explains the names present in the decompiler output.<\/span><\/p>\n

The malware logic starts in its <\/span>main()<\/span><\/em> routine, which is shown below as decompiled by JEB. <\/span><\/p>\n

<\/p>\n

Briefly summarized, this routine first sets up a few signal handlers, in particular to create a core file in case of segmentation fault. It then calls a homemade <\/span>panic()<\/span><\/em>\u00a0function — not to be confused with the standard Linux <\/span>panic()<\/span><\/a><\/em>\u00a0routine. The <\/span>panic()<\/span><\/em> function code is shown below, as seen in JEB.<\/span><\/p>\n

<\/p>\n

While the routine native code — seen on the left side — can be pretty dry to read, the decompiled code on the right side is fairly straightforward: a file named <\/span>file.txt<\/span><\/em> is opened and a given error message is written to it, accompanied by a custom system footprint built by the <\/span>footprint12()<\/span><\/em> routine.<\/span><\/p>\n

Finally, <\/span>main()<\/span><\/em> calls the <\/span>kill_run_mobile1()<\/span><\/em> function, which first kills any application listening on TCP port 18899 (likely others instances of the same malware), \u00a0and then creates a thread on the <\/span>mobile_loop1()<\/span><\/em> function, which is shown below.<\/span><\/p>\n

<\/p>\n

The new thread will listen for incoming connections and process them through a custom command handler. As can be seen from the numerous debug messages in the decompiled code, the code is still in a development stage.<\/p>\n

To summarize, this sample appears to be an attempt to repackage Mirai source code with a different update mechanism, and is still in development, as can be seen from the presence of debug routines, and the fact that plenty of code remains unused.<\/span><\/p>\n

While the technical quality of this sample is dubious, it illustrates one of the major consequence of Mirai source code public release: it has lowered the bar of entry for malicious software developers. In particular, we can expect the strain of Mirai-based malicious software to continue to grow in the following months. <\/span><\/p>\n

Native Code Signatures<\/span><\/h1>\n

In a context where numerous Mirai-based malware are deployed in the wild, having the ability to identify original Mirai code becomes particularly useful, as it allows the analyst to focus only on the new functionalities in each sample. <\/span><\/p>\n

Of course, most of Mirai-based samples do not come with symbols, and hence we need a proper mechanism to identify Mirai original code. That is the purpose of the native signature system released with JEB 2.3, which can actually identify code for all native architectures supported by JEB (x86, ARM, MIPS and the associated variants).<\/span><\/p>\n

The objective of this signature system is to identify native routines with a <\/span>minimal<\/span><\/i> number of false positives. In others words, we want to fully trust a successful identification, while we may miss some known routines.<\/span><\/p>\n

To realize this low false positives goal, our signatures are primarily based on two <\/span>features<\/span><\/i>:<\/span><\/p>\n