Aside from hearing the word “bit” and thinking “tiny” or “small”, abusing BITS Jobs can lead to HUGE compromises. In my experience, I’ve seen threat actors abuse BITS for anything from coin miners, to further access from an access-broker or scripted to drop additional malware, also known as a “dropper”. As with any other tool, the end-result of using a tool such as this, is up to the attacker! Buckle up, because in this write up, we’re going to explore what BITS jobs are, how they are abused/leveraged by threat actors, how to investigate them and of course, demo a bit of BITS for ourselves!
Before we dive too far into this artifact, let’s first briefly describe what BITS is at a very high level (Microsoft already explains what this is so I’ll keep it brief here). Microsoft BITS or Background Intelligent Transfer Service is exactly what it sounds like; it has the capability to download and upload files to various services, such as SMB or over HTTP. Think of a BITS job as another way to perform automated tasks with additional capabilitie. Right off the bat, you can see how a threat actor can abuse this, right? Now where does the “Background” part come in to play in the acronym? Well, BITS can continuously transfer files in the background, even after the application that launched it, is closed. According to Microsoft, there are three types of BITS “jobs”. A download job, upload job, and an upload-reply job (which uploads a file and receives a response stating it was received). Note that BITS jobs are stored within a database and can be executed, created, deleted, modified, etc. with PowerShell or BitsAdmin (both command line based tools).
The Rundown
BITS stands for Background Intelligent Transfer Service
BITS is a built-in Microsoft feature/tool and is most commonly used for Windows Updates, but can be used for a variety of other services
Temp files are created for BITS jobs, but cleaned up after execution. Can be found in filesystem Journal
BITS is network/process aware, meaning it has the ability to avoid bottlenecks and can limit the amount of processing power with the job
Has the ability to download/upload files to remote servers over various protocols (HTTP, HTTPS, and SMB)
Can be used to upload data to a specified server
Jobs perform a specified task
Threat Actors (TA) may commonly use BITS to download and execute their tools/binaries from specified remote servers
BITS jobs can last as long as 90 days
BITS jobs can continue to run after the parent application has exited, so long as the user is logged in
BITS jobs are stored in a database
Parsing the database requires dedicated tools
Jobs can often be created via PowerShell or the BITSAdmin tool
BITS has dedicated Windows Event Logs but may have limited logging by default
BITS can be investigated via standard program execution artifacts, such as Prefetch
Command line visibility is extremely helpful and almost paramount to determine BITS abuse
Let’s take a look at how Microsoft Describes BITS. Shown below is a description from Microsoft.
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. BITS includes PowerShell cmdlets for creating and managing transfers as well as the BitsAdmin command-line utility.
A threat actor would never abuse a built in tool that has the ability to download/upload data over common protocols, is network conscience, power conscience, can be paused, can persist after a reboot, and integrated with PowerShell, right?!
For the below demos, I'm going to use Red Canary's Atomic Redteam to conduct simulations of BITS abuse https://github.com/redcanaryco/invoke-atomicredteam/wiki
Creating the Job
Now lets break down what consists of a BITS “job”. Think of a job as essentially a container that has one or more files that will be part of the “transfer” process. This job also contains the properties or configuration that describes how the job will be performed. For example, the protocol, the source, destination, etc. Lastly, it has a priority, which will allow you to specify notifications (if requested), and if it's an upload or download job.
Adding files to the job
Once the job is created, you can now specify one or even more files that will be either uploaded or downloaded from the remote server. Note that Microsoft states upload jobs can only contain one file. Once the file is specified, you’ll have the option to add the location, both local and remote. Note that remote file must use the supported protocols, which are HTTP, HTTPS or SMB.
Now that we have a decent understanding of BITS jobs, (you all read the Microsoft article I linked above, right?.,.. RIGHT?), let’s discuss how it can be abused by threat actors.
BITS and Living off the Land
As I mentioned above, I’ve seen BITS jobs be abused for a large number of various types of compromises. It really depends on the actor, their intent, and level of sophistication. Let’s throw a quick common acronym I’m sure we’ve all heard before “LOLBIN”, LOLBAS, LoTLBAS, LoTLs, etc. The idea is “Living off the Land”. What do we mean by this? Well, using a tool that’s native to a target environment. For example, there are a ton of built in Windows tools that leverage BITS jobs for legitimate reasons, because of this, its not uncommon to see BITS executing in the environment. More commonly, we see this with various updates and diagnostics. This is exactly why TA’s may choose to use a tool such as BITS. It’s built in! There’s no need to drop additional tooling, generic anti-virus solutions likely won’t detect malicious activity from this, it can likely bypass firewall controls you have in place, it can run the background, etc. Remember, BITS jobs can easily be created by a bad actor and can be customized to perform a variety of actions.
In a nutshell, TA’s love to use these living off the land tools because they work, you’re probably not alerting on abuse of them, and overall its less likely they will get detected (though depending on your current security stack and tooling, these are still fairly easy to detect if you spend the time to ensure your tool is taking a holistic approach, looking at behavioral analytics, machine learning, etc.). Surprisingly, there’s also not a lot of default logging around many Microsoft built-in tooling.
BITS and Bites - Abuse BITS
With this said, it wouldn’t be out of the ordinary to see a malicious BITS job be paired with additional persistence, such as a scheduled task, startup item, service, etc. Think about all the ways a TA could integrate a BITS job (with what we now know) into their kill chain.
A TA delivers a malicious file that executes commands. Within that, BITS will be used to download an additional payload
A TA uses BITS as part of a malicious scheduled task. Every hour, the BITS job is executed to download a payload or even upload data
A BITS job is added as part malicious AutoRuns item. At logon, a BITS job is used to download and ensure the TAs latest malware is on the host.
Now the above are just very simple real-world examples; but the idea is to show you how easy it is to integrate BITS to an attacker's kill-chain. Note that in most cases, you’ll see BITS be added as part of a malicious script or executable as part of a “staged” attack. “Staged” meaning the payload executed performs multiple functions in succession. You may even see it integrated with a malicious PowerShell script.
Investigating BITS
As always, let’s file this type of attack up in a VM and see how we can investigate malicious BITS use! Of course, executing BITS will leave artifacts behind, such as prefetch and others. However, there are also dedicated Windows Event Logs for BITS! Of course, by default, these Event Logs may not record all the necessary information for us to truly investigate what the job did. This is why having additional tooling and telemetry from EDR tools, command line auditing, Sysmon, PowerShell verbose logging, and others, is very important to ensure you have the evidence needed to investigate these. One primary differentiator between BITS and other artifacts is the fact that BITS has a dedicated database! So if you’re on a live-system (hopefully not but I just have to put this caveat here), you can query that database using the BITS Admin tool or PowerShell! If you’re running a tool such as KAPE, you can even have it collect this database for you!
The Evidence
I'm going to add here that JPCERT has an AMAZING list of artifacts generated by BITS, which can be found here: https://jpcertcc.github.io/ToolAnalysisResultSheet/details/BITS.htm
Also, as always, LOLBAS Project never disappoints! https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/
So what evidence exists for BITS jobs? Remember, you’ll likely see bitsadmin.exe or powershell.exe within execution artifacts, such as Prefetch, SRUM, etc.. Here, we’ll focus more on the events created.
If a job is actively running you can utilize PowerShell or BitsAdmin to list current running jobs
PowerShell - Get-BitsTransfer -AllUsers
BITSAdmin - bitsadmin /list
BITSAdmin - bitsadmin /list /allusers
BITSAdmin - bitsadmin /info <JobName> /verbose
BITS Event Logs
Microsoft-Windows-Bits-ClientOperational.evtx
Event ID - 3
The BITS service created a new job.
Will display the job name, job owner, and job ID
Will display the type of job (transfer, download, etc.)
Process path will state how it was invoked (Powershell or BitsAdmin)
Event ID - 4
The transfer job is complete.
Event ID - 59
BITS started the /Download transfer job
Will provide the job type and target URL
Event ID - 60
BITS stopped transferring the /Download transfer job
Will provide the job type and target URL
Sysmon Event Logs
Event ID - 1 (process create of bitsadmin.exe)
Event ID - 3 (network connection from bitsadmin.exe or bits.exe)
PowerShell Event Logs
4104, 4103, 400, 600 (PowerShell auditing)
Security Event Logs
4688 (Process creation and command line auditing, if enabled)
Registry (may contain malicious persistence within SetNotifyCommandLine value)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BITS
BITS Database (requires special tools such as forensics suites)
C:\System Volume Information\BITS\<GUID>\qmgr.db
NOTE - This is a protected system folder that will require you granting access using the icacls tool
icacls "C:\System Volume Information" /grant <YourUsername>:F
C:\ProgramData\Microsoft\Network\Downloader\qmgr.db
Remember, its all about utilizing the artifact constellations and connecting the dots! There will be numerous artifacts that will be created as part of your incident that can be timelined and help tell the story of what you're investigating. For example, you may see via program execution that PowerShell was executed via Prefetch. In Prefetch, you see that Bitsadmin.exe was referenced. Looking at PowerShell logs, you see that PowerShell was used to invoke Bitsadmin to download a suspicious executable. You correlate this with the BITS event log. SRUM shows that BITS did in fact make an outbound connection. Parsing the MFT, you see that around the time PowerShell and BitsAdmin were invoked, a file called "1337.exe" was placed in C:\Windows\temp. As you can see, BITS event logs are just one piece of the puzzle! But the whole idea is to know where your data exists.
I know this was an extensive post but hopefully it was helpful! Again, note that there are many ways to abuse BITS and every single little detail can't be covered in a single post (unless its a research paper or something), but I wanted to hit some of the key items here as well as artifacts/events generated. Remember, as with most LOLBINS, you'll want to have visibility into process execution and command-line auditing, known normal in your environment, and create a baseline of this activity.