Анализ руткита 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 - угроза пограничного типа: он достаточно мощный для поражения антивирусных программ, но недостаточно опасный для детального исследования; достаточно распространенный для публичных криков о помощи, но не дотягивает до эпидемии.
дальше [url]http://www.nobunkum.ru/issue001/tdss-analysis.html[/url]

Алиса Шевченко, eSage Lab
[email][email protected][/email] :) :) :)

Дык это уже устаревшая статья, она неактуальна для третьей версии (TDL3).

Где-то уже эту ссылочку приводил: [URL="www.drweb.com/static/BackDoor.Tdss.565_aka_TDL3.pdf"]Описание TDSS у DrWeb (pdf)[/URL]

Центр вирусных исследований и аналитики российского представительства [B]ESET[/B] обнародовал свой аналитический отчет [URL="http://www.esetnod32.ru/.viruslab/analytics/win32.olmarik.pdf"]«Руткит Win32/Olmarik: технологии работы и распространения» (pdf)[/URL], который был подготовлен по итогам длительного мониторинга и анализа различных модификаций этого руткита.

[I]28 июня 2010 г.[/I]

[QUOTE=Vadim_SVN;662377]Центр вирусных исследований и аналитики российского представительства [B]ESET[/B] обнародовал свой аналитический отчет [URL="http://www.esetnod32.ru/.viruslab/analytics/win32.olmarik.pdf"]«Руткит Win32/Olmarik: технологии работы и распространения» (pdf)[/URL], который был подготовлен по итогам длительного мониторинга и анализа различных модификаций этого руткита.

[I]28 июня 2010 г.[/I][/QUOTE]

Тогда и [url=http://www.securelist.com/ru/analysis/208050642/TDSS]лабораторию Касперского[/url] с [url=http://www.f-secure.com/weblog/archives/The_Case_of__TDL3.pdf]F-Secure[/url] следует, наверное, тоже упомянуть - они все примерно одновременно отчеты выпустили.

Ну да. Не прошло и полгода :) ЛК хотя бы анализ всего семейства и развития сделали - уже ценно.
Кстати, эсетовская ссылка у меня не открылась - открылся просто оффсайт.

У меня В Опере нормально открылась, но еще не изучал.

Об обходе антивирусов на практике - на примере бота-руткита TDSS [URL="http://habrahabr.ru/blogs/infosecurity/93027/"]на хабре[/URL].

Какие-то неправильные пчёлы...
Вчера поставил себе этого суслика."Ну - царь,ну и что?". По базам AVZ не проходит (а по описанию - должен подставлять вместо своего дрова - легальный). Вроде бы 3-я версия.
Кроме того, нашел в нем багу, которая позволяет его детектить из юзермода. Причем, как предположил, где оно будет, так и вышло. Такое ощущение, что аверы писали.
Кстати, куда слать багрепорт? :D

[QUOTE='antanta;663830']Какие-то неправильные пчёлы... [/QUOTE]
Это мухи.

[B]ALEX(XX)[/B], Теперь я понял, зачем респиратор.

Поэкпериментировал еще, для верности. Проделывал установку несколько раз. Каждый раз заражался случайный драйвер. Любимчиком оказался disk.sys.
Насколько я понял из описания, руткит должен подставлять для проверки другой файл. У меня AVZ показывал, что файл не прошел проверку по базе. После попытки удалить проверку уже проходил (до перезагрузки).
Интересно, что механизм восстановление файла руткита работает, насколько я понял, через sfc. А значит, при отключении этой фичи система дает сбой.
На самом деле, так и есть. Если отключить sfc (в XP SP2 кроме отключения в реестре пришлось подправить нужную dll), то после удаления файла руткитного дрова, злодей создает файл нулевого размера. Но, ничего записать в него не может.
По этому признаку вычисляется вероятный злодей.
Разумеется, удаление зараженного драйвера может привести к неработоспособности системы. Отключать получается следующим способом:
Копируем правильный файл драйвера в \drivers, под измененным именем. Затем в ControlSetXXX (который помечен как "последняя удачная конфигурация") правим путь, указывая наш првильный дров. Перезагружаемся, выбирая по F8 LastKnownGood.
Вот результаты проверки одного сэмпла [url]http://www.virustotal.com/ru/analisis/d58efc96513a7f1c40353ccb595e4445a3db4d53d2923ed22225436d4fbd44ca-1278085015[/url]
Почему-то некоторые вообще не определяются. Или криво копируются. Тут еще нужно разбираться.
Примечателен тот факт, что звирь прописывает свой код в ресурсы, затирая сведения о версии etc. С одной стороны - это косвенный признак, с другой может помешать найти в ресторах нормальный файл по внутреннему имени. Это имя иногда отличается от имени файла. Поэтому, приходится брать из дистрибутива, или других источников.

Вести с фронтов. Предыдущее работает только на XP SP2. Прстой скрипт для AVZ детектит даже то, с чем есть проблемы у тулзы от eSage. Последняя показывает факт заражения, просит ребут, потом ничего не находит.
Как отключать sfc на SP3 я пока не понял, да и не стал дальше разбираться.
На SP3 начинаются фокусы. Если скопировать зараженный файл, потом удалить его через проводник, файл восстанавливается. Контрольные суммы копии и нового файла отличаются. Если же удалить файл с помощью скрипта или из консоли, то отличия нет.
Приаттачил к Explorer.exe dll, которая удаляет вражеский дров - помогло. Теперь контрольные суммы сохраненного и "нового" файла разные.
Этот суслик еще и не дает создавать аварийные дампы памяти. После его устанокви копии нужных дров ( dump_*.sys) не создаются. Будем разбираться.
Пока итог таков: рассматривамый сэмпл не детектит утилита от ЛК (от 30 июня 2010), детектит последняя версия от eSage. Но, удаляет не всегда. Это зависит от того, какой драйвер был избран для заражения. [B]Сори, tdsskiller от ЛК обнаружил и удалил в очередной раз установленный руткит. Будем тестить дальше.[/B]
Продолжение следует :)

Дело было так(XP, SP2, SP3):
1) Чистая винда. Устанавливаем TDSS, перезагружаемся.
2) [B]Переносим[/B] в надежное место папки %System32\dllcache и %Windir%\Driver Cache
3) Запускаем скрипт (прилагается).
4) Видим в логах указание на подозрительный дров. Например [B]Disk.sys[/B]
[B]ACHTUNG![/B] Скрипт переносит некоторые файлы во временный каталог. В скрипте таковым назначен TmpDir на системном диске. Поэтому,
5) Из временной директории возвращаем файлы на прежнее место (в drivers)
Кроме подозрительного. Кстати, последний по возвращении на место будет неработоспособен. И не будет детектиться антивирусами. Инфа 100%. Поэтому, если передумали "лечиться", в дриверс следует закинуть легальный драйвер [B]из дистрибутива[/B]. После перезагрузки там снова будет TDSS :D
6) Возвращаем на свои места dllcache и Driver Cache
7) Открываем в редакторе реестра HKEY_LOCAL_MACHINE\SYSTEM\Select. Смотрим, какой ControlSet прописан в LastKnownGood.
8)Помещаем правильный драйвер (например из дистрибутива) в каталог drivers, но под измененным именем. В нашем случае, пусть будет [B]XXXDisk.sys[/B]
9) Открываем соответствующий раздел, например ControlSet002\Services\Disk.sys, меняем параметр ImagePath на system32\DRIVERS\[B]XXXdisk.sys[/B]
10) Перезагружаемся, жмем при старте F8, выбираем "Загрузка последней удачной конфигурации".
Проверяем тушку Disk.sys на вшивость.
Прошу потестить, кому интересно.

Обнаружен случай заражения драйвера, когда AVZ определяет его как безопасный. В скрипте убрал отсев прошедших по базе.

Фрагмент файла подкачки с машины, зараженной TDSS:
[CODE] \\?\globalroot\vphexqgt\stwcjjni\tdlcmd.dll [/CODE]
Как говорят, "биспалева". :D

Некоторые наблюдения относительно 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) порядок восстанавливается.