Beyond Malware – Detecting Hack Tools
Posted on
by
Lysa Myers
Now that we’ve clarified the difference between the various types of malware and vulnerabilities, we’re going to talk about some other types of files that we detect which fall slightly outside those definitions. As we said in our previous blog post, the definition of malware is really one of intent. That’s why software that is intended as tools and products, which have potentially damaging effects (either purposefully or accidentally), are not considered malware. But there are times when intent of the author is less relevant in the decision whether to add detection.
The Blurred Lines of Greyware
A tricky thing about being a malware researcher is that the definition of what should and should not be detected is occasionally pretty blurry. One product or researcher may find a file or product to be malicious or a “potentially unwanted program,” and another may find it to be far enough on the side of “innocent” that they will not add detection. Historically the lines have shifted, and customers have really had a lot to do with what’s been considered acceptable to detect. If enough people find a type of tool to be more problematic than helpful, it becomes very hard for a researcher to argue that it should not be detected. There are a few types of tools, generally known as “hack tools” that have consistently fallen on the side of being worth detecting, regardless of the author’s intent.
Not Every Hack Tool is Worth Detecting
Hack tools are, as you might guess, tools that are useful to hackers (both “whitehat” and “blackhat”) and to some system administrators. There are a lot of tools that are part of operating systems that are useful to hackers – naturally, we can’t include these in detection, as it would cause a tremendous problem for a lot of people. Some tools are more clearly applicable to naughty actions (such as the popular password-cracker Jack the Ripper) which are detected by most (but not by all) anti-malware products.
Remote access programs are a great example of the sort of tool that falls into a grey area, as are rootkits. Certainly these programs can be useful tools. But in the case of a remote access tool, if the file itself is too easy to hide on someone’s machine or if there’s evidence that the tools is trying to gather specific information that is beyond the scope of trying to perform normal remote maintenance, these are things that would weight a researcher’s decision towards detecting it. With rootkits, it often boils down to the company they keep. Are the files the rootkit is hiding intending to do evil? Or, as in the case of the “Sony Rootkit,” is there the potential for the rootkit to be easily misused by bad actors?
Another example of hack tools that are generally worth detecting are those that enable someone to create viruses or Trojan files. Someone using these hack tools is not going to be harmed by running them, but their purpose is clearly to create files that could harm others. And by adding these files (and their creations) to detection, we can potentially improve our proactive detection for malware created by the toolkit, as in the case of OSX/SET. Likewise, adding detection for proof-of-concept code for things like new rootkit techniques and exploits can help protect against future, clearly malicious creations that are based on that code.
This sort of detection is certainly controversial, as the files themselves are not malicious in intent, but educational. However, the downside of this controversy is outweighed by the potential protection that adding detection can offer. Most people who use the files for educational purposes know what they’re for, and how to use them safely. And these people will know how to set up a system that is limited so that they will not harm others by using the tools. Plus, they will also know how to exclude those files from anti-virus scanning, should they wish to use them. But those people who stumble upon these tools inadvertently will be made aware of their potential for causing harm when they’re added to detection.
Further Reading:
photo credit: Christophe Verdier via photopin cc