Kurzfassung: Beim E-Mail-Bombing trägt der Angreifer die Adresse eines Mitarbeiters in Hunderte Newsletter ein, bis das Postfach unbenutzbar ist (ATT&CK T1667). Kurz darauf meldet sich ein angeblicher IT-Helpdesk per Telefon oder Teams-Chat aus einem fremden Tenant (T1566.004) und bietet Hilfe an, über Quick Assist oder ein anderes Fernwartungswerkzeug (T1219.002). Danach folgen Nachladen, Zugangsdatendiebstahl und im schlimmsten Fall Ransomware. Erkennung: Mailvolumen pro Empfänger, externe Teams-Kontakte und der Start von QuickAssist.exe in 4688 oder Sysmon 1, am stärksten als Korrelation aller drei.
E-Mail-Bombing sieht auf den ersten Blick nach einem Spam-Problem aus und ist in Wahrheit der erste Akt eines Angriffs mit Social Engineering. In der Fachliteratur heißt es auch Email Bombing, Mail Bombing, Mailbombing oder Subscription Bombing, gemeint ist immer dasselbe: Ein Postfach wird mit Tausenden legitimer Nachrichten geflutet, damit der Empfänger überfordert ist und dankbar den Anruf des „Helpdesks“ annimmt, der kurz darauf kommt. Dieser Beitrag aus der Serie „Angriff erkennen“ beschreibt die Angriffskette, die Logquellen, eine Sigma-Regel für den Start von Quick Assist, eine Korrelationsabfrage über Mail und Endpunkt, den Test im Homelab und die Härtung, die die Kette an der richtigen Stelle bricht.
Was der Angreifer tut: vom Subscription Bombing zur Fernwartung
Microsoft hat die Kette im Mai 2024 für die Gruppe Storm-1811 beschrieben, Sophos hat sie im Januar 2025 in mehr als 15 Vorfällen innerhalb von drei Monaten beobachtet, bei zwei Gruppen mit Verbindung zu Black Basta und FIN7. Im Juli 2026 folgte eine weitere Sophos-Analyse zu einer Kampagne mit Chaos-Ransomware, in der zwischen erstem Kontakt und Verschlüsselung teils weniger als 17 Stunden lagen. Der Ablauf ist in allen Fällen gleich:
- Die Mailflut. Der Angreifer meldet die Zieladresse automatisiert bei Newslettern, Foren und Shops an, die keine Bestätigung verlangen. Sophos berichtet von bis zu 3.000 Nachrichten in weniger als einer Stunde.
- Der Kontakt. Ein angeblicher IT-Mitarbeiter ruft an oder schreibt über Microsoft Teams aus einem eigens angelegten Tenant mit Namen wie „Help Desk IT“. Die Standardeinstellung von Teams erlaubt Chats und Anrufe von externen Organisationen.
- Die Fernwartung. Der Mitarbeiter soll Strg+Windows+Q drücken, Quick Assist öffnen, einen Code eingeben und die volle Steuerung freigeben. Alternativ: die Fernsteuerung in Teams selbst, AnyDesk oder ScreenConnect.
- Das Nachladen. Per curl oder bitsadmin kommen Skripte und Werkzeuge, bei Storm-1811 Qakbot, Cobalt Strike, NetSupport und am Ende Black Basta über PsExec.
Die Mailflut hat zwei Zwecke. Sie schafft den Vorwand für den Anruf, denn wer 3.000 Mails im Postfach hat, glaubt jedem, der Hilfe verspricht. Und sie begräbt Sicherheitsmeldungen wie Anmeldewarnungen oder Hinweise auf geänderte Kontodaten. MITRE hat E-Mail-Bombing deshalb im Januar 2025 als eigene Technik T1667 in die Taktik Impact aufgenommen. Die psychologischen Hebel hinter dem Anruf beschreibt der Beitrag zu Pretexting und Vishing im Detail.
Warum der Spamfilter nicht hilft
Jede einzelne Nachricht beim Subscription Bombing ist legitim. Sie kommt von einem echten Newsletter-Dienst, besteht SPF, DKIM und DMARC, enthält keinen schädlichen Link und keinen Anhang. Ein Filter, der Nachrichten einzeln bewertet, hat keinen Grund zum Blockieren. Verdächtig ist nur das Muster: sehr viele Anmeldebestätigungen von sehr vielen Absendern an einen Empfänger in sehr kurzer Zeit. Microsoft Defender for Office 365 erkennt dieses Muster seit Mitte 2025 mit einer eigenen Erkennung „Mail bombing“, die solche Nachrichten in den Junk-Ordner verschiebt und in Explorer und Advanced Hunting sichtbar macht. Das entschärft die Flut, beendet aber nicht den Angriff, denn der Anruf kommt trotzdem.
Welche Logquellen die Technik zeigen
| Quelle | Ereignis | Was du siehst |
|---|---|---|
| Exchange Online, Defender for Office 365 | Nachrichtenverfolgung, Tabelle EmailEvents | Mailvolumen pro Empfänger und Stunde, Anzahl verschiedener Absenderdomains, Erkennung „Mail bombing“ |
| Microsoft Purview Audit, Teams | Chat-Erstellung mit externen Teilnehmern | Erster Kontakt aus einem fremden Tenant, oft mit onmicrosoft.com-Domain und Anzeigenamen wie „IT Support“ |
| Security-Log | 4688 mit Befehlszeile | Start von QuickAssist.exe, danach curl, bitsadmin oder cmd.exe aus derselben Sitzung |
| Sysmon | 1, Prozess erstellt | QuickAssist.exe aus C:\Program Files\WindowsApps\MicrosoftCorporationII.QuickAssist_…, mit Elternprozess und Hash |
| Sysmon | 3 und 22 | Verbindung und DNS-Anfrage zu remoteassistance.support.services.microsoft.com, bei anderen Werkzeugen zu deren Relay-Servern |
Eine Lücke gibt es: Quick Assist schreibt laut Microsoft-Dokumentation keine lokalen Protokolle, weder beim Helfer noch beim Empfänger. Was in der Sitzung passiert, siehst du nur indirekt über die Prozesse und Verbindungen, die während der Sitzung entstehen. Welche Event-IDs dafür eingeschaltet sein müssen, steht in der Übersicht der Windows-Event-IDs.
Die Sigma-Regel
Die Regel schlägt beim Start von Quick Assist oder einem gängigen Fernwartungswerkzeug an. In Unternehmen, die Quick Assist nicht für den eigenen Support nutzen, ist jeder Treffer ein Anruf beim Benutzer wert.
title: Quick Assist or Remote Access Tool Started by User
id: 7c2e4a91-3b5d-4f8e-a6c1-9d0e2f4b8a13
status: test
description: Start von Microsoft Quick Assist oder einem Fernwartungswerkzeug,
typischer Schritt nach E-Mail-Bombing und Helpdesk-Vishing.
references:
- https://attack.mitre.org/techniques/T1219/002/
- https://attack.mitre.org/techniques/T1667/
- https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/
author: Blue Team
date: 2026-09-25
tags:
- attack.command_and_control
- attack.t1219.002
- attack.initial_access
- attack.t1566.004
logsource:
category: process_creation
product: windows
detection:
selection_quickassist:
Image|endswith: '\QuickAssist.exe'
selection_rmm:
Image|endswith:
- '\AnyDesk.exe'
- '\TeamViewer.exe'
- '\ScreenConnect.WindowsClient.exe'
- '\client32.exe'
filter_it:
User|contains:
- 'adm-'
- 'helpdesk'
condition: 1 of selection_* and not filter_it
falsepositives:
- Eigener Support, der Quick Assist oder ein RMM-Werkzeug nutzt; nach Benutzergruppe und Geraet ausnehmen
level: medium
Der Filter auf Administrationskonten ist ein Platzhalter für die eigene Namenskonvention. client32.exe ist der Client von NetSupport, den Storm-1811 verteilt hat. Wie die Regel in die Abfragesprache des eigenen SIEM kommt, steht im Beitrag zu Sigma-Regeln.
Die Korrelation: Mailflut, dann Fernwartung
Einzeln sind beide Signale laut: Mailspitzen gibt es auch bei Newsletter-Aktionen, Quick Assist auch beim echten Support. Zusammen beim selben Benutzer innerhalb weniger Stunden sind sie fast eindeutig. In Microsoft Defender XDR lässt sich das in KQL direkt abfragen:
let window = 3h;
let bombed = EmailEvents
| where Timestamp > ago(1d)
| summarize Mails = count(), Senders = dcount(SenderFromDomain)
by Upn = tolower(RecipientEmailAddress), BombStart = bin(Timestamp, 1h)
| where Mails > 200 and Senders > 50;
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe",
"ScreenConnect.WindowsClient.exe", "client32.exe")
| extend Upn = tolower(AccountUpn)
| join kind=inner bombed on Upn
| where Timestamp between (BombStart .. BombStart + window)
| project Timestamp, DeviceName, Upn, FileName, ProcessCommandLine, BombStart, Mails, Senders
Die Schwellen 200 Mails und 50 Absenderdomains pro Stunde sind ein Startwert; die eigene Grundlinie zeigt, was normal ist. Stimmen Mailadresse und Anmeldename nicht überein, etwa bei Aliasen, braucht die Verknüpfung eine Zuordnungstabelle. Mit Teams-Protokollen als drittem Glied wird die Abfrage noch schärfer. Ohne Defender XDR gilt dasselbe Prinzip für jedes SIEM, das Mailprotokolle und Endpunktdaten zusammenführt.
Der Test
Atomic Red Team hat für T1219 den Test Nummer 15 „Microsoft App Quick Assist Execution“, der Quick Assist startet. Im Homelab erwartest du danach 4688 und Sysmon 1 mit QuickAssist.exe, Sysmon 22 mit der Auflösung von remoteassistance.support.services.microsoft.com und Sysmon 3 mit der Verbindung. Die Mailflut simulierst du nur im eigenen Test-Tenant, etwa mit einem Skript, das 300 Testnachrichten von verschiedenen Absendern an ein Laborpostfach schickt. Melde nie eine echte Adresse bei fremden Diensten an, auch nicht die eigene zum Testen. Ablauf und Auswertung einer solchen Übung beschreibt der Beitrag zu Atomic Red Team.
Fehlalarme und Tuning
- Der eigene Support. Wer Quick Assist offiziell nutzt, hat bei jeder Supportsitzung einen Treffer. Besser: auf Microsoft Remote Help mit Anmeldung über die eigene Organisation umsteigen und Quick Assist entfernen. Dann ist jeder verbleibende Start verdächtig.
- Newsletter-Wellen. Mailspitzen nach Messen oder Aktionen betreffen viele Empfänger gleichzeitig mit wenigen Absendern. E-Mail-Bombing trifft einen oder wenige Empfänger mit sehr vielen Absendern; die Anzahl verschiedener Absenderdomains trennt beides.
- Externe Teams-Kontakte. Partner und Kunden chatten legitim über Teams. Verdächtig ist der erste Kontakt aus einem Tenant, mit dem nie zuvor kommuniziert wurde, mit einem Anzeigenamen, der nach interner IT klingt.
Reaktion und Härtung
Meldet ein Mitarbeiter eine Mailflut, ruft das SOC ihn über einen bekannten Kanal an, bevor es der Angreifer tut, und sagt ihm, dass niemand von der IT unaufgefordert Fernzugriff verlangt. Hat bereits eine Sitzung stattgefunden, gilt das Vorgehen für einen kompromittierten Endpunkt: Gerät isolieren, Prozesse und Verbindungen aus der Sitzung prüfen, Zugangsdaten des Benutzers zurücksetzen, Sitzungen widerrufen. Die weiteren Schritte stehen im Beitrag zur Ransomware-Reaktion. Drei Maßnahmen brechen die Kette dauerhaft:
- Externe Teams-Kommunikation begrenzen. Im Teams Admin Center unter externem Zugriff nur freigegebene Domains erlauben und Chats mit nicht verwalteten Teams-Konten abschalten. Das nimmt dem Angreifer den glaubwürdigsten Kanal.
- Quick Assist entfernen oder sperren. Microsoft empfiehlt selbst, Quick Assist zu blockieren oder zu deinstallieren, wenn es nicht gebraucht wird: per PowerShell mit
Get-AppxPackage -Name MicrosoftCorporationII.QuickAssist | Remove-AppxPackage -AllUsers, per AppLocker-Regel für gepackte Apps oder über Intune. Dasselbe gilt für RMM-Werkzeuge, die nicht offiziell im Einsatz sind. - Die Helpdesk-Regel. Die IT ruft nie unaufgefordert an, um Fernzugriff zu bekommen. Wer angerufen wird, legt auf und ruft die bekannte interne Nummer zurück. Diese eine Regel, verankert über die Meldewege und regelmäßig geübt, wirkt auch dann, wenn die Stimme am Telefon geklont ist, wie im Beitrag zu Deepfake-Vishing beschrieben. Awareness-Material zu Social Engineering findest du auf social-engineering.org.
Fazit
E-Mail-Bombing ist kein Spam, sondern die Vorbereitung eines Anrufs. Der Angreifer braucht keine Schwachstelle und keine Schadsoftware in der Mail, sondern nur ein überfordertes Opfer, einen offenen Teams-Kanal und ein Fernwartungswerkzeug, das auf jedem Windows-Rechner liegt. Wie beim Missbrauch legitimer Cloud-Dienste ist jedes Werkzeug legitim, verdächtig ist nur die Abfolge. Wer Mailvolumen, externe Teams-Kontakte und den Start von Quick Assist zusammen betrachtet, erkennt den Angriff in der Stunde, in der er noch aufzuhalten ist. Und wer Quick Assist entfernt und externe Chats begrenzt, nimmt ihm die Werkzeuge, bevor es ein SOC braucht.