I had an interesting problem with a server (Windows 2003 Standard) at a small business (6 users total) the other day – a very long startup time. The server in question is a standalone domain controller/DC as well as a database/application server and file/print server. Terminal Services is installed & configured, but rarely used – mostly for access from outside the office. Database and domain services/authentication were available fairly quickly, as were console logins (via UltraVNC/uVNC) – probably 15-20 minutes to that stage, but more than an hour before terminal services/remote desktop was available.
Digging around on the console attempting to track down the source of the problems, I found multiple services listed as “Starting” – all of them malware-based, with the actual infection cleaned out. My suspicion is that these non-startable services were causing the startup of other services to be delayed, though in this case I’m not really planning on setting up a test system to verify that.
In the rest of this post I’ll give a bit more detail on the scenario, what I found, what was needed to clean it out, and a few more notes on what I suspect was happening.
Continue reading Slow Startup with Multiple ‘Starting’ Services After Malware
Quick Fix: have a program named procmon.exe running (copy of notepad.exe) to disable malware temporarily. This should let you run searches & download fixes. This is only temporary while you clean the system. Read this post for more details and please let me know in comments if this does or does not work for you.
Update/Fix:
The system did indeed have a corrupted atapi.sys file as noted in the comments, though I did not end up using ComboFix to clean it – I was able to replace the file with the identically-sized but binary-different one from the most recent service pack (C:\Windows\ServicePackFiles\i386\atapi.sys) and have not seen the same problem recurring.
In addition, if you need to prevent it from redirecting while you download fixes, you may be able to simply copy notepad.exe (or another common executable) to the name procmon.exe and run that. Last night while I still had the infection active it did not seem to redirect while procmon was running under that name, possibly as a measure to avoid detection.
At this point (several days after initial infection, more than a week after initial reports in the wild) I suspect that many of the tools linked below are updated with definitions that cover this malware so you can probably get by with simply running updated versions of those.
Continue reading (Fix) r3953724.cn Malware/Adware Redirections
My antivirus reported an infected file (setpwrcg.exe) this morning, with a file date of 7/19/2004.
There were a few things that struck me as odd about this:
It didn’t seem like a randomly-generated name, Most viruses/worms don’t seem to bother to set their file dates, particularly not to 5 years ago, I haven’t been [...]