Rundll32 Exe Process Information In Critical Thinking

(Editor’s Note: the following blog post appeared on on September 10, 2013. We’re reposting it today because it remains an outstanding example of the detection value that Carbon Black provides.)

In a blog post, Raffi asked: “Why is notepad.exe connecting to the Internet?” He pointed out that Metasploit and Cobalt Strike use notepad.exe as a default target for process injection.

I thought this was a clever idea, so I used Carbon Black to validate notepad.exe processes with network connections as an indicator of compromise. Out of 37 million processes, I found 10 instances of notepad.exe with at least one network connection. Nine of those were legitimate connections to a networked printer, but one was not.

Carbon Black is great for tasks like this because it lets you test crazy ideas with zero friction:

I tested the theory with data from a medium multinational enterprise with about 1,000 hosts. Their Carbon Black server has recorded execution of 37 million processes over the last 83 days.

In that timeframe, there were 10 instances of notepad.exe with more than one Internet connection:

Nine of those were legitimate, but one stood out:

That’s a process that calls itself notepad.exe, so a quick review of the process list in Task Manager won’t show anything unusual, but not only is the full path out of the user’s %TEMP% folder, the icon looks as if it was hand-drawn in Visual Studio’s built-in icon editor! (Hey, malware author! Your hand-drawn image that looks like bad 8-bit graphics stands out more than the default Microsoft icon.) This process, which calls itself notepad.exe, is clearly worth investigating.

The process tree makes the process look more suspicious. In fact, it nearly confirms the process is malware:

The “notepad.exe” process instance is a child process of java.exe, which itself is a child process of iexplore.exe, via the intermediary jp2launcher.exe. This is the time when the Tier 1 helpdesk or monitoring staff can call this an incident and pass to Tier 2 IR staff for review and action.

As a Tier 2 responder, I want to find answers to three critical questions:

  • What was the original infection vector?

  • How do I remove the malware? Where is the “real” malware binary? How does the malware gain execution at reboot?

  • What is the attacker’s objective? Is the malware targeted or opportunistic?

In addition, I’d like to know unique techniques I can use to recognize this malware in the future. Let’s take these one at a time.

Original infection vector

jp2launcher.exe was launched at 2013-08-05 10:40:37 GMT:

The user launched java.exe with md5 d2ae56ceafd824ca022164a79fcb2f5c, which is Java version 6.0.31, released on 14 Feb 2012. There are more than a hundred critical security fixes since.

Immediately preceding the launch of the JRE, Internet Explorer made a network connection to an ad network:

Walking back to the first “top level” network connection in Internet Explorer, we discover a link to the user’s local news station. This occurred shortly after launching the browser:

This implies the following chain of events:

  • 10:40:01 GMT – user opens IE

  • 10:40:05 GMT – user surfs to his local news station’s website

  • 10:40:31 GMT – a malicious ad is loaded from a third-party provider

  • 10:40:31 GMT – the malicious ad exploits the user’s unpatched Java

Malware actions

Shortly after startup, java.exe connected to, created a file named notepad.exe in the user’s temporary directory, then launched it as a child process:

The malicious notepad.exe then created another binary, wow.dll, in the user’s temporary directory. It also created a wow.ini alongside the binary:

The malware then wrote to an InprocServer32 registry key:

This is one way malware can gain execution at reboot: by overwriting the COM server registration DLL for a Class ID (CLSID) of a system COM object. The CLSID {fbeb8a05-beee-4442-804e-409d6c4515e9} is associated with Explorer.exe’s ability to burn to optical media, and is itself not malicious. Adding an entry for this CLSID in HKCU means the new, malicious entry takes precedence over the valid machine-wide setting for this user. Each time explorer starts, it will load the COM object for burning CDs, which will, in turn, load the DLL responsible. Since the malware has changed the responsible DLL, the attacker’s new wow.dll will get loaded instead of the expected shell32.dll.

The malicious notepad.exe then launched two child processes:

The first child process was rundll32.exe, with the following command line:

rundll32 c:\users\xxx\appdata\local\temp\snafpmu\sxbncta\wow.dll,0

This immediately executes the new wow.dll, so the attacker does not have to wait until Explorer restarts.

The second child process, an alternate data stream on itself, was called del. After startup, it completed only one action: to delete the original notepad.exe:

This is a clever and unique self-delete technique. Malware authors frequently remove binaries to thwart forensics analysis, but Windows does not allow the deletion of any file loaded for execution, so malware must jump through some hoops to do so. There are a number of techniquesout there, but none mention the use of alternate data streams. Deeper analysis of just this technique could fill another blog post!

In summary, the malicious notepad.exe performed the following major actions:

  • Created wow.dll and wow.ini

  • Wrote to the InprocServer32 registry key to gain execution at reboot

  • Launched wow.dll via rundll32

  • Self-deleted using a relatively obscure technique with alternate datastreams

Attacker’s objective

By searching for the md5 of wow.dll, we can find all processes that loaded the malicious binary:

These are sorted by process start time. In addition to the already-known notepad.exe and rundll32.exe, wow.dll was only loaded in two other explorer.exe processes: the first was the explorer.exe that was running at the time of infection, the second was started about an hour later after the user rebooted his system.

Reviewing the activity of each explorer.exe instance, it demonstrates an unusually high number of network connections:

Reviewing a sampling of that network traffic reveals the intent of the attacker:

In the space of an hour, the malware made thousands of HTTP connections to various ad-related websites, strongly implying click-fraud.


On 5 Aug 13 at 10:40 GMT, the user surfed to his local news station’s website. The user was running JRE6 update 31, released 18 months prior. A compromised ad provider served a malicious java applet, exploiting the user’s vulnerable software. The malicious applet created a file called notepad.exe in the user’s temp folder then launched it. “notepad.exe” created wow.dll in the temp folder, added it to the InprocServer32 registry key and then deleted itself. wow.dll was loaded by explorer.exe and was used as part of what appears to be a click-fraud operation.

Where was Antivirus?

The infected host runs Trend Micro. At the time of this writing, the malicious notepad.exe is only identified by six of 45 antivirus products. The malicious wow.dll is only identified by nine. TrendMicro is not alerting on either, but neither is Symantec. Kaspersky and McAfee alert on one but not the other. Most don’t alert on either.

Endpoint antivirus limits the effectiveness of your protections to the opinion of one antivirus provider, but Carbon Black gives you a consensus opinion. With its out-of-the-box watchlists, Carbon Black will notify you as soon as four or more vendors decide a binary is malicious.

Additionally, it does not matter which malicious binary exceeds the threshold. In fact, since Carbon Black stores the relationships between processes and records their actions, any alert on any indicator – even an IP address from your network firewall – will allow you to detect the activity and make an intelligent response.

So WHY is notepad.exe connecting to the internet?

Because it’s connecting to your networked print server…that’s why. What?

Remember, we saw that there were 10 instances of notepad.exe’s with more than one internet connection:

With an air of anticipation, I reviewed each hit, only to rapidly discover notepad.exe makes legitimate network connections all the time: when a user prints to a networked printer. Here’s a typical profile of one of these network-active notepad.exe processes:

For this notepad.exe instance, the parent was explorer.exe. Explorer’s other child processes were consistent with typical user behavior, though this user didn’t leave Outlook and IE running all the time like I do – but instead closed the applications completely after each use, resulting in multiple outlook.exe child processes from the same explorer.exe.

Explorer’s parent was userinit.exe, userinit’s parent winlogon.exe — all consistent with Windows startup.

Reviewing the process activity, there are the typical DLL loads recorded immediately following process start, consistent with any typical win32 process:

The network connection occurred a few minutes later, at 14:56:31 GMT (about 7 minutes after process start):

The time difference alone is a critical indicator this is not malicious behavior: if notepad.exe was used as a target process for Metasploit (or any other attacker’s) code migration, the network connection would occur immediately following process start, to establish positive control with the attacker’s C2 server before shutting down the network connection from the originally exploited process.

So why did notepad.exe make the network connection, even if it is not malicious? A quick review of the other events that occurred at/near the time of the network connection make it clear: the user read the document (for about 7 minutes, I’d say), decided it was worth printing and printed to a networked printer:

At the same time of the network connection, notepad.exe loaded a printer driver (with md5 47bf1480075ff019fec33c8eeae97d58) and writes to several printer-related registry keys.

This network profile does not apply to all network printers. In an enterprise environment via a typical Microsoft print server, the network traffic would be via SMB on tcp/445 and not originate directly from notepad.exe but spoolsv.exe. However, Microsoft provides a framework drivers may use, but neither the customers nor the printer vendors are limited to Microsoft’s network print framework. A printer driver (and customer) is free to implement their network infrastructure however they choose.

This clearly implies the network traffic is legitimate network print traffic. If you’re a suspicious type and that DLL makes you nervous, Carbon Black links the md5 of the loaded DLL to a binary detail page. The contents there are consistent with a Xerox printer driver:

In addition to basic binary analysis (which indicates the binary is a Xerox Print Driver), Carbon Black also includes some summary data of how frequently that binary has been seen: in this case, 5500 times on 250 computers, also indicating legitimacy.

At this point, even suspicious types are wavering, but some will point to the fact the binary is unsigned and insist the file version information cannot be trusted as a result. While this is pedantically accurate, too many manufacturers do not sign their binaries. (That’s a blog post for another day) Unsigned binaries are, unfortunately, still very common on even well-managed networks.

As a final confirmation, we can use the md5 of the alleged Xerox Printer Driver and compare with a scan from 46 anti-virus products. Experienced Carbon Black users will know the value is 0:

46 antivirus products flag the DLL.

I went through all ten notepad.exe processes with network activity, and 90% had a similar profile. So, Raffi, most of the time notepad.exe is connecting to the network because it’s printing to a networked printer.


I hadn't found this thread until now, so unfortunately I'd started another on the same topic:

which would explain why there were no replies there I suppose!

Don't post to that other thread, but it will save me describing the hardware, etc, again if you have a look at it.  In brief, I have two machines.  Both are Intel I5, one a 750 anf the other a 760.  Both run Win 7 64-bit SP1.

I've found this solution to work every time:

  • Kill the game's *.exe process, leaving rundll32.exe still running (SysInternals' procexp64.exe or procexp.exe show the process tree better than Task Manager, so it's worth downloading SysInternals Suite if you haven't already got it.  You'll see rundll32.exe as a sub-branch of the *.exe for the game.  Or, to put it another way, if you're not sure what the game's *.exe is called, it's the one above the rundll32.exe thread that's hogging all the CPU power!)
  • Restart the game.
  • Kill the rundll32.exe thread (or suspend it if you're at all a bit doubtful)

I know that this has already been partly described in previous posts above, but I just wanted to point out that it's safe to kill the rundll32.exe thread after the successful restart of the game.  This stops it hogging all that CPU power (a full core's worth on my I5-750!) while you play - more performance, less heat.

As to the cause, I'm even more mystified than before.  I've tried the Game Explorer fixes and that seemed to work.  BUT one one machine, it works now for the Admin User (me and the 'serious work stuff') but not for the Guest User (games only).  Both users now have identical settings in Games Explorer but the Guest is locked off the internet, so maybe I have to connect and start each game once in that user (as per posts above).

The other strange thing is that, on that PC, UAC doesn't seem to be working.  It's set identical to my other PC (the default setting - one notch from the top) but it quite happily lets me start procexp64.exe in the Guest User and kill off processes without any prompts at all!  On my other PC, UAC is working as expected and I'm quite happy to put up with its slight inconveniences for the extra protection it offers.  Especially during those wee small hours work sessions where it's so easy to do something a bit stupid as the eyelids start to droop.

So I,m lost for a reason for this to be happening.  Everything else about Win 7 is great and stable as a housebrick.  So why these problems?

I have another problem - Windows XP Mode running in a VM:

Which interested parties may find relevant.  The reason is that the VM (or Virtual Machine, in which Windows XP Mode runs) also launches using  rundll32.exe (most things do in 64-bit land) and when 32-bit games run in Win 7 64-bit, they also start in a VM.  But there my techo knowledge fizzles out (and may be wildly inaccurate!).

Anyway.  I agree, in that I think Microsoft have an unresolved problem in there somewhere.




Leave a Reply

Your email address will not be published. Required fields are marked *