Category Archives: Malware and Security

Special notes on the latest threats and prevention/response.

Ransomware: Identification and Response

Posted on by
Reply

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:

  1. Obtain a forensic image of all affected storage devices/machines and store it safely away from the machine.
  2. 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
  3. If necessary, suspend/disable any components which are related to the malware/ransomware infection next.
  4. 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.
  5. 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.
  6. 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!

SOLUTION: Cannot Uninstall Microsoft Security Essentials from Windows 10

Posted on by
16

Recently, I encountered two different workstations that had upgraded to Windows 10 from Windows 7 on which Microsoft Security Essentials inexplicably was not uninstalled during the upgrade process by Windows Setup.  This is baffling, because MSSE isn’t designed to work with Windows 10 (it doesn’t work), and plus, it precludes the use of Windows Defender, which is essentially the Windows 10 upgraded equivalent of MSSE.

If you’re in the same situation, you’ll also discover that it is impossible to remove Microsoft Security Essentials from Programs and Features; when attempting to do so, you simply receive a generic message which states “You don’t need to install Microsoft Security Essentials.”  That’s great, Microsoft, because we don’t want to install it, we want to uninstall it.

Anyway, the solution to this problem is actually quite simple:

  1. Press Windows Key + R to open the Run dialog.
  2. In the Open: field, type:
    • explorer “%PROGRAMFILES%\Microsoft Security Client\”
      and press ENTER.
  3. Highlight the file Setup.exe, right-click it, and choose Properties.
  4. Choose Compatibility.
  5. Click Change settings for all users.
  6. Check the box next to Run this program in compatibility mode for: and choose Windows 7 from the drop-down box.
  7. Click OK on all dialogue boxes to exit all windows.
  8. In the search box at the bottom of the screen, type cmd. At the top of the pop-up window, underneath the heading Best match, right-click Command Prompt and choose Run as administrator.
  9. In the Command Prompt window that opens, type the following command:
    • “%PROGRAMFILES%\Microsoft Security Client\setup.exe” /x /disableoslimit
  10. Follow the instructions to uninstall.

That’s it!

Special thanks to corrado_boy_g60 at the Microsoft Community for information leading to this solution.

SOLUTION: Malware extensions continually reload within Chrome even after reinstallation

Posted on by
Reply

Greetings again random internet-surfing technology enthusiasts,

Today, I’d like to tackle a puzzling issue that many techs encounter with regard to disinfecting Chrome and problematic extensions that manifest within it.  Of course, anyone with any technical expertise is aware of the fact that browser extensions are currently one of the hottest attack vectors for unsuspecting users’ machines, but removing and keeping such extensions from reloading is another matter entirely.  Some of examples of these include:

  • AdBlocker (not the legitimate and excellent AdBlock)
  • Vosteran Search
  • WebProtector
  • …and many, many others

Most techs use some degree of automatic scanning and removal tools, and that’s fine, provided they don’t rely on them exclusively (as it doesn’t work… something I’ve covered countless times in the past).  However, even those who dabble in manual or assisted-manual disinfection procedures have probably found that Chrome is one of the most problematic items to permanently clean on a user’s PC.  This is ironic because Chrome also happens to be the browser I recommend to my clients for safety and speed currently (and it has been for quite some time).  Does that mean that we should move on to a different browser choice instead?

Fortunately, nope.  There is indeed a pretty universal solution to this problem, and today I’ll reveal it to you.  For purposes of illustration, we’ll choose the third example extension I listed above for today’s explanation (WebProtector).

Each Chrome extension is affiliated with a unique identifier to help users locate and install the extension from the Chrome Web Store.  WebProtector’s, for instance, happens to be kfecnpmgnlnbmipaogfhoacoioifjgko.  The Web Store does indeed host this extension in spite of its fraudulence; and Google, for all their great work in producing a relatively safe browser in Chrome, have done a pretty terrible job of keeping the store cleaned of such filth.  The problem with WebProtector (and many of these other extensions) is that even after they’re cleaned from the computer and all other malware is removed, the users may find that they reload themselves regardless later on with little or no warning.  You might think that completely uninstalling Chrome, removing all directories on the system relating to Chrome, and cleaning/resetting the user’s Chrome Data profile (as I described in another post recently) should logically solve the problem.  But it doesn’t.  The extension yet again reloads itself upon future reinstallations.

The answer to the puzzle is Policies in the Windows registry.  Chrome stores its policies in the following two keys:

  • HKCU\Software\Policies\Google
  • HKLM\Software\Policies\Google

Under these keys you will find a subkey called Extensions; it is from this key that Chrome is instructed to load the infected extensions upon each reinstallation and subsequently thereafter at regular intervals.  Simply deleting these keys (provided the user is not reliant on any policies in Chrome for administrative purposes) will prevent the behavior.  At an elevated command prompt, try typing these commands:

REG DELETE “HKCU\Software\Policies\Google” /f
REG DELETE “HKLM\Software\Policies\Google” /f

Specifically, the autoinstall keys that are likely being used are:

HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForceList

HKCU\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForceList

However I like to remove the entire Policies key on most machines as other suspect keys are also often used, such as whitelisting of bad extensions and even blacklisting of good ones.

It also goes without saying that the extension itself must first be removed for this to work.  That includes killing the keys relating to it in the following locations:

  • HKLM\SOFTWARE\Google\Chrome\Extensions\
  • HKCU\SOFTWARE\Google\Chrome\Extensions\

As well as the associated files within the user’s Chrome User Data directory.  If you’re really just looking to clean sweep the entire program, you can follow my previous instructions to backup the user’s Bookmarks and other personal items and then simply wipe out all related keys and files after uninstalling Chrome.  This will finally solve the problem!

Poweliks: Widespread malware without a filesystem object

Posted on by
Reply

Preliminary note:  This process will normally remove Poweliks from a system.  However, Poweliks is merely a tiny fraction of what is usually also alongside it on an infected system; after all, it is a downloader.  So if you’re trying DIY disinfection, just be advised that there is a very good chance that your system is still infected even after this process by multiple other malware families.  I would advise hiring a professional in your local area to assist with the job instead of risking your personal information and data!

I’ve long been preaching that scanners just don’t do the trick as a universal, one-size-fits-all solution to malware, and that’s precisely because they can’t possibly catch everything.  The latest zero-day threats will always find a way to evade even the best antimalware tools in some capacity, and because of that, a complete reliance on scanners for either proactive blocking of threats or removal of existing embedded threats is misguided and will always run into trouble.

This latest threat, which has now been circulating for a few months, is a perfect example of this.  It’s called Poweliks, and it’s unique for one very specific reason: it infects the system without the use of a filesystem component at all.  Now, it’s not like this is the first threat to accomplish such things; before it, we had such interesting specimens as the TDL4 rootkit, which created a hidden, encrypted partition at the end of the drive containing the rootkit’s code, which was loaded at each boot before the Windows partition.  Eventually, however, this rootkit was identifiable (at least, somewhat) via the presence of a conspicuous (and suspicious) 10 MB or so empty space (RAW) at the end of a drive.  And it was easy to kill: simply delete that partition from offline and set the proper Windows partition as active.

Poweliks uses a totally different approach: it embeds itself in the system’s registry in an encrypted key that actually contains the body of the malware as opposed to mere settings and program data (as is intended for the Windows registry to contain).  The identity of the key has changed across variants, but the most recent one I’ve seen is:

HKEY_LOCAL_MACHINE\Software\classes\clsid\{73E709EA-5D93-4B2E-BBB0-99B7938DA9E4}\LocalServer32

What about symptoms?  Well, they’re not all that clear-cut.  The machine will certainly be slower than normal.  Apart from that, it may simply be generally infected, as that’s what Poweliks is all about: downloading other infections.  The problem is that you cannot search for a particular process in memory or even a file on the hard drive, as no file exists and the process is always a completely legitimate one.

However, at least as of currently, it is not random.  The most recent process which has been associated with Poweliks infections is dllhost.exe.  It’s a totally normal process, so seeing it running by no means indicates infection.  However, seeing it running persistently and for long periods of time is a bit more suspicious if you’re having other symptoms.  And if you close dllhost.exe using Task Manager and it repeatedly reappears in multiple instances, it’s a really suspicious scenario.  You’ll also likely see tons of other random (normally legitimate) processes running which should not need to be running.  These can’t be specified here as they are random.

For further diagnosis, however, you can download Process Explorer to inspect the genealogy of the processes that are currently running.  It’s a dead giveaway: if dllhost.exe is launching dozens of other processes, you know it’s Poweliks.

Removal

This isn’t so bad at all if you know how to tackle it!

The easiest way to handle it is to prepare with a tool that can handle removal first.  In this case, I recommend RogueKiller.

NOTE:  This tool isn’t to be used lightly, especially by those who aren’t thoroughly familiar with computer repair.  By design, it is heavy on false positives, so take care when agreeing to remove what it flags as suspicious.

Try the following approach:

  1. Open RogueKiller; allow the prescan to finish.  Run a scan.
  2. Once the scan completes, look for its detection of Poweliks on the Registry tab.  Be sure it is selected for removal.
  3. Open Process Explorer.  Pause all dllhost.exe processes.  Kill all processes below any dllhost.exe process once the processes have been paused.
  4. Click Delete on the RogueKiller window and immediately reboot the system.

With any luck, upon reboot, the malware will be gone.  By pausing the process with Process Explorer, you essentially negate the malware’s ability to detect its neutralization via watchdog processes that relaunch the dllhost parent process after it’s killed.  That enables disinfection to take place before the malware is relaunched and the registry key is reinfected.

Of course, to repeat myself, keep in mind that Poweliks is merely a tiny fraction of what is usually also alongside it on an infected system; after all, it is a downloader.  So if you’re trying DIY disinfection, just be advised that there is a very good chance that your system is still infected even after this process by multiple other malware families.  I would advise hiring a professional in your local area to assist with the job instead of risking your personal information and data!

CryptoLocker: UNdecryptable file ransom—How to recover

Posted on by
1

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.

SOLUTION: “This is Microsoft Support” telephone scam – Computer ransom lockout

Posted on by
219

A trend of the past couple of years has been for scammers to contact computer owners directly via telephone in the United States in an effort to convince them that there is a problem with their PC and they’ll need to pay to have it fixed.  In general, these people cannot fix anything, and instead they merely charge exorbitant fees for absolutely nothing. In other words, they scam you.

The call generally goes something like this:

  1. A foreigner with a thick Indian accent identifies himself as a member of Microsoft Support or similar.
  2. He informs you that you have a number of critical problems with your PC and that you will need to have it fixed.
  3. To convince you, he offers to connect remotely and pulls up your Event Log (eventvwr.msc).  He then filters for Warnings, Errors, and Critical events and uses that as evidence that your PC will soon fail to work correctly if you do not pay him to correct it.

The astute among you have probably already sensed that something here is seriously wrong, and it’s not your PC. It’s the fact that someone is calling you to tell you there is a problem with your computer. No one will ever do that. The only way they could possibly know there is a problem is by hacking or guessing.

In this case, it’s mere guesswork, and it’s not even correct most of the time. The Event Log is supposed to log warnings and errors, and even on the healthiest of PCs there are plenty of Error Events that can be safely ignored, as they often don’t amount to anything. The important thing to remember is to never trust someone who calls you about a problem with your PC, and never, EVER let them connect remotely to your PC.

If you do make the mistake of letting them connect, but then you happen to get cold feet and refuse to pay the $180+ they request via credit card, the next thing that happens isn’t pretty. This scammer proceeded to actually follow through on his promise of the PC “not working” if they don’t agree to have him fix it, and so in a few quick steps, behind the user’s back, he enacted what is known as SysKey encryption on the SAM registry hive.

SysKey encryption is a little-known feature of Windows which allows administrators to lock out access to the Security Accounts Manager (SAM) registry hive so that login specifics cannot be stolen and the PC cannot be accessed without knowing the proper credentials. The problem is, unlike other scams, there is no way around the problem; you can’t simply remove the password, as the actual SAM hive has been encrypted entirely by the process. If your Windows installation has had SysKey activated, you’ll see the following message:

Startup Password

This computer is configured to require a password in order to start up. Please enter the Startup Password below.

The window which appears looks like this:

This computer is configured to require a password in order to start up. Please enter the Startup Password below.

The ONLY solution is to find a clean copy of the registry hives from before this occurred. This scammer knew this, however, and as such, he took an extra step to block any repair or recovery attempts: he deleted all System Restore points on the machine, which normally house backup copies of the registry hives.

Unfortunately for him, I’m a much better technician. When the customer suspected foul play and decided to call me instead of proceeding, I immediately instructed them to power off the PC. Here’s how I fixed the problem without having to reinstall Windows.

FIRST, ensure you don’t have any Restore Points to work with:

  1. Check to ensure that the folder %SYSTEMROOT%\system32\config\RegBack exists.  This is the folder which contains the last known good backup of the hives following a boot.  If it exists, continue.  If not, stop and consider contacting a technician instead.
  2. Reboot the PC and repeatedly press F8 to reach the Advanced Startup Options menu.
  3. Choose Repair your Computer from the menu.
  4. Cancel the automatic repair attempt and instead instruct the system to perform a System Restore to a date prior to the incident occurring.

If no Restore Points exist, your scammer intentionally removed them to prevent this from occurring.  If this happens to you, follow these additional steps to resolve the problem:

  1. POWER OFF your PC immediately.
  2. Boot to external media of some sort (NOT your Windows installation) and navigate to the %SYSTEMROOT%\system32\config folder.
  3. Backup the registry hives in this folder to a temporary location. The files are:
    1. SOFTWARE
    2. SYSTEM
    3. SAM
    4. SECURITY
    5. DEFAULT
  4. Navigate to %SYSTEMROOT%\system32\config\RegBack as mentioned earlier.
  5. Copy all registry hives from this folder (the same files as listed above) into the %SYSTEMROOT%\system32\config folder.
  6. Reboot the PC.

This solution only works if you have not already tried to reboot the PC subsequently.  If you have, it may still work, but that is entirely dependent upon whether or not Windows created a new RegBack copy following a successful boot.

In the case of my customer, it worked, and they were back in Windows, just like it never happened.  Nice try, scammer.  You’ll have to try harder to beat me though. 🙂

Addendum A (update 6/26/2015):

Thanks to FUScammers for pointing out this more involved, alternate method of actually removing the SAM encryption.

  1. Download this file and burn the .iso to a CD.
  2. Boot to the CD on the affected system.
  3. Follow the instructions to select the proper system drive and partition (NTFS is the partition type you are looking for).
  4. Type the path to the registry files (it’s most likely Windows/system32/config).
  5. Choose option 1 for Password reset (sam system security).
  6. Choose option 2 for Syskey status & change.
  7. Confirm that you wish to disable Syskey, then quit and confirm writing the new changes to the hive.
  8. Reboot the PC and check.

For more detailed instructions, check out this link (scroll down to “How to disable Syskey startup password”):

http://computernetworkingnotes.com/xp-tips-and-trick/remove-administrator-password.html

In Windows 8, the GPT partition type makes the use of this utility impossible.  However, you can still manually copy the hives to a supported filesystem (NTFS or FAT32), mount that filesystem instead, and follow the steps from there, then copy the hives back over the originals.  I can confirm that this method does work and that even in Windows 8.1 recovery is possible using it.

Solution: Repair damaged/missing services following malware infection

Posted on by
Reply

Many times, following a nasty infection (such as that of various rogues or rootkits), you might notice that some of the critical Windows services are missing (such as the Security Center or Windows Firewall), or that Windows seems to be devoid of some typically critical functionality (such as Windows Update).  Apart from the obvious corrective measures that often must be taken post-disinfection (such as reinstalling any security software which might have been damaged), repairing system components can be much tougher.

Today, I’ll focus specifically on how to detect/repair some of the most commonly damaged services following an infection.  The four most commonly-damaged services are:

  • BITS (The Background Intelligent Transfer Service)
  • wscsvc (The Windows Security Center Service)
  • (not present on XP) BFE (The Base Filtering Engine Service)
  • (not present on XP) MpsSvc (The Windows Firewall Service)

It’s easy to understand why these services specifically are targeted by infections: all of them are potential threats to the malware, as they deal directly with Windows’ ability to protect and update itself.

The easiest way to detect missing or damaged services is to run these commands at the Command Prompt:

sc query bits

sc query wscsvc

sc query bfe

sc query mpssvc

As mentioned above, the bottom two services don’t exist on XP.  You can also script this using batch like so:

echo Checking for damaged Windows services...

sc query bits|find "The specified service does not exist as an installed service.">nul&&( echo BITS Service [BITS] does not exist )

sc query wscsvc|find "The specified service does not exist as an installed service.">nul&&( echo Security Center Service [WscSvc] does not exist )

sc query bfe|find "The specified service does not exist as an installed service.">nul&&( echo Base Filtering Engine Service [bfe] does not exist )

sc query mpssvc|find "The specified service does not exist as an installed service.">nul&&( echo Windows Firewall Service [MpsSvc] does not exist )

If any required services return an erroneous response (i.e., “The specified service does not exist as an installed service.”) then it’s pretty clear that damage has been done by the infection which requires repair.

At this point, you have to first check to ensure that the relevant system files for each service are still intact.  The easiest way to do this is to perform a sfc /scannow operation at the command line (run as Administrator) and ensure that any damaged files were successfully repaired.

Next, it’s generally as easy as reimporting the default registry keys corresponding with each missing service.  This isn’t difficult once you find a reliable location to acquire those keys.  The best place available is currently BleepingComputer.com’s Index of Windows Services.  Simply choose the folder which matches your operating system, select the name of the damaged/missing service, download the file, and import it into your registry.

After this is finished, you’ll still need to set each service to its default Startup type.  The easiest way to do this is to simply type each of these commands at the Command Prompt (again, running as Administrator):

sc config BITS start= delayed-auto

sc config wscsvc start= delayed-auto

sc config BFE start= auto

sc config MpsSvc start= auto

Again, it bears repeating: the final two services don’t exist on XP machines.

After completing these steps, reboot the PC and see if everything’s working again.

In a later post, I’ll cover Windows Update repair procedures, permissions resets, and plenty more techniques to help repair damaged systems following infection.

Change your router’s login information

Posted on by
Reply

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!

“SafeBoot is corrupted (92h)” when McAfee Endpoint Encryption is installed

Posted on by
15

Here’s a rare example of a situation where I was actually very close to contemplating a reformat before finally stumbling across an idea which led to its resolution.

The client was an employee of a large company whose laptop hard drives (like many) are encrypted using McAfee Safeboot (Endpoint Encryption).  This is a great strategy for protecting against data theft in the event that the machine is stolen, but like all data encryption, any sort of problem whatsoever with regard to either data integrity or the encryption/decryption process can be potentially disastrous.

Since SafeBoot/EE is a boot sector encryption (“pre-boot authentication” it’s called) which applies to the entire storage volume, any problems relating to its boot partition information can completely break the entire system until either the information is repaired or the volume is manually decrypted.  Fortunately, McAfee provides a method for decrypting volumes offline using a special boot CD (called SafeTech/WinTech, depending on your version) and a rolling Authorization Code which changes daily.  Unfortunately, they only make these tools available directly to clients… meaning that us independent techs are completely out of luck, even if we have the decryption key (which the customer provided me).

While I was able to bypass the rolling Authentication Code by adjusting the system’s date to a specific day years back and using a code I found posted on an online forum, the built-in tools and even a SafeBoot Admin CD I located weren’t helpful in resolving the issue.  We had already tried contacting the IT department, who says they had no such tools at their disposal and that a reformat would be necessary.  Worse yet, my client was only in Louisville on a brief business trip, and there was data they needed on the encrypted volume.

The next morning, I had planned to contact the customer and suggest that we do just that: reformat.  But on a last-minute whim, I stumbled across an idea which could perhaps explain the strange behavior we were experiencing.

If you Google the Safeboot 92h error, you’ll find a variety of reasons why it can occur, and plenty of situations where it was never properly resolved.  Reverse-engineering the situation in my mind, however, led me to an important point which I had almost disregarded in the midst of my desire to quickly resolve the situation and return a working PC to my busy traveling executive: the possibility that malware had triggered the problem to begin with.

You see, the very first step I performed was a drive image of the encrypted data for safety.  And I had noticed that, throughout the course of the imaging process, no read errors/bad sectors had been encountered.  For surety, I even performed a hardware diagnostic subsequently, and no memory or hard drive errors were found.  This means that the encryption probably had not failed due to a hardware issue, and that instead, some sort of software was likely to blame.  Malware is the perfect culprit here; most notably, boot sector rootkits, which specifically alter the MBR and/or partition information of a victim’s machine to provide a filtering mechanism for the malware where it is also entirely undetectable.

One such rootkit you’ve already seen me write about in the past: Rootkit.Boot.Pihar.B.  It creates a hidden, encrypted partition at the end of a drive and sets it as the main Active partition, after which it chainloads the operating system partition (which is set as Inactive by the rootkit).  This effectively allows the rootkit to leave the MBR “clean” by storing all code in its encrypted partition and then loading the OS normally afterwards.  While this rootkit wasn’t currently detected as active on my client’s system (using an offline TDSSKiller run), after booting to a partition management software, I found that the hidden/encrypted partition was present.  And the OS partition, predictably, was Inactive.

It was just that simple.  Setting the OS partition as Active and then booting normally did the trick.  Following that, I had plenty of malware cleanup on my hands, most of it related to a rogue which had piggybacked on the rootkit.  This was a lot of fun since the machine’s Administrator restrictions and policies stood in the way, but in the end, the machine was repaired, all data was recovered, and my client was happy.  That is, until he returns to his hometown, where he’ll then request an updated Windows 7 machine to replace this dinosaur. 🙂

Solution: Remove startsearcher.com Google Chrome search hijacker

Posted on by
8

Today I encountered an irritating Google Chrome search hijack which wasn’t removable via the usual methods.  Attempting to remove the rogue search engine via the Chrome options menu simply produced a yellow bar at the top of the screen which read:

Some options are managed by your administrator.

Even completely uninstalling Chrome and removing the existing User Data folder under Chrome’s AppData directory didn’t fix the problem.

Shortly thereafter, however, I discovered another location where Chrome settings can be preset/mandated: the registry.  Specifically, two locations:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome

and

HKEY_CURRENT_USER\Software\Policies\Google\Chrome

The specific keys which needed deletion in this case were:

  • DefaultSearchProviderName
  • DefaultSearchProviderSearchURL
  • HomepageLocation
  • HomepageIsNewTabPage

I had to remove them from both registry areas.  But after this, the problem was gone.

If this post has helped you, please take a moment to leave a comment!