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

Space Evaders: How an Extra Space in a File Name Can Fool Some Endpoint Security Solutions

How an Extra Space in a File Name Can Fool Some Endpoint Security Solutions Space evaders
October 6, 2014 / Chris Lord

In a recent talk entitled “Crazy Sexy Hacking at BsidesAugusta, Mark Baggett discussed a technique that lets an unsigned malicious file masquerade as a validly signed file.

The trick, Mark noted, is to name a file very similar to an existing file, but add a trailing space after the name. For example, create a file named “Explorer.exe ” in C:\Windows where “Explorer.exe” already exists (note the trailing space on the end in the first version).

During the talk, a member of the audience asked how effective this method is in bypassing application whitelisting.

Neither the Bit9 Security Platform nor Carbon Black are affected by these name games, but much of Windows and many system tools are (yes, maybe even your security software).

In this blog post, I’ll show how Bit9 sees, detects and prevents malicious software that employs this naming technique.

The creative use of names, file IDs, links, and alternate data streams are standard working material for malicious software. While padding a filename with spaces is not new—it was first reported in 2006 and covered by Matt Graeber in Windows File Confusion in 2013—it is still interesting in its simplicity and effectiveness against many user-mode tools.

Below I traverse a path similar to Matt’s to demonstrate how Bit9 keeps you secure.

Space Aliens

Let’s start with getting a malicious file on the system. To avoid the file showing up under an easily visible name, I used curl to pull from a remote site. The test file, MalwareBites.exe, is a simple Windows application that isn’t signed.

Notice the two entries for explorer.exe that look identical in the output below.


One of these files is the malicious one with a trailing space. So why do the commands show identical information for two distinct directory entries?

A trace in Windbg reveals the culprit as the path processing applied to DOS-style path names in CreateFile (and all other Windows core file APIs such as DeleteFile, CreateDirectory, and GetFileSize).

These functions make use of RtlpDosPathNameToRelativeNtPathName_Ustr to process DOS-style paths (e.g., C:\Foo\Bar.exe), not those already in NT form (prefixed with “\??\”) or with path processing suppressed (prefixed with “\\?\”).

For DOS-style paths, the helper RtlGetFullPathName_Ustr is called, which removes all trailing spaces and dots from a file. Unfortunately, DOS-style paths are still the most common way of specifying file paths, so many applications will have their paths modified.

In the PowerShell example above, the two distinct directory entries returned in the enumeration are queried internally using the DOS-style paths, so each query ultimately opens the same file. This effectively masks the characteristics of the second file.

The same effect occurs when the files are viewed in Windows Explorer. In the screen captures below, the green highlight traces the properties and digital signature check for the legitimate version of explorer.exe, while the red highlight follows the properties of the malicious file. Both result in the same signature information.


Even though the properties and signature results are the same, a few anomalies are visible. The correct size and date information is shown in the listing for each of the explorer.exe instances. This comes from the directory enumeration. However, it’s wrong in the properties view that comes from querying the file information with the DOS path. Another oddity is that the icon for the malicious file is not shown. This is because there is no icon handler associated with the file type “exe” with a trailing space, so a generic file icon is shown.


An obvious question is whether Bit9—like PowerShell and Explorer—is affected by this trickery. Before trying to execute the files, I used the Bit9 diagnostic command line interface to inspect the local file state (similar information is also available in the file inventory queried through the management console or the public SQL views). The results are below (the detail has been trimmed back for space reasons).

You can see that there are two distinct file instances, one signed and approved and one unsigned, just as you’d expect.


Running the malicious file turns out to be a bit more difficult; the shell and command prompt always bring up the real version of Explorer, regardless of the use of quotes or the use of the short name. The command powershell Invoke-Item “c:\windows\explor~1.exe” started the malicious version of explorer.exe and was caught and blocked by Bit9.


The diagnostic data in the notification confirms the file instance being run matches that file details we saw earlier:


On a second attempt, I allowed the execution to proceed to see how the activity would be tracked in the events reported in the Bit9 console.

The report below was extracted from the console view (with most columns removed).


All of the key activity (from the point of drop-through to the allowed execution) was available. This level of visibility is helpful when looking back in time. Detecting this automatically would be even more useful.


Bit9 includes a set of Advanced Threat Indicators that look for suspicious behavioral patterns and activity—not just malicious hashes. These indicators catch many types of file-name tricks, but do not currently include detecting files that end in spaces. The cool thing about indicators is you can create many of your own by defining a new custom rule.

For example, consider the following rule definition:


When any process creates a file with a name ending in a space, or when such a file is run, an event is generated with all the activity details, including the processes involved and the command line. The event can trigger additional activity such as automatic upload and detonation, alerts, or banning using event rules on the server.

(Note: older versions of the console may prevent creating some types of rules when the path ends with a space.)


Sometimes it just isn’t acceptable for a malicious file to run, even if it is detected and recognized as such. On systems running Bit9 in high enforcement, no unauthorized software runs, regardless of the file name. However, systems in low and medium enforcement are better served with explicit bans on file name trickery, especially when the file looks deceptively like something a user might want to run.

There are several ways to achieve this in Bit9, but the simplest is to create a name ban on “* ” (wildcard followed by space) as shown below.


The console will warn you that the pattern ends with a space, since that space is often unintentional. (The other warning is an indication that this version of Bit9 includes active banning, which can immediately terminate banned software, in addition to blocking future execution).

When this ban is in effect, all files ending in one or more spaces will be prevented from running, regardless of the enforcement level.

Bunker Down

Given the challenges of having to maintain backwards compatibility with decades of software, Microsoft has opted to just document this as a limitation: “Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.” This “limitation” means that this problem will be with us for a long time, and who wants to fall prey to some decades-old trick?

Bit9 and Carbon Black won’t let you.

TAGS: bit9 / detection / endpoint / malicious files / malware / Prevention / Response

Related Posts