Ну мы в соседней теме обнаружили, что касперский не хавает алгоритм инжекта 15ти летней давности, так что все может быть.
Ну это зависит от конечной реализации, которую так просто, как с перехватами не проанализировать. Вполне возможно, что палится например целая цепочка последовательных апи вызовов, если хоть один из цепочки отсутствует, то палева нет.
Видимо много фолзов было и стало быть так часто делает белый софт, так что не хватает признаков малварности для триггера.
В нем можно функционировать на протяжении всего сеанса работы пользователя и из него инжектить в процессы, которые живут не так долго, типа браузеров (доступ в интернет, стилинг паролей/кук) и тд. Канеш для всякой популярной сейчас малвари типа локеров и стилеров это не особо то и нужно, но для всяческих ратников это вполне себе нормальный вариант.
Инжектит, запускает кобу, а потом мимик?))))
Смотря по функционалу, как Haunt говорил, можно и на COM ишака выходить в сеть. И не надо будет инжектиться.
Интересно, почему эти функции работают под настоящим дебагером? Вроде как же не должно, если процесс уже отлаживается второй раз к нему подключится с отладкой (обычные дебаг апи). А тут ошибок нет, СОМ отрабатывает.
А например это https://www.ired.team/offensive-security/defense-evasion/how-to-unhook-a-dll-using-c++
В соседней теме я проверял это на авасте, не работает...
Ну загружать и переписывать всю секцию .text более палевно и не факт, что сработает. Во-первых нужно останавливать все другие потоки в процессе на время работы memcpy (та же проблема, что и со сплайсингом, поток может исполнять те инструкции, которые мы переписываем). Во-вторых, зависит от того, как аверский хукер работает (он может периодически проверять наличие хуков и восстанавливать их, если они пропали, и более того он может в этом случае сразу считать текущий процесс вредоносным, тк легитимные процессы вряд ли будут снимать себе хуки). В-третьих, опять же это не будут работать в wow64, тк для каждой функции, делающий системный вызов, надо будет фиксить ссылку на KiFastSystemCall. Честно говоря, я не вижу у этого метода преимуществ в сравнении с описанными мной в статье методами.
Ну теоретически, если ты это делаешь через создание файловой секции, а не образно VirtualAlloc'ом выделяешь память, то с ней вроде ассоциируется имя маппированного файла, и это наверное можно спалить и прохукать.
все равно будет NtCreateFile, вот там и похучит.
Чтоб прочитать сискол намберы нужно прочитать нтдлл, которая уже похучена авером.
Ну анализатор на динчеке был признан малварью только авером Комодо, а там по сути из палевных действий только чтение ntdll.dll. Чтобы на лету вернуть похученные функции, нужно хукать NtReadFile и на лету подменять данные (то есть парсить и понимать, что грузится PE файл, перечислять экспорты и устанавливать хуки, если файл грузится по частям, то надо как то хранить состояние загрузки и тд), вряд ли кому то надо будет так заморачиваться, когда можно просто залочить NtCreateFile для системных библиотек, но тут могут возникать разные сайд эффекты, которые могут вывести ищ строя и вполне легитимные механизмы.
Есть не только ядро, есть и гипервизор, но многие аверы таки продолжают ставить хуки в юзер моде, и не только аверы, но и сендбоксы, типа той же кукушки.
потому что аверы маглы, которые не могут норм накодить в ринг0 или им выгодно?
По сути должно помочь, как бы ты ринг3 нагибаешь, а в ядре аверы чет не умные.
А какие еще предложения есть? Я вижу из менее проблемных путей для обхода авера - чистка сорцов на сигнатуру, чтоб в памяти не детектили и сисколы.
Ну в ядре есть патч гард и всякие системные защиты, наверное отключать или обходить их такое себе.
Тебе ничего не мешает и захардкодить их.
ВМ никак не спасает от детектов по поведению.
