Стеганография в современных кибератаках

Стеганография (от греч. στεγανός — скрытый + γράφω — пишу; буквально «тайнопись») — наука, позволяющая спрятать передаваемые данные в некотором контейнере, таким образом скрыв сам факт передачи информации.

В отличие от криптографии, которая скрывает содержимое тайного сообщения, стеганография скрывает сам факт его существования. Впервые понятие стеганографии было введено в 1499, но сам метод существует очень давно. Легенды донесли до нас метод, который использовался в Римской империи: для доставки сообщения выбирали раба, голову которого брили, а затем с помощью татуировки наносили текст. После того, как волосы отрастали, раба отправляли в путь. Получатель сообщения снова обривал голову раба и читал сообщение.

В данной статье мы будем использовать следующие определения:

• Сообщение — внедряемое скрытным образом послание, которое необходимо спрятать;
• Контейнер (стегоконтейнер) — любой объект, используемый для тайного внедрения сообщения;
• Стегосистема — методы и средства, используемые для создания скрытого канала для передачи информации;
• Стегоканал — канал для передачи стегоконтейнера;
• Ключ — ключ для получения скрытого содержания из контейнера (используется не всегда).

В течение всего ХХ века активно развивалась как стеганография, так и наука об определении факта внедренной информации в контейнер — стегоанализ (по сути — атаки на стегосистему). Но сегодня мы наблюдаем новый и опасный тренд: все больше и больше разработчиков вредоносного ПО и средств кибершпионажа прибегает к использованию стеганографии. Большинство антивирусных решений на сегодняшний день не защищают от стеганографии или защищают слабо, меж тем, нужно понимать, что каждый заполненный контейнер опасен. В нем могут быть скрыты данные, которые эксфильтруются шпионским ПО, или коммуникация вредоносного ПО с командным центром, или новые модули вредоносного ПО.

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

• Microcin (AKA six little monkeys);
• NetTraveler;
• Zberp;
• Enfal (its new loader called Zero.T);
• Shamoon;
• KinS;
• ZeusVM;
• Triton (Fibbit).

Почему авторы вредоносного ПО все активней используют стеганографию в своих разработках? Мы видим три главные причины:

• Это позволяет им скрыть сам факт загрузки/выгрузки данных, а не только сами данные;
• Помогает обойти DPI-системы, что актуально в корпоративных сетях;
• Использование стеганографии может позволить обойти проверку в AntiAPT-продуктах, поскольку последние не могут обрабатывать все графические файлы (их слишком много в корпоративных сетях, а алгоритмы анализа довольно дорогие).

Для конечного пользователя детектирование стегоконтейнера может быть нетривиальной задачей. Для примера приведем два контейнера: пустой и заполненный, в качестве которых будем использовать стандартное изображение для графических исследований Lenna.

Lenna.bmp	Lenna_stego.bmp

Оба изображения «весят» 786 486 байт, но правое содержит сообщения 10 первых глав «Лолиты» Набокова.

Посмотрите внимательно на эти две картинки. Вы можете различить их? Они одинаковые и по размеру, и по внешнему виду. Тем не менее, одна из них — контейнер с внедренным сообщением.

Проблемы налицо:

• Использование стеганографии сегодня — очень популярная идея среди авторов вредоносного и шпионского ПО;
• Антивирусные средства вообще и средства защиты периметра в частности мало что могут сделать с заполненными контейнерами: их очень трудно обнаружить поскольку они выглядят как обычные графические (и не только) файлы;
• Все существующие программы для детектирования стеганографии по сути являются PoC— Proof-of-Concept, и их логика не может быть имплементирована в промышленные средства защиты из-за низкой скорости работы, не слишком высокого уровня детектирования, и иногда даже иногда — из-за ошибок в математике (мы видели и такие случаи).

Выше был приведен список вредоносного ПО (впрочем, далеко не полный), которое использует стеганографию для сокрытия своей коммуникации. Рассмотрим конкретный пример из этого списка — вредоносный загрузчик Zero.T.

Этот загрузчик был обнаружен нами в конце 2016 года, но первое описание было опубликовано нашими коллегами из Proofpoint.

Мы назвали его Zero.T, т.к. такая строка присутствует в его исполняемом коде (в пути к pdb-файлу проекта):

Не останавливаясь здесь на попадании в систему и закреплении в ней, отметим, что Zero.T скачивает полезную нагрузку в виде Bitmap-файлов:

Обрабатывает их особым образом, после чего получает вредоносные модули:

На поверку эти три BMP-файла оказались картинками:

Но картинки эти не совсем обычные. Это — заполненные контейнеры. В каждом из которых несколько (алгоритм допускает вариативность) младших значащих бит заменены на полезную нагрузку.

Так как же определить является ли картинка заполненным контейнером или нет?  Существуют разные способы, но самый простой из них — визуальная атака. Суть его заключается в формировании новых изображений на основе исходного, состоящих из наименее значащих бит различных цветовых плоскостей.

Рассмотрим на примере изображения с фотографией Стива Джобса:

Применим к этому изображению визуальную атаку, построим новые изображения из отдельных значащих бит соответствующих разрядов:

На втором и третьем изображении заметны области с высокой энтропией (высокой плотностью данных) — это и есть внедренное сообщение.

Просто, не так ли? И да, и нет. Это просто, потому что аналитик (и даже простой пользователь!) может с легкостью увидеть внедренные данные). И сложно потому что такой анализ довольно трудно автоматизировать. К счастью, ученые уже давно разработали несколько методов выявления заполненных контейнеров, основанных на статистических характеристиках изображения. Но все они основываются на предположении, что внедренное сообщение имеет высокую энтропию. Чаще всего это действительно так: поскольку емкость контейнера ограничена, сообщение перед внедрением сжимается и/или шифруется, т.е. его энтропия повышается.

Но наш пример из реальной жизни — вредоносный загрузчик Zero.T, — не сжимает свои модули перед внедрением! Вместо этого он увеличивает количество используемых наименее значимых бит: 1,2 или 4. Да, использование большего количества наименее значащих бит приводит к появлению визуальных артефактов в изображении, заметных простому пользователю. Но ведь речь идет об автоматическом анализе. Вопрос, который нам предстоит выяснить: пригодны ли статистические методы для обнаружения внедренных сообщений в том случае, если их энтропия не высока?

Статистические методы анализа: гистограммный метод

Описываемый метод, предложенный в 2000 году Андресом Вестфелдом и Андреасом Пфитцманом, также известен как «хи-квадрат»-метод. Попытаемся изложить его суть.

Весь растр анализируется, для каждого цвета считается количество точек такого цвета в растре (для простоты здесь говорим про изображение, имеющее одну цветовую плоскость). Метод исходит из предположения, что количество точек двух соседних цветов («соседние» цвета — цвета, которые отличаются только наименее значимым битом) различается существенно для нормального, обычного изображения (пустого контейнера) (рис. а ниже). И количество пикселей таких цветов является примерно одинаковым для заполненного контейнера (рис. б)

а — пустой контейнер	б — заполненный контейнер

Визуально можно представлять себе алгоритм таким образом, это довольно просто для понимания.

Говоря строго, алгоритм заключается в последовательном выполнении следующих шагов:

• Теоретически ожидаемая частота встречаемости пикселей цвета i после внедрения сообщения рассчитывается следующим образом:
• Измеренная частота вхождения символа определенного цвета определена как:
• Хи-квадрат критерий для количества степеней свободы k-1 рассчитывается следующим образом:
• P— это вероятность того, что распределения n_i и n_i^* при этих условиях равны. Она рассчитывается при помощи интегрирования функции гладкости:

Разумеется, мы провели проверку применимости этого метода для детектирования заполненных стегоконтейнеров и вот результаты:

Оригинальное изображение	Визуальная атака	Атака «хи-квадрат», 10 зон

Пороговые значения распределения хи-квадрат для p=0,95 и p=0,99 соответственно 101.9705929 и 92.88655838. Таким образом, для зон, у которых рассчитанное значение хи-квадрат меньше порогового, можно принять исходную гипотезу «распределение частот соседних цветов — одинаковое, следовательно, это заполненный стегоконтейнер».

Действительно, если посмотреть на изображения для визуальной атаки, несложно заметить, что эти области содержат внедренное сообщение. Таким образом, для внедренных сообщений с высокой энтропией метод работает.

Статистические методы анализа: RS-метод

Еще один статистический метод обнаружения заполненных стегоконтейнеров был предложен Джессикой Фридрих, Мирославом Гольяном и Андреасом Пфитцманом в 2001 году. Он называется RS-метод, где RS означает «регулярный-сингулярный».

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

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

По шагам алгоритм работает следующим образом:

• Изображение разделяется на группы из n pixels (x₁, …, x_n).
• Описывается т.н. дискриминант-функция, которая сопоставляет каждой группе пикселей G = (x₁, …, x_n). действительное число f(x₁, …, x_n) ? R.
• Мы можем определить дискриминант-функцию для группы пикселей (x₁, …, x_n) следующим образом:
• Также мы определяем функцию флиппинга, имеющую следующие свойства:

На основании значений дискриминант-фукнции до и после флиппинга, все группы пикселей делятся на регулярные, сингулярные и неиспользуемые:

Мы провели исследование и этого метода тоже, получив следующие результаты. Мы использовали те же заполненный и пустой контейнеры, что и в предыдущем опыте.

Оригинальное изображение	Визуальная атака	Атака «хи-квадрат», 10 зон

Обратим внимание, что этот метод атаки не выносит бинарного вердикта «содержит ли этот контейнер внедренное сообщение», вместо этого он определяет примерную длину внедренного сообщения (в процентах).

Из результатов выше понятно, что для пустого сообщения этот метод вынес вердикт о заполнении менее 1% контейнера, а для заполненного — о заполнении примерно 44% контейнера. Очевидно, что результаты слегка неточные. Обратим внимание на заполненный контейнер: из визуальной атаки однозначно следует, что заполнено более 50% контейнера, в то время как RS-атака говорит нам, что заполнено 44% контейнера. Поэтому мы можем применять этот метод если установим некий «порог срабатывания»: наши эксперименты показали, что 10% является достаточным порогом надежности. Если RS-атака утверждает, что более 10% контейнера заполнено — можно доверять этому вердикту и маркировать контейнер как заполненный.

Теперь пришло время выяснить, пригодны ли два рассмотренных способа для тестирования в реальных условиях на контейнерах Zero.T, сообщение в которых имеют обычную энтропию.

Мы провели соответствующие тесты и вот результаты:

Оригинальное изображение	Атака «хи-квадрат»	RS-атака

Очевидно, что на изображениях с низкой энтропией атака типа «хи-квадрат» не применима — результаты или неудовлетворительные, или не вполне точные, зато RS-атака отработала отлично: в обеих случаях было определено наличие скрытого сообщения. Но что же делать если автоматические методы анализа показали отсутствие внедренного сообщения, а мы все еще подозреваем это?

Можно использовать конкретные процедуры для извлечения полезной нагрузки, разработанные для конкретных семейств вредоносного ПО.  Так, для рассмотренного в этой статье загрузчика Zero.T мы написали собственную процедуру экстракции внедренного сообщения, которая схематично работает следующим образом:

	+
=

Очевидно, что, если в итоге мы получили валидный результат (в данном случае — исполняемый файл), исходное изображение было контейнером.

DNS-Tunneling: тоже стеганография?

Можем ли мы считать использование DNS-туннеля подвидом стеганографии? Определенно, да. Для начала давайте вспомним, как выглядит схема DNS-туннеля в общих чертах.

В закрытой сети с пользовательской машины посылается запрос на «резолв» домена, например, wL8nd3DdINcGYAAj7Hh0H56a8nd3DdINcGYAlFDHBurWzMt[.]imbadguy[.]com (где доменное имя второго уровня не несет смысловой нагрузки). Локальный DNS-сервер передает запрос внешнему DNS-серверу. Тому, в свою очередь, неизвестно имя 3-го уровня и запрос передается дальше. Таким образом, по цепочке перенаправлений от одного DNS-сервера к другому запрос достигает DNS-сервера домена imbadguy[.]com.

Вместо разрешения запроса на сервере злоумышленник может извлечь из полученного домена нужную ему информацию, расшифровав первую часть его имени. Например, таким способом можно передать информацию о системе пользователя. В ответ DNS-сервер злоумышленника так же посылает некую информацию в зашифрованном виде, передавая ее в доменном имени 3-го уровня или выше.

Таким образом, злоумышленник имеет в запасе для каждого DNS резолва 255 символов, до 63 символов для поддоменов. 63 символа в одну сторону — 63 в ответ, 63 — туда, 63- обратно… Неплохой канал для передачи данных! А главное — скрытый, ведь невооруженным взглядом не видно, что идет обмен какой-то дополнительной информацией.

Для специалистов, знакомых с сетевыми протоколами и в частности с DNS-туннелированием, такой дамп трафика будет выглядеть довольно подозрительно: очень уж много успешных резолвов длинных доменов. В данном случае мы наблюдаем реальный пример трафика зловреда Backdoor.Win32.Denis, который использует DNS туннель как скрытый канал общения со своим командным центром.

Обнаружить DNS-туннель можно с помощью любой известной IDS, например, Snort, Suiricata или BRO Ids. Как именно распознать DNS-туннелирование? Существуют различные способы. Например, очевидно, что доменные имена для резолва при туннелировании значительно длиннее, чем обычно. В сети можно найти достаточное количество вариаций на эту тему:

alert udp any any -> any 53 (msg:»Large DNS Query, possible cover channel»; content:»|01 00 00 01 00 00 00 00 00 00|»; depth:10; offset:2; dsize:>40; sid:1235467;)

Совсем примитивно, но встречается и такое:

Alert udp $HOME_NET and -> any 53 (msg: «Large DNS Query»; dsize: >100; sid:1234567;)

Тут можно экспериментировать и стремиться найти свой идеальный баланс между количеством ложных срабатываний и нахождением реального DNS-туннелирования.

На что еще можно обратить внимание помимо подозрительно большой длины доменного имени? На аномальный синтаксис доменных имен. Все мы примерно представляем, как выглядят типовые домены — это в большинстве своем буквы и цифры. Если в доменном имени присутствуют символы, характерные для Base64 кодировки, то это выглядит довольно подозрительно, не так ли? Если при этом еще и длина не маленькая, то явно стоит присмотреться повнимательней.

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

Хочется отметить, что даже такой простой по своему смыслу подход к поиску DNS-туннелей дает очень хорошие результаты. Благодаря нескольким таким правилам для IDS мы на входящем потоке вредоносного ПО, поступающем к нам в «Лабораторию», обнаружили несколько новых, неизвестных до этого бэкдоров, использующих скрытый канал общения с командным центром — DNS-туннель.

Выводы

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

Однако решения есть, они основаны на комбинировании различных способов анализа, высокоскоростных предетектах, исследовании метаданных потенциально заполненного контейнера и т.п. Такие решения сейчас нашей компанией реализуются в нашей платформе защиты от таргетированных атак — КАТА. Ее использование позволяет сотруднику службы информационной безопасности своевременно узнать о возможной таргетированной атаке на защищаемый периметр и/или эксфильтрации данных из него.