Эволюция руткита TDL4 или полевые сводки последних месяцев

    Мы уже давно ведем пристальное наблюдение за TDL4, а также за ботнетами, основанными на этом семействе руткитов. Но в последнее время особенно интересно было наблюдать за выходом исправлений со стороны Microsoft для блокирования методов загрузки неподписанных драйверов для x64 систем, использованных для установки Win64/Olmarik.

    Начнем издалека, итак в апрельский день Х помимо всех остальных вышло исправление KB2506014, задачей которого было внести несколько изменений в модуль winloader.exe для x64 версий ОС и таким образом противодействовать загрузке не подписанных драйверов. До установки патча BCD (Boot Configuration Data) имеет три различных опции загрузки:

    BcdLibraryBoolean_DisableIntegrityCheck – принудительное отключение проверки (чаще всего используется для отладочных целей);
    BcdOSLoaderBoolean_WinPEMode – отключение в режиме установки или восстановления ОС
    BcdLibraryBoolean_AllowPrereleaseSignatures – разрешить загружать модули имеющие тестовую цифровую подпись

    После установки патча остаются только две опции — BcdLibraryBoolean_DisableIntegrityCheck и BcdLibraryBoolean_AllowPrereleaseSignatures, а BcdOSLoaderBoolean_WinPEMode больше не используется в конфигурации политик проверки целостности загружаемых драйверов. В winloader.exe есть специальная функция BlImgQueryCodeIntegrityBootOptions, которая возвращает значение определяющее политику проверок.

    На рисунке ниже представлена процедура BlImgQueryCodeIntegrityBootOptions после патча:

    image

    Как мы видим, опция BcdOSLoaderBoolean_WinPEMode больше не используется, и способ загрузки, использованный в TDL4, после этого перестал работать (подробнее о его работе можно прочитать в нашем исследовательском отчете «The Evolution of TDL: Conquering x64»).

    Однако относительно недавно вышла новая версия буткита TDL4, которая обходит и это исправление — в ней был изменен компонент ldr16, что позволило TDL4 вернуть себе способность заражать x64-разрядные системы. Кроме того, повысилась защита вредоносной программы от обнаружения и удаления за счет усовершенствования низкоуровневых обработчиков событий в режиме ядра, относящихся к объекту драйвера мини-порта устройства хранения.

    После последнего исправления от Microsoft обойти политики проверки цифровой подписи кода в режиме WinPE стало невозможно. Создателям TDL4 пришлось сменить тактику инфицирования 64-разрядных ОС. Идея осталась прежней: изменить компоненты ld32 или ldr64 в библиотеке kdcom.dll в зависимости от разрядности заражаемой ОС. Вместо переключения в режим WinPE новая версия TDL4 исправляет процедуру I_CheckImageHashInCatalog. С помощью этой процедуры проверяется целостность модулей, загружаемых программой winload.exe.

    В нормальных условиях, когда процедуре I_CheckImageHashInCatalog не удается проверить целостность модуля, возвращается значение 0xC0000428 (STATUS_INVALID_IMAGE_HASH), препятствующее загрузке системы. Буткит TDL4 вносит изменения, в результате которых вместо 0xC0000428 возвращается 0x0000C428. Новое значение не является кодом ошибки (в режиме ядра наиболее значимый бит кодов ошибок обычно устанавливается равным 1). Таким образом, ОС не обнаруживает замены библиотеки kdcom.dll.

    На следующей иллюстрации показан код, который на лету исправляет компонент ldr16 в программе winload.exe:

    image

    Однако этот новый механизм, как оказалось, работает не совсем стабильно. В некоторых системах ОС может обнаружить изменения и запустить восстановление запуска, как показано на следующем снимке экрана.

    image

    После принудительной перезагрузки система становится абсолютно незагружаемой.
    Второе усовершенствование новой версии TDL4 коснулось низкоуровневых обработчиков событий в режиме ядра, относящихся к объекту драйвера мини-порта устройства хранения. Предыдущие версии вредоносной программы захватывали объект драйвера, относящийся к объекту устройства самого низкого уровня в стеке устройств хранения, как показано на следующей схеме:

    image

    В этом случае можно быстро получить доступ к объекту устройства мини-порта (Hard drive PDO, объект PDO жесткого диска) и затем пройти по списку смежных объектов устройств, чтобы получить указатель на «настоящий» объект драйвера мини-порта жесткого диска. В новой версии TDL4 объект драйвера минипорта жесткого диска маскируется более изощренным способом:

    image
    В этом случае объект устройства самого низкого уровня в стеке устройств хранения больше не является объектом PDO, соответствующим жесткому диску. После такого изменения обнаружить и удалить эту вредоносную программу становится намного сложнее. Антивирусные продукты ESET обнаруживают последний дроппер TDL4 как Win32/Olmarik.AMN, и все процедуры лечения работают корректно.

    В предыдущем поколении TDL3 уже встречался похожий случай, когда обновление от MS роняло зараженные системы в синий экран.
    • +26
    • 10.2k
    • 5
    ESET NOD32
    84.36
    Company
    Share post

    Comments 5

      +1
      Интересно, но как-то не законченно.
        0
        Мне кажется, не хватает выводов в статье. Что, дескать, руткиты не стоят на месте, становятся более изощренными и обходят современные способы детектирования на уровне операционной системы. Еще не хватает понимания, какие антивирусы могут лечить данную болезнь. Я думаю, это все будет полезно и важно знать.
          +2
          Выводы не стали писать, т.к. они довольно прозрачны и не хотелось излагать еще раз очевидные для многих вещи. Поэтому сконцентрировались именно на технических деталях ;)
        0
        >> На следующей иллюстрации показан код, который на лету исправляет компонент ldr16 в программе winload.exe
        Кода нет, вместо него скриншот.
          +1
          Спасибо, поправили ;) Там один скриншот вообще потеряли.

        Only users with full accounts can post comments. Log in, please.