Like This Blog 0

Added by Mike Danseglio August 7, 2015

This post is an excerpt from a previous webinar – Live Detailed Forensic Investigation of Malware Infection with Mike Danseglio. April 21, 2015.

You can watch the replay of this webinar on our website Detailed Forensic Investigation of Malware Infections.

In this webinar, Mike Danseglio setup three computers with a fresh installation of Windows 7, each with their own user scenarios to convey how easy it is to accidently install malware on their system.

During the webinar, Mike answered participants question and provided some step-by-step methods people can take to identify if they have malware on their computers.

This post begins at approximately 34 minutes into the webinar.

After malware has infected a system, how can we see what’s going on behind the scenes?

Mike Danseglio: All right. I took the liberty bringing up this particular Task Manager.

I actually added the Command Line column to Task Manager because I wanted to see where all of this malware is launching from.

You’ll notice that we’ve actually got a bunch of different software launching from different locations.

Program Files is typically where apps install but apps install based on the “honor system” most of the time. They don’t have to install in Program Files.

This app, the third one down, “node.exe” did not install in Program Files.

It actually installed under the User Profile. It actually installed under the Admin User Profile. It’s the OkayFreedom application and it’s an executable is called, “node.exe.”

We’ve actually got a bunch of different apps here.

My favorite technique for using this particular window of Task Manager in malware forensics is actually to just sort by command line. Why? Because anything that’s generally (generally but not universally) that’s in Windows is probably going to be something I want to have. It’s less interesting to me. It’s not immune or perfect, but less interesting to me.

Anything above that, anything that’s loading at a Program Files, x86 or Program Files, which, if you have a 32‑bit system, you won’t see x86, you will just see them all as Program Files. Anything that’s loading in Program Files are all suspect. These are all things that loaded up. I haven’t done anything since the machine booted. These are all things that loaded at boot time and are running currently.

I can immediately see that I don’t want most of the stuff that is up here.

There’s even a USTechSupport/PC Optimizer. I haven’t even got it into the fact that there’s a live tech support thing going on in the machine.

Let’s look at killing one of these. You may think, “Well, I can remediate that. I’ll just kill the process….” It’s not that simple. Let’s get rid of GeekBuddy.

Let’s get rid of Driver Update.

Wait, I thought I got rid of GeekBuddy. Hold on. Let me right click it again and choose, “End Process.”

I could have sworn that I just got rid of GeekBuddy like 10 seconds ago. What an interesting coincidence that it has launched itself again, and again, and again, and again, and again.

There’s GeekBuddy reminding me that it launches itself. It’s taunting me, teasing me.

How does that happen?

How does this app keep getting killed and then launching itself? There’s a bunch of different ways that software can actually hook itself. It could be a restart on crash service. It can actually be a scheduler thing. It could be a separate process that’s watching for the existence of GeekBuddy as a process or a service, and if it’s failed, will re‑launch it automatically.

There’s a bunch of places in the registry that we can actually hide entries that will tell Windows, “This thing has to be running all the time, and if it isn’t, launch it again.” We can tell Windows to do that, or the software can manually do it, or both. I would wager since GeekBuddy is so persistent and so quick, it’s probably doing both.

We can try to kill these things. Actually, the hallmark of malware, typically, is the fact that it likes to be persistent. It likes to come back to itself over and over and over again. Is that bad? Yeah, that’s actually really, really, really bad.

How does malware disable anti‑malware software?

Windows is a layered modular operating system. We have the Win 32 apps. The typical 32‑64 bit apps that run up here.

We have some other modules that sit down here.

Then, we have User Mode and Kernel Mode.

Here in the Kernel we actually have services, like Service Control Manager (CTRLMGR), File System, GDI, the graphics display and a bunch of IO, etc…..

Under that, we have Kernel and the Hardware Abstraction Layer (HAL).

Finally we have the actual hardware.

This is not a perfect description, but this is good enough for this conversation.

Everything above the hardware layer is software, everything.

If you’ve got a malware scanner running here…

Let’s say you have, at this layer, you’ve actually got Semantic running up here as a Win 32 app or as something that plugs directly into Win 32.

If the malware plugs in down here, let’s say as a service.

As a Kernel Mode Service, the malware can actually affect anything higher up on the stack than itself. It can actually either fool Symantic, and tell it “there’s no malware here”. Everything is a notepad text document with ‘hello’ as the only content,” or it can actually kill processes and services that are running above it.

The question is how deep did the malware infect the system? The deeper it gets infected, the harder it is to remove, the harder it is write, and the easier it is to actually fool the anti‑malware software or uninstall it, or disable it entirely.

You can watch the replay of this webinar at Detailed Forensic Investigation of Malware Infections..

Mike Danseglio – CISSP, MCSE, and CEH

Mike Danseglio teaches IT Security Training, Windows, System Center and Windows Server 2012 classes at Interface Technical Training. His classes are available in Phoenix, AZ and online with RemoteLive™.