What Have We Learned From Past Virus Infections?

The year 2009 has so far have a been hectic one for anti-virus vendors and IT administrators alike, “thanks” to two prolific malware families: W32/Conficker and W32/Virut. Malware researchers and field engineers have literally burned the midnight oil to ensure networks are protected against these threats.

Some of the organizations that were hit with these infections had the latest Microsoft updates installed but still got infected. During the post-mortem of the outbreaks, one glaring mistake stood out.

Administrators routinely attend to distress calls from users whenever they have an issue with their machines. By habit, the admins tend to log onto the affected workstation using their own accounts””which have domain-administrator privileges. For a moment, let us assume the suspicious user’s workstation was infected with W32/Conficker. What could possibly go wrong from here?

When the W32/Conficker worm infects a machine, it scans the local network and attempts to infect machines using the credentials of the currently logged-on user. If the initial login attempt fails, then the worm attempts a brute-force attack to authenticate, using a hardcoded list of passwords. Because most organizations have enforced complex password policies these days, brute-forcing is ineffective. But the moment the administrator logs onto the affected machine using his or her domain account, W32/Conficker runs using the elevated credentials of a domain administrator. Straight away the worm can infect any host on the domain using these newly acquired administrator credentials. Shown below is a traffic-capture screenshot of this behavior.

Upon copying the worm’s DLL to the System32 folder, W32/Conficker proceeds to create a scheduled job task to execute the worm at a predefined time. In a matter of minutes the entire network, with thousands of machines, gets infected.

It’s pretty much the same story with W32/Virut, a polymorphic entry-point-obscuring virus that spreads by infecting executable and script files. A machine infected with W32/Virut would scan and infect shared drives on the network using the credentials of the currently logged-on user. Because most domain users have limited write access to shared resources on the network, the infection is confined to a subset of machines. But the moment the administrator commits the cardinal sin of logging onto an infected machine, W32/Virut runs with elevated credentials and has write access to every C$ and Admin$ share on the network.

To prevent such an outbreak from happening, it is imperative that administrators refrain from logging onto a suspect machine using their own accounts. Logging on using the workstation’s local administrator account can also have the same effect; most corporate workstations are ghosted from the same image and could have the same local admin account and password.

An alternative is to use remote desktop solutions such as VNC, GoToAssist, or TeamViewer. These three are not tied to domain authentication. Once a suspect machine is identified, it should be isolated from the network for further investigation. Better safe than sorry