Technosophy

Practical computer tips, with a smattering of digital philosophy

Category Archives: How-to Guides

Places malware hides, update #2: search engine redirection

I’m happy to report that I just stumbled across a bit of information that fixes a serious flaw/oversight in my malware removal how-to guide, and sheds a great deal of light on the inner workings of one of the more obnoxious families of malware currently slithering around on the Internet.

For those of you who are anxious to get to the fix, check the symptoms section (directly below) to make sure that these instructions apply to your situation, and then jump straight to the larger text at the very bottom of the page.

The malware that this fix addresses is a rather common breed, often bundled in with some larger malware packages – but there’s no question it’s an extremely nasty monster in its own right, because it has the ability to:

  • Block access to the websites of all securty / anti-malware sofware vendors (if you can’t access kaspersky.com, or symantec.com, for example, this bug might be the culprit), thereby preventing your antivirus engine (assuming you’ve got one) from downloading virus definition updates.
  • Hijack all the major search engines (google.com, yahoo.com, etc.) by turning every search result link into a redirect that sends you to some random commercial website.  That is, while the bug allows you to access and even submit requests to search engines, it somehow replaces all of the links provided by any given search with bogus urls, often starting with “go” (ie, go.google.com/…, or go.msn.com/…) that turn out to be redirects to webpages which are at best utterly useless, and at worst potential hosts for more downloadable malware (I think I’ve seen yellowpages.com and shopping.com, among others).
  • Generally slow down your web browser
  • Disable the Windows firewall on System startup
  • Prevent anti-malware applications, particularly MalwareBytes Anti-Malware, from installing or running.
  • Cause a variety of other mischief, which seems to vary somewhat on a case-by-case basis.  I’ve seen the first three symptoms on every system that’s been infected with this thing, however.

Those of us who know a bit about networking will probably be tempted (as I was, repeatedly) into thinking that this bug simply relies on the age-old trick of mucking with the hosts file – which makes it all the more infuriating when you open your hosts file and discover that it is apparently completely uncompromised.  No, this particular varmint is considerably more subtle and sophisticated than a simple hosts-file corrupter.  In fact, it’s not even an executable, nor an executable .dll – which means that there’s no way to either find or kill it using a task manager (even Process Explorer) – because it technically isn’t a task.  As it turns out, the bug is actually nothing less than a full-blown system driver, powering a virtual device that actually doesn’t exist – but one which (as far as Windows is concerned) is every bit as real as your mouse or graphics card.  And in the course of investigating this bug, I’ve discovered that Windows seems to protect all files associated with active devices in such a manner that they are completely impossible to see, much less delete. Which means that the general malware-removal method I outlined previously will do absolutely nothing to kill this thing – except, of course if the driver is no longer loaded.  That means that those who opt to clean out their system32 and system32/drivers directories via a Linux live CD will have no trouble at all – but those who aren’t inclined towards that kind of thing will need a different solution.

Happily, a solution has been found by an enterprising member of the tech community, who was so kind as to outline his procedure here (condensed version) and here (original source of fix).  The instructions are stellar, but they direct you to try to remove the thing using automated tools (most of which won’t work, because the virus will prevent them from running)  before telling you how to remove it manually.  Since this strikes me as an enormous waste of time, I’ve excerpted the manual removal instructions here:

Go to Start > Control Panel > System > Hardware > Device Manager > View > Show Hidden Devices.
Scroll down to “Non-plug and Play Drivers” and click the plus icon to open those drivers.
Then search for “TDSSserv.sys”
Right click on it, and select “Disable”
Note: If you select Uninstall, it will install itself again when you reboot the system, so DON’T select Uninstall.
Restart your pc.
You can now update your Antirus/Malware/Rootkit softwares and the go.google rubbish will stop.
Its now up to the Anti-Virus/Malware/Spyware companies to make an effort to stop this, and not rely on simple basic home PC user’s like myself to save the world
In simple terms, TDSSserv.sys is a service/server redirecting all software updates to 127.0.0.1 (your own computer) so they won’t update

I would offer one addendum to these instructions: once the driver has been disabled and the system restarted, go ahead and delete all of the files in your system32 and system32/drivers folders starting with “TDSS”, as well as any other residual files that seem suspicious (again, see my original evil-file-identification algorithm for details).  There’s really no point in waiting around for your anti-virus program to delete them, which is exactly what will happen the next time you run a virus scan – which, by the way, you should do immediately.

If you’re an extremely zealous/through sort, you could even go and remove (*carefully*) all the instances of “TDSS” in the registry, but I’ve never done so, and no computer I’ve worked on has suffered as a result.  Once the driver files themselves are decomissioned/deleted, the bug is vanquished.

——————

Google search optimization section (ignore this):

——————————————–

cannot run malwarebytes, cannot install malwarebytes, searches redirected, google not working, cannot use google, go somewhere else, broken, cannot acces, cannot update anti-virus, blocked

Advertisements

Places malware hides, update #1

I had the great honor of becoming acquainted with yet another malicious “anti-malware” program this evening, and in the process, I discovered yet another place where these bugs can hide their files.  Actually, the cloaking tactics used by particular scourge were some of the most fiendishly clever I’ve ever seen.  First off, the malware piggybacked on a system process (in typical rootkit style), making it impossible (a) to find out the name of the malicious process from the Process Manager, and (b) equally impossible to directly kill the process (without shutting down Windows, of course).  But this is hardly atypical malware behavior; the real kicker was where the malware had decided to deposit its files.  Here’s how I found them:

The bug in question was one of the ones that hijacks IE and displays bogus “unsafe browsing” warnings at regular intervals – and after a half-an-hour of fruitless poking around, it occurred to me that these alerts might actually supply a way for me to track them back to their source.  Sure enough, when I viewed the source HTML for the warning page, I discovered that the page was linked back to a directory in the user’s Application Data directory – to be more specific, a directory named Google. The bug had even been cheeky enough to put an empty subfolder named something like “Saved search results” in the directory – along with a bunch of .dll and .exe files with random names.  Tada.

After being thoroughly outraged (and, I must admit, a bit amused) by this program’s sheer audacity, the removal process was a simple matter of moving the entire Google directory somewhere else (I have no idea why this is, but while files being used by active processes cannot be moved, their parent folders can), and then deleting it when Windows was restarted.  (Killbox didn’t work on these, by the way).

At any rate, here’s the updated list of all the places I’ve found malware lurking to date:

C:Windows (most often .dll files with random names – though some call themselves things like “sysrestore32.exe” (in case you can’t tell, that’s definitely not what the system restore executable is called)

C:Windowssystem32 (same as above)

%USERPROFILE%Local SettingsTemp (same as aoove; I’ve also seen winlogon.exe and winlogun.exe here).

%USERPROFILE%Application DataGoogle

Generic instructions for manually removing common types of malware (viruses, trojans, even some rootkits)

This post is really an addendum to one I wrote a month ago on removing a specific family of malware.  Since then, I’ve discovered (through some exceedingly fun four hours of “research”) that the method I outlined in that post is applicable to a much wider range of malware infections than I originally thought.  Consequently, I’m posting this as both a gateway and supplement to the old post, which contains the core of my manual malware-removal method.  So if you’re currently trying to rid your computer of some nasty bug, and your security software doesn’t seem to be able to deal with it, go ahead and take a look at the instructions on this page – but before you actually try to use them, remember to come back here, because there are a couple of extremely important things that I didn’t mention in that post which you’ll greatly benefit from knowing about.  See below.

Manual Malware Removal Appendix: the finer subtleties of battling bugs

Chances are, whatever bug you’re dealing with will have abused various settings and security policies to prevent access to certain basic Windows components (ie, the command prompt, the registry editor, Windows shortcut keys, and so forth), thereby making it harder for you to find and remove the malicious files (If you don’t notice anything amiss in this regard, and all menus, control panels, and other basic Windows features seem to be functioning correctly, skip this paragraph).

  • To restore any basic functionality that might have been disabled, you can either try mucking around with the group policy editor (invoke a “Run” dialog, and then type “gpedit.msc”, then spend 30 minutes sorting through all of the available settings until you find the one you’re looking for), or you can use any combination of free utilities designed to reverse the malicious changes. The one that I’ve had the most success with is, unfortunately, very difficult to find; simply called FixPolicies.exe*, the utility is apparently little more than a lengthy script – sans GUI, and options – that restores a ton of Windows policies to their default settings. Simply download the thing, run it, and then see if you can now access the features that were disabled by the bugs. I know there are many others, but I don’t seem to have any of them in my gigantic list of links, so if this one fails to fix your problem, go consult the Master Index of Everything (aka google).

*Because this link takes you directly to the file itself, and there’s no documentation on the server that’s hosting it, the best I can do to prove that this is what I claim it is (if you were skeptical, bravo) is to point you to other sites that have recommended the use of this program: here’s one from Expert’s Exchange (sign-in required), and here’s another from some random forum.

  • A word of warning: some of the more sophisticated nasties will actually continually “reset” (read: foul up) your policies to their liking every five minutes or so – so running any of the above fixes will won’t do you much good in the long run until you’ve killed the malware’s running processes. Which brings me to my next point…

In my original post, I detailed how to go about identifying the individual files that constitute and/or support the malware that’s hijacked the system, and suggested that all such be moved to some quarantined location – but I didn’t make any mention of the fact that these files may very will be impossible to delete if any remnants of the bug are still actively running (for the same reason Windows screeches whenever you try to move any other kind of file that’s “in use”). What’s more, if you’re dealing with a particularly noxious kind of infection, leaving even one of the bug’s component files in place is often enough to allow the thing to regenerate itself the next time Windows boots. In short, here are my two fundamental axioms of malware removal:

  • To completely remove malware from a computer, one must quarantine and/or delete all of the malicious files that the bug(s) installed.
  • To quarantine and/or delete all of the malicious files on a computer, one must first ensure both that no running process are actively using the files, and that no running processes are capable of regenerating the files.

The point here is that you need to either:

(1) identify and kill every single process that is either actively using or was spawned by the files in question, or

(2) switch to an environment in which it’s totally impossible that any such process could be running.

The first option allows you to work within windows – but probably won’t help you if your computer is infected with a rootkit, which cloaks itself so well that the system thinks the rootkit code is actually part of a system process (which means that as long as that system process – explorer.exe, say – is running, you’re not going to be able to delete the malicious files. Period). The second option, by contrast, is guaranteed to allow you to delete/move any file you wish – but requires the use of a Linux boot CD. Depending on which option you choose, here’s some additional helpful information

1. If you elect to try the first option (which, being more straightforward for most people, is probably a good first step), there are two utilities that will make your search-and-removal task a great deal easier: ProcessExplorer, and KillBox:

  • Process Explorer is a souped-up version of the standard Windows Process Manager, which can (among many other things) tell you the name and location of the files that spawned each running process (useful if the malware on your computer is accessing its files by means of rundll32.exe calls, which just appear as multiple instances of “rundll32.exe” in the regular Process Manager).
  • Killbox is utility that allows you to force-delete any file on the system – even if there are processes still accessing it. I used ProcessExplorer extensively during the process of deriving the base procedure that all of this rambling is intended to supplement.

I’m afraid I don’t have the time or energy at the moment to detail the various ways in which you might use these applications to your advantage – but the programs are both fairly intuitive, and ProcessExplorer has excellent documentation, so you shouldn’t have much trouble.

2. As for the second option, I can only say that I do plan on writing a primer on how to obtain and use a Linux Boot CD for a wide variety of system-rescue purposes – but not right now. So if you know exactly what I’m talking about, and just need help with mounting your system drive, go for it (don’t forget to specify -t ntfs -o rw, since you want to delete stuff). Otherwise, if you really cannot find any other way to permanently delete the files in question, you’ll either have to consult an online Linux tutorial, or consider the possibility of reformatting your hard disk and reinstalling Windows.

Last, here are a list of symptoms that my solution has been repeatedly proven to be effective against (this is here primarily for the purpose of ensuring that this page will be one of the entries that comes up when anyone does a search for the following symptoms.  I know, I know: I’m shameless.):

Pop-ups

Browser hijacking, which prevents any web browser from being able to get to anti-malware websites, and causes the browser to be redirected to random shopping websites whenever you try to click on a link from a search engine (google, yahoo, you name it).

Disappearance of the “Display”, “Screen Saver”, and “Advanced” tabs in the Display Control Panel.

Disappearance of the Folder Options Control Panel

Crippling of Windows Security Center

Disabled Windows-key shortcuts (Winkey-R; Winkey-D, etc.)

Disabled Command Prompt

Disabled Registry Editor

Appearance of cockroaches on the desktop, accompanied by a warning informing the user that that there “are bugs on the system”  I’m not kidding.

Okay, I hope all that wasn’t too overwhelming. Many thanks to one of the people who commented on my orginal post, for reminding me to include some of these details.  More feedback is always welcome and greatly appreciated.

Finally, good luck to all!

How to remove the family of rouge anti-malware programs with names similar to “Antivirus 2008 XP” (Update: works on a wide variety of other types of malware as well)

Update: I recently discovered that many bugs that aren’t part of this family nevertheless function (and, consequently, can be killed) in exactly the same manner. Thus, unless I’m very much mistaken, these instructions can be generalized to a wide range of infections. So whenever I refer to “this family of bugs,” know that what I’m saying can probably be applied to your infection as well.

If you’re here because you are dealing with a “Antivirus 200x XP” variant, please note that you can skip anything denoted as an “update” or “for other families of malware.”

Finally, if you run into any trouble, please see the comments on this post, as well as my official appendix and updates (1 and 2), which discuss additional important details that I’ve discovered over time.

Intro:

Of all the issues I was thinking of discussing first, this one seems by far the most urgent, since the epidemic of computers being infected by malware masquerading as anti-malware is growing worse by the minute.

If you’ve come to this page by way of a google search for the aforementioned “applications,” chances are you’ll already have encountered (and possibly tried to follow) several different sets of conflicting instructions for removing your nasty parasite. While many of these how-to guides do offer useful advice, most are unfortunately somewhat incomplete; they point you to a few heavy-duty, heavily-specialized anti-malware applications that can detect MOST – but not all – of the artifacts associated with the bugs infesting your computer. After some 20 hours of fiddling with the programs recommended by these sites, as well as some other top-notch diagnostic utilities, I’ve managed to devise a removal method that is extremely fast, straightforward, and effective, and that doesn’t really require the use of ANY third-party applications at all! Because I suspect most of you are primarily looking for a quick fix, I’ll spell out exactly what you need to do first; those of you who are interested in the derivation of this technique, and proof that my suggestions are based on empirical evidence, please see the section following this step-by-step procedure. Without further ado:

Background Info & General Approach:

Basically, antivirus 2008 xp, antivirus 2009 xp, antispware 2008 xp, and whatever other titles these bugs have decided to call themselves all work roughly the same way: they embed randomly-named files with misleading extensions in your system folders, and then use valid windows components (rundll32.exe, for example) to execute themselves. Several features of this design are, I am forced to admit, fiendishly clever. Because the malicious files have randomly-generated names (kjO1xpf.log, for example), neither you nor your antivirus application can check the files against a list of dangerous filenames. [Update: for malware from other families, there’s a chance that a different, but equally devious tactic will be used to disguise the dangerous files: they may be give names that are identical, or nearly identical, to the names of critical windows files. winlogon.dll seems to be a popular one.] Furthermore, because most of the damage is done by files that aren’t themselves executables, tracking them down by means of process analysis (looking at the list of currently-running processes on your computer) is also nigh on impossible, because the processes associated with the bug (other than the “Antivirus 200?…” process, which doesn’t actually do anything other than annoy you, and can be instantly re-generated by its hidden helper-files) are almost all instances of some Windows component (again, like rundll32.exe) which look completely legitimate.

However, these bugs have a couple of critical weaknesses: though they can engage in some pretty sophisticated spoofing, they cannot change the time and date that their files were created, and they cannot identify their files as Microsoft products. Typically, all the files responsible for generating and sustaining these bugs are created within the same two-day period – and because they’ve chosen to store themselves in a folder filled with system files, which generally aren’t modified very often, they are likely to be the vast majority of those files that appeared in that particular time/date range. Therefore, here, more or less, is what you need to do (I’d recommend doing all of this with Windows explorer in “detailed list” view mode – it makes sorting and finding things a lot easier).

Procedure [First 3 steps apply only to bugs in the Antivirus 200x XP family; generic instructions start at step 4]:

  1. Navigate to the C:\Program Files directory. Find the folder named something like “Antivirus 2008 (or 2009) XP”.
  2. Remember/record both the “date modified” and “date created” fields of this file.
  3. While you’re in the Program Files directory, you might as well kill this particular part of the application. Either delete the entire “Antivirus 200?…” folder, or move it somewhere else (if you’re feeling particularly cautious), so that the program’s main engine cannot find these files.
  4. Go to your windows directory (usually C:\Windows). Sort the entire directory by “date modified” (by clicking on the “date modified” label at the top of the column). Then look for time/date markers that are fairly close to the ones you recorded in the second step [or, for other families of malware, look for time/date markers that are relatively close to the time you started noticing symptoms of an infection]
  5. Assuming you’ve found a bunch of files that seem to have been created/modified within a few days (a week, max) of the “Antivirus 200?…” folder (and you should have), proceed as follows:
  • First off, use common sense. If you see files with names like “asjkesply.dat,” be very, very suspicious. By the same token, however, don’t go randomly deleting or moving files with names like “kernel32.dll” – but do check to make sure that such files are what they seem to be (in particular, if they aren’t signed by Microsoft (see below), they’re almost certainly evil)).
  • Hover your mouse over each of the files in the time/date range of interest. If the little file information box that appears states that the file was created by “Microsoft corporation,” or some other “reputable” company, leave the files alone. Make note of all those files for which no creation-organization is listed.
  • Because you are mucking around with system files here, it cannot hurt to be too careful. I feel fairly comfortable stating that you’re probably safe moving (notice I do not say “deleting”) files that both (a) bear little or no information about what organization created them, and (b) have filenames consisting of random strings of characters – but if you have any doubt at all about a particular file, check it out on Google. Seriously, just type the entire file name in to Google, and see what comes up. If the file seems to be well known, and is stated to serve some useful function, leave it alone. You can also check out the files you’re unsure about by uploading them to VirusTotal.com, which will run them through a battery of scans by 35 different antivirus engines, and give you a report of how many engines flagged the file as being evil. (Generally, I’d say a file that comes back with fewer than five positives is probably clean; the files we’re interested in usually come back with more than 25 positives).
  • Once you’ve established beyond a reasonable doubt which files are evil, move them all into a new directory (call it something that will help you remeber that these files came from C:\windows, just in case you need to replace any of them).
  • Repeat the above process for the C:\windows\system32 directory, as well as (for other families of malware):
    • The “temp” directories of all user profiles that have been in recent use (C:\Documents and Settings\*user*\Local Settings\Temp). Actually, if at all possible, just summarily delete everything in this folder; if you didn’t know, this directory is actually a repository where Windows dumps (and usually neglects to clean up) its working files, none of which are (usually) even remotely useful. As always, however, proceed with caution.
    • C:\Windows\temp. The above addendum applies to this directory as well.

– Restart the computer.

You’re done.

— Section under construction —

Resources used/encountered in derivation of solution:

MalwareBytes’ Anti-Malware

HijackThis

VirusTotal.com

ProcessExplorer

Kaspersky on-line malware scanner

FixPolicies.exe

Some notes on the derivation and applicability of this method:

I’ve developed this strategy over the course of several months, during which time I’ve had the pleasure of encountering no less than five heavily-infected laptops: four being plagued by variants of the “antivirus 200x XP” bug, and one suffering from a variety of bugs that were almost certainly from a different family (see below). In all five cases, I was able to completely remove the malware (granted, in a couple of cases some artifacts remained, but these were just consequences of all the disgusting policy-hijacking these programs love to engage in; no trace of an active infection remained. And I suspect that if I’d used the policy fixers I now know about on those machines, those remnants would have disappeared).

At any rate, I just had an opportunity to joust with a particularly bad infestation on a laptop – and though the process took over 3 hours, the information I gleaned in the process was extremely valuable. What was particularly remarkable about this situation was that though none of the bugs on the machine in question seemed to have any direct relation to the “Antivirus 2009 XP” family of malware, the procedure described above proved equally effective here – with a few minor tweaks. In other words, my experience this evening has confirmed something I’ve suspected for quite some time: many malware developers are apparently relying on a relatively narrow and predictable set of techniques to conceal their wares – and though these techniques are often extremely effective at bamboozling anti-virus engines, many of them cannot survive even the most cursory examination by a human who knows what to look for.