BITS transfer by user account
A Background Intelligent Transfer Service job was created by a USER account rather than by the system.
What it detects
A Background Intelligent Transfer Service job was created by a USER account rather than by the system.
BITS is attractive to attackers for reasons that have nothing to do with stealthy networking: the transfer is performed by the BITS service, so the download does not appear to come from the attacker's process; it resumes across reboots and logoffs, giving free persistence; and the traffic is indistinguishable from Windows Update because it IS the Windows Update mechanism.
Owner is the usable discriminator. Servicing jobs — Windows Update, Defender definitions, Delivery Optimization — run as NT AUTHORITY\SYSTEM or a service account. A job owned by an interactive user is either an application updater or someone using bitsadmin/desktopimgdownldr to fetch a file.
Marked experimental at medium severity because that discriminator is real but not decisive: several legitimate applications create user-owned BITS jobs.
MITRE ATT&CK mapping
False positives and triage
Expect real volume: browsers, Office click-to-run, and a range of third-party updaters create user-owned BITS jobs by design. Baseline the ones your estate runs before treating this as a lead, and consider scoping it to servers, where user-initiated transfers are far rarer than on workstations.
To confirm: jobTitle is set by whatever created the job, and attacker tooling rarely bothers to make it plausible — a generic or empty title from a user session is more interesting than "Office Automatic Updates". Then find the destination URL and the local file path in the related events, and check whether the downloaded file was executed afterwards. A BITS job created by a process that is itself suspicious (a script host, a webshell's worker) removes any ambiguity.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/windows/bits_transfer_by_user_account.yaml, licensed under the Apache License 2.0.
id: windows.c2.bits_transfer_by_user_account
version: 1.0.0
status: experimental
severity: medium
confidence: 0.55
platforms: [windows]
mitre_techniques: [T1197, T1105]
description: |
A Background Intelligent Transfer Service job was created by a USER account rather
than by the system.
BITS is attractive to attackers for reasons that have nothing to do with stealthy
networking: the transfer is performed by the BITS service, so the download does not
appear to come from the attacker's process; it resumes across reboots and logoffs,
giving free persistence; and the traffic is indistinguishable from Windows Update
because it IS the Windows Update mechanism.
Owner is the usable discriminator. Servicing jobs — Windows Update, Defender
definitions, Delivery Optimization — run as `NT AUTHORITY\SYSTEM` or a service
account. A job owned by an interactive user is either an application updater or
someone using `bitsadmin`/`desktopimgdownldr` to fetch a file.
Marked experimental at medium severity because that discriminator is real but not
decisive: several legitimate applications create user-owned BITS jobs.
match:
provider_contains_any: ['Bits-Client']
native_event_id: '3'
raw_message_not_contains_any:
- 'jobOwner=NT AUTHORITY'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Expect real volume: browsers, Office click-to-run, and a range of third-party
updaters create user-owned BITS jobs by design. Baseline the ones your estate runs
before treating this as a lead, and consider scoping it to servers, where
user-initiated transfers are far rarer than on workstations.
To confirm: `jobTitle` is set by whatever created the job, and attacker tooling
rarely bothers to make it plausible — a generic or empty title from a user session
is more interesting than "Office Automatic Updates". Then find the destination URL
and the local file path in the related events, and check whether the downloaded file
was executed afterwards. A BITS job created by a process that is itself suspicious
(a script host, a webshell's worker) removes any ambiguity.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.