Carbon Black & VMware Announce Expanded Partnership to Secure the Software-Defined Data Center (SDDC) Learn more

Archive: Why is Notepad.exe Connecting to the Internet?

Why is notepad connecting to the internet process tree makes process look more suspicious confirms malware
jjguy
September 16, 2014 / Jeffrey Guy

(Editor’s Note: the following blog post appeared on carbonblack.com 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:

JJnotepad1

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:

JJnotepad2

Nine of those were legitimate, but one stood out:

JJnotepad3

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:

JJnotepad4

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:

JJnotepad5

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:

JJnotepad6

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:

jJnotepad7

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 72.51.47.69, created a file named notepad.exe in the user’s temporary directory, then launched it as a child process:

JJnotepad8

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:

JJnotepad9

The malware then wrote to an InprocServer32 registry key:

JJnotepad10

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:

JJnotepad11

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:

JJnotepad12

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 techniques out 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:

JJnotepad13

JJnotepad14

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:

JJnotepad15

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

JJnotepad16

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

Summary

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:

jjnotepad17

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:

jjnotepad18

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:

jjnotepad19

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

jjnotepad20

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:

jjnotepad21

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:

jjnotepad22

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:

jjnotepad23

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.

TAGS: blog / Carbon Black / detection / Internet / malware / network connections / Notepad / Raffi

Related Posts