Issue with ditekSHen.MALWARE.Win.Trojan.RemoteUtilitiesRAT

[mrkpl125]

Hello,

Name of the rule: ditekSHen.MALWARE.Win.Trojan.RemoteUtilitiesRAT

Description of the issue: Incorrect/false positive.

Any error messages or logs:

detection/clamav/clamav.ldb

Line 100 in cd99e73

ditekSHen.MALWARE.Win.Trojan.RemoteUtilitiesRAT;Engine:51-255,Target:1;(0|1|2|3|4|5|6|7)>3;726d616e5f6d657373616765::w;726d735f696e7669746174696f6e::w;726d735f686f73745f::w;726d616e5f61765f636170747572655f73657474696e6773::w;726d616e5f72656769737472795f6b6579::w;726d735f73797374656d5f696e666f726d6174696f6e::w;726d735f696e7465726e65745f69645f73657474696e6773::w;5f726d735f6c6f672e747874::w

Additional files and context: Remote Utilities is legitimate software for remote access. The current version is 7.6.2.0, available for download from the official website. All distributed files are signed with an EV Code Signing certificate issued to Remote Utilities Pte. Ltd. The company/software is not responsible for unsigned or modified files being used as malware, just as it is not responsible for the legitimate package being used in social engineering attacks. This rule has been around for a long time, generating a significant number of false positives in A/Vs and sandboxes utilizing this rule. Please address this issue. If you require more details about the software or the company, please contact developer@remoteutilities.com.

Thank you.

[mrkpl125]

Hello,

Any chance to get a reply with regards to this detection?

[ditekshen]

As much as the developer(s) are rightfully entitled to develop such software, I am too entitled to defend against its abuse. Additionally, as much as the developer(s) are not responsible or liable for the abuse, I am too not responsible or liable of how others use the rules.

It is up to the discretion and defense requirements of analysts, organizations, vendors, etc. on what constitutes a threat and why it is as such.

Here are some references:

1. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a
2. https://www.cisa.gov/sites/default/files/2023-06/Guide%20to%20Securing%20Remote%20Access%20Software_clean%20Final_508c.pdf
3. https://www.cisa.gov/sites/default/files/2023-08/JCDC_RMM_Cyber_Defense_Plan_TLP_CLEAR_508c_1.pdf
4. https://attack.mitre.org/software/S0592/

That said, the rule may be considered to be moved to the RMM category. However, this is very low priority at this point.

Thank you.

[mrkpl125]

Hello,

Thank you for your reply.

We do not deny your right to defend against abuse or to create Yara rules—they play an important role in informing analysts and corporate cybersecurity teams about potential threats. However, it’s crucial to avoid lumping legitimate software together with malware.

Malware and trojans are types of software created specifically for malicious activity—that’s their defining characteristic. They can’t do anything else without causing harm, except perhaps disguise themselves. In other words, causing harm is their core purpose. Remote access software like Remote Utilities, TeamViewer, AnyDesk, etc., on the other hand, is designed to let users manage networks and provide remote support. These tools were not built with malicious intent; they can only be misused in specific abuse scenarios (e.g., if modified, or if a user is tricked into installing and granting access).

In fact, even the last link you mentioned refers to Remote Utilities as a legitimate tool. Quoting directly: “RemoteUtilities is a legitimate remote administration tool that has been used by MuddyWater since at least 2021 for execution on target machines.” And the detection itself is labeled as “TOOL” (if you hover over the icon), meaning: "This software is commercial, open-source, built-in, or publicly available software that could be used by a defender, pen tester, red teamer, or an adversary."

Labeling remote access software as malware is incorrect and has real consequences: for instance, when legitimate remote access software is flagged as malware, it can disrupt access across entire networks of devices after an A/V update, sometimes in hard-to-reach locations. This might impact an airport facility, a hospital, a remote island, or an elderly individual who relies on a remote support provider.

We wouldn’t object if you characterized Remote Utilities neutrally as a legitimate tool that might, in certain cases, be misused for malware attacks—a scenario that can apply to nearly all remote access software on the market, from TeamViewer (link) to AnyDesk (link) to RustDesk(link). But using terms like "Malware," "Trojan," or "RAT" (remote access trojan) to refer to the original, unmodified version of Remote Utilities is a factual error.

Please understand this point. Currently, this rule is causing a cascade of issues, with sandboxes and other engines taking it literally and marking original Remote Utilities files as malware.

Thank you.

[mrkpl125]

One more example, if I may. Here’s the current detection of the Remote Utilities Viewer executable file (rutview.exe): VirusTotal detection link.

At the top, you can see: “Matches rule MALWARE_Win_RemoteUtilitiesRAT from ruleset malware at https://github.com/ditekshen/detection by ditekSHen.”

The absurdity here is that the Viewer is a client module and, even in theory, cannot provide remote access to another machine. It’s purely used to connect to a remote machine. In other words, installing and running Viewer on a potential victim’s computer serves no purpose. Unlike other remote access programs, Remote Utilities has a clear client-server architecture with distinct modules—the Viewer (client) and the Host (server)—each designed for its specific function.

This rule inaccurately targets the entire software, without considering the actual role of the Viewer, marking it as malware. Does this seem like a reasonable situation?

[mrkpl125]

Hello,

So there’s no response and no willingness to address the issue, despite the fact that this erroneous rule is causing multiple sandboxes to incorrectly detect our software as malware? Even though we’ve clearly explained why the rule may be inaccurate and have offered to collaborate on a thorough examination?

Given that this misclassification is misleading American consumers, we are entitled to file a complaint with the FTC, requesting an investigation into how this GitHub repository may be violating antitrust laws—specifically by misleading U.S. consumers about the actual risk level of our software, potentially leading to misguided decisions and restricting fair competition.

All the best.