{
	"id": "b6f9e2d6-87c7-4195-8255-160e01133f1d",
	"created_at": "2026-04-06T01:29:55.573409Z",
	"updated_at": "2026-04-10T03:24:18.069121Z",
	"deleted_at": null,
	"sha1_hash": "e012644ba7c04c8fc85518ff6ffb20e4bef11b93",
	"title": "Solving the 7777 Botnet enigma: A cybersecurity quest",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2737527,
	"plain_text": "Solving the 7777 Botnet enigma: A cybersecurity quest\r\nBy Sekoia TDR,\u0026nbsp;Felix Aimé,\u0026nbsp;Pierre-Antoine D.,\u0026nbsp;Charles M.,\u0026nbsp;Grégoire\r\nClermont\u0026nbsp;and\u0026nbsp;Jeremy Scion\r\nPublished: 2024-07-23 · Archived: 2026-04-06 00:18:49 UTC\r\nKey Takeaways\r\nSekoia.io investigated the mysterious 7777 botnet (aka. Quad7 botnet), published by the independent\r\nresearcher Gi7w0rm inside the “The curious case of the 7777 botnet” blogpost.\r\n \r\nThis investigation allowed us to intercept network communications and malware deployed on a TP-Link\r\nrouter compromised by the Quad7 botnet in France.\r\nTo our understanding, the Quad7 botnet operators leverage compromised TP-Link routers to relay\r\npassword spraying attacks against Microsoft 365 accounts without any specific targeting.\r\nTherefore, we link the Quad7 botnet activity to possible long term business email compromise (BEC)\r\ncybercriminal activity rather than an APT threat actor.\r\nHowever, certain mysteries remain regarding the exploits used to compromise the routers, the geographical\r\ndistribution of the botnet and the attribution of this activity cluster to a specific threat actor.\r\nThe insecure architecture of this botnet led us to think that it can be hijacked by other threat actors to install\r\ntheir own implants on the compromised TP-Link routers by using the Quad7 botnet accesses.\r\nTable of contents\r\nIntroduction\r\nAre all of these compromised TP-Links?\r\nFirst attempts to catch the Quad7 botnet \r\nIdentifying victims\r\nPhysical intervention preparation\r\nThe intervention: when expectation meets reality\r\nDigging into the network capture.\r\nLet’s take a look at the brute force attempts in our telemetry.\r\nAfter this investigation, some mysteries remain.\r\nDetection Bonus: Advice for MSSP to hunt for Quad7 O365 targeting.\r\nQuad7 Botnet Indicators of compromise\r\nGreetings\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 1 of 17\n\nIntroduction\r\nOn October 19, 2023, independent researchers Gi7w0rm and Dunstable Toblerone published a blog post about a\r\nbotnet nicknamed the `Quad7` or `7777` botnet, related to the TCP port 7777 opened on compromised devices\r\ndisplaying a mysterious xlogin: banner. This botnet is known in open source for deploying Socks5 proxies on\r\ncompromised devices to relay extremely slow “bruteforce” attacks against Microsoft 365 accounts of many\r\nentities around the world.\r\nAt Sekoia.io, we have detected these attacks on 0.11% of our monitored Microsoft 365 accounts and have been\r\ntracking this botnet since our Intrinsec colleagues shared their findings with us. As this botnet was quite\r\nmysterious, targeting our customers and nobody had published on it since Gi7w0rm’s blog post, “The Curious\r\nCase of the 7777 Botnet,” we decided to investigate it.\r\nThis blog post will present the full investigation, our successes, and our failures, as it is always interesting to be\r\ntransparent and provide feedback to the threat intelligence community and teams that may deal with similar\r\nIOT/SOHO threats in the future.\r\nAre all of these compromised TP-Links?\r\nWhen we started our investigation on this threat, we began by examining what kind of assets had been\r\ncompromised. This botnet is quite old and constantly evolving, with the number of unique IP addresses\r\ninvolved dropping from 16,000 in August 2022, to ~7,000 in July 2024. The geographic distribution of\r\ncompromised devices is quite surprising, as Bulgaria remains the most infected country, followed by Russia, the\r\nUS, and Ukraine, as shown below.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 2 of 17\n\nAccording to open-source publications, the Quad7 botnet is suspected to target different kinds of IOTs including\r\nIP cameras or NAS devices and SOHO routers, predominantly TP-Link. However, our investigation found that\r\nalmost all – we cannot be completely certain – compromised assets were in fact TP-Link routers. \r\nThe bias in the analysis of compromised assets results from the fact that the operators of  the Quad7 botnet try\r\nto disable the TP-Link management interface after compromising it by stopping the binary acting as a web\r\nserver. Therefore, no TP-Link associated interface or banner is present in many results of online scanners such as\r\nShodan or Censys. \r\nTo confirm this hypothesis, we identified valuable information on the TCP windows size returned by\r\ncompromised assets on the TCP ports 11288 and 7777. We used hping3 tool to scan compromised IP addresses\r\nand it turns out that most of the compromised devices participating in the Quad7 botnet have a windows\r\nsize known to be related to old versions of the Linux kernel used by TP-Link routers. For many TP-Link\r\nproducts two TCP windows size values stand out: 5840 (mostly) and 5760.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 3 of 17\n\nWe manually checked some other strange window sizes that we had on approximately fifty IP addresses and\r\naccording to online scanners history their TP-Link administration panels were open on the Internet in the past.\r\nThese strange window sizes can sometimes be explained, for example sometimes satellite-link providers are\r\nexpanding window size for performance gain. Therefore, at this time we were convinced that the Quad7 botnet\r\noperators had at least one exploit chain to gain a remote code execution (RCE) against several management\r\ninterfaces of TP-Link products.\r\nFirst attempts to catch the Quad7 botnet \r\nBased on these initial findings, we decided to monitor a TP-Link WR841N (firmware: 3.16.9 Build 150320\r\nRel.57500n) router for a few months. This model is the most compromised according to Censys, with a firmware\r\nversion known to be vulnerable to the Quad7 botnet. We provided access to the router from five different IP\r\naddresses (three residential IPs in France, one mobile IP in the UK, and one VPS in Bulgaria, the most impacted\r\ncountry).\r\nThe router was fully monitored, including its processes, file system, and network activity. We created a setup to\r\nconduct remote live forensic analysis whenever something suspicious caught our attention. To do so a\r\nRaspberry Pi was connected to the router via UART, serving also as a network tap on the WAN interface, as\r\nillustrated in the diagram below. The UART access enabled us to receive alerts via our internal instant messaging\r\napplication for any suspicious activity in the /tmp/ directory – as the rest of the filesystem is read-only – and at the\r\nrunning processes level. \r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 4 of 17\n\nOn 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\r\nauthenticated access to the management interface and the exploitation of standard vulnerabilities such as\r\ncommand injection, file disclosure, etc. The aim was to identify the vulnerabilities exploited by the Quad7\r\noperators.\r\nAs we were unaware of the exact exploit chain used by the Quad7 operators to achieve  remote code execution,\r\nwe also employed Scapy to dynamically modify authentication attempts. This enabled us to accept any\r\ncredentials provided by attackers attempting to access the management interface, thereby allowing us to observe\r\nthe final RCE exploitation, if any.\r\nCapturing IOT/SOHO threats with honeypots?\r\nWhen we set up this system, we were quite enthusiastic about seeing some attacks. However, regarding the Quad7\r\nbotnet, we were less enthusiastic as we knew that it seemed to be using an outdated list of IP addresses as targets.\r\nTherefore, deploying honeypots with IP addresses that were not on the threat actor list of targets would not allow\r\nus to be attacked.\r\nHoneypots are effective tools against standard threats, such as the general noise of cybercriminal activity on the\r\ninternet (brute force attacks, scanning, and remote code execution at scale when a new CVE is published).\r\nHowever, capturing something more specific is much more difficult, as some threat actors target only residential\r\nIPs, specific ASNs or conduct reconnaissance before deploying their final payload to ensure that the targeted\r\ndevice is genuine.\r\nWe waited less than a week before observing a notable attack that chained an unauthenticated file disclosure\r\nwhich seems to be not public at this time (according to a Google search) and a command injection. This\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 5 of 17\n\nunauthenticated file disclosure allowed the attacker to retrieve the pair of credentials stored in\r\n/tmp/dropbear/dropbearpwd, to replay them in the HTTP Basic authentication of the management interface. Once\r\nauthenticated, the attacker exploited a known command injection vulnerability in the Parental Control page to\r\nachieve the RCE.\r\nWe still don’t know the goal of this attack, as the attacker launched Dropbear (a pre-installed lightweight SSH\r\nagent) on a higher port, transferred his own BusyBox via the created SSH session, and then left the router after\r\ncleaning up their traces. However, it is interesting to note that this threat actor also targeted IP addresses\r\ncompromised by the Quad7 botnet.\r\nDespite finding an overlap on more than 80 IP addresses between the two attacks during our investigation,\r\nwe do not believe they are related. This threat actor engages in compromised SOHO hopping (the attack\r\noriginated from a compromised D-Link router) and utilises SSH for file transfer unlike the Quad7 operators who\r\nuse the TFTP protocol. Furthermore, this actor does not deactivate the management interface of the compromised\r\nrouter after exploiting it. Consequently, we occasionally observe this actor compromising routers prior the\r\nQuad7 botnet operators, who then most of the time close the management interface.\r\nWe also observed during this monitoring brute force attempts of the HTTP Basic authentication, exploitation of\r\nknown file disclosure vulnerabilities affecting TP-Link devices, and instances of DNS records being altered to\r\nredirect users to rogue DNS servers for ad distribution. However, these activities seemed more related to standard\r\nnoise of SOHO/IOT targeting than the Quad7 operations.\r\nIt remains unclear why the Quad7 operators persist in maintaining the infrastructure established in 2022\r\nby re-compromising routers upon their restart, rather than expanding their botnet by targeting new IP\r\naddresses. One possible reason could be to evade detection by honeypots, as new IP addresses after the `The\r\ncurious case of the 7777 botnet` may be honeypots to catch them. Another, and more plausible, explanation is\r\nthat they haven’t updated their target list for months or even years. This hypothesis would also explain the\r\ndecrease of compromised assets over the time.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 6 of 17\n\nIdentifying victims\r\nAs our honeypot didn’t yield the expected results, we shifted to a different strategy: identifying some victims in\r\nFrance. Of the eleven IPs observed in 2024, we were able to identify and contact three individuals, requesting\r\ntheir assistance in tapping their routers and physically recovering the Quad7 botnet related malwares.\r\nWhy intervene physically when a victim could simply send us their router? The reason is simple: the majority of\r\nthe file system is read-only (squashfs), and the /tmp/ directory is writable – but in volatile memory. As soon as the\r\nrouter is unplugged, its file system would be reset, making it impossible to retrieve the malicious codes.\r\nFortunately, one of these attempts was successful, providing us with more insights into the Quad7 botnet\r\noperations. Of the other two, one individual replaced his router after receiving our email but did not reply\r\nfavourably, and the third did not reply at all, possibly thinking our message was a scam.\r\nPhysical intervention preparation\r\nThe compromised router was an old Archer C7 v2.0 (Firmware: 3.15.3 Build 180305 Rel.51282n). Our contact\r\npromptly understood the situation, our intentions regarding his router and graciously allowed us access to it. We\r\nagreed to plan an operation comprising two main tasks:\r\nSending a ‘plug and play’ in-line network tap to install prior to our intervention. This tap monitored only\r\nports TELNET/7777, SOCKS/11288, and the management interface port if the router was restarted. The\r\ngoal was to understand the upper level of the infrastructure related to the Quad7 botnet and its bruteforce\r\nactivities.\r\nPhysically access the router via UART to get a root shell on it. The aim of that was to retrieve the\r\nmalware related to the Quad7 botnet. At this time, we were uncertain if the infamous `xlogin:` service\r\nlistening on the TELNET/7777 port was a kind of bind shell access or was merely a decoy from the\r\nattackers.\r\nThis intervention involved two potential points of failure to address.\r\nThe first issue was technical problems with the in-line network tap, such as bandwidth throttling or running\r\nout of disk space due to the captured data. To address this point of failure, we created a cheap tap with two\r\nEthernet ports of 1Gbps each. The setup was straightforward: the two interfaces were bridged, and a tcpdump was\r\ninitiated by a cron job at reboot to save network captures in the home directory, as illustrated below.\r\n@reboot /bin/bash -c ‘sleep 60 \u0026\u0026 UUID=$(uuidgen) \u0026\u0026 /usr/bin/tcpdump -i br0 “port [admin port] or port 7777\r\nor port 11288” -w /home/tap/capture_${UUID}.pcap -C 1000 -W 10’ \u003e\u003e /home/tap/tcpdump.log 2\u003e\u00261\r\nTo prevent the SD card in our tap from running out of space, and since we were uncertain about the network flows\r\npassing through the socks proxy implemented by the Quad7 operators, we decided to create a rotation of the pcaps\r\nwith a maximum of 10Gb of captured network flow for each reboot of the tap. Our contact simply needed to\r\nconnect the tap, and without requiring any command line or additional instructions, the tap immediately began\r\ncapturing network data.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 7 of 17\n\nThe second technical issue was related to the UART itself. From an attacker’s perspective, It is straightforward\r\nto disable the user authentication from UART after having compromised the router simply by deleting or rewriting\r\none specific file inside the /tmp/ directory. Consequently, if we cannot log in, we cannot get the malicious codes.\r\nTo address that issue, we decided to have a backup plan prior to our intervention. We developed our own remote\r\nforensics-friendly reverse shell specifically for the Archer C7. The idea behind this was simple: since we knew\r\nthat the threat actor re-compromises the router following a reboot, we could pre-implant it to get his malware.\r\nTo accomplish this, we just have to reboot the router and pre-implant it with our own reverse shell via the UART\r\naccess (re-enabled following the router’s reboot), and then wait for the attacker to drop his codes.\r\nAfter conducting numerous tests in real conditions, including opening the router without unplugging it, and\r\npreventing connection loss by manipulating it, which could lead to a router reboot, we were prepared to travel\r\n1,000 kilometers across France to access this router.\r\nThe intervention: when expectation meets reality\r\nFor this intervention, our team consisted of three individuals: a reverser to analyse the obtained malware, a\r\nsupport member to provide valuable inputs/ideas and one person to handle the router. The critical aspect was to\r\nopen and connect to the UART without unplugging the router or causing connection loss, as this could\r\nresult in the loss of the malware. We extensively tested this configuration using a PCBite, even on hot plates\r\nwith a similar width to a server cabinet (24 inches) as our contact informed us that the router was located in “a\r\nsmall server cabinet”.\r\nUpon arriving at the office where the router was hosted, we faced our first challenge: we encountered a very small\r\nswitch cabinet with limited space to manoeuvre the router. Consequently the operation to remove the Phillips\r\nscrews, open the router and connect probes to the UART was quite intricate. However, thanks to PCBite, we were\r\nable to magnetise the probes to the cabinet itself during the operation, ensuring stability of the UART connection.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 8 of 17\n\nFortunately, the attacker had not disabled the user authentication. Consequently, we obtained a root shell within\r\nseconds, enabling us to examine suspicious processes and network connections. Prior to the intervention we\r\ntook several snapshots of the list of running processes and writable directories of a clean router. Hence a\r\nsimple diffing between the compromised router and clean snapshots revealed the difference immediately. The\r\nattacker did not try to conceal itself by modifying files or process names.\r\nIn the process listing below, you can clearly see the suspicious execution of three binaries: telnetd, xlogin, and\r\nsocks5. It is worth mentioning that, as stated before, the attackers deactivated the web interface by killing\r\n/usr/bin/httpd, as it is no longer present in the running processes list.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 9 of 17\n\nTo retrieve the malicious codes from the Archer C7 2.0 using BusyBox, there are two primary methods: using\r\nTFTP (which is relatively slow, and does not verify file integrity during transfer) or simply connecting a flash\r\ndrive formatted in FAT. As we wanted to ensure the integrity of the transferred files and as the Busybox installed\r\non the Archer C7 lacked a reliable utility for this purpose, we uploaded our implant onto the router. This approach\r\nprovided us with a convenient method to download and verify the integrity of the downloaded files directly.\r\nWe successfully obtained the binaries that our attacker pushed onto the compromised router. These binaries\r\nconsisted of a Telnet binary coming from BusyBox (386bf8259668c0abb6c72fdcae904164) which is listening on\r\nthe TCP/7777 and redirected incoming connections to a simple authenticated shell named xlogin\r\n(69ced04a2ec895084d3aab1086216d32). Additionally, there was a Socks5 proxy\r\n(29e6df5bb30ed8fd12c09d9b6890ab4f) derived from the bhhbazinga’s Sock5 open source project which listened\r\non the SOCKS/11288 used to relay brute force attacks to Microsoft 365 API endpoints. Despite our expectations,\r\nthere was nothing else – no sophisticated goodies for our reverser after all.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 10 of 17\n\nHowever, binaries alone do not provide much insight without some network context around them. In the\r\nnext section we present our investigation based on the network capture collected by our network tap to determine\r\nif we found valuable data inside.\r\nDigging into the network capture.\r\nFortunately, our plug-and-play tap functioned effectively, and we collected one week’s data. Sadly, the router did\r\nnot reboot during this period and was replaced shortly after our operation. As a result, we did not capture any\r\nexploits used by the operators to re-compromise it. Nevertheless, we found answers to some of our questions by\r\nanalysing our small network capture (11MB) obtained from connections to the ports TELNET/7777 and\r\nSOCKS/11288. Here is a summary of what we have seen:\r\nOur first question was whether this botnet is used solely by the Quad7 operators to brute force Microsoft 365 user\r\naccounts or other services. Our network capture revealed that 912 connections were made using the socks\r\nproxy during one week to login.microsoftonline.com. However, there were only a few password attempts\r\n(maybe only one?) per connection, which is surprising for a ‘brute force attack.’ Therefore, we believe this botnet\r\nis primarily used to conduct simple password spraying attacks, rather than engaging in traditional brute\r\nforce attacks.\r\nWe identified two servers (142.11.205[.]164 and 23.254.201[.]175) both hosted under HOSTWINDS, US\r\n(AS54290), that authenticated themselves to the socks proxy to send requests to login.microsoftonline.com.\r\nTo check the proxy status, two IP addresses were employed (151.236.20[.]185 and 151.236.20[.]211), this time\r\nhosted under M247, RO (AS9009). These IP addresses used the socks proxy to only check the exit node IP address\r\nby issuing HTTP requests to whatismyip.akamai.com with Go and Python user agents.\r\nThis initial analysis led us to believe that only one threat actor was using the socks proxy installed on the\r\nrouter to check Microsoft 365 user accounts. This finding was surprising, given that socks remain an unsecure\r\nproxying protocol with an authentication in clear-text.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 11 of 17\n\nOur second question was related to the xlogin bind shell and who was interacting with it. We observed the IP\r\naddress 151.236.20[.]185 doing the same continuous checks to verify that the SOCKS/11288 and TELNET/7777\r\nports were available. And at one time, we saw the same IP address issuing hands-on keyboard commands via\r\nthe xlogin bind shell to update the socks5 binary on the compromised router.\r\nLet’s take a look at the brute force attempts in our telemetry.\r\nThe rate of attempts per account is on average about one every 40 hours, and it is common for accounts to have\r\nreceived more than 50 authentication attempts over several months. This suggests that a list of passwords is\r\nbeing tested on each account (password spraying), rather than credential pairs obtained from data breaches\r\n(credential stuffing).\r\nIn the dataset of Sekoia.io XDR customers, 27% of organisations (Entra ID tenants) were targeted over the\r\nlast 30 days. On average, 0.11% of monitored user accounts are affected, with some larger tenants having several\r\ndozens of targeted accounts, and some smaller organisations having up to 5% of their users targeted.\r\nSeveral industry verticals, including local authorities, have been targeted in recent days without any discernible\r\npattern relating to the type of industry or the size of the targeted entity. \r\nRegarding the targeted accounts, despite what is said in the original blogpost, no clear pattern emerges from the\r\ntargeted accounts. Indeed, while there are some VIPs, they are very much in the minority compared to the\r\nbulk of the tested accounts. Some are not even real user accounts but rather aliases such as unsubscribe@,\r\nnoreply@, or even customersupport@. The list of targeted email addresses evolves over time, with new addresses\r\nbeing added to or removed from the list. \r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 12 of 17\n\nTherefore, the threat actor behind the Quad7 botnet does not appear to be an APT but more likely\r\ncybercriminals looking to carry out business email compromise via password spraying from compromised\r\nSOHO routers.\r\nAfter this investigation, some mysteries remain.\r\nThe primary mystery of this investigation remains the attribution question. Many speculations have been\r\nmade in open-source discussions, suggesting it could be another Chinese IoT botnet or a North Korean campaign.\r\nHowever, during our investigation, we were unable to identify any evidence pointing to a known threat actor.\r\nTheir binaries are stripped and only one is really custom, the xlogin shell. The time frame of the brute force\r\nattacks did not reveal any significant information either, as the attempts were inactive on some days, and we\r\nmonitored this router for one week only.\r\nRegarding the infrastructure, we found only one interesting match with a C2 related to GobRAT – another notable\r\nIoT botnet first disclosed by the JP-CERT – next to one of the Quad7 botnet operators’ IP addresses. However, this\r\nis a very weak link as GobRAT and the other implants dropped by the same threat actor are modular and way\r\nmore sophisticated than a simple bind shell with a socks proxy.\r\nThe second mystery is the exploited vulnerabilities used to compromise these routers. We are almost certain\r\nthat the attackers had an authentication bypass leading to an RCE or an unauthenticated RCE. As TP-Link reused\r\nalmost the same firmware codebase between some router series – you can see that with WR841N related files on\r\nthe Archer C7 directory listing screenshot – it is likely possible that the attackers are using only one exploit chain\r\nthat affects all routers.\r\nThe last remaining mystery is the geographical distribution of this botnet. Initially, we thought that it might\r\nbe due to default passwords set by internet providers in specific countries. However, we are confident that the\r\noperators behind the Quad7 botnet are not doing brute-forcing attacks against the router’s management interface.\r\nTherefore, this mystery remains unsolved.\r\nIn summary, the Quad7 botnet still has many unanswered questions, and we believe that companies with a better\r\nview on the infrastructure supporting this botnet will be able to provide answers. It is important to remember that\r\nour investigation was limited to one router and one week of monitoring.\r\nThreats targeting edge devices: an unseen but prevalent danger\r\nThe Quad7 botnet operators made various mistakes, allowing the community to identify the compromised routers\r\nthrough internet scanners. However, the vast majority of threats targeting edge devices remain invisible.\r\nTherefore, we encourage restricting the remote administration of these devices to specific IP addresses to prevent\r\nthe exploitation of vulnerabilities and ensure your devices are updated with the latest firmware.\r\nIn the case of enterprise-grade edge devices (e.g., VPN/mail gateways, routers, etc.), many threat actors are using\r\nthem to gain a foothold inside networks while staying under the radar of security solutions. Consequently, we\r\nrecommend deploying specific rules to monitor authentication attempts against internal servers originating from\r\nthese edge devices’ IP addresses and other unmonitored devices inside your network.\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 13 of 17\n\nDetection Bonus: Advice for MSSP to hunt for Quad7 O365 targeting.\r\nThe authentication attempts performed via the Quad7 botnet botnet feature a fairly unique combination of\r\nattributes that make them easily identifiable in the Entra ID Sign-in log or Microsoft 365 audit log:\r\nUser-Agent is either:\r\nMozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko\r\nMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/80.0.3987.149 Safari/537.36\r\nApplication ID: 1950a258-227b-4e31-a9cf-717495945fc2 (Microsoft Azure PowerShell)\r\nResource ID is either:\r\n00000003-0000-0000-c000-000000000000 (Microsoft Graph)\r\n\u003cempty\u003e\r\nIt is possible to confirm that the request originated from the botnet by looking up the source IP address in a tool\r\nlike Censys or Shodan to confirm the presence of the “xlogin:” banner on port 7777. In the dataset of logs\r\navailable to Sekoia.io, over 98% of the authentication attempts identified by this heuristic can be conclusively\r\nattributed to the Quad7 botnet.\r\nThis query should return almost exclusively authentication failures, with the most common error codes being:\r\n50126: Invalid username or password\r\n50053: Account locked\r\n50057: Account disabled\r\nAuthentication attempts resulting in other status codes should be investigated to determine if the account’s\r\npassword was discovered. When the logs indicate that the authentication was blocked by multi-factor\r\nauthentication or conditional access policies, the password should be considered compromised, as these\r\nverifications only occur after a correct password was submitted. Identifying these authentication logs can help\r\nassess how an organisation is targeted.\r\nThank you for reading this blog post. Please don’t hesitate to provide your feedback on our publications by\r\nclicking here. You can also contact us at tdr[at]sekoia.io for further discussions.\r\nQuad7 Botnet Indicators of compromise\r\nSome IOCs \u0026 samples aren’t shared publicly. If you are a national CERT or LEA, we can share the IOCs and the\r\nsamples with you under TLP:AMBER+STRICT as they contain hardcoded passwords leading to remote shell\r\nexecution on the compromised routers.\r\nPlease contact tdr [ at ] sekoia [ dot ] io\r\nInfrastructure\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 14 of 17\n\n142.11.205[.]164\r\n23.254.201[.]175\r\n151.236.20[.]185\r\n151.236.20[.]211\r\n[TFTP SERVER: on demand]\r\nMalware\r\n98d3764862b182417c910a96e0fbfe71 init.sh\r\nc8e229bed1659f1613c1016b3345ef08 microsocks\r\n29e6df5bb30ed8fd12c09d9b6890ab4f socks5\r\n69ced04a2ec895084d3aab1086216d32 xlogin\r\nYara rules\r\nrule unknown_7777_xlogin {\r\n meta:\r\n id = \"01510244-0795-4299-aa66-056a2b4682e7\"\r\n version = \"1.0\"\r\n intrusion_set = \"Quad7 Botnet\"\r\n malware = \"xlogin\"\r\n description = \"Detects the xlogin bind shell\"\r\n source = \"Sekoia.io\"\r\n creation_date = \"2024-07-18\"\r\n classification = \"TLP:CLEAR\"\r\n hash = \"69ced04a2ec895084d3aab1086216d32\"\r\n strings:\r\n $ = { 2f 62 69 6e 2f 73 68 00 2f 74 6d 70 2f 6c 6f 67 69 6e }\r\n $ = { 2F 64 65 76 2F 6E 75 6C 6C 00 00 00 2F 62 69 6E 2F 73 68 00 2D 63 }\r\n condition:\r\n uint32be(0) == 0x7f454c46 and\r\n filesize \u0026lt; 100KB and\r\n all of them\r\n}\r\nrule tool_bhhbazinga_Sock5_strings {\r\n meta:\r\n id = \"45dafe1e-81bb-4202-93ab-fcd46e8d8d6b\"\r\n version = \"1.0\"\r\n tool = \"bhhbazinga sock5\"\r\n description = \"Detects the sock5 project developed by bhhbazinga\"\r\n source = \"Sekoia.io\"\r\n creation_date = \"2024-07-18\"\r\n classification = \"TLP:CLEAR\"\r\n hash = \"29e6df5bb30ed8fd12c09d9b6890ab4f\"\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 15 of 17\n\nstrings:\r\n $ = \"tunnel_read_handle\"\r\n $ = \"tunnel_write_handle\"\r\n $ = \"tunnel_open_handle\"\r\n $ = \"tunnel_auth_handle\"\r\n $ = \"tunnel_connect_to_remote\"\r\n $ = \"tunnel_request_handle\"\r\n $ = \"-u\u003coptional\u003e : username\"\r\n $ = \"-k\u003coptional\u003e : password\"\r\n $ = \"d\u003coptional\u003e : backgroud\"\r\n condition:\r\n uint32be(0) == 0x7f454c46 and\r\n filesize \u0026lt; 150KB and\r\n 5 of them\r\n}\r\nrule tool_microsocks_strings {\r\n meta:\r\n id = \"07cdecee-3a62-4e1d-96cd-24e4dc30925d\"\r\n version = \"1.0\"\r\n tool = \"microsocks\"\r\n description = \"Detects the microsocks project developed by rofl0r\"\r\n source = \"Sekoia.io\"\r\n creation_date = \"2024-07-18\"\r\n classification = \"TLP:CLEAR\"\r\n hash = \"c8e229bed1659f1613c1016b3345ef08\"\r\n strings:\r\n $ = \"error: user and pass must be used together\"\r\n $ = \": option requires an argument:\"\r\n $ = \"option -1 activates auth_once mode:\"\r\n $ = \"error: option -%c requires an operan\"\r\n $ = \"client[%d] %s: connected to %s:%d\"\r\n condition:\r\n uint32be(0) == 0x7f454c46 and\r\n filesize \u0026lt; 100KB and\r\n 4 of them\r\n}\r\nSigma rule\r\ntitle: Entra ID Account Password Compromised By 7777 Botnet\r\ndescription: Detects a successful Entra ID authentication featuring characteristics associated with t\r\nauthor: Sekoia.io\r\ndate: 2024/07/19\r\ntags:\r\n - tlp.clear\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 16 of 17\n\nlogsource:\r\n product: azure\r\n service: signinlogs\r\ndetection:\r\n selection:\r\n userAgent:\r\n - 'Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko'\r\n - 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrom\r\n AppId: 1950a258-227b-4e31-a9cf-717495945fc2 # Microsoft Azure PowerShell\r\n ResourceId: 00000003-0000-0000-c000-000000000000 # Microsoft Graph\r\n filter:\r\n ResultType:\r\n - 50126 # InvalidUserNameOrPassword\r\n - 50053 # IdsLocked\r\n - 50057 # UserDisabled\r\n - 50056 # InvalidPasswordNullPassword\r\n condition: selection and not filter\r\nfalsepositives:\r\n - Other error codes indicating that the password was incorrect.\r\nlevel: high\r\nNotes:\r\nA similar rule can be written for the Microsoft 365 audit log.\r\nFor simplicity, this rule omits the case where ResourceId is empty, as this variant has not been observed\r\nrecently.\r\nGreetings\r\nWe would like to thank Intrinsec for putting us on the trail of this botnet and Gi7w0rm for its publication. Thanks\r\nto Nicolas Noël (Disweb.fr), who allowed us to intervene on one of his client’s routers, as well as to everyone\r\nwho, directly or indirectly, contributed to the successful completion of this operation.\r\nShare\r\n7777 botnet Botnet CTI Malware Quad7 botnet\r\nShare this post:\r\nSource: https://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nhttps://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://blog.sekoia.io/solving-the-7777-botnet-enigma-a-cybersecurity-quest/"
	],
	"report_names": [
		"solving-the-7777-botnet-enigma-a-cybersecurity-quest"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775438995,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e012644ba7c04c8fc85518ff6ffb20e4bef11b93.pdf",
		"text": "https://archive.orkl.eu/e012644ba7c04c8fc85518ff6ffb20e4bef11b93.txt",
		"img": "https://archive.orkl.eu/e012644ba7c04c8fc85518ff6ffb20e4bef11b93.jpg"
	}
}