When is a RAT, not a RAT?

Have you heard the story about the RAT that pretended to be a RAT? If not, you’d better sit down for this one.

There’s a RAT in my kitchen

Last month, a malicious package, ethereumvulncontracthandler, was identified on the npm registry. It disguised itself as a Remote Access Tool (RAT), posing as a library for detecting vulnerabilities in Ethereum smart contracts. Instead of detecting said vulnerabilities, it dropped an open-source remote access trojan called Quasar Remote Access Trojan (RAT) onto developer systems.

To delve a little deeper into this process, following installation, the program works through retrieving and executing a script from a remote server, which facilitates the Quasar Remote Access Trojan deployment on the targeted Windows system. The code is obfuscated through techniques such as Base64 encoding, XOR encoding, and minification – all methods designed to evade detection and analysis by security tools. Furthermore, the malware searches for sandbox environments before execution to circumvent automated analysis and limit its exposure in controlled settings.

The threat research team at Socket detected the package containing the malicious code, which the npm security team subsequently removed from the registry.

Rat-a-two-ille

Quasar was initially released in 2014 as “xRAT” and renamed by its original developers to “Quasar” in 2015. This change was most probably enacted to distinguish it from nefarious versions of the software being deployed by threat actors so soon after its release.

The original program, designed as a publicly available utility for Microsoft Windows, was intended for legitimate use in various applications. However, it rapidly gained traction among malicious actors due to several critical factors. One is the program’s openly accessible source code, which allows hacker communities to examine, modify, and enhance its features easily, leading to the integration of various forms of malware. This open-source nature fosters a collaborative environment for cybercriminals, encouraging the development of sophisticated tools that can evade detection.

Another is the program’s wide range of functionalities, which make it particularly attractive for exploitation. These include keystroke logging, which captures every keystroke made by the user; screenshot capturing, which allows the unauthorized recording of a user’s screen activity; and credential harvesting, which involves the collection of usernames, passwords, and other sensitive information.

As cybercriminals became more widely understood and utilized this program’s capabilities, it became a significant threat, especially for software developers. It places their sensitive information at risk, including private keys, crucial for securing access to various systems and applications. The potential for data breaches and loss of intellectual property underscores the urgent need for enhanced security measures in the digital landscape.

Expert Insights

Security professionals have been reacting to the discovery, underscoring that such vulnerabilities with Ethereum smart contracts are nothing new, that they are a real threat for developers, and the precautions security teams need to take to mitigate such threats.

Referencing reports suggesting that vulnerabilities in Ethereum smart contracts caused financial losses exceeding $1B in 2023 alone, Balazs Greksza, Threat Response Lead at Ontinue, noted that “all smart contract developers must have heard about the problems associated with vulnerabilities in smart contracts.”

Jason Soroko, Senior Fellow at Sectigo, believes that developers working closely with smart contracts need to be particularly careful as threat actors can “discreetly monitor sensitive projects, steal information, and potentially undermine decentralized systems.”

To defend against these types of threats, organizations must implement robust privileged access controls and secrets management to protect sensitive credentials like API keys. Pairing this with code and dependency scans within the build pipelines will help ensure malicious code is flagged before it’s integrated into systems. Embedding robust security practices into the development lifecycle, with careful vetting of all third-party code, is critical to mitigating risks and securing the software supply chain.

Patrick Tiquet, Vice President at Keeper Security, asserts that the precautions entities need to take to mitigate against these threats include strong controls for privileged access and secrets like API keys. These measures need to be implemented in conjunction with other measures, such as scanning code and its dependencies in the build process, to help catch harmful code before it enters the system.

It’s All About Intention

Considering all this information and imparting you with a succinct take-home message, it would be fair to say that the determining factor that identifies when a Remote Access Tool (RAT) is not a Remote Access Tool but, in fact, a Remote Access Trojan (RAT), is in the intention of the individual controlling it.