ИБ-факапы 2019 – типичные и не очень

«Зато не скучно!» — так звучит неформальный девиз сотрудников нашего центра мониторинга киберугроз Solar JSOC (и надо сказать, 2019 год полностью ему соответствовал). В начале нового года многие любят подводить итоги и ставить новые цели, но мы решили вместо этого рассказать несколько «ужасов нашего городка» – кейсов 2019 года, которые впечатлили даже видавших виды аналитиков. Вывод же из этих историй только один: технологии развиваются и эволюционируют, а человеческая лень, халатность и безалаберность вечны.

Гостевой вай-фай

При подключении заказчиков к мониторингу мы первым делом запрашиваем наиболее важную информацию: критичные учетки, доменные группы, недоверенные сегменты, белые адреса, DMZ, критичные подсети и прочее. Недоверенные подсети — это как раз гостевой Wi-Fi, а еще сети подрядчиков, тестовые сегменты с правами на сети permit any any и т.п… Обычно мы смотрим, чтобы возможность взаимодействия с такими сегментами отсутствовала или была серьезно ограничена, потому что контролировать их очень сложно, а то и невозможно. На сети этого заказчика возможности таких взаимодействий не было, за исключением страницы авторизации в гостевой сети. Мы было успокоились, добавив запрет на взаимодействие из Wi-Fi с ТОR, C&C-серверами и прочей нечистью, чтобы нас не засыпало срабатываниями, которые потенциальному заказчику были не интересны (хотя статистику по этим инцидентам мы таки собирали – для сводных отчетов). И вот на третье утро пилотного проекта заметили аномалию: поток событий с межсетевого экрана увеличился в 4 раза!

Стали искать причину «засора» и, с удивлением обнаружили ее в сегменте гостевого Wi-Fi. Некий хост генерил 4 миллиона (!) событий в час. И события довольно любопытные — коннекты по 445 порту на рандомные белые адреса интернет-пространства. Четыре миллиона, Карл!

Сообщив об этом заказчику, стали ждать информации о хосте и инциденте, так как DHCP (он же сервер авторизации) не был подключен к SIEM. Примерно через 3–4 часа заказчик сообщил, что хост — мобильный телефон. Сказать, что мы удивились — ничего не сказать. Такой поток событий обычный мобильный телефон генерить не может. Стали выяснять подробности, и оказалось, что мобильный телефон ни при чем — кто-то просто использовал одно из зарегистрированных устройств в качестве прикрытия. Обнаружить истинный источник активности не удалось, а клиент наш заявил, что ему данный кейс не интересен, поэтому активность пришлось свернуть. Тем не менее мы предупредили специалистов заказчика о возможных рисках: так как активность (явно вредоносная) идет с их адресов, они могут, например, попасть в списки C&C-серверов антивирусных вендоров и получить претензии от правоохранительных органов (мало ли какую инфраструктуру просканирует этот хост — там ведь может быть и КИИ, а сканирование на уязвимости относится к инцидентам, о которых необходимо информировать ГосСОПКА). После таких аргументов заказчик все-таки решил разобраться подробнее и выполнить наши рекомендации. А они были следующие:

1) закрываем все порты, кроме 80 и 443 (это оказалось верным решением, так как после 445 последовал скан по 22 порту),
2) вводим ограничения по скорости раздаваемого интернета,
3) активируем фишки UTM, включая application control, и режем странные категории типа торрентов, ТОR-браузеров, определяемых сканеров и прочего,
4) включаем лимит на количество соединений в интервал времени.

Заказчику так и не удалось узнать, кто был этим активным пользователем вай-фая, но, по крайней мере, кислород ему перекрыли (и, скорее всего, злоумышленник пошел искать следующий доступный Wi-Fi.

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

By default, или Вендорская диверсия

Параллельно с пилотным подключением к мониторингу Solar JSOC заказчик вводил в эксплуатацию новый UTM. Миграция на него была поэтапной: сначала перенесли ACL по подсетям, затем политики application. На десерт осталось самое интересное.

Все случилось по классике — в пятницу вечером. Первая линия зафиксировала сработки по обращению из инфраструктуры заказчика на ТОR-ноды, фигурирующие как C&C в одной из рассылок ФинЦЕРТ. Так как проект был пилотный и заказчик все инциденты перевел в Low-критичность, звонка или дополнительного действия, помимо оповещения по почте, карточкой инцидента предусмотрено не было. Поэтому первая сработка с разных хостов на один адрес, хоть и вызвала подозрение у инженеров мониторинга, не была эскалирована дальше. Когда количество сработок достигло трех, ребята почуяли неладное и сообщили об этом аналитику, который взял инцидент в работу.

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

Подключение трех хостов на уровне локальных логов тоже не дало понимания, какой процесс генерит активность. Беспокойство нарастало, единственным рабочим вариантом оставалась изоляция хостов с параллельным снятием дампа оперативной памяти и образа жесткого диска. Аналитик приступил к подготовке инструкций и параллельно решил погуглить IP, к которому обращались хосты, на предмет его наличия в других рассылках и инцидентах (ибо тот тип активности, который мы наблюдали, отличался от описываемого в рассылке ФинЦЕРТ). В большинстве своем затея довольно гиблая, но не в этот раз.

Внимание привлекла статья в заголовке которой значились IP-адрес и название вендора UTM. Если кратко изложить суть публикации — вендор купил себе IP-адрес, ранее принадлежавший ТОR-ноде, которая фигурировала в рассылке ФинЦЕРТ. И это не только лишь всё! Дальше вендор решил сделать этот адрес дефолтным для редиректа всех подозрительных обращений из инфраструктуры своих клиентов к потенциально вредоносным адресам. То есть любой коннект со странным айпишником интерпретировался UTM как нелегитимный и редиректился на этот чудо-адрес.

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

P.S. Анализ сработок, которые обнаружил UTM, подтвердил, что все 7 активностей были False Positive.

Мы обещали рекомендации к каждому кейсу, но тут, пожалуй, дадим лишь одну: do not deploy on Friday. И предупреждайте всех заинтересованных и сочувствующих.

Исторически так сложилось

Этот лейтмотив объединяет множество самых разнообразных кейсов. Взять к примеру вывод из эксплуатации. Зачастую в компаниях потерявшие актуальность процессы просто забываются: никто не «разбирает» старую инфраструктуру, оставляя старые виртуалки, серверы и сетевые доступы. При этом за обновлениями, антивирусами и событиями на этих хостах никто не следит, и даже админы часто не знают владельцев систем. Поэтому спустя время такие элементы инфраструктуры преподносят не самые приятные сюрпризы. Чего стоит только отправка значимой телеметрии из окологосударственной организации по проекту, завершенному в 2005, на FTP-серверы уже не дружественной страны!

Часто обслуживанием систем 10-летней давности никто не занимается, хотя они продолжают эксплуатироваться. Например, портал для сброса паролей, который использует древний движок и для удобства пользователей смотрит в интернет, или RDP, который нужен подрядчику для настройки бизнес-приложений и торчит наружу по 5–6 лет.

О существовании таких проблем обычно становится известно, когда:
1) хост взломали, и произошло шифрование с дальнейшим вымогательством (последнее время таких инцидентов возникает очень много),
2) происходит миграция с одного решения на периметре на другое,
3) мы приходим на пилот и собираем профиль открытых портов на периметре.

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

Самоволка, или Потому что так удобнее

Кейс в целом довольно тривиальный, чего не скажешь о «методике реализации».

Дано:
1) пилотный проект по мониторингу у заказчика;
2) подключенные источники на периметре, а также между корпоративным и технологическим сегментами;
3) админ, дежурящий на рабочем месте и обслуживающий закрытый сегмент сети;
4) острое желание администратора меньше работать, больше спать и делать все с комфортом.

Как я уже говорил, при подключении мы запрашиваем у заказчика разную информацию, в том числе белые адреса, чтобы собрать статистику по подключениям к ним из интернета и таким образом сформировать профиль внешнего периметра. Создав правило, заполняющее список в SIEM, мы примерно за неделю-две собираем статистику обо всех открытых портах на периметре, выгружаем ее заказчику, совместно смотрим и фиксируем (параллельно закрывая то, что нелегитимно). Собирая информацию для профиля, мы периодически пробегались глазами по списку, верифицируя, что порты открыты всем или только некоторым адресам по белым спискам. Внимание привлек порт 43388, который вроде бы ничем не примечателен, но транслировался в 3389 и серый адрес, владелец которого нам был тогда неизвестен.

При проверке оказалось, что он закрыт для наших адресов. Мы подумали, что открыт он по белым спискам, но в течение дня не наблюдали на него ни одного успешного коннекта. Придя следующим утром, опять заметили, что за ночь прилетела пачка событий. На этот раз мы пристальнее посмотрели на source-адреса и увидели несколько сессий из Москвы общей длительностью более 5 часов и довольно большое количество коротких сессий из различных точек мира. Тут стало понятно, что дело не в том, что порт доступен только адресам из белого списка, а в том, что открывался он только ночью — примерно с 00.00 до 06.00 утра. Раскопав логи с домена и антивируса (к тому моменту их как раз подключили), с удивлением обнаружили, что адрес принадлежит дежурному админу, который в этот временной интервал должен быть на рабочем месте! Проанализировав коннекты с его машины, обнаружили еще одну интересную ситуацию: каждую ночь открывался еще и порт (думаю, не трудно догадаться, какой именно) в закрытый выделенный сегмент. Заметить такую активность на четвертый день пилота практически невозможно, к тому времени количество разрешенных коннектов между сегментами все-таки больше, чем открытых портов на периметре. Сообщив безопасникам о ситуации, подключили хост на уровне локальных логов и убедились, что администратор тихонько сбегает с работы домой. Как выяснилось, жил он чуть ли не в соседнем доме, и удаленное подключение, конечно, стало слишком большим соблазном.

Возможно, если бы админ обрисовал ситуацию, ему разрешили бы работать удаленно через СКДПУ при условии, что в момент аварии он сможет в течение 15 минут явиться на работу, и проблем бы вообще не возникло.

Итого

В реальности одна из основных угроз информационной безопасности – это раздолбайство на местах. Поэтому минимизируйте риски:

1. Следите за периметром и конфигурациями межсетевых экранов.
2. Старайтесь сделать удаленку в компании управляемой (VPN через терминальный сервер). А если она уже есть, контролируйте, кто ей пользуется (удаляя различные RAT на хостах, которые сейчас с легкостью детектят почти все антивирусные движки).
3. Следите за действиями привилегированных пользователей: очень часто они теряют бдительность, считая, что у них все под контролем, и собственноручно облегчают злоумышленникам доступ к критичным данным.

Автор: avpavlov

Источник ^[1]