The symptoms appear similar to https://community.mcafee.com/community/security/malware_discussion/consumer/blog /2010/09/12/security-warning-application-cannot-be-executed-the-file-is-infected -do-you-want-to-activate-your-antivirus-software-now
That worked to gain control. I have already submitted the file (manually captured) to McAfee Labs. We are in the process of running build 118 and will provide that information as well. SR# 3-1293299053.
My last reply was incorrect. The reason we had control was that we had previously renamed the malware and it was inactive. Once we let the malware execute again the "net pause winmgmt" failed with the error:
"net.exe is infected with Trojan PSW.Win32.OnlineGames.lfi. This worm is trying to send your credit card details using net.exe to connect to remote host"
When I run Getsusp it says "Getsusp.exe is infected with virtual.DOS.vlad.systa.231. This worm is trying to send your credit card details using Getsusp.exe to connect to remote host".
In anycase McAfee Lans has provided and Extra.dat for FakeAlert-SecurityTool.q
Message was edited by: HBullock on 10/29/10 9:26:02 AM CDT
Thanks for reporting. You're right. This Fakealert Trojan is using a new technique we haven't come across previously.
Upon infection it stores the names of all the active processes on the system. It then proceeds to terminate any other process that is launched post infection. It does this for two reasons.
1. Existing processes on the machine must run untouched - else the system would become unstable.
2. By killing newer processes post infection, it prevents the user from running any diagnostic tools.
To circumvent this technique, you could rename GetSusp or other troubleshooting tools to explorer.exe, iexplore.exe or active processes that you know would already be running on the affected machine.
Thanks for the update on the malware behavior. Will McAfee products including Getsusp be better able to address this type behavior in the future?
For VirusScan it should not be an issue as it starts as a service much before the malware does. (This Trojan startups via the registry run key). So once the dats have detection or you load an extra.dat, VirusScan should be able to detect and delete this Trojan.
Now that we know that malware authors are using a new technique like this - the dev team for GetSusp will have to think of a countermeasure - similar to how we countered Fake Alerts that use the WMI service to terminate processes.
It's a cat and mouse game - akin to an arms race between malware authors and antivirus researchers. There's never a dull moment on the job ;-)
Thanks for the insight. VirusScan was of little use because the DATs did not provide detection. In these cases we would rely on tools like Getsusp to locate and capture samples for McAfee Labs to provide that detection in the DATs.
We saw that MalwareBytes properly detected the malware that VirusScan could not see even when executed as the local administrator. The malware was launch on a specific user profile so the malware was not active when logging on as local administrator.
The Getsusp team needs to do more in the area of examining files that are not loaded in memory. Possibly this could be an option when we encounter infection like this that stop attempts to uncover them. If the malware is isolated in a user's profile then it is easy to gain control of the computer by loggin on as another user. We should be able to direct Getsusp to perform a deep scan of the user's profile or other areas.
Message was edited by: HBullock on 11/1/10 12:52:04 PM CDT
Message was edited by: HBullock on 11/1/10 12:52:56 PM CDT
Based on your feedback, GetSusp will now scan the HKEY_USERS hive for common malware startup locations. This should cover all the active user profiles on a machine and address issues where malware may not be running when logged in with a different user profile.
Many thanks for the feedback - the newer build will be made available in two weeks.
That very good news. Thank you for the prompt program update.