Latest fixes for FBI Virus?
Tim
Southwest PA Icrontian
The well published and easily found ways of fixing the FBI Virus on computers doesn't work much anymore. I used to be able to get it out by going into safe mode and running malwarebytes and a few other programs, now that doesn't work anymore.
Any new ideas on how to fix it and keep it from coming back? I can always wipe out the hard drive and reload everything, but there should be a better way.
Any new ideas on how to fix it and keep it from coming back? I can always wipe out the hard drive and reload everything, but there should be a better way.
0
Comments
1. disconnect the machine from the internet (disable wifi or pull the cable)
2. download the latest malwarebytes installer onto a usb stick (from another machine)
3. on the infected machine, boot to "safe mode with command prompt"
4. Login with the proper administrator credentials
5. When the command prompt window opens, verify that you are in the directory at the prompt. If not, change to it.
6. Type "control.exe"
7. Select "user accounts" from the control panel screen
8. Create a new administrator level account. (Still no internet connected to the machine)
9. reboot the machine
10. Login to the new account.
11. Install Malwarebytes from the USB stick.
12. Run Malwarebytes and clean things.
13. Shutdown and then reboot to normal account.
14. Verify virus gone
15. reconnect internet
16. start malwarebytes again and update to latest.
17. Run it again.
18. restart if necessary to clean anything else.
19. Login to normal account, go to Control Panel and remove the temporary user account.
20. $$$$$$$$$$$$
Takes about 30 minutes.
I still don't nuke and pave unless it's absolutely hopeless. Any virus can be removed if you're clever enough.
Or they're not using adequate protection and are getting hit by infested ad networks.
In most cases I've seen, a typical home user probably already had problems and a slow or semi-slow running computer, so a full hard drive wipe out and reload isn't a bad idea. It gets them to a known point and as cleaned out as possible. Then I'm the hero when not only is the FBI virus gone, but their PC is much faster as well and comes back to them with antivirus programs (AVG Free and Malwarebytes) and updated other programs too. What a bargain for $100, my standard full wipe-out-and-reload-and-save-your-important-files fee.
I support over 1000 PCs, of which, 800 are Windows 7. We've had 4 wipe and reloads due to malware and all of those has users running with admin rights.
Get to Windows 7 and use a simple user account not admin account.
Frequently developers have good reasons to support UAC requests. If you are running software that has to do anything like write to the registry, register a dll, whatever ... forget it. You need elevation. I understand that should happen at the installation stage of software, but depending on the end user's requirements you sometimes have to do things like that at run time or in the middle of the user experience. This is especially true if the software has to, for example, run a process that requires elevation even though the core features of the software generally do not require UAC.
In short, if the software has an excuse for UAC requests or not depends on what the software does which depends on end user requirements.
If the software simply isn't calling UAC at runtime when it should, and it gets unhandled exceptions later and crashes -- well that's bad software design.
It's normal for an installer because it needs to write to Program Files and the registry, but once it's installed, it should never trigger a UAC prompt.
There's no "especially hacky" things that need to be done to work within the envelope. This is an excuse that shoddy developers who don't want to follow the proper guidelines use to not read the guidelines.
There is not a single program on my work desktop that triggers UAC, and I only have 2 or 3 at home because they're legacy stuff that was written pre-Vista.
Consider if you make antivirus software, the software finds a virus in your program files directory, it asks to delete the file however the software wasn't run with admin rights to start. How do you recommend it does this without restarting with a UAC request? In fact, most anti virus at that point not only reboots the computer entirely to make sure the targeted file is out of system memory but it also launches it's deletion app with a UAC request once the computer reboots.
There are thousands of situations like this, it depends on the program's functionality. Obviously something like a web browser or a document editor don't have this problem, and that is most software. However, it simply depends. It's not a shoddy development practice.
By the way, if you want to see hackish UAC avoidance in action, run the Chrome installer. Look where Chrome actually installs everything on your system to avoid UAC requests. It actually goes exactly against Microsoft's guidelines that you are talking about so that it can install without a UAC prompt. This is to gain larger market share, and it's smart of them but it absolutely is hacky.
Chrome's installer going into user-accessible areas only is exactly what Microsoft wants for non-system-level software. A browser should be 100% able to run without touching system files, even if it is installed in Program Files.
Again, I'm not talking about installers (I expect and require Firefox to hit UAC when I first install it). I'm talking about normal launching/running of applications.
If, during it's regular operation it needs to write to a system-protected location (with exceptions for system-level software), that's the exact definition of "UR doin it rong".
Microsoft has calls in ALL of their Vista and forward APIs to detect things like current UAC level, detecting processes that require UAC through exceptions (ie. a non elevated user tries to open a file that requires admin rights to view), specifying UAC in manifest files, etc. specifically for properly handling situations where an end user has done something that requires UAC elevation even though the program was not launched with it. It's part of Microsoft's security design, and that's why it is in the APIs so that these functions can be handled gracefully.
Largely depending on the type of software, you just can't tell for sure when a user will need elevation. As such programs have to either deny functionality or opt to restart elevated because, as you know, it would be bad for a program to just request elevation every single time it runs. On the other side it is wrong to say a program should never request elevation.
This is the case for many situations, not a rare few and not restricted to security software. A program has plugins that ship unactivated because users don't want the plugins activated at install. Activating them is done through the UI because users have requested plugins be added through the UI. A user goes to install a plugin, the plugin requires a third party ax file is registered with the system, UAC elevation has to happen here.
Or let's say a user tries to open a file that requires admin rights. You have to deny them or opt to restart the program with an elevation request. Letting the program crash due to the exception would be the shoddy development you talk about and what I referenced in my first post.
I stand by my point that you can't just say a program should never request UAC at launch, and that programmers hackishly avoid UAC all the time to keep end users happy. Not because they are shoddy developers, but because a customer comes at you with this: and the last thing your respond to them with is this:
No, modify your systems to fit Microsoft's model better to begin with because we follow the actual rules already.
And per this: I don't think that is true. AFAIK, nowhere does Microsoft recommend programs be installed to localized appdata folders. Those folders are meant to be used by roaming profiles or temporary user data like cookies and etc. Once Chrome got a big enough market share, they actually started installing to the program files folder like any other program. Of course the browser can run without UAC, all it does is make httprequests. I was just giving a popular example of a hack to avoid UAC elevation requests driven by end user demand.
They solved the problem by following this guide which said to go into safe mode with command prompt and running system restore. I rarely use system restore, so I wonder how this is different from the other options in the advanced start up menu such as "repair your computer" or "last known good configuration."
Would the FBI hinder your computer usage just to make you send them a MoneyPak code? It goes to show that people still fall for these kinds of scams. Also, if people do send them a MoneyPak code, does the virus disappear from the computer or will it keep nagging them for more codes?
So make sure you're ACTUALLY nuking and not just kinda-sorta nuking. If you're gonna be lazy, do it right.
It's really hard to teach users the difference between a legit Security Essentials pop-up alert and a website that flashes an image of an identical Security Essentials pop-up alert and gets the user to download a special clean-up tool that ends up rootkitting the hard drive.
It's really hard to teach users that the video that claims it needs a newer version of Flash is actually trying to get you to install a bunch of adware and there's nothing wrong with Flash at all.
It's really hard to get people to stop using Yahoo and MSN for their homepages and email, even though I'm pretty sure Adchoices has had a rogue malware problem and deceptive adverts leading to malware for years.