Для дальнейшего понимания сути поста надо запомнить [...]]]> Пришлось мне тут анализировать один элементарный руткит, никак не срасталось у нашего анти-руткита кое-что с ним. Ерунда в принципе, бага не критичная, но разобраться все-таки стоило. В последнее время не часто выпадает возможность проанализировать что-либо, но тут повезло, можно немного отвлечься от процесса исследования/кодинга.

Для дальнейшего понимания сути поста надо запомнить то, что дата компиляции дроппера — 27 февраля 2011 года, т.е. сэмпл далеко не старый.

В процессе динамического анализа я натолкнулся на полнейший отказ руткита работать, во-первых, под виртуальной машиной, а во-вторых, под виртуальной машиной с отладчиком ядра. Дроппер, кстати, также использовал парочку элементарных и устаревших проверок виртуальной машины, но не о дроппере речь.

Вот такой код я обнаружил в драйвере:

char __cdecl IsDebug()
{
  UNICODE_STRING DestinationString; // [sp+4h] [bp-Ch]@4
  PVOID Object; // [sp+Ch] [bp-4h]@4
 
  if ( KdDebuggerEnabledAddr && *(_BYTE *)KdDebuggerEnabledAddr )
    return 1;
  RtlInitUnicodeString(&DestinationString, L"\\Driver\\NTICE");
  if ( !ObReferenceObjectByName(&DestinationString, 0x40u, 0, 0x1F01FFu, IoDriverObjectType, 0, 0, &Object) )
  {
    ObfDereferenceObject(Object);
    return 1;
  }
  return 0;
}

Способ, основанный на проверке переменной KdDebuggerEnabled, известен очень давно, однако, проверка на наличие в системе активного отладчика Soft(Win)Ice (наличие драйвера NTICE) — это что-то из ряда вон выходящее. Неужели авторы думают, что антивирусные лаборатории до сих пор используют этот устаревший инструмент?

Что ж, живы еще олдскул разработчики в родных селениях!

Мешать антивирусному продукту можно различными способами. Можно использовать руткит-технологии [...]]]> Борьба с вредоносными программами осложнена не только тем, что их необходимо обнаружить, но и тем, что после обнаружения необходимо провести корректное лечение найденного вредоносного кода и его модулей. Детектируемые объекты совершенно не желают быть обнаруженными и уничтоженными, поэтому они активно сопротивляются лечению.

Мешать антивирусному продукту можно различными способами. Можно использовать руткит-технологии для предотвращения обнаружения и удаления, а можно следить за своими компонентами и, в случае удаления, восстанавливать их. Рассмотрим те, которые восстанавливают компоненты в случае их лечения антивирусным продуктом.

Некоторые из способов, которые используются в современных вредоносных программах под 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 );
        }
}

Для борьбы с таким вредоносным кодом каждый раз приходится придумывать что-нибудь оригинальное, но мы не унываем и продолжаем вас защищать.

Оригинал

Вячеслав Русаков

В 2008 году мы констатировали появление вредоносной программы Backdoor.Win32.Sinowal и расценивали ее как технологически крайне опасную.

Такая оценка была дана вследствие того, что авторы программы использовали самые продвинутые на тот момент технологии написания вирусов, включая основные: