Threadless Injection. Делаем инъекции в чужие процессы, чтобы обойти EDR

Итак, давай вспом­ним, как про­исхо­дит стан­дар­тная инъ­екция шелл‑кода с пос­леду­ющим его выпол­нени­ем.

1. По­луче­ние дес­крип­тора про­цес­са (OpenProcess и NtOpenProcess).
2. Вы­деле­ние памяти для полез­ной наг­рузки (VirtualAllocEx и NtMapViewOfSection).
3. За­пись полез­ной наг­рузки в эту память (WriteProcessMemory и Ghost Writing).
4. Вы­пол­нение шелл‑кода (CreateRemoteThread и NtQueueApcThread).

Эта пос­ледова­тель­ность хорошо извес­тна всем средс­твам EDR, и если какое‑то ПО ее реали­зует, то сра­зу будет крас­ный флаг и завер­шение про­цес­са.

Нель­зя ли все это написать таким обра­зом, что­бы дей­ствия выпол­нялись те же, но без пря­мого исполь­зования перечис­ленных фун­кций WinAPI? С пер­выми шагами такое про­делать мож­но, но с выпол­нени­ем шелл‑кода все не так прос­то. Пря­мой вызов фун­кций CreateRemoteThread/NtQueueApcThread даст алерт EDR с веро­ятностью 100%.

Сло­вом, что­бы обвести защиту вок­руг паль­ца, нам надо сло­мать эту пос­ледова­тель­ность. Нап­ример, почему бы не перех­ватить какие‑нибудь вызовы API в сто­рон­нем при­ложе­нии, в экспор­тиру­емой фун­кции DLL и потом зас­тавить эту фун­кцию работать на нас?

Нап­ример, мож­но про­пат­чить фун­кции работы с сетью какого‑нибудь легитим­ного ПО, которое и так работа­ет с сетью, и исполь­зовать их для свя­зи со сво­ими сетевы­ми ресур­сами! В этом и сос­тоит смысл тех­ники Threadless Injection — про­пат­чить экспортные фун­кции исполь­зуемой про­цес­сом динами­чес­кой биб­лиоте­ки, что­бы при их вызове запус­кался наш код. По шагам это выг­лядит при­мер­но вот так:

1. Най­ти область памяти code cave, которая смо­жет вмес­тить наш шелл‑код и трам­плин.
2. За­писать шелл‑код и трам­плин в эту память.
3. Про­пат­чить экспор­тиру­емую фун­кцию DLL, нас­тро­ив ее на запуск нашего кода.
4. По­дож­дать вызова этой фун­кции, что­бы шелл‑код выпол­нился.

Но в динами­чес­ких биб­лиоте­ках могут быть сот­ни и тысячи фун­кций, и не факт, что ран­домно выб­ранная нам подой­дет. Ведь нет никаких гаран­тий, что она будет выз­вана в разум­ное для нас вре­мя или вооб­ще будет выз­вана.

Что­бы решить этот воп­рос, нуж­но про­вес­ти неболь­шое иссле­дова­ние ПО, в котором мы собира­емся реали­зовы­вать такой перех­ват экспортной фун­кции. В иде­аль­ном слу­чае нуж­но най­ти при­ложе­ние, которое вызыва­ет какие‑то фун­кции DLL регуляр­но: нап­ример, обра­щает­ся к сво­ему вре­мен­ному фай­лу на дис­ке и записы­вает в него про­межу­точ­ные резуль­таты сво­ей работы или про­веря­ет дос­тупность сво­их сер­веров в сети, вызывая соот­ветс­тву­ющие API с опре­делен­ным про­межут­ком вре­мени. Если най­ти такие фун­кции, то мож­но быть уве­рен­ным, что вызов точ­но про­изой­дет.

Но не сле­дует зло­упот­реблять этим пра­вилом: если при­ложе­ние вызыва­ет API слиш­ком час­то (нап­ример, нес­коль­ко раз в секун­ду) и ты захочешь перех­ватить вызов, то неиз­бежны раз­ные глю­ки.

Что­бы про­вес­ти подоб­ное иссле­дова­ние, вос­поль­зуем­ся прог­раммой API Monitor. В этой же прог­рамме мы смо­жем уви­деть, как в реаль­ном вре­мени про­исхо­дит вызов WinAPI, какие дей­ствия в инте­ресу­ющей нас прог­рамме на это вли­яют. Кро­ме того, мож­но уви­деть, какие DLL при­цеп­лены к про­цес­су и какие API они реали­зуют (то есть это не прос­то спи­сок WinAPI непонят­но отку­да). Исхо­дя из дан­ных монито­рин­га, мы дол­жны решить для себя, какую фун­кцию из экспор­та исполь­зуемой биб­лиоте­ки перех­ватывать.

Пос­ле того как подопыт­ная прог­рамма иссле­дова­на и нуж­ные WinAPI выяв­лены, мож­но начинать кодить.

Кодим

В начале статьи мы обоз­начили шаги, которые нуж­но сде­лать для реали­зации Threadless Injection, теперь приш­ло вре­мя реали­зовать каж­дый шаг в коде.