Adding Persistence Via Scheduled Tasks

Published: 2018-05-07
Last Updated: 2018-05-07 07:19:56 UTC
by Xavier Mertens (Version: 1)
3 comment(s)

Once a computer has been infected by a malware, one of the next steps to perform is to keep persistence. Usually, endpoints (workstations) are primary infection vectors due to the use made of it by people: they browse the Internet, they read emails, they open files. But workstations have a major limitation: They are rebooted often (by policy - people must turn off their computer when not at the office or by maintenance tasks like patches installation). That’s why persistence if a key required to ensure that when the computer is rebooted, the malware will still be active and be able to phone home to its C2 server.

I found a malware sample that uses a simple Microsoft .job files to implement persistence. A Job file[1] is a special XML file that contains all the details to configure a scheduled task on a Microsoft Windows host. More technical details about this file format can be found here[2]. When you execute a malware in a sandbox and a scheduled task is created, a .job file will be dropped and captured by the sandbox. Parsing files manually is boring/ time-consuming, so it’s always good to have a toolbox ready to perform this kind of tasks. Jamie Levy wrote a quick Python script to parse job files[3]. Here is the output of the malicious job file created by the sample I found:

$ python -f /tmp/malicious_belgningsstuens.job
Product Info: Windows XP
File Version: 1
UUID: {EAC916B6-B7FF-430B-B6DD-9676523133D}
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Task is ready to run
Date Run: Wednesday May 2 14:37:33.588 2018
Running Instances: 0
Application: reg
Parameters: add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v "Belgningsstuens" /f /t REG_SZ /d "C:\Documents and Settings\John\Application Data\kinglike.exe
Working Directory: reg
User: John
Comment: Comment not set
Scheduled Date: May 2 22:37:1440.0 2018

The .job file is created C:\Windows\tasks, the standard location of scheduled jobs. Thes corresponding command follows:

"C:\WINDOWS\system32\SchTasks.exe" /Create /SC HOURLY /MO 12 /TN "Belgningsstuens" \
     /TR "reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" \
     /v "\""Belgningsstuens"\"" /f /t REG_SZ /d "\""C:\Documents and Settings\John\Application Data\kinglike.exe" \

Basically, the malware drops a PE file %APPDATA%\kinglike.exe (SHA256:eb62ceaf85055120714d9b82b8da39e7d08a95ebb1763b03009511532c40c7d3) and schedules a unique task (see the flag “TASK_FLAG_DELETE_WHEN_DONE”) that will make it start again at the next boot (registry key "HKLM\Software\Microsoft\Windows\CurrentVersion\Run”).

In the example above, the scheduled task is configured to run with ‘system’ privileges (“/RU SYSTEM”) but any user can create scheduled tasks. An authenticated user has rights to create scheduled tasks and to write into the C:\Windows\Tasks directory as shows the SetACL[4] tool:


   Owner: Administrators

   Administrators        full   allow   container_inherit
   Administrators        write+read+WRITE_OWNER+WRITE_DAC+DELETE   allow   object_inherit
   SYSTEM                full   allow   container_inherit
   SYSTEM                write+read+WRITE_OWNER+WRITE_DAC+DELETE   allow   object_inherit
   Authenticated Users   read   allow   container_inherit+object_inherit
   LOCAL SERVICE         read   allow   container_inherit+object_inherit
   NETWORK SERVICE       read   allow   container_inherit+object_inherit
   CREATOR OWNER         full   allow   container_inherit+object_inherit+inherit_only

The PE file kinglike.exe has a score of 17/65 on VT[5] but the initial one (timedlll.exe - SHA256:e0143cf54d109163f0f807816907b3e375170dd9ce576164a519efba66983459) is still unknown. For the story, it’s a Netwire RAT[6] communicating to the following C2: on port 3386

I started to have a look at job files posted on VirusTotal and there are plenty of them[7][8][9]. This is something that you definitively must keep an eye on!


Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

3 comment(s)


Poor job!

1. persistence is achieved through the registry entry plus the executable, not the scheduled task!
2. the python script is defective: its UUID output is not correct.
3. standard (unprivileged) users can't schedule a task to run under SYSTEM account.
4. nobody with a sane mind uses a 3rd-party tool instead of the [I]CACLS.exe utility shipped with Windows.
About point 3, the sandbox user is running with admin rights, so "/RU SYSTEM" worked.
[quote=comment#41359]About point 3, the sandbox user is running with admin rights, so "/RU SYSTEM" worked.[/quote]

So your whole post^H^Hint is moot: an administrator can run
and write anything to the machine's "Run" keys to achieve persistence.
There's ABSOLUTELY no need for the interim job then.

JFTR: since unprivileged users can't read other users user profiles (that's where the executable is stored), the command written to the machine's "Run" key fails ... except for administrators. Again NO persistence then for unprivileged users.
You should better use/show real life examples which actually work.

Diary Archives