Кривая дорожка. Обфусцируем вызовы WinAPI новыми способами

Содержание статьи

• Проксирование вызовов
• Теория
• Обнаружение прокси-функций
• Пример с DphCommitMemoryFromPageHeap
• Через RPC
• Используем альтернативные функции
• Теория
• Замена CRT
• Через ссылки на структуры Windows
• Изучаем COM
• Замена ReadProcessMemory()
• Замена WriteProcessMemory()
• Где искать альтернативы
• Выводы

Все кру­тые вре­доно­сы ста­рают­ся пря­тать исполь­зование вызовов WinAPI, ведь наличие подоз­ритель­ных фун­кций в коде может при­вес­ти к бло­киров­ке исполне­ния нашей прог­раммы. Сущес­тву­ет не так мно­го докумен­тирован­ных спо­собов скрыть вызовы WinAPI, одна­ко у меня есть пара любопыт­ных раз­работок, и я готов ими поделить­ся. Мы поп­ракти­куем­ся в ска­ниро­вании памяти, иссле­дова­нии ком­понен­тов Windows и даже нем­ного зат­ронем RPC. warning

Статья име­ет озна­коми­тель­ный харак­тер и пред­назна­чена для спе­циалис­тов по безопас­ности, про­водя­щих тес­тирова­ние в рам­ках кон­трак­та. Автор и редак­ция не несут ответс­твен­ности за любой вред, при­чинен­ный с при­мене­нием изло­жен­ной информа­ции. Рас­простра­нение вре­донос­ных прог­рамм, наруше­ние работы сис­тем и наруше­ние тай­ны перепис­ки прес­леду­ются по закону.

Как ты зна­ешь, любой, даже самый страш­ный «вирус» — это обыч­ная прог­рамма, которая исполь­зует те же механиз­мы и фун­кции, что и легитим­ный софт. Мож­но ска­зать, идет зло­упот­ребле­ние фун­кци­ями, дос­тупны­ми любому раз­работ­чику. Иног­да встре­чает­ся абуз недоку­мен­тирован­ных воз­можнос­тей. Одним сло­вом — хакерс­тво!

Вер­дикт о приз­нании прог­раммы вре­донос­ной анти­вирус выносит пос­ле ана­лиза и сопос­тавле­ния мно­жес­тва фак­тов, но осно­вопо­лага­ющим всег­да будет ана­лиз исполь­зуемых фун­кций в коде. Ана­лизи­ровать мож­но раз­ные вещи: хуки, таб­лицы импортов, поток исполне­ния, в слож­ных слу­чаях может про­изво­дить­ся быс­трая деком­пиляция. Хакеры, в свою оче­редь, научи­лись ан­хукать, пря­тать IAT, при­менять API Hashing и пре­дот­вра­щать заг­рузку DLL.

Пред­ставь, а что, если бы мы смог­ли избе­жать исполь­зования подоз­ритель­ных фун­кций? Бук­валь­но: не тро­гаем вся­кие опас­ные шту­ки, а нас не тро­гает анти­вирус!

Нап­ример, вмес­то VirtualAllocEx() мож­но дер­гать что‑нибудь аль­тер­натив­ное, как делали в статье про шелл‑код‑ран­нер на чис­том C#. И это воз­можно! Сущес­тву­ет нес­коль­ко тех­ник, поз­воля­ющих идти обходным путем, не зат­рагивая «подоз­ритель­ные» методы или вся­чес­ки скры­вая их исполь­зование.

Проксирование вызовов

Теория

У запад­ных кол­лег эта тех­ника называ­ется Proxy Invoke. Она осно­вана на том, что хакер обна­ружи­вает такую фун­кцию, которая дер­гает нуж­ные вещи, «прок­сируя» вызов. Фак­тичес­ки идет зло­упот­ребле­ние чужими обвязка­ми над сущес­тву­ющи­ми метода­ми.

При­мер: у нас есть фун­кция ZwProtectVirtualMemory(), она поз­воля­ет изме­нить раз­решения памяти. Счи­тает­ся, так ска­жем, не самой безобид­ной, ведь с ее помощью мож­но пометить адресное прос­транс­тво как исполня­емое. При попыт­ке ее исполь­зования может вылез­ти алерт, нап­ример у Elastic.

При­мер алер­та www

Ин­терес­ное по теме:

• Doubling Down: Detecting In- Memory Threats with Kernel ETW Call Stacks
• Твит @dez_

Нас инте­ресу­ет этот: VirtualProtect API Call from an Unsigned DLL. Логика детек­та прос­та: если фун­кция вызыва­ется из адресно­го прос­транс­тва непод­писан­ной биб­лиоте­ки, то вызов счи­тает­ся вре­донос­ным. Подоб­ные рас­сужде­ния име­ют пра­во на жизнь, ведь зачем обыч­ному раз­работ­чику дер­гать Zw-фун­кцию из сво­ей прог­раммы? Явно что‑то нечис­то…

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

Источник: xakep.ru