Com evadir AMSI fent ús de DLL Hijacking
Celia Catalán.jpg)
Molt bones a tots! Avui venim amb una darrera entrega (de moment) sobre el món de l'AMSI. En aquesta ocasió, descobrirem com podríem evadir l'AMSI fent ús d'una tècnica anomenada DLL hijacking.
Quan un binari està compilat amb enllaços dinàmics, el sistema operatiu cercarà la DLL específica per cobrir una funcionalitat en temps dexecució. Moltes vegades, l'enllaç a la DLL no es defineix amb el path complet, sinó només amb el nom.
Això fa que Windows, mitjançant el seu mode de cerca, interpreti quina és la DLL que el binari pretenia carregar en aquest enllaç. L'ordre de cerca és el següent:
- El directori on hi ha l'aplicació que s'està executant
- C:\Windows\System32
- C:\Windows\System
- C:\Windows
- El directori on es troba
- Tot el que hi hagi a la variable d'entorn %PATH%
Per tant, per culpa daquest funcionament de Windows, qualsevol persona amb accés descriptura en algun lloc del disc podria evadir AMSI. Per què? Perquè si podem copiar la PowerShell per tenir-la en un lloc on tinguem permisos d'escriptura, i creem un fitxer anomenat amsi.dll, en el moment que s'obri aquesta PowerShell, carregarà aquesta DLL per tema de preferència.
En el següent exemple podem veure com, tenint la PowerShell en un lloc com lescriptori, podem fer que carregui amsi.dll daquest mateix lloc.
L'únic requisit per utilitzar aquesta tècnica és tenir una DLL (creada a C/C++) que tingui les funcions definides de la mateixa manera que la DLL real. És a dir, no cal que la funcionalitat sigui la mateixa, però amb vista a la PowerShell, la crida a la funció s'ha de donar de la mateixa manera: amb el mateix nom i els mateixos arguments.
PowerShell de 64 bits es pot trobar al següent directori:
- C:\Windows\System32\WindowsPowerShell\v1.0
Mentre que PowerShell de 32 bits es pot trobar al següent directori:
- C:\Windows\SysWOW64\WindowsPowerShell\v1.0
Una manera senzilla de realitzar aquesta tasca és mitjançant el pegat de la DLL original. En altres paraules, podríem prendre amsi.dll i canviar les instruccions pertinents perquè es perdi la funcionalitat original, i no torneu mai que hi ha malware.
Anteriorment al post Funcions AMSI expliquem per a què servia cada funció d'AMSI.
Sabem que AmsiScanBuffer torna un HRESULT, que és un codi que representa si la funció s'ha executat amb èxit o no. Si canviem AmsiScanBuffer perquè sempre torni 0x80070057, AMSI deixarà de funcionar i ho haurem evadit.
La imatge següent és una part de la funció AmsiScanBuffer.
El primer if fa una sèrie de validacions bàsiques i si les compleix, vol dir que els arguments s'han proporcionat de forma invàlida i no es podrà realitzar l'escaneig, per la qual cosa s'utilitza uVar2 a 0x80070057.
Però, què passaria si dins del els també se seteja uVar2 a 0x80070057? La resposta és que AMSI deixaria de funcionar correctament, perquè, malgrat que AMSI es comuniqui amb Windows Defender per enviar el buffer, si la funció torna INVALIDARG, l'ordre s'executarà de manera normal.
En assemblador, per tornar un valor en un return, hem de carregar el contingut en un registre de tornada, per tant, per tornar INVALIDARG, podríem afegir el següent:
- MOV EAX,0x80070057
Si utilitzes ghidra, seleccionant a la part del decompile, la part que ens interessa, podem veure on es troba el seu assemblador corresponent. Per a pedagar aquesta funció i que sempre torni INVALIDARG, podem canviar l'últim call.
Per tant, la funció quedaria com la següent:
Finalment, quedaria exportar la DLL com a PE i ja estaria.
