Всем привет, как всем известно существует множество способов инжекта в чужой процесс, но меня интересует насколько актуален перехват функций x64 ntdll в WoW64 процессах, учитывая, что все вызову от api x32 переходят в конечном итоге в x64 разрядный код функций x64 ntdll. Есть способ использования Apc из режима ядра, вот, например, https://www.sentinelone.com/blog/deep-hooks-monitoring-native-execution-wow64-applications-part-1/, в этой же статье приводится упоминание про heaven gate, есть способ из x64 инжектора записать небольшой позиционно-независимый шеллкод в WoW64 процесс, а конкретно найдя место в в x64 ntdll и вызова впоследствии оттуда LdrLoadDll и загрузки x64 библиотеки-перехватчика. Но мне интересен ещё один способ менее шумного с точки зрения AV/EDR решений вообще не быть инициатором вызова функции, например, VirtualAllocEx и WriteProcessMemory, а с помощью техники InjectMe заставить процесс-жертву с помощью вышеуказанных функций самому прочитать в неисполняемую память (например стек) , а затем записать в исполняемую память шеллкод через внешнее изменение контекста процесса-жертвы процессом-инжектором и последующим запуском контекста, указываюшим на наш шеллкод, который загрузит нашу библиотеку, которая используя heaven gate перейдёт в x64 режим, загрузит x64 библиотеку, которая в свою очередь будет мониторить и перехватывать функции уже в ntdll x64. Насколько актуально это сейчас на Windows 10 x64. Спасибо за внимание.
А как насчёт перехватить вызов в x64, но отдать на обработку в x32? В x64 обрабатывать сложно: там будет только ntdll - было бы приятнее вернуть вызов в x32, обработать в нормальном окружении (с STL, с высокоуровневыми либами) и вернуть обратно в x64.
В той же статье, которая выше про перехват в WoW64 есть модифицированный движок перехвата библиотеки minihook, но там без перехода обратно в x32, вся работа в x64 я так понимаю. Но наверное сейчас мало кто использует приложения x32, сейчас все на 64 разрядных приложениях. Просто интересно что традиционные методы инжекта довольно быстро обнаруживаются, все чаще используется социальная инженерия для отключения защитных решений.
Это очень старая тема, времен когда был emet и прочая защита, где проверялся стек вызовов и тп. Для решения использовались заглушки в системных длл, так анализер не мог определить левый" вызов. Называлось защитой стека". Тут можно посмотреть, но я не особо помню подробности. Если передать управление на впрыснутый модуль, то при попытке что либо вызвать напрямую будет детект и не важно как управление передается и какой мод. Можно все решить запуском бинарной трансляции, подмена выборки и все такое, но это сложный путь.
