Sophos Active Adversary Report 2026: Identitätsangriffe, Impacket und MFA priorisieren

Sophos Active Adversary Report 2026: Identitätsangriffe als neuer Default

Der Sophos Active Adversary Report 2026 zeigt vor allem, dass Angreifer sich immer öfter einloggen statt einzubrechen, weil Identitäten, Sessions und Fehlkonfigurationen rund um MFA in vielen Fällen den entscheidenden Hebel liefern.

Auffällig ist außerdem ein sehr konkreter Praxis-Hinweis aus dem Report. „Block Python“ soll den Einsatz gängiger Toolchains erschweren, die in vielen Umgebungen unnötig offenstehen.

Ransomware, Exfiltration & Dwell Time: Die wichtigsten Zahlen auf einen Blick

• Die durchschnittliche Dwell Time, also die Zeit vom ersten Zugriff bis zur Entdeckung, betrug im Report 3 Tage.
• In Incident-Response-Fällen lag die mediane Dwell Time bei 5,00 Tagen, weil viele Vorfälle erst bei sichtbaren Auswirkungen eskalieren.
• In MDR-Fällen lag die mediane Dwell Time bei 2,00 Tagen, was den Effekt von kontinuierlichem Monitoring und schneller Reaktion zeigt.
• Bei Non-Ransomware Incident Response blieb ein Angriff im Median 6,00 Tage unentdeckt, weil der laute Impact häufig fehlt.
• Die mediane Zeit bis zum Zugriff auf Active Directory lag bei 3,40 Stunden und war damit 70 Prozent schneller als im Vorjahr.
• Ransomware wurde in 88,10 Prozent der Fälle außerhalb der Geschäftszeiten beobachtet, wodurch Alarmierung und Bereitschaft besonders wichtig werden.
• Exfiltration fand in 78,85 Prozent der Fälle außerhalb der Geschäftszeiten statt, was Datenabfluss gezielt in ruhige Zeitfenster verlagert.
• Exfiltration erfolgte im Median nach 78,83 Stunden ab Angriffsbeginn und damit deutlich früher als viele Teams es erwarten.
• Zwischen Exfiltration und Entdeckung lagen im Median nur 1,87 Stunden, wodurch Containment oft unter starkem Zeitdruck stattfindet.
• In Ransomware-Fällen wurde Exfiltration in 49,77 Prozent bestätigt, was das Erpressungsrisiko deutlich erhöht.
• Mit potenzieller Exfiltration lag der Anteil bei 53,92 Prozent, was die Bedeutung vollständiger Logdaten für die Bewertung unterstreicht.
• Wenn Exfiltration bestätigt war, kam es in 49,07 Prozent der Fälle innerhalb von 19,5 Tagen zu einem Leak.

Datengrundlage: 661 Fälle aus IR und MDR

Der Sophos Active Adversary Report 2026 basiert auf ausgewählten Fällen aus zwei Quellen. Incident Response bildet reale Einsätze aus dem Umfeld von Kompromittierungen ab. Managed Detection and Response ergänzt diese Sicht um MDR Critical Response. Das Dataset ist damit keine reine Internet-Threat-Intel, sondern praxisnahe Fallarbeit aus dem Feld. Für Organisationen, die operative Unterstützung dauerhaft abdecken wollen, ist ein Managed-Ansatz wie Sophos MDR ein naheliegender Rahmen, weil Detektion und Reaktion nicht an Schichtmodelle gebunden sind.

Zeitraum und Umfang

• Zeitraum 01.11.2024 bis 31.10.2025
• Umfang 661 ausgewählte Fälle
• Quelle Sophos IR-Teams einschließlich Secureworks sowie Sophos MDR Critical Response

Unternehmensgrößen mit Fokus auf KMU

Ein klarer Schwerpunkt liegt auf kleineren und mittleren Organisationen. Dort treffen knappe IT-Ressourcen, heterogene Systemlandschaften und zu wenig Telemetrie häufig zusammen. Genau diese Mischung erhöht die Chance, dass Identitätsangriffe lange unbemerkt bleiben.

• 84 Prozent der Fälle stammen aus Organisationen mit weniger als 1.000 Mitarbeitenden
• 56 Prozent der betroffenen Organisationen haben höchstens 250 Mitarbeitende

Branchen mit den meisten Fällen

Manufacturing liegt im Report vorn. Danach folgen Finanz, Bau, IT und Healthcare. Die Taktiken sind dabei selten exotisch. In vielen Fällen treffen Standard-TTPs auf Standard-IT mit Standardlücken.

• Manufacturing 19,82 Prozent
• Financial 8,93 Prozent
• Construction 8,62 Prozent
• Information Technology 6,96 Prozent
• Healthcare 6,35 Prozent

Warum Identitätsangriffe 2026 alles dominieren

Der Report macht deutlich, dass der häufigste Einstieg nicht mehr über spektakuläre Zero-Days erfolgt. In vielen Fällen sind es Identitäten. Angreifer kommen über gültige Zugangsdaten oder gültige Sessions hinein. Damit werden klassische Perimeter-Kontrollen oft umgangen, weil das Verhalten technisch legitim wirkt. Um genau diese Muster besser zu erkennen, lohnt sich ein Blick auf Sophos ITDR, weil Identity-Signale und verdächtige Authentifizierungsabläufe dort gezielt adressiert werden.

Was bedeutet „Identity Attack“ im Alltag?

In der Praxis sind das meist keine spektakulären Einzelaktionen, sondern wiederholbare, skalierbare Routinen. Beim Credential Stuffing werden geleakte Zugangsdaten automatisiert getestet. Häufig wird das mit einem Brute-Force-Angriff kombiniert, etwa als Password Spraying. Dazu kommt Phishing, oft inklusive MFA-Prompt-Fatigue, bei dem Nutzer zur Freigabe gedrängt werden. Eine gezieltere Variante ist Spear Phishing, das auf einzelne Rollen oder Abteilungen zugeschnitten ist. Besonders kritisch ist außerdem Token- und Session-Missbrauch. Angreifer nutzen gestohlene Session-Cookies oder Tokens, um sich „legitim“ anzumelden, ohne dass ein Passwort-Reset allein zuverlässig hilft.

Warum das so gefährlich ist

Wenn Angreifer sich „legitim“ anmelden, wirken viele Signale zunächst normal. Dann entscheiden drei Faktoren, ob früh reagiert werden kann oder erst, wenn Verzeichnisdienste und Fileserver betroffen sind.

1. Policy-Härte mit MFA-Qualität, Conditional Access sowie sauberer Account-Policy
2. Telemetrie mit Login-Logs, Endpoint-Events, Firewall- und Proxy-Daten sowie AD-Events
3. Reaktionsgeschwindigkeit mit Containment in Minuten statt Stunden

Was daraus abzuleiten ist

Patch-Management bleibt Pflicht. Gleichzeitig gehört Identity-Härtung in dieselbe Prioritätsklasse. Wer nur Schwachstellen scannt, aber Identitäten und Sessions nicht schützt, bleibt angreifbar, selbst bei stabilen CVE-Zyklen.

Quick-Win für Entscheider Identity-Projekte sind häufig schneller umsetzbar als ein Infrastruktur-Refresh. Drei Maßnahmen liefern oft sofort Wirkung. Phishing-resistente MFA, Conditional Access und ein sauberes Tiering für privilegierte Konten.

„Block Python“: Was Sophos damit meint und wie Admins es sauber umsetzen

Der Hinweis „Block Python“ im Sophos Active Adversary Report 2026 ist bewusst pragmatisch. Gemeint ist, Python auf möglichst vielen Systemen zu unterbinden, weil das Angreifern den Einsatz von Impacket deutlich erschwert. Sophos beschreibt, dass Impacket 2025 das am häufigsten genutzte Toolset ist. Über alle Impacket-Tools zusammen macht es 36,01% der beobachteten Tools aus. Gegenüber 2024 ist die Nutzung laut Report um 83,08% gestiegen. Python steht in diesem Kontext direkt dahinter, weil viele Impacket-Workflows Python zur Ausführung benötigen.

Warum Python blocken im Enterprise-Kontext Sinn ergibt

Im Unterschied zu PowerShell ist Python in vielen Umgebungen auf Standard-Clients nicht zwingend erforderlich. Genau darin liegt der defensive Hebel. Wenn Python auf normalen Workstations nicht verfügbar ist, wird eine ganze Tool-Kategorie unattraktiver, die Angreifer häufig für Lateral Movement und Credential-Zugriffe nutzen. Sophos empfiehlt deshalb, Python zumindest auf Nicht-Developer-Workstations konsequent zu blocken.

Umsetzung in der Praxis: Drei Zonen statt alles oder nichts

1. Standard-Clients Python standardmäßig blocken. Ziel ist es, Impacket und ähnliche Toolchains auszubremsen.
2. Admin- und Privileged-Workstations Python nur zulassen, wenn es einen echten Bedarf gibt. Andernfalls ebenfalls blocken und streng kontrollieren.
3. Dev- und Automation-Systeme Python erlauben, aber mit klarer Zuständigkeit, Monitoring und begrenzten Ausnahmen.

Wenn Python nötig ist: Controls, die wirklich helfen

Sophos nennt als sinnvolle Ergänzung zu Ausnahmen passende Logs und die konsequente Nachverfolgung auffälliger Python-Nutzung, bis hin zur Ticket-Erstellung. Das ist vor allem dann wertvoll, wenn Python legitim genutzt wird, aber missbrauchsanfällig bleibt.

• Allowlisting statt pauschal erlauben nur definierte Interpreter und Pfade freigeben und auf klar benannte Gruppen begrenzen
• Detections auf Prozessketten Python-Starts mit ungewöhnlichen Child-Prozessen, neuen Netzwerkzielen oder verdächtigen Zugriffsmustern markieren
• Logging erzwingen Prozessstart, Commandline, Parent-Child-Beziehungen und Netzwerkziele erfassen und ausreichend lange vorhalten
• Ausnahmen befristen jede Ausnahme braucht Owner, Laufzeit und ein Review-Datum

Policy technisch durchsetzen: Endpoint-Controls als Hebel

Am saubersten wird „Block Python“ über zentrale Endpoint-Richtlinien umgesetzt. So lassen sich Ausnahmen pro Gruppe oder Standort steuern und verwertbare Events für Audits und Incident Response erzeugen. Für die technische Basis bietet sich eine konsistente Endpoint-Schicht an, etwa mit Sophos Endpoint als zentral verwalteter Standard. Wenn dafür zusätzlich ein dedizierter Visibility-Layer benötigt wird, ist ein EDR-Ansatz naheliegend, etwa mit Sophos EDR als Kontroll- und Sichtbarkeits-Schicht.

MFA-Realität: Token-Replay, Session-Lifetime und phishingsichere Alternativen

MFA reduziert Risiko, aber MFA ist nicht automatisch gleichbedeutend mit Phishing-Schutz. Moderne Angriffe zielen oft nicht darauf ab, das Passwort zu erraten, sondern eine bereits validierte Sitzung zu übernehmen. Genau hier entstehen Fälle von Token- oder Session-Missbrauch, bei denen ein Login technisch legitim wirkt, obwohl ein Angreifer dahintersteht.

Token-Replay und Session-Hijacking als Praxisproblem

Wenn Session-Cookies oder Tokens abgegriffen werden, kann eine Anmeldung ohne erneute Passworteingabe funktionieren. In solchen Szenarien greift ein klassischer Passwort-Reset zu spät oder nur teilweise, weil die aktive Session weiter gültig bleibt. Das Risiko steigt zusätzlich, wenn Sitzungen lange Laufzeiten haben oder Geräte- und Standortwechsel zu wenig streng geprüft werden.

MFA-Prompt-Fatigue und Push-MFA richtig einordnen

Push-MFA ist komfortabel, aber in vielen Organisationen zu leicht auszutricksen. Wiederholte MFA-Anfragen werden so lange ausgelöst, bis ein Nutzer bestätigt. Ein weiterer Faktor ist Social Engineering, bei dem eine Bestätigung als angeblich notwendiger Schritt verkauft wird. Ohne zusätzliche Signale wie Gerätebindung, Standort-Checks oder risikobasierten Zugriff bleibt Push-MFA angreifbar.

Phishing-resistente MFA als Zielbild

Phishing-resistente Verfahren setzen nicht nur auf einen zweiten Faktor, sondern binden die Anmeldung kryptografisch an Ursprung und Gerät. Das reduziert Token-Replay und erschwert die Übernahme von Sitzungen. In der Praxis sind FIDO2-basierte Methoden oder zertifikatsbasierte Logins oft die robusteren Optionen, wenn sie organisatorisch sauber ausgerollt werden.

Session-Lifetime und Conditional Access als Stellhebel

Kurze Session-Lifetimes, klare Reauth-Regeln und ein konsistenter Conditional-Access-Ansatz verkleinern das Zeitfenster für Missbrauch. Dazu gehören Regeln, die riskante Logins stärker prüfen, unbekannte Geräte einschränken und Zugriffe aus auffälligen Regionen blocken. Entscheidend ist, dass diese Regeln nicht nur auf Admin-Konten zielen, sondern auch auf Standardkonten mit Zugriff auf kritische Daten.

Prioritäten für die Umsetzung

Die wirksamste Reihenfolge startet bei privilegierten Konten und extern erreichbaren Diensten. Danach folgen Remote-Zugänge und die Absicherung von Identitätsdiensten, weil dort die größten Hebel für laterale Bewegung liegen. Sichtbarkeit gehört dazu, damit auffällige Logins und Session-Anomalien nicht im Rauschen untergehen.

Telemetrie und Logs: Retention und Sichtbarkeit

Viele erfolgreiche Angriffe bleiben nicht deshalb unentdeckt, weil keine Security-Tools vorhanden sind, sondern weil die nötige Telemetrie fehlt oder zu kurz vorgehalten wird. Ohne verwertbare Logs wird aus Detektion schnell Rätselraten. Das gilt besonders bei Identitätsangriffen, weil der Zugriff zunächst wie reguläre Nutzung aussieht.

Retention entscheidet, ob Forensik möglich ist

Kurze Aufbewahrungszeiten sind ein häufiger Bremsklotz in der Analyse. Wenn Logdaten nach wenigen Tagen verschwinden, fehlt die Rückschau auf Initial Access, erste Lateralmoves und die Vorbereitung von Exfiltration oder Verschlüsselung. Eine belastbare Retention ist deshalb nicht nur Compliance, sondern ein operativer Schutzfaktor.

Welche Logs in der Praxis den Unterschied machen

Für eine saubere Rekonstruktion reichen einzelne Logquellen selten aus. Wirksam wird es erst durch die Kombination aus Identity-, Endpoint- und Netzwerkdaten. Besonders wertvoll sind Login-Events, Endpoint-Prozessdaten und Netzwerk-Telemetrie, weil damit Bewegung, Tooling und Zielsysteme sichtbar werden.

• Identity-Logs erfolgreiche und fehlgeschlagene Anmeldungen, neue Geräte, risikoreiche Logins, Token- und Session-Ereignisse
• Endpoint-Events Prozessstarts, Commandline, Parent-Child-Beziehungen, Verdachtsindikatoren bei Credential-Zugriffen
• Netzwerkdaten DNS, Proxy, Firewall, ungewöhnliche Ost-West-Kommunikation, neue Zielregionen

Typische Fehlannahmen im Betrieb

Ein häufiger Irrtum ist die Annahme, dass Logging automatisch gleichbedeutend mit Detektion ist. Logs ohne Korrelation und ohne klare Use-Cases liefern zwar Daten, aber keine Entscheidungen. Ein zweiter Irrtum ist die Konzentration auf Perimeter-Events, während Identity- und Endpoint-Signale unterrepräsentiert bleiben. Genau dort entstehen bei modernen Angriffen die wichtigsten Hinweise.

Korrelation pragmatisch umsetzen

Entscheidend sind klare Use-Cases, eine stabile Pipeline und Alarme, die handlungsfähig machen. Dazu gehört ein definierter Standard für Zeitstempel, Nutzerzuordnung und Asset-Kontext. Für viele Umgebungen ist ein XDR-Ansatz sinnvoll, weil Endpoint- und Netzwerkereignisse mit Identitätssignalen zusammengeführt werden. Ein passender Baustein ist Sophos XDR, wenn Korrelation und Reaktion über mehrere Datenquellen hinweg abgebildet werden sollen.

Nächster Schritt für die Praxis

Ein sinnvoller Startpunkt ist eine kurze Gap-Analyse. Dabei wird geprüft, welche Identity-, Endpoint- und Netzwerkquellen vorhanden sind, wie lang die Retention ist und welche Alarme tatsächlich reagieren lassen. Daraus entsteht eine priorisierte Liste, die zuerst externe Zugänge und privilegierte Konten absichert und dann systematisch die Breite erhöht.

Tempo der Angreifer: Dwell Time und schneller AD-Zugriff

Moderne Angriffe verlaufen oft deutlich schneller als viele Betriebsmodelle es erwarten. Sobald Initial Access gelingt, folgt häufig zügig die Ausweitung von Rechten und Zugriff auf Verzeichnisdienste. Das praktische Problem ist nicht nur die technische Komplexität, sondern das knappe Zeitfenster, in dem Erkennung und Containment noch günstig sind.

Dwell Time als Führungskennzahl für Detection

Dwell Time beschreibt die Zeit vom ersten Zugriff bis zur Entdeckung. Sinkt diese Zeit, steigen die Chancen, laterale Bewegung und Datenzugriffe zu stoppen, bevor kritische Systeme betroffen sind. In vielen Umgebungen ist nicht die Erkennung einzelner IOC der Engpass, sondern die fehlende Korrelation über Identität, Endpoint und Netzwerk hinweg.

Warum Active Directory so schnell im Fokus steht

Directory Services sind der Hebel für Kontrolle und Skalierung. Sobald Konten, Gruppen oder Kerberos-Mechaniken beeinflusst werden, lassen sich Zugriffe ausweiten, Persistenz aufbauen und Sicherheitsmaßnahmen aushebeln. Genau deshalb ist AD in vielen Fällen ein frühes Ziel. Sichtbarkeit auf DCs, saubere Admin-Tierings und klare Trennung privilegierter Workflows reduzieren die Angriffsfläche deutlich.

Typischer Ablauf nach dem Einstieg

• Credential Access Sammeln und Testen von Zugangsdaten, Zugriff auf Passwortspeicher, Auslesen von Hashes
• Lateral Movement Remote-Ausführung, neue Admin-Sessions, Zugriffe auf Server und File Shares
• Discovery Abfragen von AD-Strukturen, Gruppenmitgliedschaften und Assets
• Impact Exfiltration, Verschlüsselung oder gezielte Manipulation

Was das für die Detektion bedeutet

Das Detection-Fenster schrumpft, wenn Identitätsangriffe und legitime Tools genutzt werden. Wirksam sind deshalb Regeln, die Anomalien in Authentifizierung und Session-Verhalten priorisieren und gleichzeitig die typischen Lateralmove-Pfade abdecken. Dazu zählen ungewöhnliche Admin-Logins, neue Geräte, neue Quellnetze, auffällige Remote-Prozessstarts und unerwartete Ost-West-Verbindungen.

Containment-Prinzipien, die in Minuten funktionieren

Containment muss ohne lange Abstimmungen möglich sein, sonst gewinnt der Angreifer das Tempo-Duell. Bewährt sind klar definierte Playbooks für das Sperren von Konten, das Beenden von Sessions, das Isolieren von Hosts und das Abschneiden verdächtiger Netzwerkpfade. Entscheidend ist, dass diese Schritte für privilegierte Konten und Remote-Zugänge vorab getestet werden.

Praxis-Checkliste: 10 Maßnahmen mit Sofortwirkung

Der Report zeigt ein klares Muster. Identitäten, Sessions und Standard-Tooling sind häufig der Hebel. Mit einer kurzen Prioritätenliste lassen sich die größten Lücken oft schnell schließen. Wichtig ist eine Umsetzung, die messbar ist und im Alltag nicht sofort durch Ausnahmen verwässert.

1. Identitäten härten und Angriffsfläche reduzieren

• Phishing-resistente MFA für privilegierte Konten und externe Zugänge einführen und Push-MFA nicht als Endzustand betrachten
• Conditional Access konsequent nutzen und riskante Logins stärker prüfen, unbekannte Geräte und auffällige Regionen nicht still durchwinken
• Passwort-Reuse aktiv adressieren, Leaked Password Checks und klare Reset-Prozesse in den Standardbetrieb bringen

2. Privilegien kontrollieren und Admin-Workflows trennen

• Admin-Tiering etablieren und Admin-Konten strikt von normalen Benutzerkonten trennen
• Privileged Access Workstations für administrative Tätigkeiten nutzen und Standard-Workstations aus privilegierten Workflows herausnehmen

3. Angreifer-Tooling unattraktiver machen

• Python auf Standard-Clients blocken und Ausnahmen sauber steuern, damit Impacket-basierte Angriffe weniger Reibung haben
• Allowlisting für kritische Admin-Tools, Remote-Management und Scripting-Interpreter nach Use-Case ausrollen

4. Sichtbarkeit erhöhen und Log-Lücken schließen

• Retention für Identity-, Endpoint- und Netzwerklogs so wählen, dass Rückschau und Forensik möglich sind
• Detections auf Auth-Anomalien, neue Geräte, neue Quellnetze und auffällige Prozessketten priorisieren

5. Containment operationalisieren

• Playbooks für Konto-Sperre, Session-Beendigung, Host-Isolation und Netzwerk-Blockaden definieren, testen und in Bereitschaft bringen

Kernbotschaft für die Umsetzung

Die größte Wirkung entsteht, wenn Identitätsschutz und Telemetrie gemeinsam betrachtet werden. Ohne Sichtbarkeit bleiben selbst gute Policies wirkungslos. Ohne Policies werden Logs zur Dokumentation eines bereits erfolgreichen Angriffs.

Fazit: Prävention gewinnt, wenn Identitäten und Sichtbarkeit zusammenkommen

Der Sophos Active Adversary Report 2026 unterstreicht, dass sich viele Angriffe nicht durch spektakuläre Exploits auszeichnen, sondern durch konsequente Nutzung von Identitäten, Sessions und etabliertem Tooling. Der größte Hebel liegt dort, wo Initial Access stattfindet und wo laterale Bewegung vorbereitet wird. Identitätsschutz, saubere Privilegienmodelle und belastbare Telemetrie gehören deshalb zusammen gedacht.

Wirksam wird das Ganze, wenn die Umsetzung im Betrieb belastbar bleibt. Phishing-resistente MFA und Conditional Access reduzieren den „Login als Angriff“ deutlich. Kürzere Session-Laufzeiten und klare Reauth-Regeln verkleinern das Missbrauchsfenster. Ergänzend verhindert ein pragmatisches Hardening wie das Blocken von Python auf Standard-Clients, dass verbreitete Toolchains wie Impacket in der Breite einfach funktionieren.

Am Ende zählt ein klares Ergebnis. Verdächtige Logins müssen auffallen, laterale Bewegung muss sichtbar sein und Containment muss sofort greifen. Wer diese Grundlagen sauber aufsetzt, reduziert auch die Wahrscheinlichkeit, dass sich klassische Schadsoftware wie Malware unbemerkt festsetzt. In einzelnen Szenarien lohnt sich zusätzlich der Blick auf Spyware, weil Datenabfluss nicht immer laut ist und häufig lange im Hintergrund läuft.