Ausnutzung von Schwachstellen
XDR: Jagd nach Web Shell-Angreifer
Bei einem Sicherheitsvorfall gegen die Web Shell missbrauchten Angreifer den IIS Worker, um gestohlene Daten zu exfiltrieren. Wir haben die Attacke analysiert und zeigen den Ablauf. Dieses Wissen hilft dabei, die angemessenen Vorkehrungen zu treffen.
Save to Folio
Zusammenfassung:
- Inhalt ist die Trend Micro™ Managed XDR-Untersuchung und Reaktion auf einen Kundenvorfall. Unsere Endpunktsensoren entdeckten einen Internet Information Services IIS-Worker (w3wp.exe), der verdächtige Aktivitäten ausführte und somit das Team warnte.
- Der Angreifer konnte eine Web Shell auf den IIS-Worker, der zur Zeit des Angriffs keine Einschränkungen besaß, hochladen.
- Nach dem Zugang auf diesen öffentlich zugänglichen Server konnte der Täter ein neues Konto erstellen, um Persistenz zu erlangen, und das Passwort für einen bestehenden Benutzer ändern.
- Mit einem verschlüsselten PowerShell-Befehl war er in der Lage, eine Reverse-TCP-Shell zu erstellen, die eine Verbindung zu einer IP-Adresse herstellte, um Befehle zu erteilen und zu steuern.
Diese Incident Response von Trend Micro™ Managed XDR wurde von Trend Vision One™ ausgelöst, nachdem unsere Endpunktsensoren eine verdächtige Binärdatei entdeckt hatten, die vom IIS Worker-Prozess (w3wp.exe) ausgeführt wurde. Dieses Verhalten deutet auf eine potenzielle Ausnutzung des Webservers hin, möglicherweise im Zusammenhang mit nicht autorisierten Aktivitäten oder einer kompromittierten Umgebung.
Unsere Untersuchung ergab, dass die Angreifer eine Reverse-TCP-Shell verwendeten, um eine Command-and-Control-Verbindung herzustellen. Dies ließ sich durch weitere Filter feststellen, die durch das Modell IIS Worker Process Spawning Suspicious PowerShell Command ausgelöst wurden. Nachdem die Bedrohung eingedämmt worden war, führte Managed XDR eine Untersuchung durch, bei der mehrere Payloads aufgedeckt wurden, die in das Verzeichnis C:\Users\Public heruntergeladen wurden.
Bild 1. Vorfallsdiagramm
Erstzugriff
Der Bedrohungsakteur konnte eine Web Shell auf den Internet Information Services IIS Worker hochladen. Dieselbe Web Shell war zuvor an einem anderen Ort erstellt worden, doch der Täter interagierte nicht mit ihr. Wir ermittelten den Erstzugriff, indem wir die Anfragen analysierten, die der Webserver erhielt. Wir konnten den Quellhost identifizieren, der mit der Web Shell interagierte.
Erkundung
Der Täter nutzte POST-Anfragen an Web Shells und führte Discovery-Befehle (Systemeigentümer, Systeminformationen, Prozesse, Dateien/Verzeichnisse und Kontenermittlung) mit Hilfe von vorhandenen Systemtools durch: whoami, tasklist, systeminfo und type. Auch konnte er ein neues Konto für die Persistenz aufsetzen und das Passwort eines vorhandenen Nutzers ändern. Um nicht entdeckt zu werden, benannte der Angreifer die Web Shell um und tarnte sie als legitime Datei.
Command-and-Control
Der Angreifer verwendete einen verschlüsselten PowerShell-Befehl, um eine Reverse-TCP-Shell zu erstellen, die eine Verbindung zu einer IP-Adresse für C&C herstellte, sodass Befehle zum Herunterladen zusätzlicher Tools ausgeführt werden konnten.
Die Inhalte des Working-Verzeichnisses vom Webserver wurden über 7zip archiviert und die Datei dann über eigene IIS-Serverfunktion (mit einem GET Befehl) vom Host abgezogen. Danach löschte der Angreifer die zip-Datei, um die Spuren zu verwischen.
Alle technischen Einzelheiten sowie eine Analyse der gesammelten Dateien beinhaltet der Originalbeitrag.
Lösungen und Empfehlungen
Web Shells stellen eine verbreitete Bedrohung dar. Webserver-Besitzer sollten daher wachsam sein und sicherstellen, dass ihre Server bewährte Verfahren für das Sicherheitsmanagement und die Serverkonfiguration einhalten.
Die folgenden Punkte zeigen auf, wie das Managed XDR-Team auf den aktuellen Vorfall reagiert hat:
- Response-Aktionen für die Eindämmung und Beseitigung der Bedrohung
Nach der Entdeckung zusätzlicher Payloads der Bedrohung isolierten wir den Endpunkt umgehend, um die Bedrohung einzudämmen und zu verhindern, dass sie weitere Hosts befällt. Diese zusätzlichen Payloads wurden vom Team gesammelt, untersucht und zur fachgerechten Untersuchung an das Analyseteam weitergeleitet. Es wurden remote zusätzliche Serverprotokolle gesammelt, um die mit den Web Shells verbundenen Aktivitäten zu untersuchen.
- Maßgeschneiderte Maßnahmen und Empfehlungen auf Grundlage des Vorfalls
Aus den Ergebnissen der Untersuchungen und der Kommunikation mit dem Kunden geht hervor, dass die Quelle des Web Shell-Uploads anscheinend von nicht eingeschränkten Upload von Dateien auf dem Server stammt. Wir empfahlen, die Seiten bis zur ordnungsgemäßen Dateiprüfung zu deaktivieren, den Datei-Upload einzuschränken und eine entsprechende Autorisierung für die Upload-Funktionalität einzurichten.
Während der Untersuchung stellten wir außerdem fest, dass der Host keinen ordnungsgemäßen Sicherheitsagenten (Endpoint Protection Platform) installiert hatte. Die Installation geeigneter Sicherheitsagenten kann Auswirkungen verhindern und abschwächen, da sie Web Shells bei der Ankunft erkennen.
- Telefonat mit dem Kunden und Incident Report
Um den Vorfall, die Auswirkungen der Bedrohung und die erforderlichen Maßnahmen besser zu verstehen, wurde ein Telefonat mit dem Kunden geführt. Außerdem erstellten wir einen Vorfallsbericht mit den Ergebnissen der Analyse und Empfehlungenals Referenzdokument für den Kunden.
Zum Schutz vor ähnlichen Bedrohungen empfehlen wir die folgenden Sicherheitsmaßnahmen, um Organisationen und Unternehmen bei der wirksamen Abwehr von Web Shell-Angriffen zu unterstützen:
- Validieren und Bereinigen des Inputs. Stellen Sie sicher, dass der gesamte Input auf den Webseiten validiert und bereinigt ist, um einen Injection-Angriff zu vermeiden.
- Implementieren eines Authentifizierungsprozesses und Einschränken des Zugangs. Implementieren Sie starke Authentifizierungsmethoden für jeden sensiblen Endpunkt und schränken Sie den Zugriff auf ausschließlich autorisierte Nutzer ein.
- Patchen der Systeme und Anwendungen. Überprüfen Sie Ihre Server und Webanwendungen auf bekannte Schwachstellen. Stellen Sie sicher, dass die neuesten Sicherheitspatches aufgespielt sind, vor allem auf Web Frameworks oder Serversoftware wie IIS.
- Stellen Sie sicherstellen, dass Security-Produkte nach Best Practices konfiguriert sind. Stellen Sie sicher, dass alle vorhandenen Sicherheits-Tools, etwa Endpoint Detection, Firewalls und Monitoringsysteme, entsprechend der Best Practices des Anbieters konfiguriert und aktualisiert sind.
Der Originalbeitrag umfasst zusätzlich Indicators of Compromise und für Trend Micro-Kunden Threat Intelligence Reports.