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