Did You Know? ... or ... What Is Normal?

We all know that in Windows, explorer.exe (the user shell, graphical file system interface) is the parent process to applications launched by the user, such as Internet Explorer, (iexplore.exe).  That's normal; we all know it, and it looks a little something like this:

That's great and all, but did you know that's not always the case, at least in the matter of iexplore.exe?  Sure, of course you did.  Maybe you haven't thought about it before, but you do know.

What happens when you're on a 64-bit system, and launch the 64-bit version of Internet Explorer?  Did you note the drop-down arrow next to it in the screenshot?  Well, that looks a little something like this:

First, there's the "parent" iexplore.exe (pay no attention to the changing PIDs, please).  Path is "Program Files."  But then the "child" iexplore.exe; path is "Program Files (x86)," indicating this is a 32-bit spawn of (well, you know...) which thus means that the parent is 64-bit.  So, a "new" "normal," then?

   

                  

And of course you realize that if IE is the default browser, and hasn't been launched when you click a link in an email application (such as Outlook), then Outlook will be the parent of IE, rather than Explorer.  Another normal.  You get it.  Here's how that pans out:

So, the user clicks a link in email (outlook.exe), which then spawns the browser (iexplore.exe).  Just as I noted above.  What's cool here is that the command-line parameters (on the right in the screenshot) show where the user was being taken.  Good stuff.

So anyway, the other day I thought I'd do some digging into all the times that Explorer is NOT the parent of IE; partly I wanted to challenge my knowledge, but also to see if I had an opportunity to find any evil, or build query filters that would help separate the signal from the noise for evil in the future.  I ran some queries to find all instances of IE in my environment, where Explorer was NOT the parent process.  There are actually quite a few, you might be surprised.  The predominant ones were:  iexplore.exe, svchost.exe, and outlook.exe.  Okay, we've already discussed the first and last of those, but the middle?  Do what?

First, let's revisit the first one, because this is not the same as above; this is 32-bit on 32-bit action at its tabular best:

Parent process is on the left, child on the right.  Then on the right in the middle, you have the SCODEF and CREDAT references, which indicate an IE tab.  SCODEF points to the PID of the parent.  If you look back up at the ProcessHacker screenshots above, you'll see the parent IE is PID 7760; this is referenced by SCODEF for the child process.  And it's not just me, covered in Cheetos (R) dust, making this stuff up.  Here's a reference (granted, for IE8) from MSDN Blogs. 

SVCHOST!  SVCHOST!  WE WANT SVCHOST!  

Yes, yes, I promised you svchost.exe as a parent to IE.  Now, let's pause for a second and remind ourselves what is normal for svchost.exe, too.  While there may be multiple instances of svchost.exe running at any one time, the parent will always be services.exe.  That's normal, and we all know it.  Okay, remember that.  There is a scenario, which if you've spent some time reviewing the SANS DFIR Find Evil poster you are aware of, wherein IE can be started via the command-line "-embedding" parameter; in this instance, the parent won't be explorer.exe.  Looks like this:

That -embedding switch is over on the right, and as you see on the left, the parent is svchost.exe.  Done, right?  No, not quite yet.  Take a peak at what's next...

What we're looking at here is just a wee bit different.  This isn't so much about IE, although that's come into play, too, but more to the point of svchost.exe, and it's parent.  If you see a parent other than services.exe, you may start getting concerned about malware.  Then you see rpcnet.exe, which sounds legit (ish), but still isn't normal, and you're probably more concerned about malware, since malware often uses names similar to legit names, so as to look "normal."  In addition, this rpcnet.exe is signed, and we all know that signed code is used to bypass detections in antivirus, HIPS, and other products.  So, is this malware?  

Well, opinions might vary, and it certainly behaves like malware.  However, it is - in this instance - normal and legit.  It's actually associated with embedded tracking software to help deal with stolen computer assets.  Of course, while I might "know" that, someone could be trying to get one over on me by masquerading their malware as a process I'd expect to see, so how could I further verify that?  If you know anything about this tracking software, it's not designed to be "normal" and is difficult to validate - it really truly does operate very much like malware.  So I'd most likely have to turn to other sources of evidence, possibly even packet captures, to see where it was going and how it was communicating.  If you want to know more about why validating your findings and being able to do so from multiple types/sources of evidence, come to my talk (To Silo, or Not to Silo: That is the Question) at the SANS DFIR Summit in Austin this June.  

Anyway, the SANS DFIR Find Evil poster talks about knowing what "abnormal" is, but in order to know that, you have to know what "normal" is.  Old story, but that's the same way people are trained to spot counterfeit money - know what "good" money looks like, to be able to spot what's not.  When it comes to normal with computers, and especially in enterprises, there are "global" norms and "environmental" norms.  The globals are things like the 32-bit spawn from the 64-bit parent IE, the SCODEF references for child tabs (which includes the home page, by the way), and Outlook links spawning instances of IE to reach the websites.  Environmentals aren't out to save the computer, but are things like tracking software sitting in between services.exe and svchost.exe.  If you know what those are for your world, you'll be much better off when it comes to finding evil, and separating the signal from the noise.

Happy Hunting!