SANS Digital Forensics and Incident Response Blog

SANS Digital Forensics and Incident Response Blog

Windows Scheduler (at job) Forensics

This information may be useful to people responding to compromise incidents involving Windows. Typically these days, when a job is scheduled for execution later, possibly every day, week, or month, it's done via a GUI tool or 'schtasks'. However , you can still use the original command line 'at' tool. This utility also allows such jobs to be scheduled over the network if admin credentials are possessed, which makes it quite useful to an attacker for post exploitation activities. When cleaning up after something like this, it's useful to know a bit about what it does under the hood, including the formats of the associated .job file, and the structure and location of associated log entries.

Figure 1: A scheduled job created by the At command


A scheduled job created by the At command

When the job is scheduled using the 'at' command, a file is created under the Windows\Tasks folder. This file has a .job extension, is named At#.job (jobs not scheduled by the 'at' command will have arbitrary names), and its format is described on msdn. If the job is not set up for repeat execution(weekly, monthly, etc.) then the file is deleted after the job is run. In some cases I've been able to extract the data portion from unallocated space by searching for a characteristic comment string that the 'at' command (I haven't been able to create a search keyword that will find generic .job files that weren't created by 'at'), at least in Windows XP, places on all .job files that it creates, "Created by NetScheduleJobAdd.". Note that this string is in Unicode, and is null-terminated. The 16 bits immediately following the two nulls at the end of this unicode string contain the length (little-endian) of the User Data section in bytes, and they are followed by that section (if the length is non-zero). After this section comes the reserved data size ( another 16 bit little endian value in bytes), followed by the reserved data section. Then there's a 16 bit trigger count, which contains the size of the array of triggers that follows. According to the MS documentation, this value is supposed to be the number of bytes in the array, but as it's one in all the examples I've personally seen, I think it's really supposed to be the number of triggers defined. The trigger value starts with a 2-byte size, which should be 0x30 (little-endian, of course, which means 3000). Then there's a 2-byte reserved field, followed by three more 2-byte little-endian values specifying the year, month, and day when the job is scheduled to execute first. Next come three more 2-byte values which would specify end year, month, & day for repeating jobs, and finally two more two byte values, for the start hour and start minute. There are other fields in the structure, but these are the important ones. (While there's a field specifying the job's author, in all examples I've seen from the At command, it's set to "System".)

Figure 2. Hex dump of the At1.job shown above


Hex dump of the At1.job shown above

When a scheduled job is actually executed (not when it's scheduled), a log entry is written to the scheduler's log file. The name of this file is defined by the registry key HKLM\Software\Microsoft\SchedulingAgent, but it defaults to SchedLgU.txt. On WinXP, this file is located in the Windows folder, but on Vista, they've moved it to Windows\Tasks. The log entry format looks something like the following (in unicode):

"At#.job" (filename.exe)

Started #/##/2009 #:##:## PM

"At#.job" (filename.exe)

Finished #/##/2009 #:##:## PM

Note that the numbers aren't padded with leading zeros, and that the above lines are two separate 2-line log entries. It's possible that other entries could fall in between the Start and Finish for a given job. Also, these entries are written for any scheduled job, regardless of whether it was created by 'at' or one of the other scheduler utilities. Of course if it was created by something other than 'at', the .job file will probably have a different name.

As always, please feel free to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy.

John McCash, GCFA Silver #2816, is currently a Forensic Investigator employed by a fortune 500 telecommunications equipment provider.