Кейсы для применения средств анализа сетевых аномалий: обнаружение кампании DNSpionage

Кейсы для применения средств анализа сетевых аномалий: обнаружение кампании DNSpionage
Продолжаем рассмотрение кейсов для систем анализа сетевого трафика (NTA) применительно к целям кибербезопасности. Сегодня мы посмотрим, как такие решения можно применить для обнаружения очень непростых, целенаправленных и очень эффективных кампаний под названием DNSpionage и Sea Turtle.

Но перед этим, я вкратце напомню как работает система доменных имен (DNS), которая лежит в основе взаимодействия в Интернет. Человеческий мозг так устроен, что неспособен запоминать много цифр и чисел, которые никак не ассоциируются у человека с чем-то знакомым. Да и число запоминаемых комбинаций цифр и чисел в любом случае невелико. Поэтому, чтобы не запоминать и не хранить в записной книжке сотни и тысячи IP-адресов интересующих нас сайтов и была придумана система DNS, которая транслирует более понятные человеку символьные адреса сайтов в их IP-адреса. Если мне нужно попасть на какой-либо сайт, то я отправляю DNS-запрос с именем сайта на DNS-сервер, который возвращает мне его IP-адрес, по которому я и перехожу.



Если погрузиться чуть больше в детали, то схема выглядит сложнее. Если ближайший ко мне DNS-сервер не знает IP-адреса интересующего меня сайта, он направляет меня к корневому серверу, который затем направляет меня к DNS-серверу зоны, в которой находится интересующий меня сайт (например, “.ru”), и дальше по цепочке пока я не дойду до DNS-сервера, который знает нужный мне IP-адрес.



Получается, что мы доверяем DNS-серверам, которые присылают нам IP-адреса сайтов, которые мы хотим посетить. А если кто-то взломает DNS-сервер и подменить записи соответствия символьного имени и IP-адреса? Что если нас направят на фальшивый сайт, который будет выглядеть как настоящий и который может украсть наши логины и пароли, а также иную конфиденциальную информацию о нас? Такая подмена называется DNS-перенаправлением (DNS Redirection) и она используется злоумышленниками в особо опасных атаках.



В 2009-м году “Иранская киберармия” таким образом подменила сайт twitter.com. В 2011-м турецкими хакерами было подменено 186 доменов, среди которых HSBC, Vodafone, Acer и др. В 2013-2014-м годах “Сирийская электронная армия” подменили сайты NYT, Twitter, Huffingtin Post (против Facebook попытка не удалась). В этом же году схожие действия были произведены против WhatsApp, AVG, Avira. Спустя год были подменены вьетнамский и малазийский сайты Google, а также домен федерального резервного банка Сент-Луиса. В 2016-м таким образом было украдено энное количество криптовалюты у blockchain.info.

На самом деле векторов атак на DNS существует больше, но мы сегодня рассмотрим только те из них, которые связаны с кампаниями DNSpionage и Sea Turtle .



Теперь, кратко ознакомившись с тем, как работает DNS и как можно его использовать во вред, мы можем обратиться непосредственно к кампаниям DNSpionage и Sea Turtle, начав с первой из них. В 2018-м году подразделение Cisco Talos столкнулось с ней в ряде стран Ближнего Востока. Она состояла из двух частей — заражение пользователей и DNS Redirection, которые не всегда были связаны между собой, но по ряду признаков мы сделали вывод, что за обеими частями стоит скорее всего одна и та же группировка.



В первом случае, пользователи-жертвы получали предложения о работе через LinkedIn и другие сайты для поиска работы. Все вакансии вели на подставные сайты, на которых были размещены заманчивые вакансии. Зафиксировано было два сайта — hr-wipro[.]com и hr-suncor[.]com, которые перенаправляли пользователей на легальные wipro.com и suncor.com. По ссылкам размещались файлы в формате MS Word с внедренными макросами, каждый из которых срабатывал при открытии и закрытии документа соответственно.



Первый макрос декодировал PE-файл и сохранял его по адресу ”%UserProfile%.oracleServicessvshost_serv.doc”. Второй макрос переименовывал “svshost_serv.doc” в “svshost_serv.exe”. Затем макрос создавал задачу “chromium updater v 37.5.0”, которая запускала исполняемый файл и повторяла это каждую минуту. Данное вредоносное ПО выполняло функции RAT (remote administration tool), которое и было названо DNSpionage. Оно взаимодействовало со специально созданным доменом, запрашивая/получая команды, которые и выполняло. Среди этих команд — запрос содержимого директории, сканирование сети, копирование файлов, использование удаленных утилит (WinSSHD, Putty, mimikatz) и т.п. Команды с командного сервера, а также результаты работы отправлялись в одном из двух режимов — HTTP или DNS. Второй вариант обычно проще, так как высока вероятность, что у вас отсутствует полноценная инспекция DNS-трафика и вы просто не заметите общения вредоносного кода DNSpionage с командным сервером.

Самое интересное начинается в момент общения клиентской и серверных частей вредоносной программы. Клиент отправляет на 0ffice36o[.]com (первый символ — это ноль, а последний — буква “о”) следующий обфусцированный DNS-запрос: RoyNGBDVIAA0[.]0ffice36o[.]com, где первые 4 байта сформированы случайно, а остальные (GBDVIAA0) представляют собой закодированный по base32 запрос (для каждой жертвы выбирался собственный алфавит base64/dase32). Его расшифровка дает нам «0GTx00”, где GT — это идентификатор жертвы, а x00 — номер запроса. Командный сервер отвечает нам в виде IP-адреса, не всегда корректного, например, 0.1.0.3 (протокол DNS позволяет это). Второй DNS-запрос выглядит так: t0qIGBDVIAI0[.]0ffice36o[.]com. Командный сервер возвращает нам IP-адрес: 100.105.114.0, которые представляет собой 4 символа в обычной ASCII-кодировке, что в данном случае означает исполняемую команду „dirx00”. В ответ клиентская часть DNSpionage отправляет:

gLtAGJDVIAJAKZXWY000[.]0ffice36o[.]com -> GJDVIAJAKZXWY000 -> “2GTx01 Vol»
TwGHGJDVIATVNVSSA000[.]0ffice36o[.]com -> GJDVIATVNVSSA000 -> «2GTx02 ume»
1QMUGJDVIA3JNYQGI000[.]0ffice36o[.]com -> GJDVIA3JNYQGI000 -> «2GTx03 in d»
iucCGJDVIBDSNF3GK000[.]0ffice36o[.]com -> GJDVIBDSNF3GK000 -> «2GTx04 rive»
viLxGJDVIBJAIMQGQ000[.]0ffice36o[.]com -> GJDVIBJAIMQGQ000 -> «2GTx05 C h»

В рамках второй части кампании DNSpionage осуществлялась кража учетной записи администратора DNS-сервера, изменение соответствующих DNS-записей, создание с помощью LetsEncrypt сертификатов, которые будут использованы далее в атаке “сайт посередине”. Именно на такой сайт с помощью ранее описанной атаки DNS Redirection и будут направлять избранные жертвы (всего за 2 года работы данной кампании нам удалось идентифицировать 25 перенаправлений, что говорит не о массовой, а целенаправленной атаке). Обратите внимание, что атаке может подвергнуться как ваш собственный DNS-сервер (если он у вас есть), так и сторонние DNS-сервера, которые вы уже никак не контролируете.

В рамках своей деятельности злоумышленники смогли перехватывать весь трафик, идущий на указанные заинтересовавшие хакеров домены государственных органов Ливана и Объединенных Арабских Эмиратов (Министерство финансов, полиция, Министерство связи и телекоммуникаций, авиакомпания и др.), в том числе электронную почту и VPN, что могло позволить им собрать дополнительную информацию о своих жертвах.

Кампания Sea Turtle по оценке Cisco Talos была еще более сложна, чем DNSpionage, так как злоумышленники атаковали не только DNS-сервера, но и TLD-сервера (включая ccTLD и gTLD),



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



А теперь вернемся к исходной задаче и посмотрим, как системы анализа сетевого трафика могут помочь выявить упомянутые кампании. Сразу надо отметить, что учитывая их сложность и то, что они могут быть направлены против внешних DNS-серверов, системы класса NTA помогут нам далеко не всегда. Но в тех случаях, когда речь идет о DNS-режиме работы DNSpionage или об атаке на локальные DNS-сервера в рамках DNSpionage или Sea Turtle, мы сможем с помощью Netflow увидеть все необходимые нам признаки атаки и своевременно блокировать их.

Первым делом мы должны определить наши внутренние DNS-сервера и внести их в одну группу. Это то, с чего начинается внедрение почти любой системы мониторинга аномалий. Чтобы понять, встретилась ли нам в сетевом трафике аномалий или нет, мы сначала должны определиться, что нормально и легитимно. И только после этого уже система начинает работать в полную силу.



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



В нашем случае у нас обнаружено 5 серверов:



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



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



Следующее правило позволяет выявить нам внешние подозрительные DNS-сервера, которые напрямую взаимодействуют с внутренними узлами, что может служить признаком работы командного сервера DNSpionage с зараженными корпоративными устройствами:



И мы находим примеры такого взаимодействия:



Схожим образом мы можем настроить систему обнаружения сетевых аномалий (а в данной заметке в качестве ее примера рассматривается Cisco Stealthwatch) для обнаружения несанкционированных попыток доступа внутренних узлов к локальному DNS-серверу (это может служить признаком работы DNSpionage или Sea Turtle), а также активное взаимодействие внутренних узлов с внешними узлами по протоколу DNS (это позволит зафиксировать работу DNSpionage в режиме DNS).

Зафиксировав соответствующие аномалии и нарушения политики безопасности, мы должны разработать правила, которые позволяют сигнализировать о любых будущих попытках соединения внутренних узлов, исключая локальные DNS-сервера, с внешними DNS-серверами (и наоборот).



Второе правило позволяет нам фиксировать любые попытки взаимодействия с помощью DNS-трафика внутри корпоративной сети, исключая локальные DNS-сервера.



Вот таким образом мониторинг Netflow (как и иных flow-протоколов) позволяет нам выявлять отдельные стадии достаточно сложных атак, которые могут наносить ущерб современным корпорациям и госорганам.
Alt text