Scheduled Task command with space “hides” the file from Autoruns

TL;DR; Creating a scheduled task with a space in the file path will “hide” the executable from Autoruns. The file path is split on the space, the first part becomes the scheduled task’s command and the second part is treated as the command’s arguments. Autoruns uses the command as the image (executable) path for scheduled tasks. Tested on Windows 7, 2012, and 10. The task only ran on Windows 2012 and 10.

Recently, a strange looking scheduled task was noted while reviewing a host that was thought to have malware. The task looked like:

Name: <random>
Command: "c:\users\john"
Arguments: "doe\<random>\name.exe"

Looking at the task for a minute, I realized Windows just might put the command and arguments together, effectively executing:

“c:\users\john doe\<random>\name.exe”

Time to test this hypothesis.

Create a task with a space in the file path to the executable

After creating a user with a space in the username (“first last”) and logging in as that user, I copied an executable that would open a window to the user’s profile, and created a scheduled task to execute it:

schtasks /CREATE /TN space /TR "c:\users\first last\write.exe" /SC onlogon

The single path was split into a command and arguments

Inspecting the task within Task Scheduler reveals the executable path was split on the space; the first half being the “program” and the second half the “arguments”.

Task run successfully, WordPad is started

Running the task launches write.exe (WordPad) as suspected.

Autoruns appears to only use the task’s command as the executable path.

Task configured and run Windows 2012

I created a small program to display the path to the executable to confirm the path is indeed the command joined with the argument.

I tested the scheduled task Windows 7, 2012, and 10. The task would only execute on Windows 2012 and 10. On Windows 7, procmon showed Windows was using c:\users\first as the executable path. I’ll have to investigate further to determine why the behavior is different on the various versions of Windows.

I don’t believe the attacker intended to do this. Recently I have noticed similar commands running legitimate software. I suspect it was an installer that did not take into account that file paths can have spaces.