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.

Back to overview