F#ck AMSI! Как обходят Anti-Malware Scan Interface при заражении Windows

Аб­бре­виату­ра AMSI рас­шифро­выва­ется как Anti-Malware Scan Interface. Эту тех­нологию Microsoft раз­работа­ла в качес­тве метода защиты поль­зовате­лей от вре­донос­ных прог­рамм и впер­вые внед­рила в Windows 10. AMSI в реаль­ном вре­мени перех­ватыва­ет скрип­ты и коман­ды PowerShell, JavaScript, VBScript, VBA или .NET и отсы­лает на про­вер­ку анти­вирус­ному прог­рам­мно­му обес­печению (это необя­затель­но Defender, более десяти вен­доров под­держи­вают AMSI). Но в наших при­мерах мы рас­смот­рим все же Defender.

Как это работает

Ког­да поль­зователь запус­кает скрипт или ини­циали­зиру­ет про­цесс PowerShell (либо PowerShell_ISE), в про­цесс авто­мати­чес­ки заг­ружа­ется биб­лиоте­ка AMSI.DLL. Она‑то и пре­дос­тавля­ет необ­ходимый API для вза­имо­дей­ствия с анти­вирус­ным ПО. Преж­де чем выпол­нить­ся, скрипт или коман­да при помощи уда­лен­ного вызова про­цедур (RPC) отправ­ляет­ся Microsoft Defender, он, в свою оче­редь, ана­лизи­рует получен­ную информа­цию и отсы­лает ответ обратно AMSI.DLL. Если обна­руже­на извес­тная сиг­натура, выпол­нение пре­рыва­ется и появ­ляет­ся сооб­щение о том, что скрипт заб­локиро­ван анти­вирус­ной прог­раммой.

На при­веден­ной выше схе­ме обоз­начены две фун­кции — AmsiScanString() и AmsiScanBuffer(), они, по сути, глав­ные в цепоч­ке AmsiInitialize, AmsiOpenSession, AmsiScanString, AmsiScanBuffer и AmsiCloseSession. Если гля­нуть Exports для amsi.dll, то мы уви­дим сле­дующее.

Од­нако зна­читель­ная часть это­го спис­ка нам сегод­ня не при­годит­ся.

Итак, мы запус­тили PowerShell. До того как мы смо­жем вво­дить какие‑либо коман­ды, будет заг­ружена AMSI.DLL и про­изой­дет вызов AmsiInitialize().

Тут исполь­зуют­ся два аргу­мен­та: имя при­ложе­ния и ука­затель на струк­туру CONTEXT. Параметр amsiContext будет исполь­зовать­ся в каж­дом пос­леду­ющем вызове AMSI API.

Пос­ле того как мы вве­ли коман­ду или попыта­лись выпол­нить скрипт, про­исхо­дит вызов AmsiOpenSession():

Тут тоже переда­ются два аргу­мен­та: amsiContext, получен­ный на шаге AmsiInitialize(), и ука­затель на струк­туру SESSION. Параметр amsiSession будет исполь­зовать­ся в каж­дом пос­леду­ющем вызове AMSI API внут­ри этой сес­сии.

Да­лее в дело всту­пают те самые AmsiScanString() и AmsiScanBuffer(). По наз­ванию, в прин­ципе, понят­но, какие парамет­ры они переда­ют для про­вер­ки, да и син­таксис у них поч­ти оди­наков.

Defender про­веря­ет буфер или стро­ку и воз­вра­щает резуль­тат. Если ответ от Defender — 32768, то мал­варь обна­руже­на, еди­нич­ка сиг­нализи­рует, что все чис­то.

Ну и пос­ле всех перечис­ленных выше про­верок текущая сес­сия зак­рыва­ется с исполь­зовани­ем AmsiCloseSession.

Как обойти проверку

Ме­ханизм AMSI исполь­зует сиг­натур­ное (rule-based) детек­тирова­ние угроз. Зная этот факт, мож­но при­думы­вать раз­ные так­тики и тех­ники. Некото­рые извес­тные спо­собы уже не сра­бота­ют, но, исполь­зуя модифи­кацию кода, обфуска­цию и крип­тование, мож­но добить­ся инте­рес­ных резуль­татов.

Итак, поеха­ли.

PowerShell downgrade

Пер­вый спо­соб, который иног­да сра­баты­вает, три­виален. PowerShell 2.0 уста­рел, но Microsoft не спе­шит уда­лять его из опе­раци­онной сис­темы. У ста­рой вер­сии PowerShell нет таких защит­ных механиз­мов, как AMSI, поэто­му для обхо­да детек­та иног­да дос­таточ­но исполь­зовать коман­ду powershell -version 2.