ZuoRAT  is a Meaner RAT, but It Still Can Be Trapped

ZuoRAT is a Meaner RAT, but It Still Can Be Trapped

Concerned about ZuoRAT? Try something old and something new

AMIT SERPER

August 9, 2022

Attackers usually take the path of least resistance to their target.  As we’ve adopted remote work/work from home habits this appears to be the case once again.  Our pandemic-spurred remote work behavior provided just the opportunity bad actors needed to bypass the traditional defense-in-depth protections found in most enterprises, and target their malware at less secure SOHO environments. 

Therefore, I wasn’t surprised when Black Lotus labs revealed a new Remote Access Trojan (RAT), dubbed ZuoRAT, in a June 28th blog post. ZuoRAT is not just another malware, but rather something that we as security professionals should have been expecting for quite a while now.

Usually experts distinguish between malware targeting endpoints (desktop, laptops, and servers) and malware targeting embedded systems. Malware targeting endpoints are usually more prolific and capable, while malware that are targeting embedded devices are usually coin miners or DDOS bots.  

ZuoRAT: A more sophisticated router exploit

ZuoRAT takes a very different approach - clearly it was devised in the pandemic era to exploit remote office workers with access to larger enterprise networks and the valuable data they contain.

Unlike the aforementioned examples, ZuoRAT is far more advanced and nefarious. ZuoRAT branches the network by exploiting 1-day vulnerabilities on SOHO devices (such as routers), and implements multiple attacks on the router itself  before spreading to the rest of the network and attacking it.

Once ZuoRAT’s code is executed on the router, it gathers basic information about the device itself and, more importantly, on the rest of the network. ZuoRAT then can:

  1. Start scanning the internal network through the router, looking for a hard-coded list of open ports.
  2. Turn the attacked device into a node, which the attackers can use as a proxy server to tunnel their traffic through.
  3. Be used to conduct DNS/HTTP hijacking man-in-the-middle attacks on the network.

If ZuoRAT were a piece of malware that had these same features but was targeting regular endpoints, detecting it with an EDR/EPP platform would have been a fairly common and trivial task.

However, since ZuoRAT lives on the router, a defender has absolutely no visibility into the security posture of the operating system of said device. Moreover, even if there is some sort of a visibility solution, there is certainly nothing on-device that will prevent such malicious code from loading and executing.

The constant chase after security patches

The “patchability” of said devices is problematic at best. Many of the SOHO routing devices that are being deployed today are not running up-to-date operating systems. Moreover, insecure code based on ancient libraries running on those devices is often the root cause of exploited vulnerabilities and exposures in general. 

Even ZuoRAT, which is definitely one of the more sophisticated IoT RATs to be discovered, is leveraging well-known security vulnerabilities to initially breach the routers. ZuoRAT clearly demonstrates this: Its initial breach vector is the exploitation of unpatched vulnerabilities that are several years old.

The softer the target, the bigger the challenge to secure it

Known challenges with legacy/SOHO routing devices (ZuoRAT’s target) are many:

  • SOHO routing devices persist, often for years, running similarly old firmware or software (When was the last time you changed out your home or small office router?)
  • SOHO routers are rarely rebooted (unless power fails), and even less often patched/updated.
  • Router manufacturers and ISPs, motivated to quickly adopt newer/faster technologies, often stop development of patches/fixes long prior to device EOL.
  • SOHO router devices are typically unmanaged and most users are technically unable to manage them.
  • Device manufacturers rely heavily on third-party software components to speed development time and lower costs; Unfortunately, these often prove the source of vulnerability.

So what do we do?  Something old and something new

Try something old:  (even though it’s hard!) Routine rebooting and patching should be the norm for SOHO devices.  Don’t let lack of discipline be fuel for a least resistance path for attackers.

Try something new: The ultimate solution to this quandary is for router and other IoT device manufacturers to build in dynamic defenses that can address the ever-changing threat environment with low overhead.  Runtime exploit protection, embedded within firmware, provides one mechanism and added defense to protect from 0-day and 1-day vulnerabilities since it deterministically finds and terminates common exploitation patterns, such as memory overflow, command injection, and execution flow anomalies.  

These comprise the majority of IoT attack behavior, regardless of the attack path or vulnerability targeted. Built-in firmware runtime security halts attacks in their tracks and does not require patching to afford protection.

This means if a device protected by Sternum was to get attacked by the threat actors behind ZuoRAT, the initial exploitation would have been prevented instantly, breaking the chain of infection and stopping the attack preemptively.

Additionally, Sternum’s platform offers its users unprecedented visibility into their IoT products from the standpoint of running processes, memory usage, behavior anomalies, security alerts, and much more.

Sternum’s platform gives the user the ability to investigate an IoT security incident, see which resources were affected, and quickly determine the root cause.

We hope you’ll give it a try yourself. Sternum makes available a free license for OpenWrt devices (including most SOHO routers) - experience it yourself at https://app-dev.sternum.cloud/

Better Performance with Autonomous Observability

Gain complete visibility by monitoring and analyzing events in your device or across an entire fleet, from the first line of code and until post-deployment maintenance.

Diagnose software bugs and vulnerabilities by using instrumentation, to pinpoint flaws, gain dynamic profiling and analysis of the software, including third-party code.

Learn about Sternum observability >>