Duqu: разбираем IoC и ищем следы в Proxy-логах промышленных клиентов

Symantec опубликовал отчёт по Duqu. В двух словах: кто-то взял кодовую базу Stuxnet, выкинул из неё PLC-пейлоад и сделал из результата разведывательный инструмент. Никаких диверсий - только сбор информации: документы, снимки экрана, перехват нажатий клавиш, системная инвентаризация. Судя по всему, Duqu готовит почву для чего-то следующего, а не является финальным ударом сам по себе.

Нам это интересно по конкретной причине: среди наших клиентов несколько промышленных предприятий, и после истории со Stuxnet мы договорились с частью из них смотреть на новые угрозы через призму «что из этого может касаться вас». Duqu - как раз такой случай.

Что говорит Symantec об IoC

Отчёт пока предварительный, но IoC уже достаточно конкретные.

• Сетевой - C&C-коммуникация идёт на порт 443 (HTTPS), причём трафик имитирует легитимные JPEG-запросы. Внешне - картинка, внутри - зашифрованные данные. Сервера C&C на момент публикации - IP-адреса в Индии, Бельгии и нескольких других странах. Адреса уже в блокировочных списках у вендоров, но это не значит, что завтра не появятся новые.
• Файловый - инсталлятор создаёт WMI-провайдер, который обеспечивает персистентность. Это нетривиально: вместо банального ключа в Run\HKLM или задачи в планировщике - регистрация в репозитории WMI. Увидеть без целенаправленной проверки - сложнее.
• Имена файлов - Symantec называет jminet7.sys и cmi4432.sys (руткит-драйвер), плюс несколько связанных DLL с неприметными именами в system32.

Драйвер подписан - так же, как в Stuxnet. Только сертификат на этот раз другой. Откуда он - Symantec не уточняет, отозван ли - тоже пока не ясно. Это существенный момент: если Windows видит подписанный драйвер, большинство защитных механизмов молчит.

Что мы решили проверить у клиентов

Полной уверенности, что Duqu вообще добрался до кого-то из наших подопечных, у нас нет - скорее всего, не добрался. Но инфраструктура промышленного предприятия - не то место, где хочется угадывать. Поэтому сделали два направления проверки: сеть и хосты.

Сетевая сторона. Попросили у клиентов выгрузку Proxy-логов за последние два месяца. Конкретно смотрели: исходящие TCP-соединения на порт 443 к IP-адресам из IoC Symantec, а также аномальные паттерны - небольшие периодические запросы к одному и тому же внешнему хосту с машин в технологическом сегменте. У Duqu, по описанию, маяк ходит наружу примерно каждые 36 часов.

Работа со squid-логами - не самое приятное занятие вручную. Фильтровали примерно так:

grep ":443" access.log | awk '{print $3, $7}' | sort | uniq -c | sort -rn

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

На одном объекте нашли несколько обращений к внешнему IP на 443 с машины, которая сидит в технологическом VLAN и не должна иметь внешний доступ вообще. Оказалось - инженер поставил что-то для удалённого управления ПЛК через облако, совсем не Duqu. Но факт интересный: машина лезла наружу, а никто об этом не знал.

Хостовая сторона. WMI-инвентаризация. Duqu регистрирует провайдер в WMI, чтобы загружаться без классических точек автозапуска. Проверяем:

wmic /namespace:\\root\subscription path __EventFilter get Name,Query /format:list
wmic /namespace:\\root\subscription path __EventConsumer get Name /format:list

Если найдётся что-то незнакомое в EventFilter или EventConsumer - повод разбираться дальше. Это вполне легитимный механизм, которым пользуются и нормальные приложения, поэтому мусор нужно уметь отличать от нормального фона. На всех проверенных системах нашли только стандартные записи от WMI-мониторинга самой Windows и Symantec AV.

Дополнительно прогнали поиск по именам файлов из IoC. Никакого jminet7.sys или cmi4432.sys нигде не нашлось. Хорошая новость, хотя руткит мог и переименовать их - это тоже нужно держать в голове.

Что сложно

Честно говоря, с Duqu сейчас ситуация такая: данных мало, IoC неполные, и непонятно, насколько виденные Symantec образцы репрезентативны. Stuxnet к моменту, когда его разобрали по косточкам, уже год гулял по сети - с Duqu картина аналогичная, только мы об этом узнали чуть раньше.

Проблема с WMI-персистентностью ещё и в том, что её не видно стандартными инструментами типа autoruns (Sysinternals). Autoruns смотрит Run-ключи, Services, Scheduled Tasks - но WMI EventConsumer там или нет, или неочевидно. Мы проверяли вручную через wmic, потому что другого инструмента под рукой не было.

Ещё одна засада: у нескольких клиентов нет централизованных Proxy-логов вообще. Трафик идёт напрямую через NAT, и ретроспективно смотреть не на что. Это отдельная рекомендация, которую мы уже не первый раз повторяем: Proxy с логированием - не опция для сети, где есть промышленный сегмент, это необходимость именно для таких разборов.

Где мы сейчас

Прямых следов Duqu у проверенных клиентов не нашли. Это не означает «всё чисто» в абсолютном смысле - IoC могут быть неполными, а у нас нет возможности проверить каждый хост с аппаратным анализом памяти. Но базовый аудит по сетевым признакам и WMI-провайдерам сделан.

Отчёт Symantec обновляется - следим. Если появятся новые IOC или хэши - прогоним ещё раз.

Главный практический вывод из этой истории - не про Duqu конкретно: WMI как механизм персистентности использует не только Duqu, и мониторинга Run-ключей уже недостаточно. Это надо закладывать в процедуры проверки при следующих инцидентах.