When malware ends up on an infected machine, one of the first things it will do is to ensure that it will start up again after the victim reboots their computer. For a criminal it makes sense. After all, what good is malware that stops working after a reboot?
In Windows, there are tons of ways for malware to accomplish this small but critical task, most of which involve the Registry. Technical folks call the Registry keys that are used for this purpose load points or auto-start locations. There’s even a pretty good free app from Microsoft that will show you everything configured to start itself up using any of these load points.
The Threat Research Analysts here use their knowledge of load points to fine-tune definitions. Increasingly, we have to kill a load point then reboot the computer to remove a piece of malware. I wanted to call attention to some odd load point trends, where load points are stacked like dominoes, so the action that starts the execution process is several steps removed from the actual execution.
Both tricks use Windows against itself. The Registry is really a powerful tool, mainly because the various obscure keys and their values control the vast majority of Windows’ user interaction.
Control the shellopencommand, Control the Box
One way that rogue security products, such as the so-called Wireshark Antivirus shown here (not to be confused with the perfectly legitimate network analysis tool of the same name), start themselves up after a reboot is to use a so-called Run Key.
There are a few very commonly-used locations in the Registry where, if you create a new value and put a path to a program in that value, Windows will launch the program after a reboot. Those locations include:
HKEY_LOCAL_MACHINEsoftwareMicrosoftWindowsCurrentVersionRun HKEY_CURRENT_USERsoftwareMicrosoftWindowsCurrentVersionRun HKEY_CURRENT_USERsoftwaremicrosoftwindows ntcurrentversionwindows
Once you’ve seen enough of the entries under this part of the Registry, it’s fairly easy to identify the malicious ones, because they frequently stand out as odd. For instance, many rogue AV installers simply create a random, three-character filename in an unusual location, then generate a random, three-letter Run Key that launches the app at start time.
Because it’s so easy to identify that kind of behavior, even with its “random” component, some rogues now change Registry keys that affect the behavior of whole classes of files. For example, Windows uses the following key to define how the operating system is supposed to behave when you launch a program with a .EXE file extension, either by double-clicking its icon, or a shortcut, or by starting it from the command line. That key is:
HKEY_LOCAL_MACHINEsoftwareclassesexefileshellopencommand
The normal value for this key tells Windows to simply start that program. But some rogues have been changing the value so that, every time you (or Windows) attempt to launch any .EXE file, it launches the rogue antivirus program first.
That behavior not only causes the rogue to be active, constantly, but it also allows the rogue to control which applications can (or can’t) launch.
This behavior is a double-whammy for rogue AV, because it can simultaneously kill off any real antivirus programs before they launch, and can block various other programs (such as the Task Manager) that someone might use to kill the rogue’s process, all while maintaining the illusion that it is protecting you from some sort of imaginary threat that originates with an utterly benign program.
Wireshark Antivirus also creates a Windows service (named Quicktime update) for one of its components. The component, which names itself after (but isn’t) the legitimate Windows file csrss.exe, uses service keys to launch itself, then periodically not only spawns instances of the rogue, but also downloads additional components from a subdomain of the domain greenteeforyou.com, which has a less than stellar reputation.
We’ve also been seeing rogues using similar techniques with Registry keys that use Web browser controls to launch themselves. Some samples of those keys include:
HKEY_LOCAL_MACHINEsoftwareclientsstartmenuinternetfirefox.exeshellopencommand HKEY_LOCAL_MACHINEsoftwareclientsstartmenuinternetiexplore.exeshellopencommand HKEY_CURRENT_USERsoftwareclientsstartmenuinternetfirefox.exeshellopencommand HKEY_CURRENT_USERsoftwareclientsstartmenuinternetiexplore.exeshellopencommand
In each case, the key is used to launch an instance of a rogue — instead of the browser — when you, for example, click a link in an email message or in an IM window.
Clicker Really Tries Hard to Hide
A sample of a clicker I obtained last week demonstrated one of the most egregious examples I’ve seen of malware trying to mask its load point. Rube Goldberg would have struggled to come up with a more convoluted solution.
Clickers, as you’ll recall, run in the background on an infected system. As the name suggests, they attempt to “click” through online advertisements as a method of defrauding companies that pay advertising affiliates based on how many clicks their ads receive.
For the moment, we’re calling the clicker Trojan-Clicker-Batserv, but with the exception of its bizarre loading behavior, it’s fairly generic. When executed, the clicker makes a duplicate copy of itself in the %appdata% folder for the current user; The copies use names like manager.exe, lssas.exe, or conima.exe. It then creates a batch file (also, inexplicably, in the %appdata% folder) that contains a single command: The full path to the clicker’s executable program.
Now here’s where the fun begins. The clicker does a bunch of stuff in quick succession the first time it’s run. It contacts its command-and-control Web site on port 88 and retrieves instructions; It uses the local policy engine to hide the %appdata% folder (and any folders beneath that level) from view. It also adds entries to the Windows Firewall exception list, so the clicker can connect to, and receive data from, the Internet, unimpeded. And it changes Internet Explorer’s various security settings, rendering the infected computer more vulnerable to infection by drive-by downloads and other malware.
Finally, it creates a Service key in the Registry. These are actually a series of keys that, under normal circumstances, define how Windows will run a given executable as a service — a program that normally has no visible user interface — and how that service entry will appear in the Services management snap-in (services.msc).
It’s not unusual for some kinds of malicious apps (password stealers and clickers, for example) to set themselves up as a service. In most infections, the service key acts like a Run key — it points directly at the executable that’s malicious. It’s not even all that unusual for the descriptive text of the service to look sort of plausible, like this one. But this clicker sets up its service key so it points to the batch file; When the service starts up (at boot time), Windows launches the .bat, which in turn launches the clicker.
All of this stuff makes it harder to “hand remove” the malware, and it makes the task of researching the malware more complicated, but it doesn’t inhibit our program from removing the malware or remediating the changes the malware makes in the Registry. I suppose what caught my attention is just how goofy it is. Then again, as weird and convoluted as this all is, it does work, for the most part, though the more complex the system is, the easier it is for it to fail — or in our case, the easier it is for us to kick the legs out from under it.
It just goes to show that malware creators are incrementally stepping up their game, always trying something different, even if that something looks like a series of dominoes, ready to topple.
does WebRoot stop this from happening or not
In most cases, we remediate the load points during the cleanup process, at the end of a sweep.
So, the answer to Gerald’s question was, “Sometimes”?
Sometimes a shield prevents the malware from setting a load point; Sometimes a distinctive load point leads us to the malware, which we then remove, and sometimes we remediate the load point after a sweep.
However, if the registry load point is pointing at a file that we have removed, it won’t work, and whether or not we remove the load point, the malware is gone and the system is clean.