Angriffe auf lokale Exchange- und SharePoint-Server mit AMSI stoppen

Exchange Server und SharePoint Server sind geschäftskritische Assets und gelten für viele Unternehmen als Kronjuwelen, was sie zu attraktiven Zielen für Angriffe macht. Um Kunden dabei zu helfen, ihre Umgebungen zu schützen und auf diese Angriffe zu reagieren, sind Exchange Server und SharePoint Server jetzt in die Windows Antimalware Scan Interface (AMSI) integriert, einen vielseitigen Standard, der es Anwendungen und Diensten ermöglicht, nahtlos mit jedem AMSI-kompatiblen Antimalware-Produkt zusammenzuarbeiten. Die Integration von AMSI in SharePoint und Exchange Server bietet eine wesentliche Schutzschicht, indem verhindert wird, dass schädliche Webanfragen Backend-Endpunkte erreichen.

Bedrohungsakteure haben sich immer wieder auf veraltete oder falsch konfigurierte Assets verlassen und Schwachstellen ausgenutzt, die es ihnen ermöglichen, sich dauerhaft im Zielsystem einzunisten. Im Fall von Exchange Server beispielsweise wurden die Schwachstellen ProxyShell und ProxyNotShell bei Angriffen weit verbreitet ausgenutzt, lange nachdem sie durch Sicherheitsupdates in den Jahren 2021 bzw. 2022 behoben worden waren. Bei diesen Angriffen missbrauchten die Angreifer eine Kombination aus SSRF (Server-Side Request Forgery) und Privilegienerweiterungsfehlern, wodurch die Ausführung von Remote-Code ermöglicht wurde. Durch die erfolgreiche Kompromittierung konnten die Angreifer Web-Shells ablegen, laterale Bewegungen durchführen und sensible Daten exfiltrieren, wobei sie sich oft über längere Zeiträume der Entdeckung entzogen. In jüngerer Zeit haben sich die Angreifer auf NTLM-Relay- und Credential-Leakage-Techniken verlegt. Über Outlook gesendete Office-Dokumente und E-Mails dienen Angreifern als effektive Einstiegspunkte, um NTLM-Zwangsschwachstellen auszunutzen, da sie in der Lage sind, UNC-Links in diese einzubetten. Angreifer nutzen die NTLM-Authentifizierung aus, indem sie Anmeldeinformationen an einen anfälligen Server weiterleiten, was möglicherweise zur Kompromittierung des Zielkontos führt. Microsoft hat Leitlinien zur Schadensbegrenzung gegen NTLM-Relay-Angriffe veröffentlicht.

SharePoint Server ist auch ein ständiges Ziel für Angreifer, die kritische Schwachstellen ausnutzen, um dauerhaften und privilegierten Zugriff innerhalb des Ziels zu erhalten. Bei den jüngsten Angriffen wurden heimliche Persistenztaktiken wie das Ersetzen oder Anhängen von Web-Shell-Code in vorhandene Dateien wie signout.aspx, die Installation von Tools zur Fernüberwachung und -verwaltung (RMM) für einen breiteren Zugriff und andere böswillige Aktivitäten beobachtet.

Cloud-basierte Software bietet zwar einige inhärente Sicherheitsvorteile bei Software-Updates und hoher Verfügbarkeit, doch aufgrund der Anforderungen einiger Organisationen müssen Exchange- und SharePoint-Implementierungen vor Ort ausgeführt werden. Da Cyber-Bedrohungen immer ausgefeilter werden, ist es wichtiger denn je, die Sicherheit der lokalen Infrastruktur zu gewährleisten. Diese AMSI-Integration in SharePoint Server und Exchange Server ist besonders wichtig, wenn Angreifer versuchen, Sicherheitslücken auszunutzen, insbesondere Zero-Day-Angriffe. Mit integrierter AMSI werden diese bösartigen Versuche in Echtzeit erkannt und blockiert, wodurch ein entscheidender Abwehrmechanismus geboten wird, während Organisationen an der Installation offizieller Patches und Updates arbeiten. AMSI-Erkennungen werden im Microsoft Defender-Portal angezeigt, sodass SecOps-Teams sie untersuchen, mit anderen bösartigen Aktivitäten in der Umgebung in Beziehung setzen und beheben können.

In diesem Blogbeitrag besprechen wir verschiedene Arten von Angriffen, die auf Exchange und SharePoint abzielen, und zeigen, wie AMSI Organisationen dabei unterstützt, sich vor diesen Angriffen zu schützen. Wir geben außerdem Tipps zur Schadensbegrenzung und zum Schutz sowie Details zur Erkennung und zu Suchanfragen.

AMSI-Integration

Sowohl in SharePoint Server als auch in Exchange Server ist AMSI als Sicherheitsfiltermodul in die IIS-Pipeline integriert, um eingehende HTTP-Anfragen zu überprüfen, bevor sie von der Anwendung verarbeitet werden. Der Filter wird in der onBeginRequest-Phase durch das SPRequesterFilteringModule für SharePoint Server und das HttpRequestFilteringModule für Exchange Server ausgelöst und ermöglicht so die Analyse eingehender Anfragen, bevor sie die Authentifizierungs- und Autorisierungsphasen erreichen. Durch diese Integration wird sichergestellt, dass potenzielle Bedrohungen erkannt werden, bevor sie mit der internen Verarbeitung interagieren, wodurch das Risiko einer Ausnutzung gemindert wird. Bei Erkennung einer bösartigen Anfrage gibt die Anwendung eine HTTP 400 Bad Request Response zurück.

Abbildung 1. Überblick über die AMSI-Integration in SharePoint und Exchange Server

Abbildung 2: AMSI schützt vor dem Auslesen von Mailboxen mithilfe des öffentlichen Tools MailSniper

Erweiterung von AMSI um den Scan von Request Bodies

Als AMSI erstmals integriert wurde, stellte es eine wichtige Verteidigungsebene dar, indem es die Header eingehender Anfragen scannte. Dies war für die Identifizierung böswilliger Aktivitäten, insbesondere SSRF-Versuche, von entscheidender Bedeutung. Viele moderne Angriffe sind jedoch inzwischen in Request Bodies eingebettet und nicht mehr nur in den Headern. Dies bedeutete, dass Header-Scans allein nicht mehr ausreichten, um die gesamte Bandbreite ausgeklügelter Bedrohungen zu erkennen.

Um dieses neu auftretende Risiko zu bewältigen, haben wir in beiden Produkten neuere Verbesserungen vorgenommen. Die November-Version von Exchange Server wurde um die Möglichkeit erweitert, auch den Inhalt von Anfragen zu scannen, um einen umfassenderen Schutz zu gewährleisten. Eine ähnliche Verbesserung wurde auch in SharePoint Server vorgenommen, das derzeit in der öffentlichen Vorschau verfügbar ist. Diese erweiterten Sicherheitskontrollen sind nicht standardmäßig aktiviert, sodass es für Organisationen von entscheidender Bedeutung ist, einen stärkeren Schutz zu erwägen.

Microsoft empfiehlt, diese erweiterten Optionen zu prüfen und zu aktivieren, um einen besseren Schutz und eine bessere Sichtbarkeit zu gewährleisten. Diese Verbesserungen sind besonders wichtig für die Erkennung und Minderung von Schwachstellen bei der Ausführung von Remote-Code und insbesondere von Schwachstellen nach der Authentifizierung, bei denen SSRF möglicherweise nicht erforderlich ist. Die Einführung des Scannens von Anfragetextkörpern ist ein entscheidender Schritt in unserem Engagement, diese Kronjuwelen vor ausgefeilteren, schwer zu erkennenden Bedrohungen zu schützen. Durch die Möglichkeit, den vollständigen Inhalt eingehender Anfragen zu überprüfen, erkennt AMSI nun eine größere Bandbreite bösartiger Aktivitäten.

Angriffe auf Exchange- und SharePoint-Server

SSRF-Ausnutzung

Server-Side Request Forgery (SSRF) kann es Angreifern ermöglichen, nicht autorisierte Anfragen im Namen des Servers zu stellen, wodurch sie möglicherweise auf interne Dienste und Metadaten-Endpunkte zugreifen oder sogar ihre Berechtigungen erweitern können. Angreifer können SSRF ausnutzen, um Authentifizierungsmechanismen zu umgehen, indem sie interne API-Aufrufe nutzen. Darüber hinaus könnten Angreifer durch die Verkettung von SSRF mit weiteren Schwachstellen unbefugten Zugriff auf das Backend erlangen und willkürliche Remotecodeausführung innerhalb der Umgebung durchführen.

Ein Beispiel ist CVE-2023-29357, eine kritische Schwachstelle zur Umgehung der Authentifizierung in SharePoint Server. Diese Schwachstelle ermöglichte es Angreifern, die Authentifizierung zu umgehen und erweiterte Berechtigungen zu erlangen, indem sie die unsachgemäße Validierung von Sicherheitstoken ausnutzten. Bei Angriffen wurde dies mit einer weiteren Schwachstelle, CVE-2023-24955, kombiniert, um eine nicht authentifizierte Ausführung von Remote-Code auf anfälligen SharePoint-Servern zu erreichen.

AMSI fungierte als erste Verteidigungslinie gegen diese Vorfälle und schützte die Kunden vor Tausenden von SSRF-Versuchen, die täglich beobachtet wurden, und durchbrach so die Ausbeutungskette.

Verdächtiger Zugriff auf Mailboxen durch Missbrauch von Exchange Web Services (EWS)

Exchange Web Services (EWS) ist eine Kernkomponente von Microsoft Exchange, die den programmgesteuerten Zugriff auf Mailboxen über SOAP-basierte APIs ermöglicht. Während dies für legitime Vorgänge wie die Outlook-Integration, die mobile Synchronisierung und Drittanbieter-Apps von entscheidender Bedeutung ist, wird der Dienst auch häufig von Bedrohungsakteuren missbraucht. Insbesondere bei Vorfällen wie CVE-2023-23397 wurde EWS nach der Kompromittierung verwendet, um Postfächer nach sensiblen Inhalten zu durchsuchen und E-Mails über HTTPS zu exfiltrieren, wobei es sich in den legitimen Datenverkehr einfügte.

Angreifer nutzen den tiefen Zugriff von EWS, um Postfachsuchen durchzuführen, ganze Posteingänge herunterzuladen und versteckte Weiterleitungsregeln einzurichten, wobei sie häufig gestohlene Anmeldedaten verwenden oder sich über eine andere Exchange-Schwachstelle Zugang verschaffen. Angreifer missbrauchen häufig EWS-APIs – GetFolder, FindItem und GetItem –, um heimlich nach sensiblen E-Mails in kompromittierten Postfächern zu suchen und diese zu exfiltrieren. Die GetFolder-API bildet die Postfachstruktur ab, die zur Identifizierung wichtiger Ordner wie „Posteingang“ und „Gesendete Elemente“ verwendet werden kann. Die FindItem-API ermöglicht die Suche nach E-Mails, die bestimmte Schlüsselwörter oder einen bereitgestellten Datums-/Zeitfilter enthalten, um relevante Ergebnisse abzurufen. Schließlich wird die GetItem-API verwendet, um vollständige E-Mail-Inhalte und Anhänge anzuzeigen.

Diese API-gesteuerte Missbrauchstechnik verschmilzt mit dem legitimen EWS-Verkehr, was eine Erkennung ohne eingehende Inhaltsprüfung schwierig macht. AMSI begegnet diesem Problem mit dem Scannen des Anfragetextes, wodurch verdächtige Suchmuster, ungewöhnliche Zugriffe und gezielter E-Mail-Diebstahl in Echtzeit erkannt werden können. Nachfolgend finden Sie eine Abfolge verdächtiger SOAP-Aufrufe, die von AMSI protokolliert wurden, als Angreifer versuchten, E-Mails zu exfiltrieren.

Unsichere Deserialisierung führt zu RCE

Der PowerShell-Anwendungspool ist eine privilegierte Komponente, die PowerShell-Remotesitzungen in Exchange verarbeitet und in der Regel von der Exchange-Systemsteuerung (ECP) oder der Exchange-Verwaltungsshell (EMS) aufgerufen wird. Er wird unter SYSTEM oder hochprivilegierten Dienstkonten ausgeführt, was ihn zu einem Hauptziel für Missbrauch macht. Nachdem sie sich Zugriff auf Backend-PowerShell-Endpunkte verschafft haben, können Angreifer manipulierte Cmdlets und Argumente weitergeben, die Vorgänge wie das willkürliche Schreiben von Dateien und die Ausführung von Befehlen auslösen. Diese Methode wurde bei größeren Vorfällen wie ProxyShell und ProxyNotShell beobachtet, bei denen Angreifer Befehle auf Systemebene über manipulierte PowerShell-Anfragen ausführen.

Ein häufiges Muster bei diesen Angriffen ist die Verwendung legitimer Verwaltungs-Cmdlets wie Get-Mailbox, New-MailboxExportRequest oder Set-, jedoch mit manipulierten Argumenten oder bösartigen Serialisierungspaketen, die die Ausführung von Code im Backend auslösen. AMSI hat nun vollständige Transparenz über alle Backend-PowerShell-Befehle zusammen mit den übergebenen Argumenten, um den Anforderungspuffer auf verdächtige API-Aufrufe wie Process.Start, verschiedene Dateischreib-APIs und Assembly.load zu untersuchen.

Missbrauch der Websteuerung

Die Ausnutzung von Schwachstellen wie CVE-2024-38094, CVE-2024-38024 und CVE-2024-38023 sind Beispiele für Angriffe, bei denen die Berechtigungen des Website-Eigentümers missbraucht werden, um beliebigen Code auf dem SharePoint-Server auszuführen. Bei der Ausnutzung werden die Business Data Connectivity (BDC)-Funktion und die böswillige Verwendung der Datei BDCMetadata.bdcm ausgenutzt. Diese XML-basierte Datei definiert Verbindungen zu externen Datenquellen, könnte aber missbraucht werden, um auf gefährliche .NET-Klassen und -Methoden zu verweisen. Sobald die schädliche .bdcm-Datei hochgeladen und im BDC-Dienst von SharePoint registriert ist (mit den Berechtigungen des Website-Eigentümers), kann der Angreifer die Ausführung auslösen, indem er eine externe Liste oder ein Webpart erstellt, das mit dem BDC-Modell interagiert. SharePoint verarbeitet dieses Modell und lädt und führt die angegebene Methode reflexartig aus, was zu einer RCE als SharePoint-Dienstkonto führt, das in der Regel über hohe Berechtigungen verfügt. Bei aktiviertem Body Scan steht die gesamte Nutzlast zur Überprüfung zur Verfügung und zeigt den Typ LobSystem als DotNetAssembly an, was auf eine Codeausführung hindeutet. Die tiefe Integration von AMSI ermöglicht Einblicke in den schädlichen Base64-Puffer, den Microsoft Defender for Endpoint nutzt, um Versuche der Codeausführung zu erkennen und zu blockieren.

Leitfaden für Schadensbegrenzung und Schutz

Wie diese Angriffe zeigen, sind SharePoint- und Exchange-Server hochkarätige Ziele. Bei diesen Angriffen handelt es sich in der Regel um fortgeschrittene Bedrohungen mit äußerst ausweichenden Techniken. Es ist von größter Bedeutung, diese Server vor diesen fortgeschrittenen Angriffen zu schützen. Hier sind einige Schritte, die Organisationen unternehmen können:

• Aktivieren Sie AMSI auf Exchange Server und SharePoint Server. AMSI ist ein vielseitiger Standard, der die Integration von Anwendungen und Diensten in jedes AMSI-fähige Anti-Malware-Produkt ermöglicht, das auf einem Gerät vorhanden ist. Ab SharePoint Server Subscription Edition Version 25H1 erweitert AMSI seine Scan-Funktionen um die Inhalte von HTTP-Anfragen. Die Exchange AMSI-Funktion zum Scannen von Inhalten wurde mit dem Exchange Server November 2024 Security Update (SU) eingeführt. Microsoft empfiehlt, Exchange Server und SharePoint Server auf diese Versionen oder höher zu aktualisieren, um die Vorteile der neuen verbesserten Funktion zum Scannen des Textkörpers zu nutzen. Diese Funktion zum Scannen des Textkörpers von Anfragen ist für die Erkennung und Eindämmung von Bedrohungen, die in Anfragelasten eingebettet sein können, von entscheidender Bedeutung und bietet eine umfassendere Sicherheitslösung. Prüfen Sie die Voraussetzungen und erfahren Sie in den folgenden Ressourcen, wie Sie AMSI konfigurieren:
  • AMSI-Integration mit Exchange Server
  • AMSI-Integration mit SharePoint Server konfigurieren
• Installieren Sie die neuesten Sicherheitsupdates. Ermitteln und beheben Sie Schwachstellen oder Fehlkonfigurationen in Exchange und SharePoint Server. Installieren Sie die neuesten Sicherheitsupdates, sobald sie verfügbar sind. Verwenden Sie das Threat and Vulnerability Management, um diese Server regelmäßig auf Schwachstellen, Fehlkonfigurationen und verdächtige Aktivitäten zu überprüfen.
• Lassen Sie Antivirus- und andere Schutzmaßnahmen aktiviert. Es ist wichtig, SharePoint- und Exchange-Server mit Antivirus-Software und anderen Sicherheitslösungen wie Firewall-Schutz und MFA zu schützen. Aktivieren Sie den Cloud-basierten Schutz und die automatische Übermittlung von Mustern, um mithilfe künstlicher Intelligenz und maschinellen Lernens neue und unbekannte Bedrohungen schnell zu erkennen und zu stoppen. Verwenden Sie Regeln zur Reduzierung der Angriffsfläche, um Verhaltensweisen wie den Diebstahl von Anmeldeinformationen und die verdächtige Verwendung von PsExec und WMI automatisch zu blockieren. Aktivieren Sie die Funktionen zum Schutz vor Manipulationen, um zu verhindern, dass Angreifer Sicherheitsdienste stoppen. Wenn Sie befürchten, dass diese Sicherheitskontrollen die Leistung beeinträchtigen oder den Betrieb stören könnten, wenden Sie sich an IT-Experten, um die tatsächlichen Auswirkungen dieser Einstellungen zu ermitteln. Sicherheitsteams und IT-Experten sollten bei der Anwendung von Abhilfemaßnahmen und geeigneten Einstellungen zusammenarbeiten.
• Überprüfen Sie sensible Rollen und Gruppen. Überprüfen Sie hoch privilegierte Gruppen wie Administratoren, Remotedesktopbenutzer und Unternehmensadministratoren. Angreifer fügen diesen Gruppen Konten hinzu, um auf einem Server Fuß zu fassen. Überprüfen Sie diese Gruppen regelmäßig auf verdächtige Hinzufügungen oder Entfernungen. Um Exchange/SharePoint-spezifische Anomalien zu identifizieren, überprüfen Sie die Liste der Benutzer in sensiblen Rollen.
• Schränken Sie den Zugriff ein. Wenden Sie das Prinzip der geringsten Privilegien an und achten Sie auf die Sicherheit der Anmeldedaten. Vermeiden Sie die Verwendung von domänenweiten Administratorkonten. Erzwingen Sie starke zufällige, lokale Administratorpasswörter und aktivieren Sie die mehrstufige Authentifizierung. Verwenden Sie Tools wie LAPS.
• Priorisieren Sie Warnmeldungen. Die charakteristischen Muster von SharePoint- und Exchange-Server-Kompromittierungen helfen dabei, bösartige Verhaltensweisen zu erkennen und Sicherheitspersonal zu informieren, damit dieses schnell auf die ersten Phasen der Kompromittierung reagieren kann. Achten Sie auf Warnmeldungen, die auf verdächtige Aktivitäten hinweisen, und gehen Sie diesen sofort nach. Es ist von entscheidender Bedeutung, Angriffe in der Erkundungsphase zu erkennen, also in dem Zeitraum, in dem Angreifer nach dem Zugriff mehrere Tage damit verbringen, die Umgebung zu erkunden. Öffentlich zugängliche Anwendungspools werden häufig von Angreifern durch die Bereitstellung von Web-Shells gekapert. Priorisieren Sie Warnmeldungen im Zusammenhang mit Prozessen wie net.exe, cmd.exe und powershell.exe, die aus diesen Pools stammen, oder w3wp.exe im Allgemeinen.

Microsoft Defender XDR-Erkennungen

Microsoft Defender XDR-Kunden können sich auf die untenstehende Liste der zutreffenden Erkennungen beziehen. Microsoft Defender XDR koordiniert die Erkennung, Prävention, Untersuchung und Reaktion auf Endpunkten, Identitäten, E-Mails und Apps, um einen integrierten Schutz vor Angriffen wie der in diesem Blog beschriebenen Bedrohung zu bieten.

Kunden mit bereitgestelltem Zugriff können auch Microsoft Security Copilot in Microsoft Defender verwenden, um Vorfälle zu untersuchen und darauf zu reagieren, nach Bedrohungen zu suchen und ihr Unternehmen mit relevanten Bedrohungsinformationen zu schützen.

Microsoft Defender Antivirus

Microsoft Defender Antivirus erkennt Bedrohungen auf SharePoint Server als folgende Malware:

• Exploit:Script/SPLobSystemRCE.A
• Exploit:Script/SPLobSystemRCE.B
• Exploit:Script/SPAuthBypass.A

Microsoft Defender Antivirus erkennt Bedrohungen auf Exchange Server als folgende Malware:

• Exploit:Script/SuspMailboxSearchEWS.A
• Exploit:Script/SuspExchgSession.D
• Exploit:Script/ExchgProxyRequest

Microsoft Defender für Endpunkte

Die folgenden Microsoft Defender for Endpoint-Warnungen können auf Aktivitäten im Zusammenhang mit den in diesem Blog behandelten Bedrohungen hinweisen. Beachten Sie jedoch, dass diese Warnungen auch durch nicht damit zusammenhängende Bedrohungsaktivitäten ausgelöst werden können.

• Mögliche Web-Shell-Installation
• Mögliche IIS-Web-Shell
• Verdächtige Prozesse, die auf eine Web-Shell hinweisen
• Mögliche IIS-Kompromittierung
• Verdächtige Exchange-Prozessausführung
• Mögliche Ausnutzung von Exchange Server-Schwachstellen

Microsoft Security Exposure Management

Microsoft Security Exposure Management (MSEM) bietet Kunden eine verbesserte Sichtbarkeit wichtiger Assets, indem es vordefinierte Klassifizierungslogiken für hochwertige Assets bereitstellt. Dies umfasst sowohl verwaltete (Microsoft Defender für Endpoint-onboarded) als auch nicht verwaltete Exchange-Server.

Kunden können den Gerätebestand und die kritische Klassifizierungsbibliothek überprüfen, um Exchange-Server zu identifizieren und die Anwendung der neuen Sicherheitseinstellungen auf diese in Betracht zu ziehen.

Microsoft Security Copilot

Security Copilot-Kunden können die eigenständige Erfahrung nutzen, um ihre eigenen Eingabeaufforderungen zu erstellen, oder die folgenden vorgefertigten Eingabeaufforderungsbücher ausführen, um die Reaktion auf Vorfälle oder Untersuchungsaufgaben im Zusammenhang mit dieser Bedrohung zu automatisieren:

• Untersuchung von Vorfällen
• Microsoft-Benutzeranalyse
• Profil des Bedrohungsakteurs
• Threat Intelligence 360-Bericht basierend auf dem MDTI-Artikel
• Bewertung der Auswirkungen von Schwachstellen

Beachten Sie, dass einige Eingabeaufforderungsbücher den Zugriff auf Plugins für Microsoft-Produkte wie Microsoft Defender XDR oder Microsoft Sentinel erfordern.

Microsoft Sentinel

Microsoft Sentinel-Kunden können die TI-Mapping-Analysen (eine Reihe von Analysen, denen alle das Präfix „TI map“ vorangestellt ist) verwenden, um die in diesem Blogbeitrag erwähnten Indikatoren für bösartige Domänen automatisch mit Daten in ihrem Arbeitsbereich abzugleichen. Wenn die TI-Map-Analysen derzeit nicht bereitgestellt werden, können Kunden die Threat Intelligence-Lösung aus dem Microsoft Sentinel Content Hub installieren, um die Analyseregel in ihrem Sentinel-Arbeitsbereich bereitzustellen.

Unser Beitrag über die Web-Shell-Bedrohungsjagd mit Microsoft Sentinel enthält auch eine Anleitung zur allgemeinen Suche nach Web-Shells. Die Exchange SSRF Autodiscover ProxyShell-Erkennung, die als Reaktion auf ProxyShell erstellt wurde, kann aufgrund funktionaler Ähnlichkeiten mit dieser Bedrohung für Abfragen verwendet werden. Außerdem suchen die neuen Exchange Server Suspicious File Downloads und Exchange Worker Process Making Remote Call-Abfragen speziell nach verdächtigen Downloads oder Aktivitäten in IIS-Protokollen. Zusätzlich zu diesen haben wir noch einige weitere, die bei der Suche nach Aktivitäten nach der Ausnutzung hilfreich sein könnten:

• Exchange OAB-Attribut des virtuellen Verzeichnisses, das eine potenzielle Web-Shell enthält
• Web-Shell-Aktivität
• Böswillige Webanwendungsanfragen, die mit Microsoft Defender for Endpoint-Warnungen verknüpft sind
• Exchange IIS-Worker, der Web-Shell löscht
• Web-Shell-Erkennung
• MailSniper-Aktivität erkennen

Erfahren Sie mehr

Die neuesten Sicherheitsforschungsergebnisse der Microsoft Threat Intelligence-Community finden Sie im Microsoft Threat Intelligence-Blog: https://aka.ms/threatintelblog.

Um über neue Veröffentlichungen informiert zu werden und an Diskussionen in den sozialen Medien teilzunehmen, folgen Sie uns auf LinkedIn unter https://www.linkedin.com/showcase/microsoft-threat-intelligence und auf X (ehemals Twitter) unter https://x.com/MsftSecIntel.

Um Geschichten und Einblicke aus der Microsoft Threat Intelligence-Community über die sich ständig weiterentwickelnde Bedrohungslandschaft zu hören, hören Sie sich den Microsoft Threat Intelligence-Podcast an: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

VOLLSTÄNDIGER BERICHT in englischer Sprache hier.

---

Bild/Quelle: https://depositphotos.com/de/home.html