Pages

Monday, 24 May 2021

Hunting for Suspicious Usage of Background Intelligent Transfer Service (BITS)

BITS Overview

  
Background Intelligent Transfer Service (BITS) is used by programmers and system administrators to download files from or upload files to HTTP web servers and SMB file shares. 

BITS will take the cost of the transfer into consideration, as well as the network usage so that the user's foreground work has as little impact as possible. BITS also handles network interruptions, pausing and automatically resuming transfers, even after a reboot, which makes it a very good candidate for implant Command and Control standard tasks (download, upload and ex-filtration). 

BITS includes PowerShell cmdlets for creating and managing transfers as well as the BitsAdmin command-line utility.

BITS is composed of a Client (i.e. bitsadmin, powershell) loading Bitsproxy.dll, qmgrprxy.dll or  Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll and a Server (svchost.exe with the process's command-line value contains the keyword "BITS" and hosting the service DLL qmgr.dll):

Figure 1 - BITS Client


Figure 2 - BITS Server

Communication between the BITS client and server is performed via RPC, and the IBackgroundCopyManager  is the main BITS interface used to enumerate or create new BITS Jobs:

Figure 3 - OleView  of the BITS service exposed interfaces

  Figure 4 - BITS IBackgroundCopyManager Interface exposed Methods

Figure 5 - BITS JOB TYPE

From a behavior perspective all the download and upload activities are performed by the BITS server (svchost.exe) impersonating the BITS client which breaks the link between the client and the server if using standard monitoring telemetry such as Sysmon network and file creation events.

BITS can be also abused for persistence by setting a command to run every time a transfer job enters the BG_JOB_STATE_ERROR or BG_JOB_STATE_TRANSFERRED state using the IBackgroundCopyJob2::SetNotifyCmdLine method (i.e. bitsadmin.exe /SetNotifyCmdLine) which will result in a malicious program or command to be run persistently on a target system.

 Figure 6 - BITS SetNotifyCmdLine Parameters

Detection and Hunting


From a detection and forensics perspective Windows provides good logging events for the BITS client activities via the Microsoft-Windows-Bits-Client provider (enabled by default), key events are:
  • EventID 3 - BITS service created a new Job
  • EventID 59 - BITS started the <jobname> transfer job that is associated with http://example.com URL.
  • EventID 60 - BITS stopped transferring the <jobname> transfer job that is associated with the http://example.com URL. The status code is 0xxxx.
  • EventID 4 - The transfer job is complete
  • EventID 5 - Job cancelled.
  • Other events that are related to performance and transfer errors
Events such as 59, 60 and 61 contains the download/upload URL (very useful for forensics and detection) and event 3 contains the details of the BITS client process path and the Job name (very useful for detecting abnormal BITS clients).

Below example of BITS events resulting from this malware sample (Remcos or Netwire RAT loader):

  Figure 7 - BITS Client Event Logs 3 and 60        


A)  Unusual BITS Client:


By default on a Windows machine there are a limited number of BITS clients (native Windows binaries) and the majority are related to third party programs such as browsers. To baseline the clients we can use Bitsproxy.dll or qmgrprxy.dll ImageLoad events (such as Sysmon EventId 7) or BITS Client Event Logs EventId 3.

By default the following are the known normal BITS client with process path residing under c:\windows\ directory.

c:\Windows\SysWOW64\bitsadmin.exe
c:\Windows\System32\MDMAppInstaller.exe
c:\Windows\System32\DeviceEnroller.exe
c:\Windows\SysWOW64\OneDriveSetup.exe
c:\Windows\System32\ofdeploy.exe
c:\Windows\System32\directxdatabaseupdater.exe
c:\Windows\System32\MRT.exe (x)
c:\Windows\System32\aitstatic.exe
c:\Windows\System32\desktopimgdownldr.exe
c:\Windows\System32\Speech_OneCore\common\SpeechModelDownload.exe
c:\Windows\System32\RecoveryDrive.exe
c:\Windows\System32\svchost.exe (BITS service)

Excluding the above we can hunt/detect for unusual client, below an example of a hunting EQL query:


Figure 8 - Unusual Bits Client Hunt

Figure 9 - Notepad.exe Unusual BITS Client

B) Program Execution via BITS SetNotifyCmdline Persistence: 


Programs set to execute via the SetNotifyCmdline method are a child of the BITS service, there are some legit instances especially signed stuff running from program files directories, but its quite rare:

Figure 10 - Hunt Example for Persistence via BITS SetNotifyCmdline Method



Figure 11 - Malware example persisting via BITS SetNotifyCmdline Method

C) Execution of a File Downloaded via BITS Service:


Last example is to hunt for executable content that is downloaded via BITS service and immediately executed, we can do that by correlating File rename event (old file name always follow this pattern BITXXXX.tmp and renamed to the target file name)  by the BITS service followed by process execution by file.path/process.executable:

Figure 12 - Download & Execution of a file via BITS using PowerShell

As you can see below we can link the file download activity to the process execution event:

Figure 13 - Hunt for Process Execution of a File Downloaded via BITS service

Figure 14 - Hunt Results for Process Execution of a File Downloaded via BITS service


There other scenarios but that should give you an idea of the building blocks and how to play with them to spot unusual combinations.

Monday, 4 January 2021

How to Design Abnormal Child Processes Rules without Telemetry

    In detection engineering we often encounter attack techniques that result into a system process spawning an unusual child process, which can be used as a good detection or hunting logic. The only problem that remains is to exclude legitimate/expected benign child processes,  and for this often we need some endpoint production telemetry (the more the better), unfortunately not everyone has this privilege. In this post we will share with you some quick steps you can follow to tune your rule with no telemetry access.

For this let's take the example of a malware masquerading as WerFault.exe via hollowing or any equivalent form of injection, and our goal is to detect suspicious instances via looking at any abnormal child process (e.g. cmd.exe):

1) Imported Modules: Step 1 consist of identifying all imported DLL that are specific to the functioning of the subject process (not generic ones such as kernel32.dll, ntdll.dll etc.), in our example we can see 2 modules wer.dll and faultrep.dll:


  

2) Strings: Step 2 consist of identifying all executables in the process (werfault.exe) strings and also the previously identified function specific DLLs (wer.dll, faultrep.dll):


Of course not all programs names are valid child processes of WerFault.exe, to confirm which one are potential benign/expected child processes we need to move to the next step. 

3) Process Creation APIs: goal here is to identify all references to process creation related APIs (CreateProcessA/W, CreateProcessAsUserA/W, CreateProcessInternal, WinExec,  ShellExecute , ShellExecuteEx, NtCreateProcess, ZwCreateProcess  etc.). we will need to start first with those extracted directly from WerFault.exe, and then repeat same steps for the function specific DLLs.

For brevity we will show the steps for WerFault.exe example only, open your subject process in your favorite disassembler (you don't need to be a reverser!) and go to the the imports view, then search for the process creation related APIs:


Next double-click on the matched API name, then right-click or X to display the functions that use this API:


 As you can see below, we have only 6 functions to check, you can also start from the process names identified in Step 2 (Strings View), but for better flow and understanding start first with the APIs XREFs:


The CreateProcess API arguments that we care about (point the potential benign child process we are looking for) are lpCommandLine or lpApplicationName:


In the example of the CInpagePlugIn::StartCoFireProcess function we can see that the cofire.exe t is a potential child process.


In this case it was easy (adjacent to the API call), in other cases you will need to drill-down a couple of functions to find the ApplicationName or CommandLine being populated, you can always go back to the Program names extracted at phase 2 and cross reference the function that uses them for correlation. 

Psr.exe is another potential child process referenced in CAppRecorderPlugin::StopRecordingSession 


4) Going back to Step 1 if needed:  before repeating the same steps 1, 2 and 3 on wer.dll and faultrep.dll, first check via strings or checking the Import Table the presence of any process creation related APIs:


In case of no references to process names or process creation APIs, it's safe to move directly to step 5.

5) Detection Logic: Last step is straightforward, look for process with parent process name equal to WerFault.exe and process name is different than the identified potential benign child processes:

process where process.parent.name == "werfault.exe" and not process.name in ("cofire.exe", "psr.exe, ", "VsJITDebugger.exe", "TTTracer.exe", "rundll32.exe")


  Of course this approach will miss in some instances potential false positives such as processes created with arguments passed via standard input, config files, registry values, COM, RPC and equivalent :





above you can see an example where a potential child process name is extracted from the registry values ReflectDebugger. or Debugger:




This method is time consuming but still if applied to a limited number of target processes it can provide you with an initial working detection rule with minimum noise and with no access to production endpoint process execution telemetry.

References:

https://twitter.com/SBousseaden/status/1235533224337641473

https://www.hexacorn.com/blog/2018/08/31/beyond-good-ol-run-key-part-85/

https://github.com/elastic/detection-rules/blob/main/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml