Linux / Shishiga malware uses Lua scripts
Among the malware samples for Linux received daily, we noticed a suspicious instance, which detected only Dr.Web - like Linux.LuaBot. Oddly enough, since our frequency of detection of Malabar family of the Luabot is usually higher.
After completing the analysis, we found out that the program is written in Lua and belongs to a new family that is not associated with the already known Luabot. Malvar is called Linux / Shishiga. It uses four protocols (SSH - Telnet - HTTP - BitTorrent) and Lua scripts.
')
Linux / Shishiga attacks the GNU / Linux system. The infection vector is typical - brute force weak passwords from the list. Malware works much like Linux / Moose , but it can also brute-force SSH. Here is a complete list of passwords as of this writing
bftelnet.lua
bfssh.lua
We also found several Linux / Shishiga binaries for various architectures, including MIPS (from older to younger and vice versa), ARM (armv4l), i686, and PowerPC. They are often used in Internet of Things devices. We assume that other architectures may be supported, such as SPARC, SH-4 or m68k, but more on that later.
Linux / Shishiga is a binary file packed using UPX 3.91 (executable file packer). But UPX will have difficulty with unpacking, as Shishiga adds data to the end of the packed file.
After unpacking the file, we see that it is statically linked to the work program library Lua, and the code is removed.
When executing, the binary file launches the Malawari module Lua by the following methods:
The getmods method returns an archived blob, which will be discussed in more detail later. Then the hard-coded Lua code (malware.lua) is executed through the functions luaL_loadstring and lua_pcall. The Lua code is pretty simple, here is a brief description of the source code without changes from us.
malware.lua
(1) opens the Malvari exe file from / proc / self / exe and returns its contents;
(2) restore the zlib archive using the getmods method, unpack it, and then parse it with tags and store it in the Lua array;
(3) invokes the main.lua module.
There is an extensive list of all the Lua scripts found in the compromise metrics section. For most of them, the names speak for themselves, but we still briefly describe some of them.
callhome.lua
bfssh.lua / bftelnet.lua
The architecture verification code looks like this:
bfssh.lua, getArchELF method
(1) each ELF file must begin with \ x7fELF;
(2) ftype, which represents e_type (ELF file type = executable, shared, etc.) is not used;
(3) bits represents e_ident [EI_CLASS] (32 or 64 bits), denc represents e_ident [EI_DATA] (older to younger, and vice versa), and farch represents e_machine in the ELF header.
bfssh.lua, getArchName method
(1) bits not used
(2) checks the file belonging to MIPS (from the younger one) (e_machine == EM_MIPS and e_ident [EI_DATA] == ELFDATA2LSB)
(3) checks the ownership of an Intel 80386 or Intel 80860 or AMD x86-64 file (e_machine == EM_386 or e_machine == EM_860 or e_machine == EM_X86_64)
config.lua
persist.lua
scanner.lua
worm.lua (this script was removed in the latest version of Linux / Shishiga)
The content of the readme.lua file will be appreciated by Russian speakers:
In the past few weeks, we have seen small changes: some blocks have been rewritten, test blocks have been added, unnecessary files have been deleted, but in general nothing remarkable.
The main binary file is called .lm, but we also managed to get a file called .dm - a simple backdoor listening on 0.0.0.0 (all IPv4 addresses) of port 2015. The name of the backdoor file changed from dl to dm.
Linux / Shishiga can exchange data using any of the modules httpproto.lua, btloader.lua or server.lua. The httpproto.lua module has functions that allow you to encode and decode information and make HTTP POST and GET requests. The source code below shows the coding process.
httpproto.lua
btloader.lua uses the torrent.lua module (a BitTorrent function wrapper) to save and load nodes from the nodes.cfg file. It also gets its configuration from the {server, update, script} .bt files (in Bencode format) and uses the BitTorrent protocol to check for updates of these files. script.bt allows you to execute the Lua script, and update.bt allows the execution of the .lm binary. Below are examples of decoded .bt files, shown as Python dictionaries.
script.bt
(1) signature
(2) public key
update.bt
server.bt
Finally, the main function of the server.lua module is to create an HTTP server with the port specified in config.lua. In all the samples we have studied at the moment, this was port 8888.
The server responds only to requests / info and / upload. The following is the “brushed” version of the server response to the / info path. All the files below can be easily downloaded from the infected device.
(1) Lua scripts
(2) backdoor (old name: .dl)
(3) BitTorrent scripts
(4) Malvari version
(5) module loader
A request to the root / port 8888 will result in HTTP / 1.0 404 OK, which is a simple indicator of compromise (IoC).
Http.lua answer function
At this stage of the study, we asked the Censys team to conduct a massive Internet scan on TCP port 8888. They found about ten IP addresses on which the HTTP response coincided. These addresses belong to potentially infected machines.
At first glance, Linux / Shishiga may seem similar to other malicious programs that spread through the weak Telnet and SSH, but it is distinguished by the use of the BitTorrent protocol and Lua modules. BitTorrent in the Hajime worm, inspired by Mirai, was discovered last year, and we can only guess if it will become more popular in the future.
It is possible that Shishiga is evolving and will be more common. So far, a small number of victims, changes to components, comments in the code, and information on eliminating bugs indicate that work on the software is in progress. To prevent your device from infecting Shishiga with malware and similar worms, you should not use standard Telnet and SSH credentials.
We thank the Censys team for their cooperation.
Command server
93.117.137.35
SHA-1 (.lm)
SHA-1 (.dl)
Lua Script File Names
Files that could potentially indicate infection
We remind you about a 50% discount when migrating to ESET NOD32 corporate solutions from products from other manufacturers.
After completing the analysis, we found out that the program is written in Lua and belongs to a new family that is not associated with the already known Luabot. Malvar is called Linux / Shishiga. It uses four protocols (SSH - Telnet - HTTP - BitTorrent) and Lua scripts.
')
Shishiga habitat
Linux / Shishiga attacks the GNU / Linux system. The infection vector is typical - brute force weak passwords from the list. Malware works much like Linux / Moose , but it can also brute-force SSH. Here is a complete list of passwords as of this writing
bftelnet.lua
[...] local accounts={ {"admin","admin"}, {"root","root"}, {"adm","adm"}, {"acer","acer"}, {"user","user"}, {"security","security"} } [...] bfssh.lua
[...] local accounts={ {"admin","admin"}, {"root","root"}, {"adm","adm"}, {"ubnt","ubnt"}, {"root",""}, {"admin",""}, {"adm",""}, {"user","user"}, {"pi","pi"}, } --[[ {"acer","acer"}, {"security","security"}, {"root","toor"}, {"root","roottoor"}, {"root","password"}, {"root","test"}, {"root","abc123"}, {"root","111111"}, {"root","1q2w3e"}, {"root","oracle"}, {"root","1q2w3e4r"}, {"root","123123"}, {"root","qwe123"}, {"root","p@ssw0rd"}, {"root","1"}, {"root","12"}, {"root","123"}, {"root","1234"}, {"root","12346"}, {"root","123467"}, {"root","1234678"}, {"root","12346789"}, {"root","123467890"}, {"root","qwerty"}, {"root","pass"}, {"root","toor"}, {"root","roottoor"}, {"root","password123"}, {"root","password123456"}, {"root","pass123"}, {"root","password"}, {"root","passw0rd"}, {"root","1qaz"}, {"root","1qaz2wsx"}, {"root","asdfgh"}, {"user","user"}, {"user",""}, {"acer","acer"}, {"security","security"}, {"root","passw0rds"}, ]] [...] We also found several Linux / Shishiga binaries for various architectures, including MIPS (from older to younger and vice versa), ARM (armv4l), i686, and PowerPC. They are often used in Internet of Things devices. We assume that other architectures may be supported, such as SPARC, SH-4 or m68k, but more on that later.
Shishiga features
Linux / Shishiga is a binary file packed using UPX 3.91 (executable file packer). But UPX will have difficulty with unpacking, as Shishiga adds data to the end of the packed file.
After unpacking the file, we see that it is statically linked to the work program library Lua, and the code is removed.
$ file unpacked.i686.lm unpacked.i686.lm: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped When executing, the binary file launches the Malawari module Lua by the following methods:
malware_module_methods dd offset aGetver ; "getver" dd offset getver dd offset aGetos ; "getos" dd offset getos dd offset aGetarch ; "getarch" dd offset getarch dd offset aGetmacaddr ; "getmacaddr" dd offset getmacaddr dd offset aGetmods ; "getmods" dd offset getmods dd offset aSetargs ; "setargs" dd offset setargs The getmods method returns an archived blob, which will be discussed in more detail later. Then the hard-coded Lua code (malware.lua) is executed through the functions luaL_loadstring and lua_pcall. The Lua code is pretty simple, here is a brief description of the source code without changes from us.
malware.lua
local unistd=require("posix.unistd") require("malware") function getexe() local fn=unistd.readlink("/proc/self/exe") if fn==nil and arg~=nil then fn=arg[0] --symlink removed end if fn==nil then print("couldn't find bot file") return nil end local file=io.open(fn,"r") if file==nil then print("couldn't find bot file") return nil end local data=file:read("*all") file:close() return data end function getMods() return zlib.inflate()(malware.getmods()) end function getScriptFiles(scripts) local files={} local i=1 while true do local a1,b1,c1=string.find(scripts,'%-%-script%-begin%-%-([%w%.]+)%-%-',i) if a1==nil then break end local a2,b2,c2=string.find(scripts,'%-%-script%-end%-%-([%w%.]+)%-%-',i) if a2==nil then break end if c1~=c2 then return nil end local src=string.sub(scripts,b1+1,a2-1) i=b2+1 files[c1]=src end return files end malware.exe=getexe() (1) local modules=getScriptFiles(getMods()) (2) [...] f=load(malware.modules['main.lua']) (3) local s,err=pcall(f) if s==false then print(err) end (1) opens the Malvari exe file from / proc / self / exe and returns its contents;
(2) restore the zlib archive using the getmods method, unpack it, and then parse it with tags and store it in the Lua array;
(3) invokes the main.lua module.
There is an extensive list of all the Lua scripts found in the compromise metrics section. For most of them, the names speak for themselves, but we still briefly describe some of them.
callhome.lua
- gets the server.bt or servers configuration file from config.lua;
- if it is impossible to contact the current default server, it changes it to another one;
- sends files (reports or accounts, both in JSON format);
- executes tasks from the list of tasks received from the C & C server.
bfssh.lua / bftelnet.lua
- module for brute-force SSH- and Telnet-logins;
- checks if the echo -en command "\\ x31 \\ x33 \\ x33 \\ x37" on output 1337; if not, exit; otherwise, continue;
- device architecture is determined by the file from / bin / ls by running cat / bin / ls and parsing the ELF header, more on this below;
- Malvari distribution (.lm and .dm files) according to the device architecture;
- saving successful combinations of user parameters.
The architecture verification code looks like this:
bfssh.lua, getArchELF method
function bfssh.getArchELF(text) local bits,denc,ver,ftype,farch if text==nil then return nil end local i=text:find("\x7fELF") (1) if i~=nil then bits,denc,ver=string.unpack("<BBB",text:sub(i+4)) if denc==1 then ftype,farch=string.unpack("<HH",text:sub(i+16)) (2) else ftype,farch=string.unpack(">HH",text:sub(i+16)) end end return bits,denc,farch (3) end (1) each ELF file must begin with \ x7fELF;
(2) ftype, which represents e_type (ELF file type = executable, shared, etc.) is not used;
(3) bits represents e_ident [EI_CLASS] (32 or 64 bits), denc represents e_ident [EI_DATA] (older to younger, and vice versa), and farch represents e_machine in the ELF header.
bfssh.lua, getArchName method
function bfssh.getArchName(bits,denc,farch) (1) if farch==0x8 and denc==1 then (2) return "mipsel" end if farch==0x8 and denc==2 then return "mips" end if farch==0x28 then return "armv4l" end if farch==0x2 then return "sparc" end if farch==0x2a then return "sh4" end if farch==0x4 then return "m68k" end if farch==0x14 then return "powerpc" end if farch==0x3 or farch==0x7 or farch==0x3e then (3) return "i686" end return nil end (1) bits not used
(2) checks the file belonging to MIPS (from the younger one) (e_machine == EM_MIPS and e_ident [EI_DATA] == ELFDATA2LSB)
(3) checks the ownership of an Intel 80386 or Intel 80860 or AMD x86-64 file (e_machine == EM_386 or e_machine == EM_860 or e_machine == EM_X86_64)
config.lua
- contains the public key publicKey to verify the binary signature (.lm or .dm);
- contains a list of loader components;
- contains the names of .bt files, port numbers of SOCKS and HTTP servers;
- contains the IP addresses of the server (possibly C & C).
persist.lua
- preservation method, depending on user rights (root or user)
scanner.lua
- used to generate random / 16 networks that are not local
worm.lua (this script was removed in the latest version of Linux / Shishiga)
- enables scanning of a specified port;
- allows downloading;
- obtains information from a newly infected server.
The content of the readme.lua file will be appreciated by Russian speakers:
In the past few weeks, we have seen small changes: some blocks have been rewritten, test blocks have been added, unnecessary files have been deleted, but in general nothing remarkable.
The main binary file is called .lm, but we also managed to get a file called .dm - a simple backdoor listening on 0.0.0.0 (all IPv4 addresses) of port 2015. The name of the backdoor file changed from dl to dm.
Shishiga Communications
Linux / Shishiga can exchange data using any of the modules httpproto.lua, btloader.lua or server.lua. The httpproto.lua module has functions that allow you to encode and decode information and make HTTP POST and GET requests. The source code below shows the coding process.
httpproto.lua
[...] function httpproto.encode(data) local msg=bencode.encode(data) local c=zlib.crc32()(msg) local k=string.pack("<I",utils.random()) return k..crypto.rc4(k,string.pack("<I",c)..msg) end [...] btloader.lua uses the torrent.lua module (a BitTorrent function wrapper) to save and load nodes from the nodes.cfg file. It also gets its configuration from the {server, update, script} .bt files (in Bencode format) and uses the BitTorrent protocol to check for updates of these files. script.bt allows you to execute the Lua script, and update.bt allows the execution of the .lm binary. Below are examples of decoded .bt files, shown as Python dictionaries.
script.bt
{ 'sig': <removed>,(1) 'k': <removed>,(2) 'salt': 'script', 'seq': 1486885364, 'v': 'caba4dbe2f7add9371b94b97cf0d351b72449072,test.lua\n' } (1) signature
(2) public key
update.bt
{ 'sig': <removed>, 'k': <removed>, 'salt': 'update', 'seq': 1486885364, 'v': 'bf4d9e25fc210a1d9809aebb03b30748dd588d08,mipsel.lm\n 8a0d58472f6166ade0ae677bab7940fe38d66d35,armv4l.lm\n 51a4ca78ebb0649721ae472290bea7bfe983d727,mips.lm\n 979fb376d6adc65473c4f51ad1cc36e3612a1e73,powerpc.lm\n ce4b3c92a96137e6215a5e2f5fd28a672eddaaab,i686.lm\n' } server.bt
{ 'sig': <removed>, 'k': <removed, 'salt': 'server', 'seq': 1486835166, 'v': '93.117.137.35:8080\n' } Finally, the main function of the server.lua module is to create an HTTP server with the port specified in config.lua. In all the samples we have studied at the moment, this was port 8888.
The server responds only to requests / info and / upload. The following is the “brushed” version of the server response to the / info path. All the files below can be easily downloaded from the infected device.
{ "src":[ (1) "test.lua", "test1.lua", "test10.lua", "test2.lua", "test3.lua", "test5.lua", "test6.lua", "test_1.lua", "test_2.lua", "test_3.lua", "test_4.lua" ], "dm":[ (2) "armv4l.dm", "i686.dm", "mips.dm", "mipsel.dm" ], "bt":[ (3) "script.bt", "server.bt", "update.bt" ], "version":"1.0.0", (4) "lua":[ (5) "armv4l.lm", "i686.lm", "mips.lm", "mipsel.lm", "powerpc.lm" ], "os":"lin", "arch":"i686", "lua_version":"Lua 5.3" } (1) Lua scripts
(2) backdoor (old name: .dl)
(3) BitTorrent scripts
(4) Malvari version
(5) module loader
A request to the root / port 8888 will result in HTTP / 1.0 404 OK, which is a simple indicator of compromise (IoC).
Http.lua answer function
function http.response(req,code,data,timeout) timeout=timeout or timeoutDef local hdr="HTTP/1.0 %d OK\r\nContent-Length: %d\r\nConnection: close\r\n\r\n" async.sendall(req.sock,hdr:format(code,data:len())..data,timeout) return true end At this stage of the study, we asked the Censys team to conduct a massive Internet scan on TCP port 8888. They found about ten IP addresses on which the HTTP response coincided. These addresses belong to potentially infected machines.
Conclusion
At first glance, Linux / Shishiga may seem similar to other malicious programs that spread through the weak Telnet and SSH, but it is distinguished by the use of the BitTorrent protocol and Lua modules. BitTorrent in the Hajime worm, inspired by Mirai, was discovered last year, and we can only guess if it will become more popular in the future.
It is possible that Shishiga is evolving and will be more common. So far, a small number of victims, changes to components, comments in the code, and information on eliminating bugs indicate that work on the software is in progress. To prevent your device from infecting Shishiga with malware and similar worms, you should not use standard Telnet and SSH credentials.
We thank the Censys team for their cooperation.
Infection Indicators (IoC)
Command server
93.117.137.35
SHA-1 (.lm)
003f548796fb52ad281ae82c7e0bb7532dd34241 1a79092c6468d39a10f805c96ad7f8bf303b7dc8 1cc1b97f8f9bb7c4f435ef1316e08e5331b4331b 2889803777e2dfec7684512f45e87248a07d508f 2a809d37be5aa0655f5cc997eb62683e1b45da17 3f1ef05ca850e2f5030ee279b1c589c9e3cc576c 41bf0d5612ba5bc9a05e9d94df0f841b159264a0 4bc106f6231daa6641783dd9276b4f5c7fc41589 4d55efe18643d7408cbe12dd4f319a68084bd11e 4df58ab26f0fc8ec2d1513611ca2b852e7107096 51a4ca78ebb0649721ae472290bea7bfe983d727 5a88b67d8dfaf1f68308311b808f00e769e39e46 6458c48e5167a2371d9243d4b47ad191d642685b 688ccbca8b2918a161917031e21b6810c59eeab0 6e3ba86d1f91669e87945b8ea0211b58e315e189 6f41c8f797814e2e3f073601ce81e8adceef6a27 8a0d58472f6166ade0ae677bab7940fe38d66d35 8a1f9212f181e68a63e06a955e64d333b78c6bf6 8e3c4eb04d4cfd8f44c721111c5251d30ac848b6 979fb376d6adc65473c4f51ad1cc36e3612a1e73 a1f2535576116d93b62d7f5fc6e30e66e0e0a216 a694c6ecc2ff9702905f22b14ed448e9e76fe531 ac094b239851eaf2e9fd309285c0996fb33771a8 b14f7af9665ef77af530109a0331f8ca0bd2a167 b86935c4539901cdec9081d8a8ca915903adaff1 ba5df105496b0c4df7206d29fa544b7a7a346735 bf4d9e25fc210a1d9809aebb03b30748dd588d08 c22f0fb01c6d47957732a8b0f5ef0f7d4e614c79 ce4b3c92a96137e6215a5e2f5fd28a672eddaaab d8a5d9c4605b33bd47fedbad5a0da9928de6aa33 f73022a4801e06d675e5c3011060242af7b949ad SHA-1 (.dl)
274181d2f9c6b8f0e217db23f1d39aa94c161d6e 8abbb049bffd679686323160ca4b6a86184550a1 95444c2ccc5fff19145d60f1e817fd682cabe0cd 9cde845852653339f67667c2408126f02f246949 Lua Script File Names
async.lua async.lua.old bencode.lua bfssh.lua bfssh.lua.old2 bftelnet.lua btloader.lua callhome.lua callhome.lua.old config.lua crypto.lua dht.lua event.lua evs.lua http.lua httpproto.lua libevent2.lua luaevent.lua main.lua main2.lua malware.lua persist.lua readme.lua routing.lua scanner.lua scanner2.lua server.lua socket.lua socks.lua ssh.lua ssl.lua telnet.lua test.lua test1.lua test10.lua test2.lua test3.lua test5.lua test6.lua threads.lua torrent.lua udp.lua utils.lua worm.lua Files that could potentially indicate infection
/tmp/.local/* /tmp/drop /tmp/srv $HOME/.local/ssh.txt $HOME/.local/telnet.txt $HOME/.local/nodes.cfg $HOME/.local/check $HOME/.local/script.bt $HOME/.local/update.bt $HOME/.local/server.bt $HOME/.local/syslog $HOME/.local/syslog.pid $HOME/.local/{armv4l,i686,mips,mipsel}.{dl,dm} $HOME/.local/{armv4l,i686,mips,mipsel,powerpc}.lm /etc/rc2.d/S04syslogd /etc/rc3.d/S04syslogd /etc/rc4.d/S04syslogd /etc/rc5.d/S04syslogd /etc/init.d/syslogd /bin/syslogd /etc/cron.hourly/syslogd We remind you about a 50% discount when migrating to ESET NOD32 corporate solutions from products from other manufacturers.
Source: https://habr.com/ru/post/327824/
All Articles