Virus Outbreak Mitigation 101 – A Weekend with W32.SillyFDC.BDP

As much as we try to avoid them, computer viruses are just as much a part of the computing landscape as the operating systems they infect.  We go through numerous measures to try to prevent them from making their way onto our systems, but despite our best efforts they occasionally get the upper hand.  This past weekend I received a call from a client needing assistance after a virus, W32.SillyFDC.BDP to be exact, had made its way onto their network and very rapidly spread to multiple machines.  Symantec Endpoint Protection, which the client was running on all their servers and workstations, was identifying and removing the infected files on certain servers, but these servers kept getting re-infected almost instantly.  Dealing with a virus outbreak isn’t something most people – myself included – deal with on a daily basis, but by approaching it systematically we were able to have the issue completely resolved in time for work Monday morning.  Here’s how we approached the issue (and if you’re battling the same virus, the steps below should help you get through it):

1. Identify the threat. Until you know what you’re up against, it’s impossible to come up with an effective plan to resolve the issue.  While Symantec was catching infected files and did actually label some of them as W32.SillyFDC.BDP, it was throwing up quite a few incorrect virus IDs as well (i.e. Bloodhound.Exploit.343) that made it hard to know what we were dealing with.  We ultimately identified the threat by examining the pattern of files that was appearing in the infected locations (in this case: autorun.inf, setup50045.fon, setup50045.lnk, myporno.avi.lnk and pornmovies.lnk) and doing some creative Googling with that information.  That lead us to a Symantec KB article that described exactly what we were experiencing.

1. Mitigate the risk. The primary goal when dealing with a virus is to ensure that no data is lost and that no security breaches occur.as a result of the virus. Once we knew what we were dealing with we were able to more accurately determine if the virus posed any immediate danger.  Symantec’s classification of the virus as “very low” risk was comforting, indicating this virus was more of a nuisance than a risk for data loss or security breach.  We took a closer look at the firewall to make the virus wasn’t attempting to contact any of the remote HTTP sites identified by Symantec, which it wasn’t.  At that point we made the decision to shutdown all workstations to prevent further infection but not take any servers offline.  Had the risk been any more severe we would have most likely shut down the entire network until we had a better idea of how to remove the virus.

1. Determine the pathway for infection. We knew, based on Symantec’s article, exactly what the virus does from a technical perspective, but  it can be difficult to translate that information into what needs to be done to contain it.  After taking an infected machine and trying a few strategies to see what would remove the virus completely and what would not, we realized that most of our servers that appeared “infected” weren’t really infected at all.  They were still a threat because they were hosting the virus files that allowed other machines to get infected, but cleaning these servers was as simple as deleting a few files.  The truly infected machines were the ones that had the virus installed as a service, and those were the ones we needed to address to ultimately eliminate the virus.

1. Develop a containment strategy. Preventing the virus from spreading further than it already has makes the ultimate goal of eliminating it that much easier.  We wanted to make sure no new machines would get infected.  Since we knew one way this virus spreads is by taking advantage of a Windows Autorun vulnerability, we chose to temporarily disable Autorun in the entire domain via Group Policy.  Additionally, upon closer inspection of the files the virus was distributing, we realized these files were getting created as the system account of the infected machine.  That gave us two crucial pieces of information: a) which machines were infected, and b) that the system account needed write access to the shares it was infecting.  The shares the virus was taking up residence in were set to grant Everyone read/write access.  It was a tedious and time consuming process, but by reviewing each share and granting Domain Users rather that Everyone write access we eliminated the virus’s ability to spread throughout the network.  (This was a pivotal step in getting the outbreak contained, and if you’re reading this article because you have this virus this is something you need to do.)

1. Eliminate the virus. If you’ve successfully prevented the virus from spreading further, its days on your network are numbered.  Our challenge with this particular virus was that we now needed to identify which machines were actually infected so we could manually clean them.  Because the virus renames itself with each new computer it installs on it’s difficult for Symantec (or any other antivirus program for that matter) to properly identify and remove it.  We needed to get a little crafty to make finding the infected machines easy.  I put together a quick script to scan the registry for a key that we knew would be affected if the virus was installed: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSvcHost”netsvcs”.  If in that key it found an entry that indicated the virus was present, the script logged the machine name to a custom SQL database we created.  We deployed the script as a startup script for all workstations, and by booting up the machines we were able to determine exactly which ones were infected.  After that it was simply a matter of following the removal steps noted in the Symantec article.  In our case, while on first glace it appeared the entire network was infected, only about 9 machines were actually distributing the virus throughout the network.

1. Be proactive to prevent reinfections. If the virus was able to get on your network in the first place, there’s a good chance it can do it a second time.  Once we felt we had the virus eliminated we took the time to review our antivirus policies and ensure our servers and workstations were up to date on patches.  We are still periodically checking our custom SQL database to ensure no new infected machine are appearing on the network.  We also chose to keep Windows Autorun functionality disabled for the time being, and even went as far as to temporarily prevent the use of USB storage devices since the virus can easily become resident on those as well.  The latter restriction has since been lifted.