A Worm Triggering Autolock - Another Sighting of W32.Downadup?
An ISC reader asked us about reports of malware that's locking user accounts. According to several media reports (1, 2), a "virus" has affected computers of the Vancouver School Board (VSB) on January 7. The most noticeable effects of the infection were user accounts getting locked. The district's staff were told not to turn on their computers to curtail the spread of the malware.
VSB seems to consider the worm a simple nuisance. However, the observed lockouts might be a side effect of an infection capable of other threats. A worm might inadvertently an auto-lockout defense when attempting to brute-force passwords. That might be the reason for the denial of service condition observed by VSB.
Though we received no other reports of this infection, its effects are reminiscent of the W32.Downadup worm we described in a December 31 diary. The worm spread by exploiting the RPC vulnerability (MS08-067). It also attempted to brute-force user passwords when connecting to the ADMIN$ share of systems on the local network. However, we have no additional information about the VSB incident, so we cannot confirm whether VSB's infection is, indeed, tied to W32.Downadup.
Update 1: We received a report of another school district experiencing problems of a similar scale. In this case, the user accounts are not being locked out. This worm "adds its own information" under the Windows XP logo during startup. "It then hijacks some processes and continues to spread. Although it seems like an easy clean, according to Symantec, this worm is quite the annoyance." In this district, the worm is being detected as W32.Downadup.
Update 2: F-Secure published a list of the domains used by the Win32.Downadup worm earlier. Today they published another list of additional 1,500 sites used by the worm.
Update 3: Symantec reports that it has "observed an increase in infections relating to W32.Downadup over the holiday period and is urging organizations to apply the patch for Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability as soon as possible." See Symantec's note for more details about the new variant.
-- Lenny
Lenny Zeltser
Security Consulting - Savvis, Inc.
Lenny teaches a SANS course on analyzing malware.
Comments
We found that Symantec was able to detect the offending file if you set the service to manual and restart the box and start the service manually (please don't do this on your production network while connected!) Symantec will catch the file. But it will not catch it on a normal machine restart.
Regards,
~Phreak
Phreakus
Jan 10th 2009
1 decade ago