Recently, security researcher @unixfreaxjp discovered a new variant of the Okiru botnet, which includes an ELF malware that targets the ARC CPU architecture. This was a significant discovery since ARC or Argonaut RISC Core processors are widely used for System on a Chip (SoC) in IoT devices, and are currently being dispatched in more than 1.5 billion products per year. Arc processors are also the second most popular CPU in the world, and have been licensed by more than 190 companies. The sheer number of potential targets makes this botnet variant more dangerous than ever, and could potentially cause the same degree of havoc as occurred with the DNS service provider Dyn.
The first Okiru sample appeared around October 2017, and FortiGuard Labs created a write up of its development last December, which included worm capabilities and the embedding of two different exploits. As a follow up, we will now share our findings on the latest Okiru variant that targets ARC processors.
Let’s get right to it.
ARC sample: 2356c1d64995ee825c728957f7428543101c3271ac46e78ce2c98278a4480e4d
During our analysis of the Okiru sample, we found it had ELF files embedded in its code. To dump the embedded files we created an IDA python script and searched the magic string “7F 45 4C 46” (ELF). With this we were able to uncover 11 files with different architectures.
Fig 1. Ida Output Window
Upon analysis of the dumped file we determined that these executables function as downloaders. This means that Okiru has the capability to infect a wide range of IOT devices as long as they’re supported by the architecture of its downloaders.
So are these embedded downloaders new? Well, no.
To explain, let’s take a look at another Okiru sample, which was seen October 31, 2017:
Intel x86 sample: e5fc493874f2a49e1a1594f3ee2254fa30e6dd69c6f24d24a08a562f03b2fd26
This sample has the same embedded ELF downloaders as the Okiru ARC. Also, the code includes a function for checking the architecture, as shown below. The most interesting elemet is the last one, where e_machine is compared to 93, which is the ARC International ARCompact processor.
Fig 2. Targeted Architecture
Even though the ARC Okiru was only seen recently, based on the sample from last October it is clear that Okiru has been checking for ARC devices for some time. This suggests that even though it wasn’t supported at that time, it was already on Okiru’s cross-hairs.
Having dumped the 11 downloader files from Okiru, we focused our analysis on the Intel x86 sample. The pseudocode of the downloader is quite straight-forward, starting by connecting to its C&C 220.127.116.11 at port 5543. Interestingly, the port used is not a reserved port and could be beneficial for bypassing firewall rules if not properly configured.
Fig 3. Downloader Pseudocode
The data being sent to its C&C is a hardcoded_value that corresponds to the device’s architecture (see table 1). During our analysis, the C&C was already down and had no response. But reading the code we can see that the C&C responds with some data, which we suspect is the main payload with the correct architecture, and afterwards, this data is written locally to the device.
The following are the supported architectures for the payload (as of now.)
Table 1. Architecture with the hardcoded values
By actively adding support for other architectures, Okiru has created a leverage to its other Mirai-based botnets. And with majority of IoT devices still using default and/or predictable passwords, only time will tell on the number of botnets that Okiru will be able to control.
FortiGuard Labs will continue to monitor the latest threats and developments in IoT and share interesting findings.
We thank our teammates Jasper Manuel and Dario Durando for the additional analysis.
-= FortiGuard Lion Team =-
e5fc493874f2a49e1a1594f3ee2254fa30e6dd69c6f24d24a08a562f03b2fd26 – ELF/Mirai.AO!tr
2356c1d64995ee825c728957f7428543101c3271ac46e78ce2c98278a4480e4d – Linux/Mirai.Y!tr.bdr