проактивка и CreateRemoteThread

Внедряю код в процесс с помощью стандартной апи-функции CreateRemoteThread

все замечательно работает, но проактивка KIS палит создание удаленного потока, и ругается на подозрительную активность

подскажите пожалуйста, достаточно ли будет для обхода проактивки эмуляции CreateRemoteThread с помощью недокументированных функций ntdll ?
если да, то каким образом можно ее сэмулировать?
если нет, то как ее обойти ?

 

jtysrtj
В 7-й виндоз есть какието неизвестные мне сервисы, но в XP нет таких. Клиф мониторит ядерный вызовы в сдт, более того внедрение кода в процесс обычными техническими способами не пройдёт, тредуется описатель целевого процесса, который без открытия или создания процесса негде взять.

 

Истину глаголит Clerk где брать то "права" на открытия процесса, любая проактивка уже этот фак запалит. ТАк что тут надо рыть чтото новое

 

а хуки в сдт реально снять или нет ?

 

jtysrtj
Никаких проблем с восстановлением сдт нет.. из ядра.

 

Ну-ну, надежды юношей питают... ))

 

можно попробовать через WriteProcessMemory создать поток, но её, насколько мне помнится КАВ тоже хучит. как-то давно (года 2 назад), этот способ прокатывал, КАВ на вызов WriteProcessMemory (без последующего CreateRemoteThread) не жаловался. теперь х.з., давно подобным софтом не занимался.

 

В таком случае перемап секций, 10-й клиф не следит за этим.

 

а GetThreadContext/SetThreadContext не пробывал?) ну или там через Mutex...

 

можно спросить это как? чисто из любопытства

 

Rel
А толку пробовать, если сервис захвачен(#213):

http://wasm.ru/forum/viewtopic.php?pid=316289#p316289
Давно кисой не интересовался, но попробуйте физиклмемори секцию замапить через сокращение имени(директорию открыть), может не пофиксили, тогда вся ось доступной будет. Хотя всё это хлам.

 

В общем (самом херовом) случае сдт не восстановить. Как говорится, кто первый - тот и папа В частном случае нетрудно

 

Medstrax
В теории да, но, как правило, авторы проактивок оставляют парочку дырок, из-за которых "папа" теряет свой контроль над системой)

 

Medstrax
Некоторые базовые принципы, которые следует применить если хотите найти дырку(отсутствие проверок вхождения указателя в диапазон пользовательского ап. и тп. не рассматриваем, это вроде реализовано граматно):
o Проверка нулевых указателей. Ядро не всегда проверяет нулевые указатели, не критично ибо сех обработает сепшен при доступе. Память с нулевого адреса мы можем выделить. Прот также выполняет проверки нулевых указателей, отпуская сервис если такой указатель обнаружен.
o Аттач. KeStackAttachProcess/KeAttachProcess. Если выполнены эти функции, после них может возникнуть исключение, а сех не выполнит детач, то по возврату потока из сервиса он окажется в другом процессе.
o SuspendApc. Тред на нулевом IRQL может быть остановлен, если доставка ядерной апк не запрещена. Это грубые ошибки синхронизации. Например ObOpenObjectByName, далее мы можем остановить тред и взять хэндл. Как видно клиф не выполняет подобную синхронизацию.
o Освобождение/выделение памяти. Например перехватчик проверил валидность буфера, если не валидный, то отпустит сервис. Тут мы выделяем память и буфер становится валидным(2 потока).

 

у меня проактивка не палила следующее:

1. OpenProcess
2. ???
3. VirtualAllocEx
4. WriteProcessMemory
5. QueueUserAPC

самое веселое, и вставить бы почаще - эмуляция замолкает.
???:
__try {
__asm in al, 2
} __except( EXCEPTION_EXECUTE_HANDLER ) {
hProcess = (HANDLE)( (DWORD)hProcess + ( STATUS_PRIVILEGED_INSTRUCTION - GetExceptionCode() ));
}

 

эммм... поясните мне тупому блок '???'... в основном вопрос в хитрой строчке с хендлом... что это за вычисления?)

 

PavPS
Эмулятор != прот. Вдобавок in al,2 будет использована непосредственно как сигнатура.

 

Если, к примеру, вы пишите инфектор для PE, и спользуете соответствующие структуры, поинтеры, то вош код либо сразу после компиляции либо после запуска будет назван как вирус (я точно не помню то название, коим каспер его именует). Е вот если испоьлзовать указатели на не валидный, абстрактный блок памяти, затем спомощью такого блока ИМЕННО в except блоке вычислить валидное значение указателя, то это остается не замеченным. Для всех авиров не утверждаю. проверено на каспере. хотя есть сведения, что эта технология все же подходит и для других.
Так же происходит и с хэндлами к процессу. Каспер палит последовательность открытия процесса и записи в его память. Если использовать этот блок, то кепочка открыть_процесс-записать_в_его_память будет разорвана. Опять таки лично проверено и используется.
Я предполагаю, что это лишь средство против эмулятора (или как там её, проактивки). Ессно, если хэндлить операции сверху в НТ-шных вызовах, то реальные указатели и хэндлы полюбому всплывут, но на данный момент каспер до этого не дошел.
Надеюсь пояснил.

 

именно используя эту константу и код, который будет возвращен при обработке исклолючения (в сумме даст 0) и дает ровно такое же значение хэндла hProcess. Но... эмуль каспера не корректно работает (видимо) с этим и значение GetExceptionCode() получается не равным STATUS_PRIVILEGED_INSTRUCTION, а значит получает не тот хэндл и теряет связь со следующим этапом записи в память.

 

PavPS, ждите в скором времени костылей