Web shell gedetecteerd op server [CHK-3029]

Reden

Een web shell is remote access die er niet uitziet als remote access. Er luistert geen nieuwe service, er is geen ongebruikelijke uitgaande verbinding, er is geen logon event: de aanvaller vraagt simpelweg een pagina op via HTTPS, op poort 443, door dezelfde webserver die uw legitieme site bedient. Voor een firewall is het gewoon webverkeer.

Web shells zijn meestal een gevolg en niet een oorzaak. Iets stelde de aanvaller eerst in staat een bestand in de web root te schrijven: een ongepatchte kwetsbaarheid in de applicatie of serversoftware, een blootgestelde uploadfunctie, of gestolen beheerderscredentials. Het vinden van de shell betekent dat die initiële zwakte al is misbruikt, en dat die er nog steeds is tenzij u hem ook vindt.

Daarnaast zijn ze een persistence-mechanisme, en dat maakt ze urgent. Een web shell overleeft wachtwoordresets en herstarts, en geeft een aanvaller een betrouwbare weg terug lang nadat de oorspronkelijke kwetsbaarheid is gepatcht. Op een domain-joined server is het regelmatig het pivotpunt naar het interne netwerk. Alleen het bestand verwijderen is niet voldoende.

Opvolging

Voer deze stappen uit om deze detectie adequaat op te volgen:

1. Isoleer eerst de server. Isoleer de betrokken machine in Microsoft Defender. Een web shell is actieve toegang, en de prioriteit is die afsluiten vóór onderzoek. Zou isolatie een bedrijfskritische dienst platleggen, beperk de server dan op netwerk- of WAF-niveau terwijl u werkt.
2. Bepaal wat er via de shell is gedaan. Dat is belangrijker dan het bestand zelf:
   1. Bekijk de logs van de webserver op verzoeken aan het pad van de shell. Die laten zien wanneer hij voor het eerst is gebruikt, vanaf welke adressen en hoe vaak. Het eerste gebruik ligt normaal gesproken dicht bij de initiële compromise.
   2. Bekijk process creation op de server rond en na dat tijdstip. Commando's via een web shell verschijnen als child processes van het webserverproces (w3wp.exe, php-fpm, httpd).
   3. Zoek naar lateral movement en credential access vanaf die server, en beschouw iedere credential die erop stond of werd gebruikt als blootgesteld.
3. Zoek uit hoe de shell er is gekomen. Zoek de upload: een ongepatchte applicatie, een blootgesteld upload-endpoint, of een gestolen beheerdersaccount. De shell verwijderen zonder de toegangsweg te sluiten betekent dat hij terugkomt.
4. Zoek naar meer. Web shells worden zelden alleen geplaatst. Vergelijk de web root met een bekende goede deployment of met source control, en zoek naar recent gewijzigde bestanden in de gehele boom in plaats van alleen daar waar de detectie afging.
5. Herbouw in plaats van op te schonen, waar dat kan. De applicatie opnieuw uitrollen vanuit source op een schone server is de enige manier om zeker te zijn over wat er achterblijft. Moet de server ter plekke worden opgeschoond, beschouw dat dan als een tijdelijke maatregel.
6. Escaleer naar IR. Neem contact op met Attic voor incident response ondersteuning. Een bevestigde web shell op een internetgerichte server rechtvaardigt volledig onderzoek. Dit is een van de detecties waarbij de bevinding vrijwel nooit het hele verhaal is.

Meer informatie

• Microsoft Learn: Investigate incidents in Microsoft Defender XDR
• Microsoft Learn: Take response actions on a device
• Microsoft Security Blog: Web shell attacks continue to rise
• MITRE ATT&CK: T1505.003 - Server Software Component: Web Shell
• MITRE ATT&CK: T1190 - Exploit Public-Facing Application