Malware loves Windows Task Scheduler

Malware authors have been using the Windows Task Scheduler (or AT.exe jobs) to victimize hosts for at least a decade, but the seems to have ushered in a renaissance. Recent Zlob variants have made frequent use of Task Scheduler; the widespread click-fraud Trojan Bamital drew on Task Scheduler as well.

Stuxnet exploited Task Scheduler in a way that was previously unknown — it was a true zero-day attack. But malware doesn’t have to get too fancy to put Task Scheduler to ill use. For example, malware will often create a task that looks for certain preconditions to launch, downloads new malicious code on a schedule, or uses scheduled tasks as a way to always remain in memory. I’ve seen malware hunters struggle to find out how the malicious code “keeps re-infecting their clean system.” Answer: Check the Task Scheduler.

Unfortunately, I’m finding more and more examples of new malware and even APT-style attacks that are abusing Task Scheduler and AT.exe, and they are being sneaky about it. Now is a good time for all of us to check the Task Scheduler.

Know your Windows Task Scheduler

Between current and older versions of Windows, there are three different utilities for scheduling tasks. Here’s a quick recap of their differences. The early precursor to Windows Task Scheduler, AT.exe, only worked at the command line. Schtasks.exe was added in Windows XP and Windows Server 2003 as a replacement for AT.exe, but AT.exe was still included for backward compatibility. The Windows Task Scheduler is a more functional GUI application that has been around, in one form or another, since Windows 95 Plus Pack. All three tools rely upon the Task Scheduler service.

All three task-scheduling tools can work locally or remotely against other hosts. When used remotely, AT.exe uses Remote Procedure Calls (RPC) within Server Message Blocks (SMB) packets. Schtasks and Windows Task Scheduler use native RPC and skip the SMB inclusion. When used remotely, the targeted host’s Task Scheduler service handles the heavy work of creating, scheduling, and running the job. The older versions of these tools require that the task administrator be a privileged user, but tasks not requiring elevation can be created by regular user accounts.

Scheduled tasks are implemented as individual files. Each task is named according to a system-unique Security Identifier Description (or SID) or given a user- or system-supplied name. Tasks are stored in %Windir%Tasks or %Windir%System32Tasks by default, and may have .job extensions. The .job files are binary, but they can be decoded (more on that below). In Windows Vista, Windows 7, and Windows Server 2008, the new task files are XML and easily readable.

You can examine old and new task files, but it isn’t always easy. First, the files may be owned by the System account and inaccessible to Administrators. They are often located in %Windir%System32Tasks and made invisible using the Hidden attribute. Even if you are looking for them — and most people aren’t — they can be difficult to find.

Windows Task Scheduler safety tips So what can you do? There are a few steps you can take, and they’re not hard — you just have to be aware of them. First, you can look for unexpected, hidden job files. You can use Windows Explorer, Attrib.exe, or DIR /ah to search for hidden files, but an even easier way is to use Sysinternals Autoruns. Autoruns lets you zero straight in on all scheduled tasks, whether they’re hidden or not. 

Unfortunately, if you’ve never looked around to see what jobs normally run on your systems (and it can be dozens to hundreds enabled by Microsoft or legitimate software), figuring out what is nasty versus nice can take some time. Here’s where it pays just to be aware of this attack vector because you don’t want to look at every job file all the time. Heck, that will drive you crazy. But you can be sure to look for suspicious job files whenever you’re doing a malware investigation.

As I said before, this might involve decoding binary .job files. This Windows Incident Response article can help you with that.

Windows Event Logging can be your friend as well. You can enable Object Access auditing on the task folders noted above and alert on unusual activity. This will take some fine-tuning of course.

Finally, you can use a network monitoring tool (Network Monitor, Wireshark, and so on) to look for instances of unexpected hosts that are creating unexpected remote jobs. Remote jobs are pretty common when malware or malicious hackers are involved.

What do I mean by unexpected hosts? Well, most client computers should not be creating remote jobs to other clients and servers. Most servers should not be creating remote jobs to other servers and clients. You can use network monitoring tools to figure out which remote jobs are normal and legitimate. Use the normal activity to create a baseline, then alert on deviations from the norm. The remote job activity can be identified and filtered fairly easily. Microsoft’s Network Monitor identifies the application-layer protocol as TSCH, by default.

If you haven’t included Windows Task Scheduler jobs in your malware investigation procedures, you should. If you have a network intrusion detection system or network anomaly system looking for dubious network activity, make suspicious remote jobs part of the sweep. Simply being aware of this rising attack vector and introducing it into your normal forensics activities is a great step forward.