Такие истории редко оказываются публичными: мало кто любит хвастаться тем, как их пошифровали (даже если это хэппиэнд). Но пора признать — эти истории есть, они ближе, чем мы думаем, и их абсолютно точно в разы больше, чем все привыкли считать. Шифровальщики все еще остаются в топе угроз среди атак на организации. Одну из таких атак сумела запечатлеть система поведенческого анализа сетевого трафика PT Network Attack Discovery (PT NAD), которая в это время пилотировалась в компании. И если бы только оператор SOC обратил внимание на алерты в интерфейсе новой системы… но история не терпит сослагательного наклонения.
Пролог
Ночью 16 апреля 2023 года в Москве было тепло — всего +8. Воздух во всю пах весной и предвкушением надвигающегося лета — он был сладким и пьянящим. В ту же спокойную ночь в серверной одной компании мигали огоньки серверов и мерно шумел кондиционер. В сети неторопливо шифровался домен.
Время и обстоятельства выбраны неслучайно. Когда еще шифровать домен, как не в ночь с субботы на воскресенье? Мы повернем вспять цепочку ошибок. Пройдем череду драматических событий от конца к началу и узнаем, как хакеры проникли в сеть и действовали на протяжении своего пути. Мы также узнаем о местах, в которых злоумышленники спалились, из-за чего могли быть вовремя остановлены. И все это увлекательное путешествие пройдем глазами PT Network Attack Discovery (PT NAD).
Начало конца
У всего есть начало и конец. На скриншоте вы видите конец. Поведенческие модули PT NAD обнаружили массовое создание новых задач на узлах в домене. Время подходящее — с 02:34 до 03:00. Глубокая ночь или раннее утро? Это не имеет значения, ведь все, кто мог вовремя заметить и предотвратить атаку, мирно спали в своих домах. Никто не остановит шифровальщика.
Прошу обратить внимание не только на то, что для запуска команд хакеры используют обычные задачи планировщика Windows, но и на узлы, которые их создают. Как правило, самые трагичные истории — это истории о дружбе и предательстве. Например, о том, как контроллер домена, которому доверяешь, как себе, стал источником заражения (DC в имени узла означает Domain Controller).
Пароль в строке запуска шифровальщика shadow.exe создает лишь иллюзию контроля и шанса все спасти. Он везде одинаковый, и расшифровать с его помощью файл вряд ли получится. Имена задач сгенерированы псевдослучайным алгоритмом, да и придумывать для маскировки настоящие имена ни к чему, если вы шифруете буквально каждый узел в сети. Строка запуска, скорее всего, говорит о присутствии шифровальщика LockBit. Параметр pass используется для дешифровки части кода исполняемого файла — такой вот способ обхода антивируса.
Как он туда попал? Контроллеры доменов — это самый охраняемый узел в сети, доступ к которому есть только у администраторов. Постойте-ка! PT NAD позволяет искать сетевые сессии, где передавались файлы с определенным именем.
За полчаса до начала шифрования exe-файл передавался между двумя контроллерами домена, один из которых впоследствии и начал атаку. Но обратите внимание на учетные записи. Одна из них имеет префикс adm_, который обычно указывает на учетную запись администратора с максимальными правами в домене.
Что бы вы сделали на месте хакера, перед тем как шифровать данные? Если вы считаете себя порядочным хакером, нужно уметь восстанавливать зашифрованные данные после выкупа, или вам скоро перестанут верить — у злоумышленников тоже есть репутация. А важные данные можно еще и выгрузить к себе — они обычно публикуются на сайтах утечек, если выкуп не заплатят. И речь не о нескольких архивах с рабочего стола главного юриста — объем данных может достигать нескольких терабайтов. Как их можно незаметно реплицировать на свои серверы? Да и вообще куда копировать украденные данные?
Похоже, конкретно в этом случае хакеры буквально на месяц арендовали VPS-сервер для выгрузки данных. Логин и пароль на скриншоте хоть и вырезаны, но присутствуют в сессии. В идеальном мире оператор PT NAD мог бы воспользоваться ими, чтобы зайти на сервер злоумышленников и удалить архивы со своими данными. В качестве альтернативы хакеры могут выгружать данные на облачные сервисы хранения, такие как Mega или Dropbox.
Как хакеры получили учетную запись с максимальными привилегиями? Как проникли на узел .51 (DC) и что предшествовало этим событиям? Как бы ни хотелось, мы не узнаем ответов на эти вопросы. Во время расследования киберпреступлений нить повествования может теряться и возникать в совершенно неожиданных местах, а какие-то из вопросов так и останутся без ответов. Так же и в нашей истории. Хакеры могли уйти в пользовательский сегмент сети и бродить там по узлам в поисках доступов.
Почему мы не видим трафик пользовательского сегмента? Как правило, эти участки сети «заворачивают» для анализа в последнюю очередь, а в первую — то, что представляет для злоумышленника особый интерес: ядро сети и серверные сегменты. Затем для анализа заводят внешний трафик, трафик зоны DMZ, сегменты VPN и Wi-Fi. Как бы мы ни хотели, анализировать все не получится, но это не является большой проблемой для средств защиты. Мы можем позволить себе не иметь данных обо всей цепочке действий атакующих, ведь стоит им выдать себя всего один раз — вся их деятельность будет быстро остановлена.
Настало время переместиться в начало истории.
С чего все начиналось?
Безопасники шутят, что самый безопасный сервер — тот, что отключен от сети (интернета и 220). Правда заключается в том, что у каждой большой компании есть несколько точек входа в сеть: сайт, VPN для удаленных сотрудников, сервер почты и удобный сервер SSH только для своих на нестандартном порте. Потенциально их можно взломать или подобрать пароль, а серверы, которые доступны из интернета, называются периметром. Сеть Wi-Fi для сотрудников, кстати, тоже является такой точкой входа.
Стоит ли говорить о том, что защищать периметр необходимо особенно тщательно? Примерно так же, как и пароли доменных пользователей. События 2017 года и эпидемия WannaCry наглядно нам это показали. Паспортные столы и больницы были парализованы на несколько дней «благодаря» тому, что 445 порт на серверах этих организаций был доступен в интернете всем и каждому, без видимой на то причины. Эпидемия WannaCry с тех пор больше не возвращалась, но любой открытый порт (3389/RDP или 22/SSH) каждый день становится объектом пусть небольшого, но перебора паролей.
Так или иначе, если вы сделали 22-й порт публично доступным, будьте готовы ко множеству входящих соединений. Если отключить авторизацию по паролю и добавить авторизацию по закрытому ключу, ваш SSH-сервер становится практически непробиваемым. Серьезных эксплойтов для OpenSSH мир не видел давно, а доступ по SSH хостинг-провайдеры используют повсеместно.
Но если вы видите вот такие сетевые сессии по протоколу SSH с незнакомых серверов, кажется, ситуация начинает выходить из под контроля.
Заглянуть «под капот» SSH-соединений на этот раз не получится.
Они зашифрованы. Хотя по побочному каналу длин пакетов можно судить о том, была ли авторизация по ключу или по паролю и использовалось ли SSH-соединение в качестве туннеля.
Что дальше? Согласно матрице MITRE ATT&CK и здравому смыслу, за первоначальным доступом следует разведка в сети. Злоумышленники перебирают порты SMB/445 и SSH/22 на соседних серверах в DMZ-сегменте. По всей видимости, они имеют данные какой-то учетной записи, которую будут пробовать везде, где это только возможно, чтобы затем распространиться дальше по сети в поисках новых учетных записей. Эта тактика называется Lateral Movement, или перемещение внутри периметра.
Спустя пару часов хакеры переходят к активным наступательным действиям. При помощи скриптов из фреймворка Impacket они начинают перебирать пароли, комбинируют известные имена пользователей и пароли других учетных записей, надеясь на переиспользование пароля (password reuse). Классический пример атаки Password Spraying — когда злоумышленники пробуют один и тот же пароль для многих учетных записей. Эта техника позволяет совершить много попыток перебора без риска блокировки учетных записей. Такую активность удалось выявить благодаря сетевым правилам обнаружения, которые написаны для специфических артефактов запросов Kerberos от библиотеки Impacket. Часто злоумышленники и не думают о том, что их легко заметить по сетевым запросам.
Однажды обнаружив себя, хакер уже не сможет спрятаться от NTA-системы.
Его действия можно будет отслеживать в ручном режиме, просматривая сетевые сессии от скомпрометированных узлов, или во время поиска сессий, где использовались скомпрометированные учетные записи. Если ничего с этим не делать, то список скомпрометированных активов будет расти как снежный ком, хотя хакеры и предпочитают использовать одни и те же учетные записи.
Но бывают и необычные атрибуты 🤡🤡🤡 Например, сессия с авторизацией по протоколу NTLM. Это устаревший протокол, на замену которому пришел Kerberos. Однако он все еще широко распространен, и теперь их используют вместе. Внутри сообщения NTLM есть поле hostname, которое содержит имя узла клиента. Оно опциональное, но по умолчанию хакерский дистрибутив Kali Linux честно кладет туда свое имя — KALI, если ничего не менять. Можно ли найти все сетевые сессии с этим именем? Конечно 🤫
Грандиозных успехов наши герои повествования не достигли, тыкаясь между узлами и пробуя трендовые эксплойты вроде PrinterBug или Zerologon. Но 28 марта произошел переломный момент. Со скомпрометированного узла .98 хакеры начинают исполнять команды разведки whoami, ipconfig на другом узле. Учетную запись хакеры тоже спалили — ею оказалась svc_sync. Видимо, они раздобыли ее на одном из серверов.
Впервые svc_sync была замечена в конце марта, а значит хакерам на ее поиск потребовалось около пяти дней. Это то время, за которое команда ИБ могла бы полностью изолировать скомпрометированные активы и провести расследование инцидента. С 29-го по 31-е марта хакеры еще перемещались внутри периметра, то и дело используя новую учетную запись или учетную запись администратора, а потом и вовсе ушли на выходные. Вернувшись, они, по всей видимости, ушли собирать информацию с недоступных для нас узлов. Вновь они появились уже в апреле, выгружая гигабайты ценных данных на внешний сервер. Но эту часть истории вы уже знаете.
Эпилог
Попадая в новую сеть, хакеры, как и новые сотрудники, не знают, куда идти и где искать интересующие их данные. Только им не у кого спросить. Чтобы освоиться в сети, им необходимо время — дни, недели, а иногда и месяцы. По счастливой для хакеров случайности в этот раз все произошло довольно быстро.
Кроме описанной нами, существуют десятки историй, которые не произошли: про шифровальщиков, которых не успели запустить, и про данные, которые не успели украсть. О них читать не так интересно, как о случившихся инцидентах. О них не любят говорить. Как и не любят принимать сложное решение выключить сеть на выходные, если есть хотя бы малейший риск того, что в понедельник придется разворачивать бэкапы.
От первой SSH-сессии до приказа на шифрование у хакеров ушло более трех недель. За это время они выдавали себя практически на каждом шагу. Да, они не использовали популярные в этом году фреймворки Cobalt Strike и Sliver, облачные сервисы хранения или эксплойты для уязвимостей в «1С-Битрикс». Хотя с таким доступом по протоколу SSH не нужны никакие дополнительные инструменты. Но даже с таким минимальным разнообразием инструментов мы смогли бы вовремя заметить действия злоумышленников в трафике с помощью NTA-системы. А восстановить цепочку действий с конца, используя сохраненную копию трафика и метаданные, было бы делом техники.
Все имена вымышлены, любые совпадения случайны. Берегите себя и свои пароли. С вами был Кирилл Шипулин, руководитель группы обнаружения атак в сети, экспертный центр безопасности Positive Technologies. До новых историй.