Russian Botnet RSOCKS and the Dangers of Unsecured IoT

A law enforcement operation between the US, UK, Germany, and the Netherlands has successfully taken down the infrastructure of a large Russian botnet. The botnet, known as RSOCKS, is estimated to contain millions of hacked IoT devices worldwide.

Instead of targeting desktop machines with commodity malware, the hackers behind RSOCKS have changed tactics by first targeting Internet of Things (IOT) devices. IoT devices are an ideal target due in part to their poor security and lack of visibility for end users. The RSOCKS botnet is the latest in a trend of botnets actively targeting the IoT landscape.


If you’re infected by malware, it’s likely to be part of a botnet. Cybercrime has become big business, and anyone interested in making money illegally can run a botnet regardless of skill level. Botnet sellers often resell access to their hacked machines, leading to additional infections and further compromise of an infected system or network. This kind of black market proxy-selling operation is often used for credit card fraud, spam, and as plausible deniability when conducting more targeted attacks. 

RSOCKS advertised itself as an IP proxy service offering legitimate IP addresses from internet service providers (ISP). However, it was actually selling IP addresses of IoT devices hacked through the botnet. This service allows hackers to conceal their IP addresses when conducting various illicit activities. 

For RSOCKS, proxies were sold in packages. These ranged from $30 per day for access to 2,000 proxies, to $200 per day for access to 90,000 proxies, with each one coming from a compromised IoT device. The FBI estimates the number of infections at the time of ROCKS’ takedown to be 325,000 systems worldwide.


As antivirus vendors become more sophisticated, malware authors are facing a problem. Malware is being detected more quickly, with connections to botnets now measured in days rather than months or years. For RSOCKS and others in their black market industry, this rapid detection is bad for business. RSOCKS wants to provide their customers with non-attributable proxy connections from hacked machines, to facilitate illegal activity such as credit card fraud or spam. For this specific use case, machines dropping out after being detected isn’t good for them or their customer. So where’s a malware author to turn?

What if there were a platform running on most victims’ networks that had unrestricted access to the internet, often no firewall to monitor traffic, no designated antivirus solutions, and no visibility for the end user? Enter IoT devices – the next great botnet target.

IoT devices provide attackers with a treasure trove of ways to access an internal network, making them an appealing target for botnets. These smart devices have extensive security weaknesses, including default credential reuse, lack of visibility, lack of defensive tooling, and lack of an SDLC process typically used when developing these devices.

For IoT devices, the main vector for spreading malware is through the brute-forcing of default user or manufacturer passwords. Few people are aware that their DVR system has an SSH server running with admin:admin as the root login. That is, until their ISP contacts them for involvement in a DDoS attack on a game or website. These issues are inherently hard to mitigate at the device level, particularly when the device is a consumer appliance, because why would end users need to SSH in as root to their coffee machine? But this convention often leaves users with no way to change the default passwords for system services. 


Assuming a compromised system connects to your internal network somehow, how secure is your internal infrastructure? Your external attack surface may be incredibly well locked down, but once inside the network, things tend to change. There’s an assumed level of trust on the inside.

A fancy edge firewall or email gateway with “AI” phishing protection will likely stop attackers from phishing employees, and an expensive, brand new XDR solution will likely stop attackers from compromising employee endpoints. But what if the cracks are elsewhere, in say, unprotected devices?

Who’s updating that internal Jenkins server? Who’s updating that internal kanban app an employee set up 2 years ago, connected to your SSO, and has every employee using it? What about the internal portal to reset employee passwords that was written in 2008 and is still vulnerable to SQL injection?

The only real options are to put smart devices behind a firewall (preventing SSH/Telnet access from the internet) or go full zero trust. Is this ideal from a security perspective? Not entirely. An attacker could still pivot from a compromised endpoint to an IoT device within the network and launch attacks from there, even when endpoint access has been detected and blocked. The majority of “smart” appliances will never offer more than the bare minimum security by default.

It’s worth noting that while RSOCKS didn’t actually sell access to internal networks, the initial access vector they used is still viable for other attackers. RSOCKS has been taken down, but others will surely take its place. Nowadays the internet has hundreds of thousands of brute force attempts on embedded systems, mostly from script kiddies trying to grow their botnet. It’s not exactly a stretch for criminals to sell access to compromised systems if there’s money to be made.


The RSOCKS botnet is just the latest example of attackers evolving, and it’s far from an isolated incident. As attackers evolve, security standards are unfortunately falling behind. Most organizations’ perception of security is that it’s something done once to comply with auditors and forgotten about until the next audit or major security breach. While that would be easier, in reality, security is a constantly changing landscape. Attackers are moving the playing field from compromised employee endpoints to compromised routers or IoT devices, where the visibility is almost nonexistent. This means our vigilance must be on the move as well. As the attackers evolve, so too must the defenders.

Microsoft Permits Hackers to Use Macros Again

In April, Microsoft dealt a huge blow to malicious malware operations by blocking VBA macros on downloaded documents by default. Security researchers and blue team defenders everywhere rejoiced, while red teams and attackers wept. But now Microsoft has decided to do a 180 and undo the change, enabling VBA macros once again.

The reason behind this rollback is still unknown. We suspect this change was reverted due to some amount of businesses relying on macros for automated data processing. Or perhaps too many end-users found it burdensome to unblock files downloaded multiple times per day. According to Microsoft, this decision was “based on the feedback of customers,” though Microsoft has not shared the exact negative feedback that motivated the rollback. However, users have reported publicly that they were unable to find the “Unblock” button to remove the “Mark of the Web” from downloaded files, which effectively made unblocking macros impossible. 

How Macros Work and Why They Can be Dangerous

Macros, which allow users to automate frequently-used formatting settings, are a holdover from the days of legacy Office. The scripting interface available in newer Office solutions didn’t yet exist, so automating settings meant relying on external tools or writing in Visual Basic for Applications (VBA), an embedded language implementation of Visual Basic 6 (VB6). 

Macros make use of this fully-integrated language, which is capable of automatically running code when a document is opened, and which uses functions calling out to the standard VB6 library. Given these features, it’s clear how macros have led to abuse. 

The initial viruses delivered from macros were mostly harmless or annoying viruses designed to self-spread through desktop email clients and removable media like floppy disks. However, this slowly changed when the internet became mainstream and virus makers realized there was profit to be made in exploiting macros. 

VBA macros are among the most popular entry points for malware operations.  Among these are Melissa, Emotet, TrickBot, Qbot, Concept, and thousands more used in phishing attacks. Attackers don’t need to bring their A-game zero days and exploit packs when they can simply embed a macro in a document, obfuscate it against anti-virus products, and watch the shells come raining in. Malicious actors realized that while it may be difficult to get a target to open an executable file, getting them to open an Office document is far easier, as it’s something they do every day.

A Long-awaited Feature

This now-canceled feature has been highly anticipated and was expected to reach widespread availability in June. It covered Access, Excel, PowerPoint, Visio, and Word applications in the cloud, and traditional versions of Office: Office 365, Office 2021, Office 2019, Office 2016, and Office 2013 for Windows (macOS, iOS, Android, and web versions not included).

If the blocking of VBA macros were indeed implemented, it would be a game changer. This would force attackers to adapt to the new landscape without the easy code execution methods that have worked for decades. 

The disabling of macros would only affect documents obtained from “untrusted” sources as denoted by the NTFS file systems alternative file stream “Mark of the Web”, which is automatically given to files obtained from the internet. This is generally a “good enough” marker that the file probably shouldn’t be executing code on a system. If Microsoft had followed through and kept this new feature, the end user would see a warning when opening up a macro-enabled document downloaded from an untrusted source. It would have a big “SECURITY WARNING” and a link explaining the dangers of loading untrusted macros.

The Big Picture

For now, Microsoft has left unsuspecting users unprotected. Hackers are once again free to send malicious Office documents with VBA scripts (provided they put in some minimal effort to avoid AV detection). These attacks rely on a lack of understanding from the end user about what macros can do. Combined with pretexts such as documents claiming to be from Microsoft, or claiming one must “Enable macros to decrypt the document”, a lot of users will continue getting fooled.

The education of users is important, and anyone who works with company IT should understand the risks of macro-enabled documents. It may not seem like a big deal, but while a company’s external security posture may be robust, its internal security is rarely so certain. Assumed levels of trust exist once inside a physical local network, but users must learn to remain vigilant. 

While there is no silver bullet for security, there are a number of things that can be done to protect you or your company. The first is to look into disabling macros entirely if the business doesn’t use them. This can be done for enterprises through a Group Policy Object (GPO), or for end users through registry changes or Office settings. Further details on disabling macros can be found with Microsoft

New P2P Botnet and Cryptocurrency Miner Panchan Breaches Linux Servers

Akamai security researchers have reported a new peer-to-peer botnet written in Golang. The malware, called Panchan, is aimed primarily at spreading cryptocurrency miners.

Panchan itself is a worm, allowing it to spread across the internet by brute-forcing default SSH credentials primarily on IoT devices such as routers and smart devices. The malware also collects SSH private keys and attempts to use them to move laterally across the target network. So far the botnet operators have targeted telecoms and academic institutions in Asia, Europe, and North America.


Once on an infected system the malware pulls in two crypto miners: XMRig and nbhash, the proprietary miner of the cryptocurrency pool NiceHash. These binaries are never written to disk and are instead backed by a memory-mapped file descriptor created by the memfd_create libc function.

Researchers have been tracking this threat in the wild since March and have noted several interesting characteristics about it and its operators, which may shed some light on its origins and intended use. The botnet uses a custom cleartext TCP protocol to provide peer-to-peer functionality, which causes its infected hosts to act as the infrastructure keeping the botnet alive. This makes it difficult to isolate and stop the botnet once it has infected enough computers. Panchan also playfully identifies itself before every message with, “pan-chan’s mining rig hi!” followed by the actual configuration/commands provided by the administrator.

Panchan pulls private keys from the infected system, but also reads the .known_hosts file, a file created by the SSH client to store SSH fingerprints and provide a Trust on First Use (TOFU) security model to prevent future MITM attacks. Panchan then iterates over the .known_hosts entries, which contain an IP or hostname, and tries to log in to them with the SSH keys to further spread itself.

A custom admin panel is also provided by the botnet and nicknamed “Godmode.” Similar to other self-spreading Linux-based bots, the panel is typically accessed using telnet or netcat. However, unlike other bots where authentication is done via the possession of a private key, Panchan allows its authors to access the admin panel running on any infected host and ensures no one apart from them can update the bot’s configuration. This approach provides a potential method that authorities could use to seize control of the botnet, by creating a fake panel and harvesting the private key. 

This approach to authentication is spectacularly bad practice on behalf of the author, and quite amusing – they are submitting a private key that can be used to control and update the bot’s config on a host that they’ve infected. 

This panel is only available in Japanese with no English localization, hinting at the author’s native language being Japanese.

In addition to the unique custom panel, the malware author is also on Discord advertising their server inside the code and botnet backend responses. They are using Discord webhooks as a way to monitor new infections, by sending a POST request to a webhook once a new initial infection has occurred.

The malware author has made good attempts to remain undetected on the target system for as long as possible, iterating over the process list to look for performance monitoring tools (such as htop and top) and, upon seeing them, killing the miner to avoid detection. However, usage of centralized services such as Discord and NiceHash in contrast to apparent attempts to keep the botnet resilient and stealthy are certainly interesting and provide valuable avenues for law enforcement to take down the botnet.


Panchan is written in the Go programming language (Golang) and uses some of the language’s unique features to maximize its spread. The ability to “Write once, run everywhere!” without the need for a JVM or a Python interpreter is very appealing to malware authors. This, combined with the fact that Golang binaries are inherently harder to reverse due to their string resolution, usage of goroutines, and odd calling conventions (inspired by the Plan9 ABI!), makes it an appealing choice for writing malware. 

Across the industry, an uptick in Go-based malware has been observed. While not impossible (the industry has been catching up), the current gap in the availability of comprehensive tooling in Go has provided malware authors more leeway in designing their malware than a traditional language like C/C++.


Cryptocurrency offers a lucrative method for attackers to cash out, especially when they avoid legitimate exchanges that require official identification. We see cryptocurrency usage by threat actors increasing, especially as more severe sanctions are issued following attacks. This is particularly true for state-sponsored attackers for whom cryptocurrency can finance attacks with little to no attribution to the attackers.

The “playful” nature of this botnet and the fact that it’s “only” mining cryptocurrency may lead administrators to believe it’s not a major threat. However, due to the speed at which Panchan can spread and the fact that it’s designed to be modular and updatable, it’s impossible to determine what the authors may add next. They may pivot from cryptocurrency mining to selling access, or to other threat vectors. For this reason, any infection should be taken very seriously and the initial access vector identified and remediated.


Akamai researchers have provided a list of IOCs, YARA rules and Snort rules, as well as a convenient helper script you can run if you suspect you’re infected with Panchan. It looks for the following artifacts:

  • A systemd-worker.service 
  • xinetd in a non standard location
  • An active socket listening on port 1919

This script can be found here:

While the first two are clear indicators, the latter could be misidentified if you have a legitimate service running on port 1919.

However, due to the always-evolving nature of malware, these IOCs could be invalid by the time you’re reading this. As the saying goes: prevention is better than cure.

Due to the initial access vector appearing to be a self-spreading SSH worm primarily using default credentials, remediating this access vector shouldn’t be too difficult. If you have IoT devices with hard-coded credentials that you cannot change then it may be worth reevaluating your use of those devices depending on your threat model.

Need a hand with this? That’s fine, this stuff is hard. At Soteryan we’re happy to help you review your threat model and improve your company’s security posture.