What is the policy on "network stress test" tools such as LOIC?

What is the policy on "network stress" tools and other "grey area" software?

With the high profile anonymous ddos attacks hitting the headlines recently, I was quite surprised to see that prevx does not classify the LOIC as malware. It is freely available on sourceforge and has been used to launch these much publicised ddos attacks. I understand you can't keep track of every network testing tool but in this case I think some attention is warranted.

What I want to know is, would prevx consider classifying such tools (and others like it) as "bad"....because they can be and have been used for malicious purposes?

From an enterprise point of view, you certainly do not want users downloading and launching a ddos from within your network...and would expect AV software to notify you of it's presence.

 

This is fantastic question which I've been wanting to create a thread on for some time - thanks for the prompt!

We go back and forth internally on these points as well but in the end, the tools themselves are not malicious so we decide to not detect them. There are quite a lot of riskware tools like this (NirSoft utilities, mIRC, ServU, HideWindow to name a few) but our current rationale is that we allow them through and block the malware that uses them.

All of our products offer the ability to block specific applications so if an Enterprise finds an application that they want to remove from their network, they can easily do so, however, we are looking to add another category of applications for riskware and give the user the choice to include or exclude them.

Our central database view gives a very interesting picture on many of these applications: thousands of users override them to "Trust Always" but thousands more leave them blocked.

The other somewhat tangential discussion here is "rogue" products. We're seeing an increasing number of products being deemed as rogue when, in fact, they actually are finding legitimate "issues" on the PC and just warning too heavily about them. While I would certainly stay far away from a product that finds 50+ issues on a bare Windows XP installation and says that you have to pay to clean them, they aren't technically inaccurate. We've changed our opinion of rogues to be focused on entrypoints (how the file got into the system - i.e. if it came in through an exploit then it is definitely bad) and actual "detections" (if it finds files that aren't on the system then it is bad).

This differs from what some other companies deem as malicious so, as a parallel note, it is possible that Prevx would score lower in tests because of our stance against these pseudo-rogues and "riskware" samples.

Let me know your thoughts - we're definitely interested in community input here!

 

No worries

I'd like to make a few comments about the point you have raised here. Please excuse me for putting people in a tl;dr situation but I think going into a bit of detail is warranted and appreciate any comments.
Lets start with mIRC- this is an interesting one. This is a popular IRC client that is also popular with malware writers, who use it for a variety of purposes including turning a victim computer into a client in their botnet.

In its most simple form, a malware utilisng mIRC will be a self extracting archive of some sort, with the mIRC executable+ related files and a .reg or .bat file to automate the registration of the malware onto the computer. In such cases, the mIRC client by itself will pose no risk to the user, but when combined with the .reg/.bat file, it will register mIRC on the computer silently, connect it to the IRC channel controlled by the botnet master and await further instructions. The victim will not realise mIRC is running on their computer while it sits happily in their desktop tray (usually with a “blank” icon to stop itself being noticed).

In such a case the first defence will be detecting the archive/sfx itself. After this, the .reg and .bat files which automate the registering of the tampered mIRC client on the computer. However, if a security solution is to fail on both counts then there is nothing to stop mIRC from fulfilling the requests of the botnet master.
Let us just imagine for a moment what kind of user would knowingly install and use mIRC- certainly, most people on wilders would know what this program is, but past that I am doubtful, as most ordinary people use the “new” generation of IM-clients such as Skype and MSN Messenger. If a user is willingly installing mIRC, then he or she will most definitely be aware of what its purpose is.
Now let us consider a situation in which we start to label mIRC clients as “potentially dangerous”. Please excuse any technical inaccuracies as I am by no means an expert at the mechanics of detection.

User A is unwittingly the victim of an IRC based malware that is attempting to launch on their computer. The security solution has failed to detect the initial archive, or the .bat/.reg files that automate its installation as malicious, but it has identified that mIRC client has been installed (perhaps to a non-standard location). The security solution by default gives a warning message- perhaps “yellow” in colour to signify that user attention is required. The alert informs them that an IRC client has been detected as “potentially unsafe” and that unless they know and trust this program, they should remove it. The user is given the option to “Remove”, “Ignore” or “Trust” the file.

Because the user is unaware of what an IRC client is, they choose the option the option to remove it. If they are unsure they will probably conduct a web-search or contact the technical support/knowledge base of the security solution provider for a more detailed explanation. The malware is disabled. Similarly, in an enterprise environment, the administrator may want to block the installation of mIRC to stop people using it on the corporate network. He may not know that someone is using mIRC (hence not able to specify which files specifically to block), but would like his security solution to cover such cases “just in case” a user or malware does attempt to launch mIRC on a network computer.

Also consider cases where a security solution that does not detect mIRC clients as malicious is downloaded onto an already infected computer- there is a high probability that it will let the IRC malware slip past its radar as it is already installed. I think it isn’t an ideal solution to rely only on detecting the “malware” which uses tools such as mIRC, because there is no guarantee that you will be able to account for each modification!


On the other hand, we could have User B- who regularly uses mIRC to communicate with friends and finds that their favourite IRC client is suddenly labelled as suspicious by their security solution. In such a case, they will again read the warning advising of the potential threat, unless they know and trust the file.
Because they know what mIRC is and they installed it themselves, they will choose the option to “trust” the file, or do a web-search/contact technical support to query this “false” reading on mIRC.
In this case, it is a case of educating a user why a file is flagged and perhaps creating a knowledgebase article to explain what the dangers of an mIRC client are (for example), to allay fears they are infected.

If we have an enterprise user who has mIRC installed on their machines, they could create a global “trust” rule to allow this program to run freely. It is merely a matter of configuration and any responsible administrator will run tests to ensure a security solution is correctly configured before deploying it network-wide, to avoid potential problems.


In my opinon, this is an option better than the alternative of doing nothing at all (with regards to mIRC and other such tools).

I briefly touched on this above- an administrator for a large network will unfortunately, not be able to keep track of everything users are downloading and executing on networked computers. If they are not aware of the presence of a tool such as LOIC on their network or mIRC, how are they able to block it effectively?

I think offloading this responsibility to the security solution, even partially, will simplify their task greatly.

For such programs, I think a separate “riskware” category would be beneficial.
Perhaps, the security solution could even suggest that a user performs a periodic scan (once every two months) for example, with “riskware” category enabled, and if any such programs are found then they are directed to a knowledgebase page explaining what riskware is and how best to deal with it.
I suggest this because having a “riskware” category that 80% of users do not bother to turn on defeats the purpose of having it there in the first place and is sacrificing protection for the sake of user convenience.

I think the main issue for users here will be not knowing what a “riskware” is or how to deal with it- but if you indicate to users that engineers are on standby to diagnose and remedy any issues with riskware this should put their minds at ease, more or less, and word the alert in such a way that the user feels they can always go back and reverse their decision to “allow” or “remove” an application....(perhaps “decide later?”).

These grey area apps are forceful for a reason- because they have dishonest intentions at heart. Preying upon the ignorance or relatively low experience of the average user isn’t just ethically wrong, but it could also technically be illegal depending on how forceful/gimmicky the program decides to be.

 

I'm not really a fan of flagging tools like that, but it would be okay if there would be an opt-in only option for detecting riskware like this and those rogue-ish programs you talk about. To avoid conflicts with developers of these rogue's you could perhaps differentiate riskware between potentially unwanted software and potentially unsafe software.