Cómo evadir AMSI haciendo uso de DLL Hijacking

Nola saihestu AMSI DLL bahiketa erabiliz



Oso ona guztiontzat! Gaur AMSIren munduari buruzko azken atal batekin gatoz (oraingoz). Oraingo honetan, DLL bahiketa izeneko teknika erabiliz AMSI nola saihestu dezakegun ezagutuko dugu. 

Binario bat esteka dinamikoekin konpilatzen denean, sistema eragileak DLL espezifikoa bilatuko du exekuzio denborako funtzionalitate bat estaltzeko. Kasu askotan, DLLrako esteka ez da bide osoarekin definitzen, izenarekin baizik. 

Honi esker, Windows-ek, bere bilaketa-moduaren bidez, esteka horretan bitarrak zein DLL kargatu nahi duen interpreta dezake. Bilaketa-ordena honako hau da:

  • Exekutatzen ari den aplikazioa dagoen direktorioa
  • C:\Windows\System32
  • C:\Windows\System
  • C:\Windows
  • Non dagoen direktorioa
  • %PATH% ingurune-aldagaian dagoen edozer

Hori dela eta, Windows-ek funtzionatzen duen modu honetan, diskoaren nonbait idazteko sarbidea duen edonork AMSI saihes dezake. Zeren? PowerShell kopiatu ahal badugu idazteko baimenak ditugun leku batean edukitzeko, eta amsi.dll izeneko fitxategi bat sortzen badugu, PowerShell hori irekitzen denean, DLL hori kargatuko du lehentasunez. 

Hurrengo adibidean ikus dezakegu nola, PowerShell mahaigaina bezalako leku batean edukita, amsi.dll leku beretik kargatu dezakegun.


Teknika hau erabiltzeko baldintza bakarra DLL bat edukitzea da (C/C++-n sortua) funtzioak benetako DLLaren modu berean definituta dituena. Hau da, ez da beharrezkoa funtzionaltasuna berdina izatea, baina PowerShell-entzat, funtzioaren deia modu berean eman behar da: izen berdinarekin eta argumentu berdinekin.

64 biteko PowerShell direktorio honetan aurki daiteke:

  • C:\Windows\System32\WindowsPowerShell\v1.0
32 biteko PowerShell direktorio honetan aurki daitekeen arren:
  • C:\Windows\SysWOW64\WindowsPowerShell\v1.0

Zeregin hau burutzeko modu erraz bat jatorrizko DLL-a adabakitzea da. Beste era batera esanda, amsi.dll hartu eta dagozkion argibideak alda genitzake jatorrizko funtzionalitatea gal ez dadin, eta ez du inoiz malwarerik itzuliko.

Aurretik AMSI Funtzioak argitalpenean AMSI funtzio bakoitza zertarako zen azaldu genuen.

Badakigu AmsiScanBuffer-ek HRESULT bat itzultzen duela, hau da, funtzioa ondo exekutatu den ala ez adierazten duen kodea. AmsiScanBuffer beti 0x80070057 itzultzeko aldatzen badugu, AMSIk funtzionatzeari utziko dio eta saihestu egingo dugu.

Hurrengo irudia AmsiScanBuffer funtzioaren zati bat da. 



Lehenengo baldin etak oinarrizko balioztatze sorta bat egiten du eta gainditzen badu, argumentuak baliogabe eman direla eta eskaneatzea ezinezkoa izango dela esan nahi du, beraz, uVar2 0x80070057 gisa ezartzen du.

Baina zer gertatuko litzateke else uVar2 barruan ere 0x80070057 gisa ezarriko balitz? Erantzuna da AMSIk ondo funtzionatzeari utziko liokeela, izan ere, AMSI Windows Defender-ekin buffera bidaltzeko komunikatzen bada ere, funtzioak INVALIDARG itzultzen badu, komandoa normalean exekutatuko da.

Muntatzailean, itzuleran balio bat itzultzeko, edukia itzulera-erregistro batean kargatu behar dugu, beraz, INVALIDARG itzultzeko, honako hau gehitu genezake:
  • MOV        EAX,0x80070057
ghidra erabiltzen baduzu, deskonpilatu atalean, interesatzen zaigun zatia hautatuz, dagokion mihiztatzailea non dagoen ikus dezakegu. Funtzio hau beti INVALIDARG itzultzeko, azken deia alda dezakegu.



Hori dela eta, funtzioak honako itxura izango luke:



Azkenik, beharrezkoa izango litzateke DLL PE gisa esportatzea eta hori izango litzateke.


Eta honekin AMSIri agur esaten diogu momentuz. Gehiago nahi gabe geratu bazara, idatzi iezaguzu!


Justo MartínSecurity Analyst at Zerolynx.
Itzuli blogera

Utzi iruzkin bat

Kontuan izan iruzkinak argitaratu aurretik onartu behar direla.