In May 2016, the SecureWorks® Incident Response (IR) Team conducted an engagement involving a malware compromise. Antivirus software had previously detected and remediated malware on the compromised system, but malware-related network alerts continued. A SecureWorks IR analyst flagged anomalous entries in the BITS event log. Further analysis by SecureWorks Counter Threat Unit™ (CTU) researchers identified active malicious BITS jobs to download and execute new malware. The poisoned BITS tasks, which created installation and clean-up scripts after their payloads were downloaded, were self-contained in the BITS job database, with no files or registry modifications to detect on the host.

BITS provides a native, reliable file transfer capability for the Windows operating system. It retrieves Windows updates and is also used by some third-party software vendors to handle file transfers (e.g., their update packages). Malware authors and intruders have abused the service since at least 2007. Attractive features for threat actors include the abilities to retrieve or upload files using an application trusted by host firewalls, to reliably resume interrupted transfers, to create tasks that can endure for months, and to launch arbitrary programs when a task completes. CTU™ researchers determined that the threat actors had leveraged the last feature, a lesser-known capability that Microsoft uses to facilitate "notification" actions when jobs complete, to create the self-contained, download-and-execute BITS tasks that persisted even after the original malware was eliminated.

In the SecureWorks IR engagement, the affected system was a Windows 7 host used for administrative functions in an academic environment. The BITS event log on the system (see Figure 1) included records of previously completed transfers initiated by the malware.

Logged details about the pending tasks were terse. The log indicated that new jobs had been created but did not provide detail. CTU researchers used tools that parsed the BITS job database and provided the missing details (see Figure 2).

The results revealed two similar pending BITS transfer tasks. The first task retrieves a file from the URL shown in Figure 3 and saves the downloaded file to C:\ProgramData\{066b06e5-512c-0}\{066b06e5-512c-0}.d. Partial transfer data is stored in the temp file created at C:\ProgramData\{066b06e5-512c-0}\BIT68A6.tmp.

Figure 3. URI used by first pending task. (Source: SecureWorks)

The SID associated with creating the transfer job was "S-1-5-21- xxxxxxxxxx -xxxxxxxxxx- xxxxxxxxxx -279539". After completing the transfer, the BITS service executed the following command as a "notification program." The command creates and launches a Windows batch script (x.bat) that tries to finalize and clean up the BITS job entry and then checks if the downloaded file is saved as C:\ProgramData\{066b06e5-512c-0}\{066b06e5-512c-0}.d. If it finds the downloaded file, the batch script launches the program with regsvr32.exe, with syntax that indicates the program is a DLL. If the file does not exist, the script tries to run any file with a .tmp extension in the same directory. BITS saves unfinished downloads as files ending with .tmp, so this approach appears to address cases where the filename is downloaded but not renamed. The batch file deletes itself when done.

The second BITS job was almost identical but was assigned a different job name and directory name, and was pulled from http:// big4u.org/u/. These BITS jobs tried repeatedly to download and execute, regardless of whether the original malware that created them was present. The BITS service essentially assumes responsibility for completing all of the functionality specified by the BITS job. The default maximum lifetime for a BITS job is 90 days, but that can be extended. Analysis of the BITS database and corroborating forensic data from the host confirmed that both jobs were still pending on the host as of the engagement.

A forensic review of the host determined that the original malware infection occurred on March 4, 2016 and was detected and removed by antivirus about 10 days later. Although the original malware was not recovered, the available indicators suggest that it was likely the trojan that Symantec calls Zlob.Q and that SecureWorks groups with DNSChanger malware.

CTU researchers recommend that clients consider enumerating active BITS tasks on a host that continues to generate network or host alerts after remediation. One way to enumerate these tasks is to execute the bitsadmin client from a cmd.exe session with elevated privileges (bitsadmin /list /allusers /verbose), which produces the output shown in Figure 4.

To mitigate exposure to this threat, CTU researchers recommend that clients use available controls to restrict access using the indicators in Table 1. The domains may contain malicious content, so consider the risks before opening them in a browser.