Если вы думаете, что расследование ИБ-инцидентов — это скучное копание в логах под монотонное жужжание серверов, то спешу вас разочаровать. Это скорее детективный сериал, где вместо отпечатков пальцев — логи, а место преступления — запутанная паутина корпоративной сети. И да, наш главный герой тоже любит эффектно снимать солнцезащитные очки, только вместо фразы «Похоже, у нас убийство» он говорит: «Кажется, у нас компрометация Exchange».

В этой статье мы погрузимся в увлекательный мир расследований, где каждый день — новая головоломка, а злоумышленники иногда оказываются более изобретательными, чем создатели CTF-заданий. Разберем ключевые аспекты этой непростой, но захватывающей работы: обсудим типичные сценарии атак, вспомним пару интересных историй из практики и ответим на вопрос о том, стоит ли компаниям идти на переговоры с хакерами. 

Мы запустили подкаст «Все по ИБ» и публикуем избранные моменты в текстовом формате, но в хабрастатью помещается далеко не все интересное. Рекомендуем послушать выпуск целиком.

Действующие лица:

• Владимир Ченцов, руководитель департамента комплексного аудита и безопасной разработки компании Бастион.

• Семен Рогачев, руководитель отдела реагирования на инциденты. 

О грани между реагированием и расследованием 

Мониторинг угроз — важная, но не самая захватывающая часть работы SOC. Не будем на нем останавливаться и сразу перейдем к самому интересному: реагированию и расследованию. Заказчики часто путают эти понятия, и зря: если реагирование на инциденты напоминает работы по деминированию, где нужно срочно локализовать угрозу, то расследование — это скорее вдумчивые и методичные археологические раскопки, позволяющие по крупицам восстановить картину атаки.

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

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

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

Почему сразу триаж? У меня в практике были случаи, когда заказчик пытался самостоятельно снять образ диска, и тратил уйму времени на его физическую передачу со всеми сопутствующими формальностями. Это не лучшая идея. У вас есть системный диск на 512 ТБ. Пока вы снимите образ, пока передадите его... Разумнее снять триаж, который весит 0,5 ГБ, и не задействовать поезда и самолеты для передачи этого добра.

Отдельных мемов заслуживают попытки скачать полный образ диска из какого-нибудь облака. Например, однажды системный администратор на стороне заказчика просто уснул, не заметив, что передача образа прервалась.

Когда инцидент нейтрализован, мы переходим к расследованию — глубокому анализу причин и последствий атаки, по итогам которого заказчик получает отчет с описанием шагов атакующего и рекомендациями по укреплению ИБ-инфраструктуры. Для проведения расследований нужна хорошая дедукция, умение разбираться в техниках и тактиках атакующих, прокаченные навыки Threat Intelligence и глубокие познания в области цифровых артефактов.

Артефакты — это оставленные злоумышленником цифровые следы, кусочки паззла, которые позволяют восстановить картину инцидента. Наиболее ценными артефактами обычно являются Evidence of Execution — следы выполнения программ в операционной системе. Конечно, не стоит забывать и про журналы аутентификации пользователей — именно их часто не хватает при расследовании инцидентов.

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

Хактивисты или вымогатели — с кем сталкивается российский бизнес?

Что касается характера и «состава» инцидентов, то целенаправленные заказные атаки происходят значительно реже, чем принято считать. Чаще всего действуют вооруженные зловредами злоумышленники, которым нужны деньги. С 2022 года Россия вышла из условной «тихой гавани», и нас накрыла эпидемия шифровальщиков. Многие группировки не ограничиваются стандартными угрозами по уничтожению зашифрованных данных, вдобавок прибегая к «двойному» и «тройному» вымогательству (Double/Triple Extortion).

При Double Extortion атакующие дополнительно выгружают критически важную информацию, угрожая ее публикацией, чтобы повысить давление на компанию. Triple Extortion представляет собой еще более агрессивную тактику: злоумышленники не просто шантажируют жертву украденными данными, но еще и грозят подвергнуть ее инфраструктуру DDoS-атаке. 

Встречаются и хактивисты, но их истинные мотивы не всегда соответствуют заявлениям. Например, в одном из недавних кейсов хакеры длительное время пытались получить выкуп и даже начали сливать в сеть личные данные сотрудников, чтобы усилить давление на компанию. Вели себя достаточно некрасиво даже по меркам черных шляп, а когда поняли, что денег уже можно не ждать — внезапно «переобулись» и объявили, что их атака была политически мотивированной. 

Методы расследования инцидентов с шифровальщиками

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

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

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

• Встречаются шифровальщики, после которых восстановить файлы не получается, даже если у вас есть корректная точка восстановления. В таких случаях даже наличие ключа шифрования и заново написанный декриптор ничего не гарантируют. 

• Иногда клиенты сами «роют яму», отрубая машины во время процесса шифрования. Во-первых, так уменьшается вероятность восстановления, во-вторых, ключ, который обычно хранится в оперативной памяти и дописывается в конце файла, просто не сохраняется.

Как бизнес упрощает работу атакующим

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

Порой даже не приходится искать сложные эксплойты или хитроумные техники — злоумышленники попросту пользуются тем, что кто-то не закрыл очевидные бреши. Сперва сталкиваешься с атакой и думаешь: «Ну да, круто придумали, интересно…» Но потом начинаешь глубже разбираться в деталях инцидента и понимаешь: впечатляет разве что уровень безалаберности, который допустили разработчики сервиса.

В одном из расследований мы обнаружили такую цепочку атаки: злоумышленники проникли в Linux-инфраструктуру, затем расширили доступ на Windows-среду, где запустили программу-шифровальщик и выгрузили важные данные.

Мы подсветили эту схему администратору, а он отвечает: «ой, а я думал, что у нас линуксовая и виндовая часть инфраструктуры разделены». Ты предлагаешь ему дать SSH и пингануть домен контроллера, и вы вместе выясняете, что это не так, и что для предотвращения инцидента даже не нужно было никаких СЗИ. Простая инвентаризация и регулярное обновление информации могли предотвратить миллионные убытки.

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

Возможно, это когнитивные искажения человека, который слишком часто встречается с инцидентами, но по моим наблюдениям, бизнес слишком часто уверен, что все работает прекрасно. Даже простая мысль «а вдруг нас уже взломали» — редкая птица в голове заказчика. 

С одной стороны, это проблема человеческого фактора: директору по ИБ сложно признать, что возможно где-то его СОИБ не работает. С другой, это неверное восприятие защиты периметра: все думают, что в компании все хорошо до тех пор, пока не становится совсем плохо. А ведь отсутствие зафиксированных инцидентов информационной безопасности вовсе не означает, что их нет. 

Показательный пример из нашей практики: компания подвергалась атакам через одну и ту же уязвимость в Microsoft Exchange на протяжении двух лет. При первом взломе злоумышленники зашифровали данные, но компания восстановилась из уже зараженного бэкапа. Через год снова заглянули на огонек — просканировали инфраструктуру, разлили майнер. Ни один из инцидентов расследовать не стали, поэтому еще через полгода произошла третья атака с использованием программы-шифровальщика, которая в итоге парализовала работу компании.

Почему штатных специалистов бывает недостаточно

Для малого бизнеса выхлоп, который получит компания, часто несоразмерен затратам на найм профи, поэтому многие небольшие компании делегируют расследование инцидентов внутренним ИБ-специалистам. 

В чем тут проблема? Даже если у малого или среднего бизнеса есть ИБ-отдел, среди штатных сотрудников вряд ли найдется специалист по расследованию инцидентов. Конечно, они могут попытаться, и периодически у них даже будет получаться: есть люди, которые любят глубоко копать и обладают широким кругозором. Они вполне могут закрывать базовые потребности компании на чистом энтузиазме. Но даже при успешном прохождении всех этапов самостоятельного расследования остается риск того, что злоумышленник сохранил доступ к системе. 

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

Другая серьезная проблема — затянутое принятие решений. Когда заказчик обращается за помощью через несколько недель после инцидента, возможности расследования существенно ограничиваются. Это особенно критично для Linux-систем со стандартными настройками логирования, где журналы событий регулярно удаляются в процессе ротации. Порой заказчики сами удаляют редкие или ранее неизвестные вредоносы, которые стоит исследовать. 

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

Четкого тайминга, когда пора привлекать сторонних специалистов к расследованию, не существует. Универсальная рекомендация — чем быстрее, тем лучше. Бывали случаи, когда нам приходилось исследовать события восьмимесячной давности, а при проведении полной проверки безопасности (Compromise Assessment) мы обнаруживали следы проникновений, которым было больше шести лет.

Торг с хакерами: манипуляции, риски и реальные дедлайны

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

Утверждать, что ни в коем случае нельзя платить хакерам, не будем. В некоторых ситуациях бизнес так функционирует, что заплатить оказывается дешевле. Ну встанет у вас миллиардный бизнес, и во сколько вам обойдется этот простой? Одному из наших заказчиков простой длительностью около часа обошелся в 40 млн. рублей. Можно не платить, но попробуйте тогда объяснить этот момент собственнику бизнеса. Как говорится, «spice must flow».

Почему эти игры разума приносят столько удовольствия

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

Возьмем недавний случай из нашей практики. Известная хакерская группировка провела масштабный взлом и раструбила о своих успехах на весь Telegram. Расследуя этот инцидент, мы обнаружили, что полгода назад ему предшествовала практически идентичная атака: уязвимость и точка проникновения — одни и те же, но инструменты при этом использовались абсолютно разные. 

По итогу мы пришли к выводу, что клиента с разницей в полгода взломали две разные группировки:

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

• Вторая незаметно прокралась за полгода до первой, применив инструменты, которые до этого вообще никогда не светились в паблике. Хотя базовые принципы их работы были не новы, обнаруженное ПО оказалось уникальным и ранее не встречалось.

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

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