TDSS на бухгалтерском ПК: антивирус молчит, TDSSKiller говорит

История началась примерно так: бухгалтер пожаловалась, что компьютер «тормозит и иногда сам открывает страницы». Мы решили, что это стандартная история с забитым реестром или нерадивым обновлением Windows. Пришли посмотреть - и провозились значительно дольше, чем планировали.

Первая диагностика ничего не дала

На машине стоял Kaspersky Endpoint Security 8, базы - свежие, последнее полное сканирование три дня назад, результат чистый. Windows XP SP3, всё по корпоративной политике. На первый взгляд - образцово-показательная рабочая станция.

Мы на всякий случай запустили сканирование вручную. Антивирус отработал, сообщил «угрозы не обнаружены» и предложил нам выпить чаю. Тем не менее Machine в диспетчере задач периодически показывал подозрительные всплески активности svchost.exe, а netstat выдавал несколько установленных соединений на адреса, которые не вписывались ни в AD, ни в прокси, ни в обновления - просто непонятные IP где-то во внешней сети.

Это уже был аргумент для более внимательного разбора.

TDSS: почему обычный антивирус его не видит

Семейство TDSS - это буткит. Не просто вредоносная программа, которая прячется в реестре или маскируется под системный процесс. Она переписывает MBR - загрузочную запись диска - и загружается ещё до ядра Windows. После этого у неё есть возможность перехватывать обращения к диску на уровне драйвера. Антивирус запрашивает: «покажи мне содержимое сектора X» - TDSS перехватывает запрос и возвращает чистый оригинал вместо заражённой версии. Антивирус доволен. Буткит тоже.

Это не теоретическая атака - на тот момент исследователи уже описали несколько поколений TDSS (его ещё называют Alureon и TDL), каждое из которых совершенствовало именно механизм сокрытия. TDL-3 и TDL-4 умели работать и в 32-битных, и в 64-битных системах, обходить проверку подписей драйверов.

TDSSKiller: инструмент под конкретную задачу

Kaspersky выпустил TDSSKiller - специализированную утилиту именно для этого семейства. Логика другая: не проверять файлы через стандартный антивирусный движок, а смотреть на MBR напрямую через нижнеуровневые системные вызовы, минуя драйверный стек, который буткит успел скомпрометировать.

Запустили TDSSKiller на той самой бухгалтерской машине. Утилита нашла заражённый MBR за несколько минут - то, что штатный антивирус игнорировал. Предложила восстановить загрузочную запись. Восстановили, перезагрузились, повторили - чисто.

После этого сделали полный образ диска на отдельный NAS, чтобы иметь артефакты, и только потом занялись машиной дальше.

Откуда взялось и куда ходило

Вопрос «откуда» дал предсказуемый ответ: бухгалтер периодически пользовалась личной флешкой. Ни USB-блокировки политикой, ни проверки съёмных носителей при подключении - были рекомендации, но их никто не включил на этой группе машин. С большой вероятностью TDSS попал именно так, хотя восстановить точный момент заражения мы не смогли.

Вопрос «куда ходило» оказался интереснее. Мы подняли журналы с межсетевого экрана за последние две недели и отфильтровали исходящие соединения с IP-адреса этой машины.

Картина была такая:

• Регулярные короткие запросы на несколько внешних IP, периодичность - от 10 до 30 минут. Типичный паттерн heartbeat к C2 - командному серверу.
• Несколько более длинных сессий по HTTP на порту 80, с объёмом исходящего трафика в районе нескольких килобайт. Данные уходили наружу.
• Один IP из списка совпал с известным адресом C2 из публичного отчёта Symantec по Alureon - это подтвердило семейство и дало понять, что заражение было рабочим, а не просто лежало мёртвым грузом.

Что именно утекло - восстановить точно нельзя. Трафик шёл в шифрованном виде поверх HTTP. Хорошая новость: машина бухгалтера не имела доступа к базе 1С напрямую через сеть - только через терминальный сервер, где сессия открывалась под её учёткой. Плохая новость: учётные данные домена на этой машине могли быть перехвачены.

Мы немедленно сменили пароль пользователя, принудительно переинвалидировали её Kerberos-тикеты через сброс пароля в AD и проверили журналы аутентификации на контроллере домена за последние две недели - ничего аномального, но это не гарантия.

Что поменяли после

Несколько практических вещей, которые сделали сразу:

• USB-политика на рабочих станциях бухгалтерии - теперь съёмные носители только для чтения и только после проверки антивирусом при подключении. Это решалось групповой политикой, просто раньше руки не доходили.
• TDSSKiller в регламент - не вместо антивируса, а как дополнительный инструмент при любой нестандартной ситуации с машиной: тормозит, ведёт себя странно, есть непонятные соединения. Запустить и посмотреть на MBR стоит рефлекторно.
• Журналы файрвола - убедились, что исходящий трафик логируется с разбивкой по источнику и что эти логи вообще просматриваются, а не просто пишутся.
• Терминальный сервер проверили на предмет аномальных входов - всё в порядке, но теперь это в регулярном чек-листе.

Один вопрос остался без ответа: как давно машина была заражена. Если TDSSKiller эффективно скрывал активность от антивируса, мы не знаем, сколько времени буткит провёл на этой машине до того, как бухгалтер пришла с жалобой. Это неприятно.

Мы провели аналогичную проверку остальных машин этого клиента с помощью TDSSKiller - на остальных чисто. Но сам факт, что один заражённый ПК две недели (как минимум) жил в инфраструктуре, не будучи обнаруженным штатными средствами - это аргумент в пользу того, что антивирус не является единственным и достаточным инструментом обнаружения. Сетевой мониторинг исходящих соединений должен быть в связке с ним.

Всё описанное - часть нашей работы по аудиту безопасности инфраструктуры. Иногда аудит начинается с жалобы, что «компьютер тормозит».