Kurzfassung: Der Background Intelligent Transfer Service (BITS) ist ein legitimer Windows-Dienst, der Dateien im Hintergrund überträgt - ausfallsicher, mit Wiederaufnahme nach Neustart. Genau das macht ihn für Angreifer attraktiv: Ein BITS-Job lädt unauffällig nach und kann über einen Benachrichtigungsbefehl bei jedem Abschluss eigenen Code ausführen - eine stille Persistenz, die Reboots übersteht. Die Erkennung setzt an drei Stellen an: bitsadmin beim Download, bitsadmin beim Setzen eines Notify-Befehls und Start-BitsTransfer in PowerShell. Drei sigma-cli-validierte Sigma-Regeln, Härtung und der Test im Lab. Serie "Angriff erkennen".
Mit den BITS-Jobs schließt die Persistenz-Reihe ab. Nach den Registry-Run-Keys, dem neuen Konto als Hintertür und dem IFEO-Debugger folgt eine Technik, die sich an einem ganz normalen Systemdienst festmacht. BITS ist derselbe Mechanismus, über den Windows Update und viele Installer ihre Pakete holen: robust, bandbreitenschonend, mit Wiederaufnahme. Ein Angreifer, der denselben Dienst benutzt, verschwindet im Grundrauschen - sein Download sieht aus wie ein Update, und sein Job läuft im Kontext des Dienstes weiter, auch wenn der ursprüngliche Prozess längst beendet ist. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.
Einordnung in ATT&CK: BITS Jobs (T1197). MITRE führt die Technik gleich in drei Taktiken: Persistence (TA0003), weil ein Job Neustarts übersteht und über einen Benachrichtigungsbefehl erneut Code startet; Defense Evasion, weil der Transfer im Dienstkontext läuft und oft an einfachen Filtern vorbeigeht; und Execution. In dieser Serie steht sie in der Spalte Persistence.
Was der Angreifer tut
Der Missbrauch von BITS läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Varianten ab:
- Unauffällig nachladen. Über bitsadmin.exe oder das PowerShell-Cmdlet Start-BitsTransfer wird eine Datei von einem Server geholt. Der eigentliche Transfer läuft im Dienst svchost, nicht als Kind des aufrufenden Prozesses - das verschleiert die Herkunft.
- Über den Neustart hinaus bestehen. Ein BITS-Job hat eine lange Lebensdauer (standardmäßig bis zu 90 Tage) und nimmt den Transfer nach einem Reboot von selbst wieder auf. Der Job allein ist schon eine Form von Persistenz.
- Code über den Benachrichtigungsbefehl starten. Mit /SetNotifyCmdLine bekommt ein Job einen Befehl, den BITS beim Abschluss oder bei einem Fehler ausführt. So startet der Dienst die Nutzlast - ganz ohne klassischen Autostart-Eintrag.
- Später zuschlagen. Download und Ausführung lassen sich zeitlich trennen: Der Job liegt bereit und wird erst durch ein Ereignis oder nach Ablauf einer Frist wirksam.
Für die Erkennung ist entscheidend: Der aufrufende Befehl ist in der Prozess-Telemetrie sichtbar, und ein Benachrichtigungsbefehl an einem BITS-Job hat im Normalbetrieb praktisch keinen legitimen Grund.
Welche Logquellen die Technik zeigt
- Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen den Aufruf von bitsadmin.exe samt Kommandozeile - Flags wie /transfer, /addfile und /SetNotifyCmdLine stehen dort im Klartext. Das ist die wichtigste Quelle.
- PowerShell-Protokolle. Script Block Logging und die Prozesserstellung machen Start-BitsTransfer sichtbar - das PowerShell-Gegenstück zu bitsadmin.
- Das BITS-Betriebsprotokoll. Microsoft-Windows-Bits-Client/Operational protokolliert angelegte Jobs, URLs und Zielpfade. Hier sieht man den Transfer auch dann, wenn der aufrufende Prozess schon weg ist - allerdings mischt sich hier viel legitimer Verkehr (Updates) ein.
- Die nachgelagerte Aktion. Was aus der nachgeladenen Datei oder dem Notify-Befehl folgt, zeigt die Endpunkt-Telemetrie, siehe Sysmon einrichten. bitsadmin selbst gehört zu den klassischen LOLBins.
Das Muster im Log
Das klarste Signal ist der Aufruf von bitsadmin.exe mit einem Benachrichtigungsbefehl: /SetNotifyCmdLine an einem Job gibt es im Normalbetrieb kaum, und wenn der hinterlegte Befehl auf eine Shell oder ein Nutzerverzeichnis zeigt, ist die Sache eindeutig. Das zweite Muster ist bitsadmin mit /transfer oder /addfile und einer http-Quelle - ein Download über einen Dienst, der auf Endpunkten selten von Hand bedient wird. Das dritte ist Start-BitsTransfer in einer PowerShell-Kommandozeile mit einer externen Quelle. Legitimer BITS-Verkehr stammt fast immer von Systemprozessen und Update-Komponenten, nicht von einer interaktiven bitsadmin- oder PowerShell-Sitzung. Wie immer trennt der Blick auf aufrufenden Prozess, Flags und Ziel den Alltag vom Angriff.
Drei Sigma-Regeln
Die Regeln sind mit sigma-cli geprüft. Die erste nimmt den Download über bitsadmin, die zweite den Benachrichtigungsbefehl, die dritte den PowerShell-Weg. Die zweite ist die spezifischste und verdient den höchsten Rang.
1. Download per bitsadmin (T1197). bitsadmin.exe mit /transfer oder /addfile und einer http- oder https-Quelle. Die Regel steht auf level: medium, weil bitsadmin auch in Verwaltungsskripten vorkommt.
title: Download per bitsadmin (BITS-Transfer)
id: a6292f00-eb27-42b1-a291-2145510e8756
status: experimental
description: |
Erkennt den Download einer Datei ueber bitsadmin.exe mit /transfer oder /addfile und einer
http- oder https-Quelle. BITS ist ein legitimer Hintergrunddienst, wird von Angreifern aber
als unauffaelliger Downloader und als Persistenz genutzt, weil ein BITS-Job Neustarts und
Netzunterbrechungen uebersteht und spaeter weiterlaeuft.
references:
- https://attack.mitre.org/techniques/T1197/
author: blue-team.net
tags:
- attack.persistence
- attack.stealth
- attack.t1197
logsource:
product: windows
category: process_creation
detection:
sel_img:
Image|endswith: '\bitsadmin.exe'
sel_cmd:
CommandLine|contains:
- '/transfer'
- '/addfile'
sel_url:
CommandLine|contains:
- 'http://'
- 'https://'
condition: sel_img and sel_cmd and sel_url
falsepositives:
- Einzelne Administrations- oder Softwareverteilungs-Skripte, die bitsadmin nutzen - nach Host und Konto als Baseline ausnehmen
level: medium
2. BITS-Job mit Benachrichtigungsbefehl (T1197). bitsadmin mit /SetNotifyCmdLine oder /SetNotifyFlags - der Persistenz- und Ausführungstrick, praktisch immer verdächtig. Die Regel steht auf level: high.
title: BITS-Job mit Benachrichtigungsbefehl (SetNotifyCmdLine)
id: dda8bb97-9cac-4eb0-ae44-0c440fe3f62f
status: experimental
description: |
Erkennt das Setzen eines Benachrichtigungsbefehls an einem BITS-Job ueber bitsadmin
/SetNotifyCmdLine oder /SetNotifyFlags. Damit fuehrt BITS beim Abschluss oder Fehler eines
Jobs einen beliebigen Befehl aus - der klassische BITS-Persistenz- und Ausfuehrungstrick.
Ein BITS-Job kann tagelang bestehen und uebersteht Neustarts, deshalb ist das eine stille,
dauerhafte Hintertuer.
references:
- https://attack.mitre.org/techniques/T1197/
author: blue-team.net
tags:
- attack.persistence
- attack.execution
- attack.t1197
logsource:
product: windows
category: process_creation
detection:
sel_img:
Image|endswith: '\bitsadmin.exe'
sel_notify:
CommandLine|contains:
- 'SetNotifyCmdLine'
- 'SetNotifyFlags'
condition: sel_img and sel_notify
falsepositives:
- Praktisch keine; ein Benachrichtigungsbefehl an einem BITS-Job ist im Normalbetrieb sehr selten
level: high
3. BITS-Transfer per PowerShell (T1197). Start-BitsTransfer mit einer externen Quelle - das PowerShell-Gegenstück zu Regel 1. Ebenfalls level: medium.
title: BITS-Transfer per PowerShell (Start-BitsTransfer)
id: 30b88458-81bf-4054-8d16-e08fc1e4aba7
status: experimental
description: |
Erkennt einen BITS-Transfer ueber das PowerShell-Cmdlet Start-BitsTransfer mit einer
http- oder https-Quelle. Das ist das PowerShell-Gegenstueck zu bitsadmin und wird zum
unauffaelligen Nachladen genutzt - der Transfer laeuft im Dienstkontext, nicht sichtbar
als Kind der PowerShell.
references:
- https://attack.mitre.org/techniques/T1197/
author: blue-team.net
tags:
- attack.persistence
- attack.stealth
- attack.t1197
logsource:
product: windows
category: process_creation
detection:
sel_img:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
sel_cmd:
CommandLine|contains: 'Start-BitsTransfer'
sel_url:
CommandLine|contains:
- 'http://'
- 'https://'
condition: sel_img and sel_cmd and sel_url
falsepositives:
- Administrations- und Update-Skripte, die Start-BitsTransfer legitim verwenden - bekannte Skripte und Quellen als Baseline ausnehmen
level: medium
Härtung: der Angriff, der ins Leere läuft
- bitsadmin einschränken. bitsadmin.exe gilt als veraltet; wo es nicht gebraucht wird, lässt es sich per Anwendungssteuerung (WDAC oder AppLocker) für normale Nutzer blockieren. Das trifft den bequemsten Weg zuerst.
- Benachrichtigungsbefehle überwachen. Jeder Job mit einem Notify-Befehl gehört alarmiert - dafür gibt es im Normalbetrieb kaum einen Grund. Diese eine Regel fängt den gefährlichsten Fall.
- Ausgehenden Verkehr kontrollieren. BITS lädt über HTTP(S). Wer ausgehende Ziele über einen Proxy filtert und protokolliert, nimmt dem unauffälligen Download die Grundlage.
- BITS-Betriebsprotokoll einsammeln. Microsoft-Windows-Bits-Client/Operational in die zentrale Sammlung aufnehmen, damit auch Jobs ohne sichtbaren Elternprozess erfasst werden.
Der Test
Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon:
- Für Regel 1 mit bitsadmin.exe testweise eine harmlose Datei über /transfer von einem internen Webserver holen. In Event 4688 muss die Kommandozeile mit /transfer und der URL erscheinen.
- Für Regel 2 an einem Testjob mit /SetNotifyCmdLine einen harmlosen Befehl (etwa cmd /c echo) hinterlegen. Die Kommandozeile mit SetNotifyCmdLine muss in der Prozess-Telemetrie auftauchen; danach den Job wieder entfernen.
- Für Regel 3 in PowerShell Start-BitsTransfer mit einer internen Quelle aufrufen und das Erscheinen in der PowerShell- und Prozess-Telemetrie prüfen.
- Breiter wird der Test mit den Fällen zu T1197 aus Atomic Red Team.
Fehlalarme und Tuning
- Softwareverteilung. Manche Verwaltungs- und Update-Skripte nutzen bitsadmin oder Start-BitsTransfer legitim. Für Regel 1 und 3 die bekannten Skripte, Konten und Quellen als Baseline ausnehmen.
- Der Notify-Befehl ist eindeutig. Regel 2 braucht kaum Tuning - ein Benachrichtigungsbefehl an einem BITS-Job hat selten einen legitimen Grund und gehört zu den hochprioren Alarmen.
- Systemprozesse ausklammern. Der legitime BITS-Verkehr läuft über Systemkomponenten, nicht über interaktive bitsadmin-Aufrufe. Wer auf den aufrufenden Prozess und das Konto filtert, trennt Update von Angriff.
- Ziel statt nur Werkzeug. Interne, bekannte Quell-URLs lassen sich ausnehmen; externe oder frisch registrierte Ziele bleiben die interessanten Fälle.
Fazit
BITS ist der unauffälligste der hier gezeigten Persistenz-Wege: Er nutzt einen legitimen Systemdienst, der Download sieht aus wie ein Update, und ein Job übersteht Neustarts von selbst. Die verlässlichen Signale sind der bitsadmin-Aufruf mit Transfer-Flags, der Benachrichtigungsbefehl per /SetNotifyCmdLine und Start-BitsTransfer in PowerShell. Die wirksamste Härtung schränkt bitsadmin ein, alarmiert auf jeden Notify-Befehl und kontrolliert den ausgehenden Verkehr. Damit ist die Persistenz-Reihe komplett - von den Registry-Run-Keys über das neue Konto und den IFEO-Debugger bis zu den BITS-Jobs. Alle Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Persistence.