Ransomware: Identification and Response

Posted on April 10, 2017 by Steve Schardein

By now, ransomware is an unfortunate fact of life. Anyone who’s been working in IT for some time has very likely brushed up against it at some point during their career–and while it’s a stunning encounter in the outset, it’s the response to that encounter that makes all the difference.

Before we go any further, I want to make this very clear: if your data is important to you, it is very wise not to attempt recovery/response on your own. Bring your machine to a professional instead! If you have nothing to lose, however, below are some guidelines to follow to attempt recovery in the aftermath of an attack.

It’s useful to comprehend the steps most ransomware specimens take to attacking/encrypting data on a machine to help facilitate a response to their attacks. This is absolutely not meant to be a comprehensive article on the subject (far more detailed analyses have been written by experts such as Lawrence Abrams at his excellent BleepingComputer.com), but here are a few common points that apply to most every ransomware in the wild today:

Most of them limit the types of files they encrypt to those which are most likely to contain critical user data–stuff like photos/pictures, documents, videos, databases, etc.
System/program/non-user data directories (X:\Windows, Program Files, Program Data, %APPDATA%, etc.) are explicitly excluded from encryption to prevent system stability issues post-infection and improve efficiency
Encryption normally begins silently in the early morning hours while the user is less likely to be in front of the machine.

The above items are done in the interest of efficiency to ensure the ransomware is able to complete its encryption job without the user noticing. Typically, after the completion of the encryption, the ransomware will then remove itself from the system–leaving only a ransom note with payment instructions, as that’s all the attackers care about at this point after all.

Although most of them apply the same strategy (and many are, in fact, even blood-related), the first step to properly responding to a ransomware attack is to take a sample and attempt a positive ID of the malware. This can be accomplished by using services such as ID Ransomware (by MalwareHunterTeam/Demonslay335), which is a free online resource that attempts to identify a ransomware infection based on either a ransom note or sample encrypted file. However, it’s very important that you do not obtain the file while running on the infected OS. Doing so provides the ransomware precious additional time to complete its destruction of the existing data if it has not already completed. If you must collect the file in the host infected OS, only do so after you obtain a forensic image of the data.

Once an ID has (hopefully) been completed, the next step is to respond and attempt recovery (if necessary/desired)–assuming no backups are present and that does not exist as a (much simpler) option. This involves several steps, but it roughly goes something like this:

Obtain a forensic image of all affected storage devices/machines and store it safely away from the machine.
Boot to a portable environment and manually inspect the parameters of the system, including:
1. Boot processes, services, tasks, and other items frequently leveraged by malware as loading points
2. The locations of any files which are infected, malware, or related to the ransomware infection
3. The System Volume Information repository contents and the Volume Shadow Copy parameters/settings (to ensure that Shadow Copies and System Restore are turned on and that sufficient space is configured to allow for the storage of Shadow Copies)
4. The health of any affected storage devices
If necessary, suspend/disable any components which are related to the malware/ransomware infection next.
Once this is completed, reboot into the host OS (Safe Mode if possible) and, if a decrypter has been identified for your particular ransomware infection, obtain it and attempt decryption of the data.
If a decrypter has not been identified, the only remaining solution is usually to attempt to dig into the Volume Shadow Copy Storage in hopes of previous versions of the affected data still being present.
- Ransomware specimens often attempt to purge shadow copies of files post-encryption to prevent recovery of the files using shadow copy storage. However, the methods used to do this are often heavy and time-consuming (typically it’s a vssadmin command that’s used to accomplish this). Many times the process will not have completely finished by the time the user notices the damage. That’s why sometimes digging into the VSS storage can be a successful solution to recovering data following a ransomware attack.
- There are multiple tools available which can accomplish Shadow Copy file restoration, but the best is probably ShadowExplorer.
If shadow copies do not exist, the last-ditch effort to retrieve some remaining data is typically to perform a file carving operation on the entire hard drive. Tools such as PhotoRec can be used to accomplish this. File Carving identifies files based on their headers and not based on filesystem information/structural data (MFT/FAT/etc). As a result, it can sometimes turn up lost files even following a ransomware attack.
- Most ransomware specimens wipe both free space and the sectors on the disk affiliated with previous/clean versions of encrypted files once encryption is complete, so this process is usually fruitless. But, as a last resort, it’s worth a shot.

If all else fails, backups are the final option. If no backups exist, the user must consider paying the ransom in hopes of recovering their data–though authorities and experts will invariably tell you not to do this, as it encourages ransomware as a viable business venture and, therefore, the attackers win. However, most ransomware gangs will in fact restore data following successful receipt of payment–and sometimes it is the only option.

Once recovery has (hopefully) been completed, any remaining ransom notes can be automatically removed using Demonslay335’s RansomNoteCleaner tool here.

For specific help on a ransomware infection, check out BleepingComputer’s free support forum here. Remember, though–if your data is important to you, let an expert handle it! Don’t attempt a DIY recovery!

CryptoLocker: UNdecryptable file ransom—How to recover

Posted on October 20, 2013 by Steve Schardein

For some time now, malware authors and attackers buying licenses for use of their programs on the black market have been making a killing off of file recovery ransom schemes. The most widespread of these was the “Windows File Recovery” style rogues that hit a couple of years ago, where a rogue recovery program named something of the sort would appear on an infected system in an attempt to convince the user that they had lost all of their data due to some catastrophic event (i.e., a hard disk failure) and that they would need to pay to have those files retrieved. More recently, these were followed up by the still-rampant FBI Moneypak Trojans, which display a message at Windows startup explaining that the FBI has locked the PC due to its use for illegal activities and that the user will need to pay $300 via Moneypak to have it unlocked.

None of these initial attempts were very difficult to thwart unless the user or technician was completely unfamiliar with them. The Windows Recovery rogues simply hid the files, which could easily be unhidden following their removal. The most sinister thing they ever did was moved the user’s shortcuts to a hidden temporary folder. The FBI Moneypak is a cinch to kill once you know of its loading points (though it does often come bundled with the ZeroAccess rootkit). Some of the later iterations of these ransom rogues took this a step further by actually encrypting the user’s data, but even these could be beaten with special decryption tools. Eventually, they were assigned the title of Ransomware, which technically could be used to classify any of these specimens.

In case you haven’t heard, there’s a new form of this malware, however, and it’s much, much nastier. It’s called CryptoLocker, and it also encrypts the user’s data—but it does so using a fusion of AES and RSA encryption that is literally impossible to reverse without the possession of a private key. That private key resides on a remote server that is only accessible once the user actually pays to have the decryption performed (and it doesn’t always work, either). By the time the user knows they’ve been infected, all of their precious data has usually already been encrypted. Needless to say, this is disastrous, especially for businesses.

Over the course of the past few weeks, I’ve had two different customers with this infection. While it’s true that there is no possible way to decrypt the data, fortunately, there are still ways to recover some or even all of the data (albeit, slightly older versions of the files) if you know just one simple trick.

Windows Vista and beyond include a little-known feature called Volume Shadow Copy. It’s closely-related to System Restore, of which many people are familiar already, but most people are not aware of the fact that Volume Shadow Copy (unlike System Restore) actually includes management of versioned snapshots of the user’s data as well.

This is a valuable tool in data recovery, of course, provided the system is bootable and the Volume Shadow Copy functionality is accessible/unbroken. But it also happens to work with current versions of the CryptoLocker Trojan.

Here’s the process you’d need to follow:

Remove the CryptoLocker Trojan first or all recovered data will also be encrypted.
- This is actually pretty easy to do; you can find a plethora of information about it across the internet. The Trojan loads from an executable in the user’s AppData\Roaming folder (Documents and Settings\Application Data on XP) which can simply be removed to kill it.
- However, CryptoLocker also has been bundled with Zbot very frequently, so also be sure to check for a randomly-named folder in AppData\Roaming or AppData\Local as well containing a single randomly-named executable and remove it as well.
Either right-click on a folder and choose Restore previous versions in Windows 7 to reveal dated snapshots of the contents of that folder, or in any version of Windows (XP SP2 and beyond), download ShadowExplorer to assist in the browsing and copying of these versioned copies.
Copy the data from the most recent unencrypted snapshot to a safe location.

If you need help locating all of the files which were encrypted, you can download ListCrilock from Grinler, which is a tool that lists the contents of the HKEY_CURRENT_USER\Software\CryptoLocker\Files registry key (the location CryptoLocker records the files it has encrypted).

While this is a very fortunate oversight by the authors of the malware, I wouldn’t expect it to last. All that would need to be added is a quick routine to clear all restore points or the contents of the System Volume Information folder to prevent this recovery from taking place, and the authors know this—something which is probably in the works already as this solution has begun to spread throughout the security communities. Ultimately, what this should do is remind everyone of the importance of regular (preferably versioned) backups offsite or to a drive which is disconnected in between backups (to prevent the files from being encrypted upon the next connection).

Thanks to Grinler for much of the information used to assemble this post, for his excellent tool, and for running a terrific website in the process.

Change your router’s login information

Posted on April 6, 2012 by Steve Schardein

As a bit of an extension from an earlier post, I’d just like to reiterate the importance of changing the default login information for your router (or your customers’ routers). I’ve seen another uptick in DNS-Changer/DNS Hijack activity which includes the modification of router DNS settings to include malicious IP addresses, most of which hail from within the Russian Federation.

There is an easy way to correct this. For starters, obviously, you need to ensure your router isn’t infected. If the DNS settings have been changed, blank them out, then follow it up with a new username/password for your router. It doesn’t need to be anything complex; even simply changing it to anything else will do the trick. The malware responsible aren’t brute forcing the passwords or anything like that; they’re simply leveraging knowledge of the default login info for each router model to weasel their way into the settings and add their own DNS information.

It also goes without saying that all client PCs need to be clean before making the change, lest the settings will be reversed by any active malware on the network after you change them. It is possible to change the login info first, and then blank out the DNS settings if you’re unsure which machine is causing problems and you just wish to prevent propagation of the malware/further information theft. But this must be done from a clean machine.

Many ISPs will warn users if they’re affected by such DNSChanger infections. By cleaning the malware off the PCs and checking the routers, you can ensure the problem is resolved. However, there is one final setting to check:

HKLM\System\ControlSet001\Services\Tcpip\Parameters\\DhcpNameServer

This registry value will often be modified to include the same malicious DNS servers. Be sure to check it on each machine, lest a clean machine can quickly become infected once again!

Solution: STOP Error 0x0000007b (0xfffff880009a98e8 0xffffffffc000000d 0x0000000000000000…)

Posted on October 16, 2011 by Steve Schardein

Hoo boy, this one’s a doozy.

So following the removal of certain rootkits (such as Rootkit.Boot.SST.a, which is associated with the Windows Recovery rogue), you may find that your Windows boot configuration data has been totally corrupted. Worse yet, the usual steps to remedy (such as those described in my earlier post about TDL4 and the resulting blue screen) all fall apart when you reach the bootrec /RebuildBCD command, which returns the message:

Total identified Windows installations: 0

Geez. This essentially means that the bootrec command cannot identify your Windows installation, even though the Windows Recovery Environment has no trouble doing so upon starting. So, now what?

Sometimes it’s as simple as opening up your favorite disk partitioning software and marking the C: partition as ACTIVE, and if there are still problems, subsequently recovering the boot data as I mentioned in the TDL4 post (keep in mind however that the System Managed partition is typically Active normally on a Windows 7 system thanks to the isolated boot partition that it uses). This problem occurs because of some modern rootkits which create a hidden, encrypted partition at the end of the system drive and mark it as Active and Primary (while simultaneously marking the standard boot partition as Inactive). This infection has been covered in other recent blog posts as well.

Sometimes, however, the BCD is totally corrupted and this doesn’t even work. At this point, most every source on the internet comes up a dead end. Everyone ends up reformatting or reinstalling Windows overtop their existing partition; nothing else seems to work.

You might not think it’d be helpful, but there’s an intimidating post over at the EasyBCD NeoSmart site which explains how to manually rebuild the Vista bootloader from the ground up in catastrophic situations. As it turns out, this procedure applies to Windows 7 as well (which uses the same bootloader and BCD structure), and it’s the key to your recovery here.

It’s no easy feat however, so roll up your sleeves and get ready to do some typing. Here’s the full procedure from start to finish:

Boot to the Windows Recovery Environment either by selecting Repair Your Computer when Windows fails to boot, by inserting the Windows installation disc, or by using a Windows ERD/MS DART disc (if you happen to have access to one, that is).
Cancel the recovery attempt if it tries to start on its own (it will fail anyway) and then choose the advanced options link at the bottom of the window.
Choose to open the Command Prompt.
Here’s the fun part. Once at the prompt, enter the following commands one by one. Take care not to mistype anything, and be sure to replace C: with whatever your system drive happens to be:

bootrec.exe /fixmbr
bootsect.exe /nt60 all /force
bcdedit /export C:\BCD_Backup
attrib -h -s C:\boot\BCD
ren C:\boot\BCD BCD.old
bcdedit /createstore c:\boot\bcd.temp
bcdedit.exe /store c:\boot\bcd.temp /create {bootmgr} /d “Windows Boot Manager”
bcdedit.exe /import c:\boot\bcd.temp
bcdedit.exe /set {bootmgr} device partition=C:
bcdedit.exe /timeout 10
attrib -h -s C:\boot\bcd.temp
del c:\boot\bcd.temp
bcdedit.exe /create /d “Windows 7” /application osloader

At this point, note the value within the curly braces {……..} as you will need it during the next steps. Replace the dots within the curly braces below with that entire string on each line. NOTE: To make this easier, once you type it once, you can press the Up arrow to restore the last command and simply edit that line for the next one.

bcdedit.exe /set {…..} device partition=C:
bcdedit.exe /set {…..} osdevice partition=C:
bcdedit.exe /set {…..} path \Windows\system32\winload.exe
bcdedit.exe /set {…..} systemroot \Windows
bcdedit.exe /displayorder {…..}
bcdedit.exe /default {…..}
bcdedit.exe /set {…..} locale en-US

Thanks to Bitt Faulk for the final line, which restores the correct Windows loading screen as well. You will need to replace the en-US entry with something different representing your region if you are not in the US.

Then you’re back in Windows, miraculously. No reinstall necessary!

Side effects? A little. Hopefully you can handle not having the nifty new Windows 7 startup animation screen, because this will lose it for you. Instead, you’ll be stuck with the old-school plain Jane Windows Vista progress bar. You’ll also lose any special boot options you had previously. But as a last resort, this works, and it’s still just as quick as ever.

Apart from that, once you’re back in Windows, of course, you’ll still have to disinfect the rest of the way. In my customer’s case, the system damage was actually so bad that I ended up performing an in-place upgrade (the Vista/7 equivalent of a Repair Install), but after that, everything was great. It was a triumph for sure, and yet another situation where the usual solution of reformat/reinstall was not necessary. Now you know how to avoid it!

I hope you’ve found this post useful–if so, please take a moment to leave me a comment!

If you need computer help in the Louisville, KY area, there’s simply no one better. Give me a call today!

STOP: c0000135 – The program can’t start because consrv is missing. Try resintalling the program.

Posted on October 14, 2011 by Steve Schardein

Getting this error? Wouldn’t you know, it’s actually the product of a nasty little rootkit called ZeroAccess MAX++ of which you might be familiar. The particular variant that causes this error actually uses the consrv.dll file to ensure it is able to load at boot on 64-bit systems. As such, among other items, this rootkit drops a file called consrv.dll into the %SYSTEMROOT%\system32 folder. It’s the reference to this file in the registry which wreaks said havoc once the file is removed by any means (antivirus, offline deletion, etc.).

To rectify the problem, you will need to gain access to the %SYSTEMROOT%\system32\config\SYSTEM registry hive remotely (whether by Recovery Console’s regedit and the Load Hive… command or by booting to another operating system and loading the hive in similar manner) and change an entry modified by the rootkit back to its default value.

The infected machine will have a modified string (REG_EXPAND_SZ) data of the Windows registry value in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\SubSystems which looks like this:

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=consrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

This value is wrong, and it’s the reference to consrv which is generating your c0000135 stop error. Instead, change it to:

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

This will solve the problem and enable the machine to boot. Please note that you should also modify the same value in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\… for completeness.

For a little more background/ancillary info, on the machine I was repairing which experienced this issue, the rootkit was accompanied by an additional MBR bootkit of the family Rootkit.boot.Pihar.a. TDSSKiller actually took care of this one and restored the clean MBR. In addition, plenty of other malware was along for the ride (all of it predictably hidden by the rootkit combo). It was a nasty situation, but nothing I couldn’t handle. 😉
I hope you have found this case study useful. Please let me know if it has helped you!

“Infected” routers threaten death by DNS

Posted on August 12, 2011 by Steve Schardein

Recently, I took delivery of a client’s PC which had been thoroughly scanned, but he was concerned that it might not be fully clean. If you’ve followed my work, you already know that this is relatively common; scanners, for all their merits, can only access what they’re allowed to access, and they can only detect what they’re written to detect. Even heuristic detection can only go so far, and with today’s polymorphic malware (a.k.a., malware which changes its form with every specimen), signature-based detection is hardly reliable for the ever-common zero-day threats.

Such was indeed the case with this client’s computer, which was indeed still infected, regardless of clean scans by Symantec, Ad-Aware, and other utilities. Although nothing had identified them, they were almost certainly a new variant of the Trojan.Tracur family of malware. Previous versions of the Trojan have been known to create copies of local system services, using legitimate descriptions for legitimate services and even the same names—just suffixed with the number “32”. Normally it drops related files in the system32 directory, but this variant actually had created its sister files inside \ProgramData – over 30 of them, one for nearly every single service on the system.

But that isn’t the subject of this blog post. More interesting was the phone call I received once this client had taken their PC back home and begun using it again: he was still having problems, he told me. Web sites were loading with weird formatting, and when using Chrome, login attempts at popular sites popped up another window prompting a second login. The behavior sounded very similar to what some rootkits attempt to steal passwords and financial data.

This situation might not sound strange, but you have to understand: I never return infected computers. I had performed the same rigorous inspection on his before calling him to pick it up, including a full analysis of all OS loading points, drivers, services, and the master boot record of the system drive. I also check for policies, malicious proxies, faulty DNS caching, and infected critical system files—nearly all of this manually, using tools which I have specially developed for the task.

So I wasn’t convinced that malware was still on the PC—but I was concerned that perhaps we were missing something else. I reviewed his logs (of which I keep detailed copies for every client) and found no signs of any danger, so I began considering other possibilities. What else could possibly be the problem? His router.

Router infections are nasty little things. Technically, they aren’t infections, but rather, corrupted settings (thanks to malware) which lead to compromised PCs and information. They aren’t necessarily new; this has been a trend which actually started a couple of years ago and has become increasingly common among malware.

It’s actually pretty simple how they work: once a client computer has been infected, the malware takes advantage of the fact that no one ever changes their default router password. Equipped with this information, it accesses the router configuration and changes the DNS servers to malicious servers of its own, which can filter and steal traffic passing through them or even redirect users to altogether different sites when they request a page. This can be made entirely transparent to the user, as the displayed web address (the so-called FQDN) is still the same—only the resolved IP address has changed.

It isn’t uncommon for such router infections to reinfect clients even after they’re cleaned, presenting a seriously hazardous situation. The solution involves simultaneously performing a hard reset on the router (by holding down the reset button for 15 seconds or longer) and disinfecting the PC (and all affected PCs on the network) before connecting back to the router. Following that, the network must be reconfigured on the router, and a password needs to be set to prevent future infiltrations.

In my client’s case, there really wasn’t any proof that this was what was happening with his PC, but it was the next logical step after rechecking his PC remotely using some log-generating deep system scanning software. So we reset the router, which seemed to resolve the internet traffic issues. However, the problems with Chrome persisted, even without any extensions installed. Given the options, we eventually elected to uninstall Chrome, chalking up the additional problems to a possible unknown bug in the browser itself. Case in point: no other browsers, including Mozilla Firefox, had the same issue. Just to be certain, I rechecked all proxies, the master boot record, and system files. The PC was indeed 100% clean, and my client was happy.

TDL4 removal leads to Windows 7 64-bit stop error on boot

Posted on August 1, 2011 by Steve Schardein

I’m proud to say that it’s been literally two years since I’ve reformatted a PC due to malware, and I’ve disinfected many hundreds in that time period. But yesterday, I encountered a PC infected with TDL4 (which I’ve dealt with many times), however this one was a Windows 7 64-bit machine. Following removal of the rootkit offline via TDSSKiller in WinPE (set to scan Boot Sectors only), the PC began crashing on every boot, even when Safe Mode was attempted. The typical invasive offline procedures I use to rectify these issues — such as the disabling of nearly all third-party filesystem and NDIS filter drivers — did nothing to correct the issue. Restoring a previous System Restore point and even manually restoring the registry hives from the RegBack folder also accomplished nothing.

Finally, I decided to backup/restore the BCD. To do this, I used a Windows 7 recovery disc (in my case, ERD/MS DART) and opened a command prompt. From there, I (mostly) just followed the Microsoft guidelines for restoring a corrupted BCD:

c:
bcdedit /export C:\BCD_Backup
attrib -s -h c:\boot\bcd
ren c:\boot\bcd bcd.old
bootrec /fixmbr
C:\boot\bootsect.exe /nt60 all /force
bootrec /RebuildBcd
bootrec /FixBoot

(Note that C: must be replaced with the relevant Windows drive.)

This corrected the issue on this PC. I hope this helps someone in the future!

Post-disinfection Stop Error: c000021a

Posted on February 6, 2011 by Steve Schardein

On multiple occasions over the past couple of years (since kernel-patching rootkits have become prevalent), I have encountered a particularly troubling STOP Error that most often technicians simply respond to by running a repair or clean install of the operating system. It looks something like this:

STOP: c000021a {Fatal System Error}

The windows Logon Process system process terminated unexpectedly with a status of 0x[various] (0x[various] 0x[various]). The system has been shut down.

Where [various] represents any number of hexadecimal error codes that may apply.

In this case, simply restoring the registry to a previous state as I’ve written about before does not correct the problem.

There are posts and pages to address this situation scattered across the internet, but nearly all of them offer different solutions, and most of them don’t seem to work. Microsoft has a page that relates the issue to Windows NT OS, blaming it on the PendingFileRenameOperations registry key which is often used by malware and antimalware to perform a rename operation on reboot. However, fixing this key as they suggest also does not solve the problem.

Most often, when it’s encountered post-disinfection, I find that the problem relates to an issue with a patched system file. I’m not certain, but it nearly always seems to be winlogon.exe.

Regardless, there is one and one only way to ensure the problem is corrected: find and replace the suspect file! There are multiple ways to accomplish this:

Boot to a custom OS or slave the drive, check the system files (or run a virus scanner through them), and replace the faulty files with good copies (see below).
Run a system file check from the Windows Recovery Console by typing sfc /scannow.
Boot to an MS DART ERD Commander disc for Windows XP and run a system file repair from within the environment (this is my method of choice).

If you are forced to manually inspect and/or replace the files, I suggest checking for Company information and investigating any files which are missing the usual Microsoft Corporation info. If a suspect file is encountered, check its MD5 hash and Google it to see if it’s a known patched copy.

Once the culprit(s) has been identified, navigate to the system32\dllcache folder and copy the corresponding file there to its correct location. If it isn’t there or the copy is also bad, restore it from the Windows CD, or look for a folder called \i386. You can also run a search for the file throughout the entire Windows directory to find copies which have been downloaded for Service Packs and other Windows Updates. Just be sure to get the correct version.

In my most recent customer’s case, the files at fault were explorer.exe and winlogon.exe. Both had been patched by a rootkit and needed to be replaced. Once that was finished, the system booted up just fine.

If you’re looking for computer help in the Louisville area, look no further. Call me today and get it done right!

TDL4

Posted on November 1, 2010 by Steve Schardein

In keeping with tradition, this year has seen a great number of TDSS (Win32/Alureon) rootkit infections, many of which go undiagnosed by the average tech. Although the numbers have dropped off some, the difference now is that those who are infected face a much more difficult diagnosis, as TDSS (a.k.a. Win32/Alureon) has continued to evolve.

The latest of these iterations is TDL4 (referred to here as DOS/Alureon), which manages to infect the MBR, as well as in some cases, a kernel-mode driver. This technically classifies it as both a bootkit and a kernel-mode rootkit (although theoretically these are wholly separate infections), making detection and removal extremely difficult and risky.

Even worse is the fact that TDL4 stores its primary rootkit code in an encrypted virtual file system. In cases where a combination infection is present, if the bootkit is removed, the kernel-mode rootkit can seemingly resume activities regardless.

Symptoms and diagnosis

The purpose of TDSS is to provide control over an infected PC so that it can be administered by an attacker (generally, a customer of the malware authors), who can then use the PC for whatever they choose: generation of web page hits, advertising, spam, or information theft.

The primary symptom of a TDSS infection has not changed: most often, the infected computer will redirect internet searches to pages of its own choosing. The mechanism behind this works on the HTTP protocol level; typically, the infected computer’s network traffic is also routed through a fake network proxy which actually redirects all network application traffic first through the rootkit. Attempts to remove this proxy setting will, of course, be reversed if the rootkit is not first dealt with.

One way to diagnose whether or not a system is under the control of TDL4 is to open a Command Prompt and type diskpart, followed by lis dis. If you receive the response there are no fixed disks to show, it is likely you are dealing with a TDL4 rootkit.

A wealth of utilities exist which claim to be able to diagnose and remove this threat. Most of them work quite well, but all of them are risky. Since TDSS is updated on a very regular basis, new variants adjust their strategies. As a result, running one of these utilities without a full system drive image can occasionally result in an unbootable computer. The only way to correct this if it occurs is to find the offending patched system file from offline and replace it with a known good copy.

Personally, I have written a script to search for patched system files and replace them automatically to ensure I do not miss any kernel-mode rootkits when suspected.

My most recent encounter

Although I generally still encounter TDSS on a weekly basis, the most recent version of the infection I saw was a combination of the TDL4 bootkit and the TDL3 random system driver rootkit. It was not clear whether the TDL3 rootkit was still active in any way following the TDL4 infection; naturally, I didn’t allow it to stick around long enough to find out.

Regardless, the bootkit was first removed, after which the system file, isapnp.sys in this example, was replaced offline with a known good copy (in this case, found in the computer’sdllcache folder). Afterwards, I removed the conventional fake network proxy to restore internet connectivity, as well as cleaned up some NTFS mount points which were probably left by another unrelated infection (possibly the max++ rootkit from last year).

And, of course, the final step was to kill a boring old rogue antivirus application that just wouldn’t go away with TDSS’ protection behind it. Good riddance!