Chapter Three: Command and Control

After days of hoping and trying, I finally captured a copy of the binary program, a program that the QF cyber operators directed the victim Linksys and Asus routers to run. It turned out that the binary sent by the QF operators at this stage, with MD5 hash 7ca9f378ca7650d79b478595df2d2681, was first submitted to VirusTotal on 30 April. In fact, all the copies of the program used at this stage were identical.

I performed basic strings analysis and identified some firewall rules, and perhaps part of QuantumFilament’s command-and-control (C2) infrastructure. But I couldn’t just stop there. I needed to know what the program did, how it worked. Since I’m not a malware analyst, I hired one.

For brevity, I will call the binary with MD5 hash 7ca9f378ca7650d79b478595df2d2681 the "loader binary, version 14".

I enlisted the services of Nitay Artenstein, a security researcher, to reverse engineer the loader binary, and to document the structure and function of any network packets it sent or received. Mr. Artenstein’s analysis was critical for this research to continue.

Mr. Artenstein found that approximately hourly, the loader binary sent a registration packet to the five hardcoded IP addresses identified in the iptables firewall rules, specifically:

109.206.177.16

50.77.24.41

109.206.186.250

91.217.90.49

91.217.90.19

The reason I call the loader binary version 14 is that there was an internal version number sent in the hourly registration beacon, which was 14 in this binary.

I procured a compatible Asus router (they really are fine routers), ran the captured loader binary on the router, and monitored the network traffic going back and forth. Mr. Artenstein’s analysis helped me to find the relevant traffic, and the recorded traffic filled in some key details like byte order. The two approaches–static analysis and live analysis–proved complementary to getting some answers.

The purpose of the loader binary is to run additional binary programs sent by the QF network. The loader binary listens for inbound network packets on UDP port 4143, like these:

The 20 byte packets can be divided into five 32-bit words, and have the following structure:

Word

Meaning

1

A length byte, a function number, and an authentication byte, always observed to be hex 10 01 00 8f

2

The IP address from which to download the next program, in this case 109.206.177.16. The download connection is made by TCP.

3

The version number of the binary to request, big endian integer.

4

File size, big endian integer

5

The name of the binary to request and run

Two unique ELF binaries have been distributed to the QF network of hacked routers using the above mechanism:

Name,version

Size

MD5

SHA-1

.sox,15

87724

fdf3f53f1044eb516c5abe85bedf45f6

3e86fdd6e1b8005e541af4c22d3a98b2432f1fd4

.dis,14

86196

7f5c0f1b66276eb9f800a172a43cdb8e

3f6042d3361fdfb0edee1399685b370e2b92cde2

As of post time, neither file’s hashes are found in VirusTotal’s database.

The .sox and .dis programs have not been analyzed in detail. However, based on observed behavior, the .sox binary directs the hacked router to act as a SOCKS proxy, and I theorize the .dis program might be the component that scans for and exploits other routers, adding new hacked routers to QF’s inventory.

So we have established that QF cyber operators break into unpatched Asus and Linksys home and office routers, giving QF the ability to run additional programs on the compromised router. The behavior observed suggests QF uses the routers as SOCKS proxies to hide the origin of network traffic, stealing the router’s owner’s network bandwidth. And the router also tries to find and hack other vulnerable routers.