Researchers Raise Alarm Over New Iteration of Coreflood Botnet - Desktop Security News Analysis - Dark Reading.

 

This recent article from the Dark Reading web site talks about the Coreflood Trojan horse virus which steals passwords.  The major concern of this virus is the ability of this virus to steal accounts and passwords from the infected machine and transfer those accounts to the hackers.  While signature based virus detection programs can detect and remove the virus, it is too late since the program has done its damage.  The prediction is that this botnet will become a favorite among hackers to steal passwords and then use those passwords to carry out attacks on enterprises. The problem in mind is how to protect against such an attack.  The first is pretty much common since which is to always have AV protection and the latest signature file.  We will not go into this area since this pretty much common practice.  The second area and perhaps more difficult to address is to have a process of bringing new systems into the environment.

So here is the problem.  You image a new system with an image that was create a couple of months ago.  The image has A/V protection but the signature file is a couple of months old.  The system imaging goes fine but shortly after initial boot to the network, the system gets attacked by a virus.  The problem here is that the system does not have a current signature file and the virus was not captured by the heuristics technology built into most A/V products.  Now you are stuck with how to clean the system.  So how do you avoid this type of problem in the first place.  I have defined three ways to avoid this potential problem.  These are in the imaging process, using a safe network and Network Access Protection (NAP).

First lets start off with a solution that could be implemented pretty easy today and does help reduce the exposure time.  As part of the imaging process add a step in the process that downloads the latest signature file from a known location.  One way to implement this is simply to have a script that kicks off the signature update process with the A/V client.  To do this the client will need access to the network which still leaves it open to attacks.  Another way to implement this process is to store the latest signature file on a USB device so the signature can be updated before the client attaches to the network.  By using either of these two methods, you will either reduce or eliminate the exposure time on the network

Another way to attack this problem is to build a safe network.  As safe network is a network that had a limited number of clients with no Internet or corpnet connectivity.  The client is built on this safe network and the signature file is updated before the client is allowed to connect to the corpnet.  This may require a change in your build process especially if a re-imaging process is part of the part of the problem resolution process.  In this case, the end user may have to bring his system to a help desk location with a safe network connection.

The third way to address this problem is to leverage NAP and quarantine the client to a restricted network until the signature file is updated.  You will need to use a NAP implementation that uses the network devices and not a simple DHCP solution.  You will want a separate network to protect the client.  In the quarantine environment, you provide all the necessary systems to build a system and update the system with the latest signature files and security updates. 

Using one of these three ways (and there are probably others) you can start with a clean protected system and reduce the number of infections due to unprotected systems.  Carefully look at your a build process and identify ways of reduce the exposure time to attacks.