-
Анализ руткита TDSS
Вступление
Руткит TDSS также известен под именами Tidserv, TDSServ и Alureon. Отдельные его компоненты детектируются антивирусами под другими именами, такими как Trojan.Win32.DNSChanger и Trojan.FakeAlert.
Причины, по которым данный руткит удостоен детального исследования, таковы.
1. Судя по огромному количеству "воплей о помощи" от пользователей на публичных форумах, большинство антивирусов не справляются с лечением руткита, хотя успешно его обнаруживают.[1]
2. В публичном доступе нет полноценного описания функционала TDSS.
3. Реализация TDSS интересна тем, что, являясь со всей очевидностью эффективной, она не задействует никаких изощренных техник "нового поколения" или "0-day".
4. TDSS активно распространяется в живой среде, развиваясь в мощный ботнет. По данным Лаборатории Касперского за март-апрель 2009 г., в базы ежедневно добавляется от 100 до 300 сигнатур для новых и модифицированных файлов руткита. [2]
Таким образом, руткит TDSS - угроза пограничного типа: он достаточно мощный для поражения антивирусных программ, но недостаточно опасный для детального исследования; достаточно распространенный для публичных криков о помощи, но не дотягивает до эпидемии.
дальше http://www.nobunkum.ru/issue001/tdss-analysis.html
Алиса Шевченко, eSage Lab
[email protected]
http://club-symantec.ru/forum.php
-
-
Будь в курсе!
Будь в курсе!
Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:
-
Дык это уже устаревшая статья, она неактуальна для третьей версии (TDL3).
-
-
Где-то уже эту ссылочку приводил: Описание TDSS у DrWeb (pdf)
-
Центр вирусных исследований и аналитики российского представительства ESET обнародовал свой аналитический отчет «Руткит Win32/Olmarik: технологии работы и распространения» (pdf), который был подготовлен по итогам длительного мониторинга и анализа различных модификаций этого руткита.
28 июня 2010 г.
-
Сообщение от
Vadim_SVN
Тогда и лабораторию Касперского с F-Secure следует, наверное, тоже упомянуть - они все примерно одновременно отчеты выпустили.
-
-
Ну да. Не прошло и полгода ЛК хотя бы анализ всего семейства и развития сделали - уже ценно.
Кстати, эсетовская ссылка у меня не открылась - открылся просто оффсайт.
-
-
У меня В Опере нормально открылась, но еще не изучал.
Павел
AVZ HijackThis помощь с 10-00 до 18-00МСК
Windows7, SEP(work)
WindowsXP KIS(home)
На up не реагирую
-
-
Об обходе антивирусов на практике - на примере бота-руткита TDSS на хабре.
-
Какие-то неправильные пчёлы...
Вчера поставил себе этого суслика."Ну - царь,ну и что?". По базам AVZ не проходит (а по описанию - должен подставлять вместо своего дрова - легальный). Вроде бы 3-я версия.
Кроме того, нашел в нем багу, которая позволяет его детектить из юзермода. Причем, как предположил, где оно будет, так и вышло. Такое ощущение, что аверы писали.
Кстати, куда слать багрепорт?
-
-
Сообщение от
antanta
Какие-то неправильные пчёлы...
Это мухи.
Left home for a few days and look what happens...
-
-
ALEX(XX), Теперь я понял, зачем респиратор.
-
-
Поэкпериментировал еще, для верности. Проделывал установку несколько раз. Каждый раз заражался случайный драйвер. Любимчиком оказался disk.sys.
Насколько я понял из описания, руткит должен подставлять для проверки другой файл. У меня AVZ показывал, что файл не прошел проверку по базе. После попытки удалить проверку уже проходил (до перезагрузки).
Интересно, что механизм восстановление файла руткита работает, насколько я понял, через sfc. А значит, при отключении этой фичи система дает сбой.
На самом деле, так и есть. Если отключить sfc (в XP SP2 кроме отключения в реестре пришлось подправить нужную dll), то после удаления файла руткитного дрова, злодей создает файл нулевого размера. Но, ничего записать в него не может.
По этому признаку вычисляется вероятный злодей.
Разумеется, удаление зараженного драйвера может привести к неработоспособности системы. Отключать получается следующим способом:
Копируем правильный файл драйвера в \drivers, под измененным именем. Затем в ControlSetXXX (который помечен как "последняя удачная конфигурация") правим путь, указывая наш првильный дров. Перезагружаемся, выбирая по F8 LastKnownGood.
Вот результаты проверки одного сэмпла http://www.virustotal.com/ru/analisi...4ca-1278085015
Почему-то некоторые вообще не определяются. Или криво копируются. Тут еще нужно разбираться.
Примечателен тот факт, что звирь прописывает свой код в ресурсы, затирая сведения о версии etc. С одной стороны - это косвенный признак, с другой может помешать найти в ресторах нормальный файл по внутреннему имени. Это имя иногда отличается от имени файла. Поэтому, приходится брать из дистрибутива, или других источников.
-
-
Вести с фронтов. Предыдущее работает только на XP SP2. Прстой скрипт для AVZ детектит даже то, с чем есть проблемы у тулзы от eSage. Последняя показывает факт заражения, просит ребут, потом ничего не находит.
Как отключать sfc на SP3 я пока не понял, да и не стал дальше разбираться.
На SP3 начинаются фокусы. Если скопировать зараженный файл, потом удалить его через проводник, файл восстанавливается. Контрольные суммы копии и нового файла отличаются. Если же удалить файл с помощью скрипта или из консоли, то отличия нет.
Приаттачил к Explorer.exe dll, которая удаляет вражеский дров - помогло. Теперь контрольные суммы сохраненного и "нового" файла разные.
Этот суслик еще и не дает создавать аварийные дампы памяти. После его устанокви копии нужных дров ( dump_*.sys) не создаются. Будем разбираться.
Пока итог таков: рассматривамый сэмпл не детектит утилита от ЛК (от 30 июня 2010), детектит последняя версия от eSage. Но, удаляет не всегда. Это зависит от того, какой драйвер был избран для заражения. Сори, tdsskiller от ЛК обнаружил и удалил в очередной раз установленный руткит. Будем тестить дальше.
Продолжение следует
Последний раз редактировалось antanta; 06.07.2010 в 12:17.
Причина: Добавил.
-
-
Дело было так(XP, SP2, SP3):
1) Чистая винда. Устанавливаем TDSS, перезагружаемся.
2) Переносим в надежное место папки %System32\dllcache и %Windir%\Driver Cache
3) Запускаем скрипт (прилагается).
4) Видим в логах указание на подозрительный дров. Например Disk.sys
ACHTUNG! Скрипт переносит некоторые файлы во временный каталог. В скрипте таковым назначен TmpDir на системном диске. Поэтому,
5) Из временной директории возвращаем файлы на прежнее место (в drivers)
Кроме подозрительного. Кстати, последний по возвращении на место будет неработоспособен. И не будет детектиться антивирусами. Инфа 100%. Поэтому, если передумали "лечиться", в дриверс следует закинуть легальный драйвер из дистрибутива. После перезагрузки там снова будет TDSS
6) Возвращаем на свои места dllcache и Driver Cache
7) Открываем в редакторе реестра HKEY_LOCAL_MACHINE\SYSTEM\Select. Смотрим, какой ControlSet прописан в LastKnownGood.
Помещаем правильный драйвер (например из дистрибутива) в каталог drivers, но под измененным именем. В нашем случае, пусть будет XXXDisk.sys
9) Открываем соответствующий раздел, например ControlSet002\Services\Disk.sys, меняем параметр ImagePath на system32\DRIVERS\XXXdisk.sys
10) Перезагружаемся, жмем при старте F8, выбираем "Загрузка последней удачной конфигурации".
Проверяем тушку Disk.sys на вшивость.
Прошу потестить, кому интересно.
-
-
Обнаружен случай заражения драйвера, когда AVZ определяет его как безопасный. В скрипте убрал отсев прошедших по базе.
-
-
Фрагмент файла подкачки с машины, зараженной TDSS:
Код:
\\?\globalroot\vphexqgt\stwcjjni\tdlcmd.dll
Как говорят, "биспалева".
-
-
Некоторые наблюдения относительно TDL++ (он же TDSS bootkit).
Как и предыдущая версия, этот зверек скрытно загружает DLL, работающую в юзермоде. Отличия в том, что теперь, в зависимости от "разрядности" системы (32 или 64 бит) используется либо cmd.dll, либо cmd64.dll.
Следы присутствия в памяти (по крайней мере 32-битной версии) по прежнему можно обнаружить в файле подкачки.
В отличие от предыдущей версии руткит не препятствует созданию аварийных дампов.
Анализ аварийных дампов.
Для различных версий ОС линейки NT характерным является как базовый адрес в памяти ntoskrnl.exe, так и примерный порядок расположения модулей ядра в памяти.
Спровоцировав BSOD на чистой и пораженной системе, были получены крэш дампы, и проанализированы с помощью ядерного отладчика.
Результаты можно проиллюстрировать логами отладчика. На системах Windows XP SP2, SP3 нормальное расположение выглядит как показано в файле claer_debug.log. В инфицированной системе порядок размещения другой (infected_debug.log). Такой порядок, вообще то, характерен, например, для Windows 7. Обратите внимание на размещение kdcom.dll. После удаления руткита (с помощью специализированных утилит, или из консоли восстановления - fixmbr) порядок восстанавливается.
-