Thousands of hacked TP-Link routers used in years-long account takeover attacks
The botnet is being skillfully used to launch “highly evasive” password-spraying attacks.
Hackers working on behalf of the Chinese government are using a botnet of thousands of routers, cameras, and other Internet-connected devices to perform highly evasive password spray attacks against users of Microsoft’s Azure cloud service, the company warned Thursday.
The malicious network, made up almost entirely of TP-Link routers, was first documented in October 2023 by a researcher who named it Botnet-7777. The geographically dispersed collection of more than 16,000 compromised devices at its peak got its name because it exposes its malicious malware on port 7777.
Account compromise at scale
In July and again in August of this year, security researchers from Serbia and Team Cymru reported the botnet was still operational. All three reports said that Botnet-7777 was being used to skillfully perform password spraying, a form of attack that sends large numbers of login attempts from many different IP addresses. Because each individual device limits the login attempts, the carefully coordinated account-takeover campaign is hard to detect by the targeted service.
On Thursday, Microsoft reported that CovertNetwork-1658—the name Microsoft uses to track the botnet—is being used by multiple Chinese threat actors in an attempt to compromise targeted Azure accounts. The company said the attacks are “highly evasive” because the botnet—now estimated at about 8,000 strong on average—takes pains to conceal the malicious activity.
“Any threat actor using the CovertNetwork-1658 infrastructure could conduct password spraying campaigns at a larger scale and greatly increase the likelihood of successful credential compromise and initial access to multiple organizations in a short amount of time,” Microsoft officials wrote. “This scale, combined with quick operational turnover of compromised credentials between CovertNetwork-1658 and Chinese threat actors, allows for the potential of account compromises across multiple sectors and geographic regions.
Article
Solving the 7777 Botnet enigma: A cybersecurity quest
Discover 7777 botnet (aka Quad7) and its activity, targets, and use of TP-Link routers in Microsoft 365 attacks in our latest investigation.
Key Takeaways
Sekoia.io investigated the mysterious 7777 botnet (aka. Quad7 botnet), published by the independent researcher Gi7w0rm inside the “The curious case of the 7777 botnet” blogpost.
This investigation allowed us to intercept network communications and malware deployed on a TP-Link router compromised by the Quad7 botnet in France.
To our understanding, the Quad7 botnet operators leverage compromised TP-Link routers to relay password spraying attacks against Microsoft 365 accounts without any specific targeting.
Therefore, we link the Quad7 botnet activity to possible long term business email compromise (BEC) cybercriminal activity rather than an APT threat actor.
However, certain mysteries remain regarding the exploits used to compromise the routers, the geographical distribution of the botnet and the attribution of this activity cluster to a specific threat actor.
The insecure architecture of this botnet led us to think that it can be hijacked by other threat actors to install their own implants on the compromised TP-Link routers by using the Quad7 botnet accesses.
Therefore, we link the Quad7 botnet activity to possible long term business email compromise (BEC) cybercriminal activity rather than an APT threat actor.
However, certain mysteries remain regarding the exploits used to compromise the routers, the geographical distribution of the botnet and the attribution of this activity cluster to a specific threat actor.
The insecure architecture of this botnet led us to think that it can be hijacked by other threat actors to install their own implants on the compromised TP-Link routers by using the Quad7 botnet accesses.
At Sekoia.io, we have detected these attacks on 0.11% of our monitored Microsoft 365 accounts and have been tracking this botnet since our Intrinsec colleagues shared their findings with us. As this botnet was quite mysterious, targeting our customers and nobody had published on it since Gi7w0rm’s blog post, “The Curious Case of the 7777 Botnet,” we decided to investigate it.
This blog post will present the full investigation, our successes, and our failures, as it is always interesting to be transparent and provide feedback to the threat intelligence community and teams that may deal with similar IOT/SOHO threats in the future.
Are all of these compromised TP-Links?
When we started our investigation on this threat, we began by examining what kind of assets had been compromised. This botnet is quite old and constantly evolving, with the number of unique IP addresses involved dropping from 16,000 in August 2022, to ~7,000 in July 2024. The geographic distribution of compromised devices is quite surprising, as Bulgaria remains the most infected country, followed by Russia, the US, and Ukraine, as shown below.
According to open-source publications, the Quad7 botnet is suspected to target different kinds of IOTs including IP cameras or NAS devices and SOHO routers, predominantly TP-Link. However, our investigation found that almost all – we cannot be completely certain – compromised assets were in fact TP-Link routers.
The bias in the analysis of compromised assets results from the fact that the operators of the Quad7 botnet try to disable the TP-Link management interface after compromising it by stopping the binary acting as a web server. Therefore, no TP-Link associated interface or banner is present in many results of online scanners such as Shodan or Censys.
To confirm this hypothesis, we identified valuable information on the TCP windows size returned by compromised assets on the TCP ports 11288 and 7777. We used hping3 tool to scan compromised IP addresses and it turns out that most of the compromised devices participating in the Quad7 botnet have a windows size known to be related to old versions of the Linux kernel used by TP-Link routers. For many TP-Link products two TCP windows size values stand out: 5840 (mostly) and 5760.
We manually checked some other strange window sizes that we had on approximately fifty IP addresses and according to online scanners history their TP-Link administration panels were open on the Internet in the past. These strange window sizes can sometimes be explained, for example sometimes satellite-link providers are expanding window size for performance gain. Therefore, at this time we were convinced that the Quad7 botnet operators had at least one exploit chain to gain a remote code execution (RCE) against several management interfaces of TP-Link products.
First attempts to catch the Quad7 botnet
Based on these initial findings, we decided to monitor a TP-Link WR841N (firmware: 3.16.9 Build 150320 Rel.57500n) router for a few months. This model is the most compromised according to Censys, with a firmware version known to be vulnerable to the Quad7 botnet. We provided access to the router from five different IP addresses (three residential IPs in France, one mobile IP in the UK, and one VPS in Bulgaria, the most impacted country).
The router was fully monitored, including its processes, file system, and network activity. We created a setup to conduct remote live forensic analysis whenever something suspicious caught our attention. To do so a Raspberry Pi was connected to the router via UART, serving also as a network tap on the WAN interface, as illustrated in the diagram below. The UART access enabled us to receive alerts via our internal instant messaging application for any suspicious activity in the /tmp/ directory – as the rest of the filesystem is read-only – and at the running processes level.
On the other hand, the network tap wasn’t merely a simple network bridge running tcpdump. We utilised the well-known Python Scapy library to monitor and alert us – via our internal instant messaging service too – about any authenticated access to the management interface and the exploitation of standard vulnerabilities such as command injection, file disclosure, etc. The aim was to identify the vulnerabilities exploited by the Quad7 operators.
As we were unaware of the exact exploit chain used by the Quad7 operators to achieve remote code execution, we also employed Scapy to dynamically modify authentication attempts. This enabled us to accept any credentials provided by attackers attempting to access the management interface, thereby allowing us to observe the final RCE exploitation, if any.
Capturing IOT/SOHO threats with honeypots?
When we set up this system, we were quite enthusiastic about seeing some attacks. However, regarding the Quad7 botnet, we were less enthusiastic as we knew that it seemed to be using an outdated list of IP addresses as targets. Therefore, deploying honeypots with IP addresses that were not on the threat actor list of targets would not allow us to be attacked.
Honeypots are effective tools against standard threats, such as the general noise of cybercriminal activity on the internet (brute force attacks, scanning, and remote code execution at scale when a new CVE is published). However, capturing something more specific is much more difficult, as some threat actors target only residential IPs, specific ASNs or conduct reconnaissance before deploying their final payload to ensure that the targeted device is genuine.
We waited less than a week before observing a notable attack that chained an unauthenticated file disclosure which seems to be not public at this time (according to a Google search) and a command injection. This unauthenticated file disclosure allowed the attacker to retrieve the pair of credentials stored in /tmp/dropbear/dropbearpwd, to replay them in the HTTP Basic authentication of the management interface. Once authenticated, the attacker exploited a known command injection vulnerability in the Parental Control page to achieve the RCE.
We still don’t know the goal of this attack, as the attacker launched Dropbear (a pre-installed lightweight SSH agent) on a higher port, transferred his own BusyBox via the created SSH session, and then left the router after cleaning up their traces. However, it is interesting to note that this threat actor also targeted IP addresses compromised by the Quad7 botnet.
Despite finding an overlap on more than 80 IP addresses between the two attacks during our investigation, we do not believe they are related. This threat actor engages in compromised SOHO hopping (the attack originated from a compromised D-Link router) and utilises SSH for file transfer unlike the Quad7 operators who use the TFTP protocol. Furthermore, this actor does not deactivate the management interface of the compromised router after exploiting it. Consequently, we occasionally observe this actor compromising routers prior the Quad7 botnet operators, who then most of the time close the management interface.
We also observed during this monitoring brute force attempts of the HTTP Basic authentication, exploitation of known file disclosure vulnerabilities affecting TP-Link devices, and instances of DNS records being altered to redirect users to rogue DNS servers for ad distribution. However, these activities seemed more related to standard noise of SOHO/IOT targeting than the Quad7 operations.
It remains unclear why the Quad7 operators persist in maintaining the infrastructure established in 2022 by re-compromising routers upon their restart, rather than expanding their botnet by targeting new IP addresses. One possible reason could be to evade detection by honeypots, as new IP addresses after the
The curious case of the 7777 botnetmay be honeypots to catch them. Another, and more plausible, explanation is that they haven’t updated their target list for months or even years. This hypothesis would also explain the decrease of compromised assets over the time.Identifying victims
As our honeypot didn’t yield the expected results, we shifted to a different strategy: identifying some victims in France. Of the eleven IPs observed in 2024, we were able to identify and contact three individuals, requesting their assistance in tapping their routers and physically recovering the Quad7 botnet related malwares.
Why intervene physically when a victim could simply send us their router? The reason is simple: the majority of the file system is read-only (squashfs), and the /tmp/ directory is writable – but in volatile memory. As soon as the router is unplugged, its file system would be reset, making it impossible to retrieve the malicious codes.
Fortunately, one of these attempts was successful, providing us with more insights into the Quad7 botnet operations. Of the other two, one individual replaced his router after receiving our email but did not reply favourably, and the third did not reply at all, possibly thinking our message was a scam.