BITS service abuse detection

Threat snapshot

The Background Intelligent Transfer Service is a Windows system service designed to transfer files in the background using idle network bandwidth. It is the mechanism that Windows Update uses to download patches, and it is built into every Windows installation. BITS transfers are persistent, resume automatically after interruptions, and run in the context of the svchost.exe process. They are also largely invisible to standard network monitoring: BITS traffic blends with legitimate Windows Update and Microsoft telemetry traffic, uses HTTP and HTTPS, and generates no process creation events for the downloading process itself.

Attackers abuse BITS to download payloads, stage data for exfiltration, and establish persistent download mechanisms that survive reboots and network interruptions, all while appearing as routine system traffic. One specific abuse pattern involves an uncommon or attacker-controlled process loading the BITS client proxy DLL, qmgrprxy.dll, which is the interface library through which processes interact with the BITS service programmatically. When a process that is not a documented, signed Windows Update or management component loads this DLL, it is almost certainly attempting to interact with BITS for purposes other than its intended design. Log360 detects this through the BITS Client BitsProxy DLL Loaded By Uncommon Process rule.

At a glance

How this attack works

The BITS service exposes a COM interface that allows processes to programmatically create, manage, and monitor transfer jobs. A process that wants to interact with BITS loads qmgrprxy.dll, the BITS client proxy library, to gain access to this COM interface. Legitimate BITS consumers include Windows Update (wuauclt.exe, WaaSMedicAgent.exe), SCCM, Intune Management Extension, and a small number of other Microsoft management components. These are predictable, signed, well-documented processes with specific operational purposes.

An attacker who wants to abuse BITS creates a BITS job programmatically through the COM interface exposed via qmgrprxy.dll. This allows them to schedule a download from an attacker-controlled URL that will execute automatically, transfer a file using the BITS service's own process identity and network context rather than their malware's identity, persist the download job across reboots and network interruptions without requiring the malware to be running, and benefit from the fact that BITS traffic is typically allowed through firewalls and network monitoring that blocks other outbound traffic categories.

The detection anchor for this rule is the image load event: Sysmon Event ID 7 captures when a process loads a DLL. When qmgrprxy.dll is loaded by a process that is not in the documented set of legitimate BITS consumers, this load event is the earliest observable signal of BITS API access by an uncommon process. The process loading the DLL has not yet created a BITS job, submitted a URL, or downloaded anything, but the intent to interact with BITS is already evident from the DLL load alone.

Common attack scenarios include a malware binary or script loading qmgrprxy.dll to schedule a download of a second-stage payload from a C2 URL, a persistence mechanism that creates a recurring BITS job to re-download a payload on a schedule, a data exfiltration tool that uses a BITS upload job to send files to an attacker-controlled server disguised as a routine transfer, and a dropper that uses BITS to download additional components without spawning any visible child processes.

Attack chain

The table below maps each stage of a BITS service abuse attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A technology company with 150 employees uses Windows endpoints managed via Intune. Windows Update and Intune management operations account for a regular baseline of BITS activity on all endpoints. A threat actor who compromised a software developer's account via credential stuffing against the developer's GitHub account has used those credentials to access the developer's corporate endpoint via VPN.

The attacker drops a lightweight loader script into the developer's AppData directory, disguised as a Node.js package cache file. The loader, when executed, loads qmgrprxy.dll and uses the BITS COM interface to create a transfer job that downloads a second-stage payload from a GitHub raw content URL. The URL points to a repository the attacker controls, hosted on the legitimate GitHub infrastructure, making the download destination difficult to block via URL reputation alone.

Log360 fires the BITS Client BitsProxy DLL Loaded By Uncommon Process alert when the loader loads qmgrprxy.dll. The loading process is node.exe, the Node.js runtime, which has no documented reason to interact with the BITS API. The SOC analyst reviewing the alert identifies node.exe as the loading process, cross-references the parent process chain showing it was launched from a script in AppData, and initiates an investigation. The second-stage payload has not yet been executed because the BITS download is still in progress at the time of isolation.

Why this happens

BITS job creation is not monitored in most environments because it is considered an internal Windows mechanism rather than a user-initiated or attacker-accessible capability. Security teams that monitor process creation, file writes, and network connections do not typically monitor for DLL load events specifically targeting qmgrprxy.dll, because the legitimate BITS consumers are well-known and the DLL itself is a system component. Without Sysmon Image Load monitoring configured for this specific DLL, the BITS API access goes undetected and the subsequent download is attributed entirely to the BITS service process rather than to the malicious loader.

Business impact: What can go wrong

BITS service abuse that goes undetected enables a range of downstream consequences:

• Fileless-adjacent payload delivery: BITS allows an attacker to download additional tools without spawning visible child processes from their initial payload. The download appears as routine svchost.exe network activity, defeating process-tree-based detection that would catch a direct download by the malware process.
• Reboot-persistent download mechanism: a BITS job set to re-download a payload on a schedule persists across reboots as a built-in operating system feature. Unlike scheduled tasks or Run key persistence, BITS job persistence requires no additional registry or file system modifications that might be caught by persistence-focused detection rules.
• Firewall and proxy bypass: BITS traffic is typically allowed through corporate proxies and firewalls because it is attributed to svchost.exe and uses standard HTTP and HTTPS. URL-based blocking is the primary proxy-layer control, but attacker-controlled content hosted on legitimate platforms such as GitHub, OneDrive, or Pastebin may not be caught by URL reputation controls.
• Data exfiltration via upload jobs: BITS supports upload jobs as well as download jobs. An attacker can use a BITS upload job to transfer staged data archives to an attacker-controlled server, with the transfer attributed to the BITS service process and using the same traffic channels that legitimate Windows Update uploads use.
• Extended dwell time: the combination of a BITS-based download mechanism and traffic that blends with Windows Update activity allows an attacker to maintain a recurring payload delivery mechanism for extended periods without any obvious process-level or network-level signal. Dwell time in undetected BITS abuse campaigns can extend to weeks.
• Secondary payload staging: BITS is commonly used as a staging mechanism for larger secondary payloads that are too large to include in an initial phishing attachment. Ransomware encryptors, lateral movement toolkits, and credential dumping tools are all delivered via BITS in documented campaigns.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the BITS Client BitsProxy DLL Loaded By Uncommon Process rule can fire reliably, ensure the following are in place:

• Sysmon is deployed on all monitored endpoints with Event ID 7 (Image Loaded) enabled in the Sysmon configuration. Event ID 7 is the primary telemetry source for this rule. Without it, DLL load events are not captured and the rule cannot fire. Note that Event ID 7 can generate high log volume if not filtered carefully: configure the Sysmon Image Load rules to capture loads of qmgrprxy.dll specifically rather than all DLL loads, which would create excessive noise.
• Sysmon Event ID 1 (Process Create) is enabled in the Sysmon configuration. This provides the parent process chain for the process loading qmgrprxy.dll, which is essential for determining whether the loading process was launched by a legitimate management tool or by a malicious script or binary.
• The Microsoft-Windows-Bits-Client operational log is enabled and being forwarded to Log360. This log generates Event ID 59 when a BITS job is created, providing the downstream confirmation that a job was actually submitted using the loaded DLL. Enable this log by navigating to Event Viewer > Applications and Services Logs > Microsoft > Windows > Bits-Client > Operational and enabling it, or via wevtutil sl Microsoft-Windows-Bits-Client/Operational /e:true.
• Endpoint agents or Windows Event Forwarding are configured to forward Security, Sysmon, and the BITS-Client operational log from all monitored endpoints to Log360. BITS abuse occurs on individual endpoints and the relevant telemetry is endpoint-local. Coverage must include all workstations, not only servers.

Note: Sysmon Event ID 7 (Image Loaded) is disabled by default in many Sysmon configurations because it generates high log volume when all DLL loads are captured. The recommended approach is to enable Event ID 7 with a targeted include rule specifically for qmgrprxy.dll rather than enabling it broadly. Add an ImageLoad include rule with ImageLoaded containing qmgrprxy.dll to the Sysmon configuration. This captures only the specific DLL load events relevant to this rule without significantly increasing overall log volume.

Detecting BITS service abuse using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: BITS Client BitsProxy DLL Loaded By Uncommon Process. Configure an alert profile for the same. Set the severity to Trouble. The rule targets DLL image load events, which have a slightly broader false positive surface than process execution or registry events. Review the loading process name carefully during initial deployment to calibrate the expected false positive rate for your environment before adjusting severity.

Step 2: Read the alert

When the rule fires, the alert will display the hostname, the process name and path loading qmgrprxy.dll, the parent process name and path, and the timestamp. Review the loading process path first. A process in System32 or Program Files that is not in the documented allow list is lower confidence than a process in AppData, Temp, or a user profile directory. Then review the parent process: understanding what launched the loading process reveals the delivery mechanism. A script interpreter or office application as the parent of an unusual BITS consumer is high confidence malicious.

Investigating an alert

When the BITS Client BitsProxy DLL Loaded By Uncommon Process rule fires, an L2 analyst should work through the following steps:

• Identify the loading process and verify whether it is a documented legitimate BITS consumer. Open the alert detail and check the process name and full path against the documented allow list. If the process name matches a known legitimate tool but the path is not in the documented installation location, the process is likely a masquerading malicious binary, which is higher severity than a completely unknown process name.
• Check the parent process chain. Open the Incident Workbench and trace the process tree back from the loading process. Determine what launched the process and what launched that process. A chain that terminates at a phishing document, a downloaded installer in AppData, or a browser-spawned process confirms a malicious delivery vector.
• Check for BITS job creation following the DLL load. Query Log360 for Microsoft-Windows-Bits-Client Event ID 59 on the same host in the minutes following the qmgrprxy.dll load event. If a BITS job was created, identify the URL and the local destination path specified in the job. The URL reveals the attacker's download infrastructure and the destination path shows where the payload was written.
• Check for file creation at the BITS job destination. If a BITS job was identified, query Log360 for Sysmon Event ID 11 on the same host for the destination path. Determine whether the download completed and the file was written. Hash the file if it is present and check it against threat intelligence.
• Check for outbound network connections attributed to svchost.exe. Query Log360 for network connections from svchost.exe on the affected host following the qmgrprxy.dll load. Connections to URLs outside the documented Windows Update, Microsoft telemetry, and enterprise management endpoints in the post-alert window are likely BITS service connections created by the attacker's job.
• Determine whether a recurring BITS job was created for persistence. Query the BITS-Client operational log for the job details from the Event ID 59 entry. If the job has a recurring schedule or if additional jobs are visible, the attacker has established a BITS-based persistence mechanism that will re-download the payload even if the initial binary is removed.

Escalation trigger

Escalate immediately to L3 if the loading process is in a user-writable directory such as AppData, Temp, or Downloads; if a BITS job was confirmed created with a URL pointing to external infrastructure; if the downloaded file hash matches known malware or is unsigned; if the parent process chain traces back to a phishing document, a downloaded installer, or a browser-spawned script; or if a recurring BITS job appears to be configured for persistent payload delivery. Isolate the host before completing the investigation if a BITS download has already completed and an executable or script was written to the destination path.

Responding and remediating

Immediate containment

• Cancel any active or pending BITS jobs created by the attacker using bitsadmin /cancel or PowerShell: Get-BitsTransfer | Where-Object { <filter by URL or job name> } | Remove-BitsTransfer. Cancelling the job prevents further downloads from the attacker's URL even if the malicious loader process has been terminated.
• Terminate the process that loaded qmgrprxy.dll and remove the associated binary from disk if it is identified as malicious. Do not delete the binary before hashing and preserving a forensic copy.
• Isolate the affected host from the network if a BITS download has completed and a second-stage payload has been written to disk, or if C2 activity from a previously downloaded payload is confirmed. Network isolation prevents further C2 communication and BITS upload jobs that may be staging data for exfiltration.

Forensic preservation

• Export the Sysmon operational log from the affected host covering the DLL load event, the parent process chain, and any subsequent file creation events. These logs establish the complete sequence from initial execution to BITS API access to payload delivery.
• Export the Microsoft-Windows-Bits-Client operational log from the affected host covering all BITS job events in the incident window. This log contains the URL, destination path, job creation time, and completion status for each BITS job, providing the full picture of what was downloaded and from where.
• Preserve any files downloaded via BITS jobs before removal. Hash them, document their paths and creation timestamps, and submit to a sandbox environment for analysis to determine their full capability and any additional IOCs they contain.

Eradication and recovery

• Enumerate and cancel all BITS jobs on the affected host: Get-BitsTransfer -AllUsers to list all jobs, including those created by other user sessions. Remove any job whose URL is not associated with Windows Update, Microsoft services, or documented enterprise management infrastructure.
• Scan all other endpoints in the environment for the same BITS job URLs and destination file hashes. Query Log360 for the BITS-Client Event ID 59 entries across all agents in the preceding 24 hours, filtering for jobs whose URLs match the attacker's infrastructure identified during the investigation.
• Review and remove any additional persistence mechanisms that the downloaded payload may have established. A secondary payload delivered via BITS may have created its own persistence through scheduled tasks, registry Run keys, or services that must be found and removed alongside the BITS job itself.

False positive guidance

Legitimate BITS consumers are well-documented and narrow in scope. False positives typically arise from enterprise management tooling that has not been added to the rule's allow list. The following scenarios may produce false positive alerts:

• Enterprise management and deployment tools: SCCM, Intune, and similar enterprise management platforms legitimately use the BITS API to schedule and manage software deployments. Their management agent processes (ccmexec.exe for SCCM, IntuneManagementExtension.exe for Intune) load qmgrprxy.dll as part of their normal operation. If these appear in alerts, verify the process path matches the documented installation location and add a scoped exclusion for the specific binary path.
• Third-party update agents: some software vendors implement their own update mechanisms using the BITS API. These update agents, when not pre-documented in the allow list, will trigger the rule. Verify the vendor identity, confirm the binary is signed by the expected vendor certificate, and add a scoped exclusion for the specific update agent binary path.
• Developer tools with BITS integration: some development tools and build systems integrate with BITS for large file transfers. These will appear as developer runtime processes loading qmgrprxy.dll in development environments. Verify the development tool, confirm the binary is in a documented installation directory rather than a user-writable path, and assess whether BITS integration is a documented feature of the tool.
• Custom administrative scripts: IT teams that have written PowerShell or VBScript tools that interact with BITS for network bandwidth-friendly file distribution may trigger the rule when those scripts run. Verify the script source, confirm it is stored in a managed location rather than an ad hoc user path, and create a scoped exclusion for the specific script host binary if the behaviour is documented and approved.

Key differentiator

Legitimate processes loading qmgrprxy.dll are signed Microsoft binaries or documented enterprise management agents, located in their expected installation directories under Program Files or System32, with a parent process chain that corresponds to normal service or management tool operation. An attacker-controlled process loading this DLL will be in a user-writable directory, will be an unusual host process such as node.exe, python.exe, or wscript.exe, or will be a signed binary running from an unexpected path. The process path is the most reliable differentiator: any process loading qmgrprxy.dll from outside its documented installation directory warrants immediate investigation.

Hardening and prevention

The following controls reduce the risk of BITS service abuse in your environment:

• Restrict BITS job creation permissions via Group Policy. The Group Policy setting Computer Configuration > Administrative Templates > Windows Components > Background Intelligent Transfer Service > Do not allow the BITS client to use Windows Branch Cache can restrict certain BITS behaviours. Additionally, the BITS service can be configured to limit job creation to specific processes via the BITS service's built-in job creation quota and bandwidth throttling settings.
• Monitor and restrict outbound HTTPS connections from svchost.exe at the network perimeter. While BITS traffic is attributed to svchost.exe, the specific destination URLs for attacker-created jobs will not match the documented Windows Update and Microsoft telemetry endpoints. Proxy logs that capture svchost.exe connections can identify anomalous BITS download URLs even when the process creating the job is not directly visible.
• Deploy application control policies via AppLocker or WDAC that restrict which processes can load qmgrprxy.dll. An allow rule that permits only documented BITS consumers to load this DLL prevents attacker-controlled processes from accessing the BITS API entirely, blocking the technique at the execution layer before any job can be created.
• Enable the Microsoft-Windows-Bits-Client operational log across all endpoints and forward it to Log360. BITS job creation events (Event ID 59) provide visibility into the jobs being created, the URLs they target, and the destination paths they use, providing detection coverage even if the DLL load event is not captured.
• Restrict the execution of script interpreters (PowerShell, wscript.exe, cscript.exe, mshta.exe) from user-writable directories via AppLocker or WDAC policies. Many BITS abuse scenarios involve a script interpreter loading qmgrprxy.dll from a malicious script in AppData or Temp. Preventing script execution from these paths eliminates a significant portion of the delivery surface.