Борьба с вредоносными программами осложнена не только тем, что их необходимо обнаружить, но и тем, что после обнаружения необходимо провести корректное лечение найденного вредоносного кода и его модулей. Детектируемые объекты совершенно не желают быть обнаруженными и уничтоженными, поэтому они активно сопротивляются лечению.
Мешать антивирусному продукту можно различными способами. Можно использовать руткит-технологии для предотвращения обнаружения и удаления, а можно следить за своими компонентами и, в случае удаления, восстанавливать их. Рассмотрим те, которые восстанавливают компоненты в случае их лечения антивирусным продуктом.
Некоторые из способов, которые используются в современных вредоносных программах под Windows:
- нотификации (информационные сообщения ОС) на изменение ключей реестра или значений реестра и восстановление их в случае лечения антивирусом;
- следящий поток в цикле проверяющий ключи реестра, значения реестра или файлы;
- второстепенный процесс, поток или внедренный код, следящий за основным процессом или потоком и перезапускающий его в случае уничтожения антивирусом;
Вышеперечисленные способы — основные, однако, вариаций существует намного больше.
15 мая мы представили статью о вредоносной программе, вернее ее новой модификации, носящей кодовое название ‘буткит’. В бутките используется метод заражения загрузочной записи диска, но не обошлось и без использования способа восстановления MBR в случае лечения его антивирусным продуктом.
Авторы данного руткита подошли к вопросу о перепроверке MBR с интересной стороны. На ранней стадии загрузки операционной системы запускается поток в режиме ядра, который в цикле проверяет наличие в памяти системного процесса explorer.exe и ожидает его завершения. После инициации перезагрузки операционная система завершает все процессы, в том числе и explorer.exe. Схематично этот код выглядит так:
NTSTATUS InitThreadWithExplorer(...) { // выделяем память под MBR status = AllocateAndZeroMemory( &g_MainMbrBuf, 512, 0, ' kdD' ); // читаем зараженный MBR в глобальный буфер status = SendIrpMjRead( g_MainMbrBuf ); // запускаем поток, который находит explorer.exe и ждет status = RunSystemThread( FindExplorerWaitAndCallOnReboot, ... ); } NTSTATUS FindExplorerWaitAndCallOnReboot(...) { // запускаем цикл поиска explorer.exe do { explorerpid = ReturnProcessPidByName( L"explorer.exe" ); // если найден explorer.exe, то выходим из цикла if ( explorerpid ) break; } while(...); // получаем объект процесса explorer.exe по его идентификатору status = PsLookupProcessByProcessId( explorerpid, &pProcess ); // ожидаем завершения процесса explorer.exe KeWaitForMultipleObjects( 2, &Objects, WaitAny, 0, 0, 0, 0, 0 ) // если explorer.exe завершился, то вызываем функцию проверки MBR CallOnReboot(...); }
Функция CallOnReboot сравнивает текущий MBR с эталоном (зараженной загрузочной записью). Делается это для того, чтобы на момент перезагрузки системы восстановить вылеченную антивирусом загрузочную запись:
NTSTATUS CallOnReboot(...) { pMBR = 0; // выделяем память под MBR status = AllocateAndZeroMemory( &pMBR, 512, 0, ' kdD' ); // читаем MBR status = SendIrpMjRead( pMBR ); i = 0; // запускаем цикл проверки do { k = i; l = i; // если какой-либо байт MBR отличается, то выходим из цикла if ( *(_BYTE *)(pMBR + i) != *(_BYTE *)(g_MainMbrBuf + i) ) break; k = i++ + 1; } while ( l < 432 ); // если был найден отличающийся байт if ( k < 432 ) { // копируем в pMBR зараженный MBR memmove( pMBR, g_MainMbrBuf, 432 ); // перезаписываем вылеченный MBR status = SendIrpMjWrite( pMBR ); } }
Для борьбы с таким вредоносным кодом каждый раз приходится придумывать что-нибудь оригинальное, но мы не унываем и продолжаем вас защищать.
Читайте также:
Loading ...
> «Некоторые из способов, которые используются в современных вредоносных программах под Windows»
какие существуют техники противодействия выше упомянутым способам? активное заражение того же tdss (в котором очень грамотно применены эти техники) на сколько я знаю на данный момент не лечит никто.
Использование драйвера для отложенного лечения реестра или файлов. Защита веток от изменений после их лечения и так далее. Tdss противный, согласен, но и его можно вынести, нет ничего экстра сложного.
http://www.esagelab.ru/projects/#tdss_remover
Специально для TDSS-а мы вот такую лечилку написали, которая на данный момент бай дизайн детектит и успешно удаляет все известные модификации этого трояна.
(охтунк, реклама в бложике =)))
Охтунг!!! Я прям как сердцем чуял, что Алиско не одна =)
Антивирусы, я так понимаю, для препятствования подобным восстановлениям deep-deep disk hooks сейчас используют?)
Ну, ДрВеб использует hard reset :))) А в ЛК каждый раз что-нибудь новое. Это новое намного гиморнее, чем hard reset, но такой ребут опасен по определенным причинам.
Плюс драйвер диска, вероятно, использует какое-то планирование операций воода-вывода, так что гарантий того что восстановленная mbr запишется на физический носитель мгновенно нет вобоще.
А вообще, самое простое в данном случае решение, как мне кажется, заключается в поиске принадлежащих руткиту потоков (анализом стека вызовов, например) с их последующим деликатным убиением (удалением из списков планировщика).
Угу, или так или повесить хук ниже. Хук менее надежен тем, что его можно снять, однако, он на порядки проще реализуется, чем поиск и анализ потоков. Плюс выкидывание из списков планировщика — сплошной undoc осезависимый, но вполне реализуемый ;)
Ещё как опасен, юзеры, у которых система стояла на FAT32 партиции, неверное, были рады =))