Rumpo Venatus

Rumpo Venatus

  • Comments 1
  • Likes

The five or six people who have read my little bio snippet on Technet read that I like to play video games-specifically Xbox 360 games. I was doing just that the other night-playing Fallout 3-when my wife walked into the study to ask for help with all of the viruses which had just been detected on her laptop.

The gaming was interrupted. A wise married man makes sure his wife’s computer is working. Marital sanity is preserved using this and other fundamentals.

In this blog post we’re going to talk about what was going on in my wife’s laptop and how I fixed it.

Now, most of my blog posts revolve around server specific issues or information in the Microsoft Directory Services world-you know, AD, and the like. But this little diversion highlights how you use a really cool tool in a practical way that can be applied to many different troubleshooting situations. It’s also may be useful from the viewpoint that your average Directory Services specialist is typically also a security specialist at his or her office.

To sum up the issue, the laptop was infected with malware. I don’t know the specific vector that did it-probably some socially engineered link with a picture that looked exactly like something legitimate she clicks on usually-but it was obvious as soon as a looked at it that there was malware involved. Several Internet Explorer (IE) windows were open, several of which mimicked anti-virus detection software user interfaces. They had big warning messages that viruses had been detected and encouraging the user to click on buttons-buttons which were in fact hyperlinks to other places.

Rather than delve into how it got onto the machine I needed to move quickly to remove the malware from her laptop so that I could reconvene my adventure into the post-apocalyptic world of Fallout 3.

To do that I had to figure out how the IE browser was getting “hijacked”. It was apparent that-even with a new logon session or as another user on the same computer-all I had to do was open the web browser to the home page and after a few moments these uninvited pages would open on their own. So, nothing the user did at that point instigated the problem…other than simply opening IE. Clearly, something was happening in IE.

Let me take a quick moment to point out that this malware concern was seen on Windows XP (with the latest service pack and security fixes), not Vista. I seriously doubt this could occur with Vista’s builtin security-contrary to what slick Apple marketing says.

To find out more about what was happening within IE I downloaded Process Explorer. Some of the less commonly used things which Process Explorer can do is to show the threads for a process and their call stacks (think of this as information about what code has recently “fired off”), the open handles a process has, and what DLLs a process has loaded. These are exactly what was going to come in handy here.

Since I knew IE was there as a process I went to that in Process Explorer’s left hand pane and selected that process’ properties. I then clicked on the Threads folder tab so it was in front. What you will normally see when looking at this sort of thing is an “image name” and memory addresses. The image name really amounts to being the file name. Handy info, that, since we wanted to see if there were any questionable looking image names in any of the IE process thread’s call stacks.

And there were.

naughtcode1

Clicking on the stack button after highlighting a suspect thread doesn’t show a great deal more but it is interesting.

naughtycode2

So it looks like the malware is running from code stored in the file named “__c00817F6.dat”. It’s a safe bet that this file name changes frequently as an effort to elude anti-virus definition files catching it when they scan the computer after a definition file update.

A search in Process Explorer shows that winlogon loads this as a DLL and so has a handle to this file, suggesting that it is loaded when winlogon.exe starts. Since winlogon.exe is a core user session file (basically) that means this file will load anytime someone logs on with an interactive session.

Process Explorer Search

Note: You’ll notice an Explorer.exe handle to this suspect file as well. That’s because I searched in Windows before I searched in Process Explorer.

So we have a suspect file. Now what? Well, it’s time to find where the file lives since we’re ultimately going to want to delete it.

Windows Explorer Search

So the file has an innocuous name and resides in a place where legitimate Windows files are: c:\Windows\system32. OK, delete that bad boy!

For this case, attempts to delete that file will fail. There are three obvious reasons this can fail: permissions on the file, there is an open handle to the file, or the file is loaded as a DLL and so is in use and cannot be deleted.

From the above Process Explorer search we can tell that there is both a handle open to the file and it is loaded into memory as a DLL, so those two things are going against us for deleting the file. A quick check of the permissions on the file show that we should have sufficient rights to delete it.

So now we have to figure out how to keep the file from loading at logon. For that we have to consider how things are called to be loaded in the first place. That is typically done by looking to the registry entries for that process and seeing what files are listed for it there.

Here’s where we look for Winlogon.exe’s relevant entries, and our suspect is present.

Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\__c00817F6

This registry entry has five values:

Name: Asynchronous

Type: REG_DWORD

Data: 0x1

Name: DllName

Type: REG_SZ

Data: C:\WINDOWS\system32\__c00817F6.dat

Name: Impersonate

Type: REG_DWORD

Data: 0x0

Name: Startup

Type: REG_SZ

Data: B

Name: Logon

Type: REG_SZ

Data: B

The first thought is “delete the registry entries!”. Unfortunately, the malware developer thought that someone might want to do that, too, and so they apparently have code to add the registry entry and it’s values back.

However, we can be clever here. In this case I simply change the DllName registry value data for the path of the malware to have a different name, and then quickly place registry permission Deny entries for everyone on that registry entry. That way the bad guy can’t change it back.

Then reboot, logon and viola! we can delete the __c00817F6.dat file. Now my wife can surf the internet tubes in peace.

Back to Fallout 3 at last! Game on!

Let’s file this under security, though the general Process Explorer technique above can be used for a lot of useful situations.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment