af Bhabesh Raj Rai, Security Research

Den 29. september 2022 bekræftede Microsoft rapporter om modstandere, der udnytter to zero-day sårbarheder, som påvirker Microsoft Exchange-servere: CVE-2022-41040 (CVSSv3-score på 6,3) og CVE-2022-41082 (CVSSv3-score på 8,8). Førstnævnte er en sårbarhed over for Server-Side Request Forgery (SSRF), mens sidstnævnte tillader fjernkodeudførelse (RCE), når PowerShell er tilgængelig for modstanderen. Modstandere skal have autentificeret adgang til Exchange-serveren for at udnytte begge sårbarheder.

Den vietnamesiske teknologivirksomhed GTSC opdagede disse fejl tilbage i august, og den 28. september udgav den en blog med flere detaljer. Dagen efter gav Microsoft kunderne vejledning i at opdage og afhjælpe truslerne. Både Microsoft og GTSC observerede modstandere, der installerede den populære China Chopper-webshell ved hjælp af angrebskæden.

Sårbarhederne minder meget om de ProxyShell-sårbarheder, der blev opdaget i 2021. Sikkerhedsforsker Kevin Beaumont har givet dem øgenavnet ProxyNotShell på grund af deres lighed med ProxyShell, hvor hovedforskellen er, at ProxyNotShell kræver godkendelse.

Hurtige fakta om ProxyNotShell

  • Kræver godkendt adgang til Exchange-serveren
  • Berører kun Exchange-servere på stedet (2013/2016/2019)
  • Der er ingen patch tilgængelig i øjeblikket
  • Modstanderne kæder de to zero-days til at aflevere web shells
  • Microsoft observerede angreb i færre end 10 organisationer på verdensplan

Detekter udnyttelse af ProxyNotShell ved hjælp af Logpoint

Udfør IoC-sweeps for ProxyNotShell ved hjælp af logfiler fra august og fremefter.

(source_address IN [137.184.67.33, 125.212.220.48, 5.180.61.17, 47.242.39.92, 61.244.94.85, 86.48.6.69, 86.48.12.64, 94.140.8.48, 94.140.8.113, 103.9.76.208, 103.9.76.211, 104.244.79.6, 112.118.48.186, 122.155.174.188, 125.212.241.134, 185.220.101.182, 194.150.167.88, 212.119.34.11, 206.188.196.77]
destination_address IN [137.184.67.33, 125.212.220.48, 5.180.61.17, 47.242.39.92, 61.244.94.85, 86.48.6.69, 86.48.12.64, 94.140.8.48, 94.140.8.113, 103.9.76.208, 103.9.76.211, 104.244.79.6, 112.118.48.186, 122.155.174.188, 125.212.241.134, 185.220.101.182, 194.150.167.88, 212.119.34.11, 206.188.196.77])
(hash IN [c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1, 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5, b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca, be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257, 074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82, 45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9, 9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0, 29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3, c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2, 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e]
OR hash_sha256 IN [c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1, 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5, b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca, be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257, 074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82, 45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9, 9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0, 29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3, c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2, 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e])

Exchange understøtter siden juni 2021 integration med Antimalware Scan Interface (AMSI).  Vi anbefaler Exchange-administratorer at sikre, at alle opdateringer er installeret, og at AMSI-scanning fungerer. Administratorer bør også kontrollere, om de har placeret Exchange-mapper i AV-udeladelser af hensyn til ydeevnen.

label=Threat label=Detect 
threat IN ["Backdoor:ASP/Webshell.Y", "Backdoor:Win32/RewriteHttp.A", "Backdoor:JS/SimChocexShell.A!dha", "Behavior:Win32/IISExchgDropWebshell.A!dha", "Behavior:Win32/IISExchgDropWebshell.A", "Trojan:Win32/IISExchgSpawnCMD.A", "Trojan:Win32/WebShellTerminal.A", "Trojan:Win32/WebShellTerminal.B"]

Analytikere skal se efter artefakter fra chopperens web shell i procesoprettelseslogs.

label="Process" label=Create
parent_process="*\w3wp.exe" command IN ["*&ipconfig&echo*", "*&quser&echo*", "*&whoami&echo*", "*&c:&echo*", "*&cd&echo*", "*&dir&echo*", "*&echo [E]*", "*&echo [S]*"]

Ligeledes råder vi analytikere til at søge efter mistænkelige underordnede processer af w3wp.exe.

label="Process" label=Create parent_process="*\w3wp.exe"
-process IN ["*\WerFault.exe", "*\csc.exe"]
| chart count() by log_ts, user, "process", parent_command, command

Som nævnt i GTSC-rapporten har angriberne brugt certutil til at downloade web shells.

label="Process" label=Create process="*\certutil.exe" 
command IN ["* -urlcache *", "* /urlcache *"]

På samme måde søges der efter mistænkelige filoprettelser i PerfLogs eller offentlige biblioteker, som angribere normalt bruger til at huse downloadede payloads.

norm_id=WindowsSysmon event_id=11
path IN ["C:\Users\Public*", "C:\PerfLogs*", "C:\root*"]

Detekteringer til ProxyShell fungerer også for ProxyNotShell. Kunder kan bruge eksisterende ProxyShell-alarmer, der findes i i Logpoint Alert Rules-applikationen. Som nævnt i Microsofts blog brugte modstandere China Chopper-webshell til at udføre AD-rekognoscering, og Alert Rules-applikationen dækker de nødvendige TTP’er.

Implementér afhjælpningsmuligheder med det samme

Vi råder Exchange-administratorer til at vurdere og implementere enhver af de tre afhjælpningsmuligheder, som Microsoft gav i deres kundevejledning til ProxyNotShell, så hurtigt som muligt. Microsoft udgav også et script til at implementere afhjælpningerne for SSRF-vektor CVE-2022-41040 på de berørte Exchange-servere.

Analytikere bør overvåge udnyttelsesforsøg, indtil Microsoft frigiver patches til ProxyNotShell. Vi råder analytikere til løbende at holde øje med web shells, fordi detektering af aktivitet efter udnyttelsen kan hjælpe med at afdække zero-day- eller N-day-sårbarheder.

Vi opdaterer bloggen, efterhånden som situationen udvikler sig.

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint:

Contact Logpoint