Background On Sep. 30, 2016, the source code for M irai , a prolific internet wo
ID: 3886313 • Letter: B
Question
Background
On Sep. 30, 2016, the source code for M irai, a prolific internet worm/botnet targeting
embedded/IoT Linux devices, was released on the website hackforums.com by its author, an
individual pseudonom ously known only as A nna-senpai.1 Because Anni-senpai had claimed that
Mirai had infected over 380,000 devices, and that the malware had been responsible for a
record 620 Gbps distributed denial-of-service (“DDoS”) attack, the computer security community
very quickly took int erest in examining the source code and understanding Mirai’s operation.
The Security Research Group (SRG) at Rapidity Networks, Inc. also took an interest in
understanding the Mirai worm, and after completing its initial examination of the released source
code, set out to capture a sample in the wild. To do this, the SRG deployed a network of
medium-interaction honeypots–computer systems intended to attract malicious activity for
information-gathering purposes–configured to mimic a vulnerable IoT device of the sort Mirai
infects, in the hopes that a live Mirai node would soon discover the honeypot system and
attempt to conscript it.
On Oct. 5, 2016, a node within the honeypot network reported internet activity that very closely
resembled the reconnaissance and infection behaviors of M irai. However, upon closer analysis,
the SRG discovered that the sample it had captured was not Mirai, but rather something
considerably more sophisticated. The SRG conducted online searches in an attempt to identify
its unknown specimen, but could not find any indication that this particular worm had yet been
discovered by the broader security community.
Becaus e this worm very closely mimics the discovery and attack phases of Mirai, a worm
named for the Japanese word for “future,” the SRG researchers affectionately gave this sample
the moniker of Hajime–Japanese for “beginning.”
Like many internet worms, the Hajime malware has a lifecycle. A Hajime infection begins when
a node already in the Hajime network–scanning random IPv4 addresses on the public
internet–discovers a device which accepts connections on TCP port 23, the designated port for
the Telnet service. The attacking H ajime node attempts several username and password
combinations from its hardcoded list of credentials and, upon being granted entry, examines the
target system and begins its infection in stages. The first stage is a small, short-lived file-transfer
program which connects back to the attacking node and copies down a much larger download
program. The download program–the second stage–joins a peer-to-peer decentralized network
and retrieves its configuration and a scanning program. The scanning program searches the
public internet for more vulnerable systems to infect, thus continuing the lifecycle.
Stage 0: Reconnaissance and infection phase
This stage occurs completely over the initial Telnet session and does not actually involve an
uploaded binary. As such, we have opted to call this “stage 0,” because while it is important in
establishing a foothold in a vulnerable device, there is no actual malware present on the device
yet. All logic for stage 0 is actually implemented in the attacking node.
An attacking node scans the IPv4 address space at random. It repeatedly generates random
IPv4 addresses, attempts to connect to them on port 23, and attempts to log in by sequentially
going through a table of username/password credential pairs.
After each pair of credentials, Hajime waits for a response from the target device. If the
credentials are rejected, Hajime closes the current connection, reconnects, and tries the next
pair. While many of these credential pairs can be found in M irai (i.e. their hardcoded credentials
lists are similar), they differ in their login behavior: H ajime follows its credentials list sequentially,
while Mirai makes login attempts in a weighted random order.
Once a successful username/password combination is found, Hajime attempts to get access to
a Linux shell by sending the following 5 lines:
enable
system
shell
sh
/bin/busybox ECCHI
The first 4 lines are sent in a blind attempt to navigate whatever vendor-specific command-line
interface (CLI) the Telnet server implements. enable is a common CLI command to allow access
Rapidity Networks
Security Research Group Page 3 of 18
to privileged-mode commands. system attempts to navigate to a menu of system-management
options. shell and sh attempt to run a Bourne shell. If any command fails, it will fail
The purpose of the final /bin/busybox ECCHI line is to test that a Linux shell has actually been
started. A proprietary CLI is likely to reject the command, but a legitimate Linux shell would
execute Busybox, which will reject the argument with ECCHI: applet not found , letting Hajime
know that it has a bona fide Linux shell.
Once Hajime has confirmed its access to the target device’s shell, it begins analyzing the target
device. First, it checks the system mounts for a writeable location in the target filesystem:
# cat /proc/mounts; /bin/busybox ECCHI
Note the repeat of the venerable /bin/busybox ECCHI command, which serves a purpose not
dissimilar to its use before: Hajime and M irai both use the E CCHI: applet not found signature to
find the end of the command line’s output.
Hajime picks the first writeable path that is not /proc, /sys, or / and uses that as its working path.
This sequence serves multiple purposes. First, it tests if there’s already a stage1 binary present.
Second, it tests that the chosen working directory really is writeable. Finally, it retrieves the
/bin/echo binary so that Hajime can inspect its header to determine the target’s processor
architecture. Once the target processor is determined, Hajime uploads and executes the stage1
binary:
# echo -ne
"ELF(
x00T4D4
8" > .s; /bin/busybox
ECCHI
# echo -ne
"
xe3 - f
0 Ѝ`p " >> .s; /bin/busybox
ECCHI
# echo -ne
"- fЍOOM
xe2PEK/
Explanation / Answer
The world has seen different deadly malware ,virus attacks which made into the headlines.One of such was on Sep 20,2016 the source code for M rai a prolific interent worn targetting the embedded Linux devices realesed by the author of the website of hackforums.com under the pen name of A nna-senpai.this worm affected around 380000 devices and it was also responsible for a record of 620 Gbps DDOS attack.Like different worm and a more powerful one came with a name of HAJIME which in Japanese means "BEGINING".But this one was different.Hajime had a lifecycle it starts the infection when a node is already in the Hajime network-scanning random IPv4 addresses on the public
internet–discovers a device which accepts connections on TCP port 23, the designated port for the Telnet service.The attack for the node start by by cracking the username and password combination from its list.As it enters into the system the attack begins.The first stage is a small, short-lived file-transfer
program which connects back to the attacking node and copies down a much larger download
program. The download program–the second stage–joins a peer-to-peer decentralized network
and retrieves its configuration and a scanning program. The scanning program searches the
public internet for more vulnerable systems to infect, thus continuing the lifecycle.our researchers were able to catch and disassemble a fresh stage1
binary fast enough to get the IP:port information from an attacking host before it closed its TCP
socket.
Hajime does not verify that connections to its malware distribution port are originating from
attacked hosts. This allowed the SRG researchers to connect later and download the stage2
binary at their leisure.The second stage is the final and the last stage of the Hajime worm.It is the sole responsible for retrieving and executing any further payloads which are taken off the P2P network.
This is how the malware Hajime works and damage the system.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.