Hide ‘N Seek: what can we learn from an evolving botnet

null

You may have read recently that the Hide ‘N Seek (HNS) botnet, which had targeted Internet of Things (IoT) devices, has now expanded its focus to cross-platform databases.

The botnet first gained attention earlier this year, initially for becoming one of few IoT botnets to communicate via a custom-built peer to peer (P2P) protocol, and then later in May when it gained the ability to survive a reboot - also known as persistence.

This was an interesting turn, as most IoT devices have a read-only file system and vendor/device specific tools or APIs to make configuration persist and control which processes start at boot. Because of this, malware programs are usually running from ephemeral (temporary) RAM file systems and get wiped at reboot. 

Most bot coders do not go the extra mile to make them persistent, as most IoT devices are not rebooted that often. They put their development investment in more efficient scanning and exploiting mechanisms which allows their botnets to keep IoT share in a competitive environment.

With the latest development the botnet, best known for infecting home routers, IP cameras and digital video recorders, has now started compromising NoSQL database servers.

Its newest trick demonstrates that this botnet was designed from the start to be a scalable and persistent platform. 

Tracking botnet evolution

IoT botnets share their history with Linux malware. Most of the vulnerable IoT devices run a stripped version of Linux, the same operating system that is powering most internet services today. This means operating systems on IoT devices provide the lowest common denominator of all Linux based platforms in terms of shared libraries and capabilities. 

Moving from IoT to full-blown cloud servers, virtual servers and/or containers is just a cross-compile away. Nearly all IoT malware discovered to date already provides cross-compiled binaries, capable of creating executable code for a platform other than the one on which the compiler is running.

Jumping from IoT to Linux servers is merely a matter of tuning the infection vectors, for example adding CouchDB and OrientDB exploits to the code. 

Cloud servers providing elastic memory and CPU, increasing resources on demand, are great for running crypto mining operations while IoT devices, which are more resource constrained but have the power in numbers, provide the ultimate platform for Distributed Denial of Service attacks, anonymising proxies for concealing targeted attacks or distributed vulnerability scanning operations. 

Once attackers have a solid botnet foundation, they can optimise the payloads how they see fit and increase their revenue from multiple (illegal) income streams such as mining, booter services, ransom DDoS, SPAM services and more.

HNS, through its P2P command and control, was meant from the start to be a scalable and persistent platform. Now we are seeing the first examples of the attackers taking advantage of their creation. 

Most IoT malware, especially those based on Mirai, are opportunistic in nature. Attackers invest very little in the development and hope for quick gains while they are very much aware that upon first detection by security researchers the game is over. 

But the more elaborate and craftily designed Command-and-control protocols, also called C&C or C2 mechanisms, and update features such as those provided by Hajime and HNS are a bigger initial investment for the attackers in coding the features but provide a more persistent platform that can be grown by adding more infection vectors and malicious payloads over time. 

Take Hajime for example, initially detected two days before the DYN attacks and still operational. It received several updates, mainly in terms of new infection vectors, and was able to maintain a good set of infected (protected) devices. 

Hajime is a sophisticated, flexible, thoughtfully designed and future-proof IoT botnet. It is capable of updating itself and provides the ability to extend its member bots with ‘richer’ functionality efficiently and fast. 

Today, the internet has turned into a battlefield for IoT devices. Bots leveraging the newest infection vectors and most aggressive scanning will take share. Some of those botnets are opportunistic and fade away quickly, others are growing and shrinking over time but persistent and staying on the forefront by implementing a variety of vulnerabilities and infection vectors – HNS falls in the latter category.   

That is why we talk about the battle of the IoT bots, with different botnets fighting for IoT resources. When a new bot starts on an IoT device, it first looks for any familiar (known) bots and kicks them out, it will also try to protect the device using iptables or similar firewall rules and terminating vulnerable daemons such as telnetd and sshd, ensuring it hardens its position on the device and protect itself from further infection by competing botnets. 

But most of them do not try to become persistent because that is very device dependent – most IoT devices only provide read-only access to system files and use ram-based file systems for temporary data – so it is hard to find a suitable place that makes changes persistent across reboots. While it has been proven successful in the past by researchers, it was mainly through exploiting a vulnerability in the device itself that they were able to make their infection persistent – which is why HNS is such an interesting example.

What can organisations do to protect themselves?

Most of the infection vectors leveraged by IoT and non-IoT botnets are using known vulnerabilities, some dating back several years. A good security hygiene will bring an organisation a long way in protecting against these malwares. 

Regular updates, good password management and changing or removing default accounts, regular or automated checks for configuration management to prevent configuration errors or newly added defaults that might expose services are just a few of the actions that security conscious organisations should be taking.

Protecting against the threats posed by these malwares requires not much more than attention and care for servers and services that are directly exposed on the internet. 

But for those occasional moments where a botnet is leveraging 0-day vulnerabilities, critical services such as web/mobile interfaces and APIs should consider adding web application security. Security solutions for these types of issues should be already considered from a data breach and targeted attack point of view, and not necessarily driven by a need to protect against malwares and botnets.

Making sure you have the basics in place is often more effective than you think, making these steps essential to improving your overall security posture.

Pascal Geenens, EMEA Security Evangelist at Radware 

Image Credit: Koretnyk Anastasiia / Shutterstock