Practical computer tips, with a smattering of digital philosophy
Monthly Archives: November 2008
November 13, 2008Posted by on
FYI – if a linux distro mounts a disk as “sda1,” that by itself does not, apparently, serve as definitive proof that the drive in question is in fact a serial drive – if the drive happens to be in a laptop. For those of you who are scratching your heads and wondering what exactly I’m blathering about, here’s the deal: as I understood it, the standard convention was for most linux distros to automatically assign the name hd* to IDE hard disks, and sd* to all disks with serial interfaces (either USB or SATA). This rule of thumb apparently does not apply to laptop hard drives, however, which I just found out the hard way.
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)
November 1, 2008Posted by on
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.
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]:
- Navigate to the C:\Program Files directory. Find the folder named something like “Antivirus 2008 (or 2009) XP”.
- Remember/record both the “date modified” and “date created” fields of this file.
- 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.
- 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]
- 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.
— Section under construction —
Resources used/encountered in derivation of solution:
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.