Linux Shishiga malware using LUA scripts

Linux Shishiga malware using LUA scripts

The usage of the BitTorrent protocol and Lua modules separates Linux/Shishiga from other types of malware, according to analysis by ESET.

The usage of the BitTorrent protocol and Lua modules separates Linux/Shishiga from other types of malware, according to analysis by ESET.

Among all the Linux samples that we receive every day, we noticed one sample detected only by Dr.Web – their detection name was Linux.LuaBot. We deemed this to be suspicious as our detection rates for the Luabot family have generally been high. Upon analysis, it turned out that this was, indeed, a bot written in Lua, but it represents a new family, and is not related to previously seen Luabot malware. Thus, we’ve given it a new name: Linux/Shishiga. It uses 4 different protocols (SSH – Telnet – HTTP – BitTorrent) and Lua scripts for modularity.

How to Meet Shishiga?

Linux/Shishiga targets GNU/Linux systems. Its infection vector is a very common one: bruteforcing weak credentials based on a password list. It does this in a similar fashion to Linux/Moose with the added capability to bruteforce SSH credentials too. Here is the complete credentials list at the time of writing:


We found several binaries of Linux/Shishiga for various architectures such as MIPS (both big- and little-endian), ARM (armv4l), i686, and also PowerPC. These are common for IoT devices. We think that other architectures like SPARC, SH-4 or m68k could be supported as we will explain later.

Shishiga’s skills

Linux/Shishiga is a binary packed with UPX 3.91 (Ultimate Packer for Executables), but the UPX tool will have trouble unpacking these binaries because Shishiga adds data at the end of the packed file.

After unpacking, we see that it’s statically linked with the Lua runtime library and stripped of all symbols.

Once executed, the binary will initialize the malware Lua module with the following methods:

Malware methods

The getmods method will return the archive blob as we will explain later. Then hardcoded Lua code (malware.lua) is executed via the luaL_loadstring and lua_pcall functions. The Lua code is quite straightforward, but here is a quick walkthrough of the source code without any modifications on our part.

(1) open the malware executable file from /proc/self/exe and return its content;
(2) retrieve the zlib archive via getmods method, decompresses it, then parse it using tags and store it in a Lua’s array;
(3) call main.lua module;

There is an exhaustive list of all Lua scripts found in the IoCs section. Most of them have self-explanatory filenames, but here is a brief summary of some of them.


  • retrieve the configuration file or servers from config.lua;
  • if unable to reach the current default server, change to a different server;
  • send files (reports or accounts, both JSON formatted);
  • execute tasks from task list retrieved from the C&C server;

bfssh.lua / bftelnet.lua

  • module to bruteforce SSH and Telnet logins;
  • check if the command echo -en "\\x31\\x33\\x33\\x37" outputs 1337; if not, exit else continue;
  • device architecture is determined from the /bin/ls file by running cat /bin/ls and parsing the ELF header, see below;
  • spread the malware (both .lm and .dm files) according to the device architecture;
  • save successful credentials;

The architecture checking code is as follows:

bfssh.lua, getArchELF method
(1) every ELF file has to start with \x7fELF
(2) ftype that represents e_type (ELF file type = executable, shared etc.) is not used
(3) bits represents e_ident[EI_CLASS] (32-bit or 64-bit), denc represents e_ident[EI_DATA] (little or big endian), and farch represents e_machine in the ELF header
bfssh.lua, getArchName method
(1) bits is not used
(2) check if file is for MIPS little endian (e_machine == EM_MIPS and e_ident[EI_DATA] == ELFDATA2LSB)
(3) check if file is for Intel 80386 or Intel 80860 or AMD x86-64 (e_machine == EM_386 or e_machine == EM_860 or e_machine == EM_X86_64)


  • contains publicKey to verify the signature of the binary (.lm or .dm);
  • contains bootstrap nodes list;
  • contains filenames of .bt files, port numbers of SOCKS and HTTP server;
  • contains IP address of the server (probably C&C server);


  • persistence method depending on the privilege (root or user)


  • used to generate random /16 networks that are not local

worm.lua (this script was removed in the latest version of Linux/Shishiga)

  • allows scanning on a given port;
  • allows upload;
  • gets information from the new infected server;

The readme.lua script has a message banner that grabs your attention, if you speak Russian:

This translates to:

It seems that the malware author was inspired by E.Letov and his album Everything goes according to plan – see the last verse of the title song.

Over the past few weeks, we observed some minor changes like parts of some modules being rewritten, addition of testing modules, removal of redundant files, but nothing especially noteworthy.

While the main binary is named <architecture>.lm, we also managed to retrieve binaries with the following name <architecture>.dm – a simple backdoor that listens on (all IPv4 addresses) port 2015. One of the small changes was in the name of this backdoor binary – it changed from dl to dm.

Shishiga communication

Linux/Shishiga can communicate using any of the modules httpproto.lua, btloader.lua or server.lua. The httpproto.lua module has functions that allow the given data to be encoded or decoded, and make HTTP POST and GET requests. The source code below shows the process of encoding data.


btloader.lua uses the torrent.lua module (a wrapper for BitTorrent functions) to save or load nodes from the nodes.cfg file. It also retrieves its configuration data from {server,update,script}.bt files (in Bencode format) and uses the BitTorrent protocol to check for new versions of these files. allows the execution of a Lua script and allows executing the .lm binary. Below are examples of decoded .bt files shown as Python dictionaries.
(1) signature
(2) public key

Finally, the server.lua module’s main functionality is to create an HTTP server with the port defined in config.lua. In all samples we have analyzed so far, that is port 8888.

The server responds only to /info and /upload requests. Below is a (prettified) version of the server response to the /info path. All of the files below can be easily downloaded from the infected device.

(1) Lua scripts
(2) backdoor (old name: .dl)
(3) BitTorrent scripts
(4) malware version
(5) modules loader

Querying the root / on port 8888 will result in HTTP/1.0 404 OK, which serves as a simple indicator of compromise (IoC).

http.lua response function

At this point in our investigation, we asked the Censys team to do a mass scan of the Internet on TCP port 8888. They found about 10 IP addresses that match this particular HTTP answer. These IP addresses are potentially infected machines.


At a first glance, Linux/Shishiga might appear to be like the others, spreading through weak Telnet and SSH credentials, but the usage of the BitTorrent protocol and Lua modules separates it from the herd. BitTorrent used in a Mirai-inspired worm, Hajime, was observed last year and we can only speculate that it might become more popular in the future.

It’s possible that Shishiga could still evolve and become more widespread but the low number of victims, constant adding, removing, and modifying of the components, code comments and even debug information, clearly indicate that it’s a work in progress. To prevent your devices from being infected by Shishiga and similar worms, you should not use default Telnet and SSH credentials.

We would like to thank the Censys team for their collaboration.



SHA-1 hashes (.lm)
SHA-1 hashes (.dl)

Lua’s scripts filename
Files that could potentially indicate an infection