Впервые в истории мероприятий SOC Forum были опубликованы данные о реальных взломах, с которыми столкнулись российские компании в 2023 году. Полученный опыт может быть полезен другим участникам рынка. Речь идёт не только о рисках, но и о реальных случаях успешных кибератак и ответных действий защитников.
- Введение
- Кибератака на инфраструктуру Platformix
- Кибератака на Kaspersky («Операция Триангуляция»)
- Типовая кибератака на инфраструктуру российской компании
- Кибератака на инфраструктуру российского телеком-оператора
- Выводы
Введение
Одним из нововведений SOC Forum 2023 стало появление нового блока в бизнесово-технологической секции, получившего название «Кейсы взломов». Сам факт того, что четыре российские ИБ-компании решили поделиться реальными кейсами публично, беспрецедентен. Верится, что это начинание не будет исключением. Публикуемая информация явно полезна другим участникам рынка.
Почему?
Провалы случаются у всех, в том числе у крупных игроков рынка. Но в российской культуре до сих пор не было принято рассказывать публично об ошибках. Считается, что это наносит урон репутации компании.
Этого правила придерживаются все компании в мире, Россия — не исключение. Но если законодательство обязывает раскрывать данные, то приходится говорить и о неудачах.
В России пока расследования носят исключительно внутрикорпоративный характер. Информация об инцидентах всё равно проникает наружу, но область её хождения ограничивается докладами вышестоящим организациям и регулятору, а также слухами. Как правило, это — служебная тайна, не допускающая разглашения.
Публичная презентация, сделанная на SOC Forum 2023, добавляет доверия компаниям, которые решились на это. Одновременно другие игроки получают достоверную информацию из первых уст. Это помогает им лучше понять, что аналогичные инциденты могут произойти и с ними. Как следствие, прогрессирует рынок ИБ в целом.
Рисунок 1. Сессия «Кейсы взломов российских ИБ-компаний» на SOC Forum 2023
Кибератака на инфраструктуру Platformix
Среди многих компаний бытует мнение, что нет веских причин для целевых кибератак против них. Принято считать, что атаки совершаются с очевидными, наперёд заданными целями. Но как быть, например, с атаками ради хайпа или хактивизма?
Об атаке на компанию Platformix рассказал Виталий Масютин, замдиректора по ИБ. Кибератака была совершена на ИТ-компанию (интегратора), отличающуюся зрелым подходом к защите. Как такое возможно?
Как отметил спикер, на момент начала атаки у них была высокая степень уверенности в своей защищённости. Компания имела сертификаты на все процессы в соответствии с требованиями регулятора. Оценивая ситуацию с точки зрения полученного опыта, Виталий Масютин отметил, что главной причиной ущерба стала завышенная самоуверенность, убеждённость в том, что подобное практически не имело шансов произойти.
До начала кибератаки в компании интуитивно считали, что атаковать их целенаправленно не будут. «Много денег взять с нас невозможно; секретных данных у нас нет, мы не являемся частью какой-либо государственной системы. Даже в случае DDoS-атаки, теоретически способной помешать обычному графику работы, мы могли разойтись по домам и работать удалённо — с бэкапами у нас всё было хорошо».
Рисунок 2. Схема атаки на компанию Platformix
Атака на компанию Platformix произошла ночью в субботу. Фактически оказалось, что были пропущены все стадии совершения кибератаки. Её следы были замечены только после того, как сисадмины обнаружили потерю выхода на управление доменом.
Атаку выявили по косвенному признаку: не наблюдалось привычных ответов от сервиса антивирусной защиты. Администратор решил найти причину сбоя антивируса, но не смог подключиться к серверу, используя свои учётные данные. Последующий анализ показал, что практически все учётные записи администраторов скомпрометированы. Анализ логов Active Directory показал появление подозрительных действий.
Дальнейшие события были очевидны. ИТ-специалисты занялись восстановлением данных из резервных копий и первым делом ввели ограничения на удалённый доступ для всех посторонних пользователей. Служба ИБ подключила SIEM-, EDR- и XDR-агенты к инфраструктуре и стала проводить мониторинг событий в настоящем времени.
Рисунок 3. Схема защитных мероприятий в компании Platformix
Исследование инфраструктуры дало следующие результаты. Были выявлены:
- компрометация учётных данных для пяти администраторов и двоих пользователей;
- компрометация восьми серверов (включая сервер антивирусной защиты) и семи рабочих станций;
- подозрительный драйвер, ранее встречавшийся в атаках вымогателей (ransomware);
- подозрительный сайт в инфраструктуре.
Кибератака была остановлена за 97 минут. Поскольку драйвер, с помощью которого отключили антивирус, был подписан китайским производителем, первоначально появилась гипотеза, что атака пришла из Китая. Но на этом репутационная проверка закончилась. Было принято решение, что компетенций для оценки оставшихся следов может оказаться недостаточно. Существовал риск повторения атаки, заявил Виталий Масютин. Поэтому были приглашены специалисты из Kaspersky.
Рисунок 4. План мероприятий по устранению последствий атаки на компанию Platformix
Их профессиональная оценка не отличалась по логике от того, что делали специалисты Platformix. Но, по мнению спикера, проводимый анализ был существенно глубже по содержанию.
Удалось выявить другие заражённые машины, что стало признаком горизонтального перемещения по инфраструктуре. Всего было проведено около десяти повторных итераций проверки.
В результате обнаружился источник кибератаки: электронное письмо. Только через неделю при полном отсутствии каких-либо других признаков вредоносной активности было принято решение, что отражение атаки завершено.
Как было осуществлено нападение?
По мнению Platformix, кибератака была осуществлена через стороннюю организацию, к которой ранее относились с полным доверием. Там злоумышленник сумел получить доступ к управлению электронной почтой. Используя её возможности, он создал всё необходимое для реализации атаки. Использовался набор вредоносных программ, которые на тот момент не детектировались популярными антивирусами.
Злоумышленник выделил среди работников Platformix потенциальных жертв (28 человек) с учётом проектов, над которыми они трудились. Фишинговое письмо было доставлено таким образом, чтобы не вызывать сомнений в его достоверности.
При открытии фишингового письма устанавливался драйвер. Он отключал антивирус и осуществлял повышение привилегий. Когда была получена учётная запись для управления доменом, произошло дальнейшее развитие атаки.
Рисунок 5. ИБ-мероприятия после инцидента в компании Platformix
После кибератаки компания сделала следующее:
- провела стандартные мероприятия с целью повышения внимания сотрудников к ИБ;
- переустановила программы и сервисы, осуществила сброс учётных записей всех пользователей с повышенными правами и пересмотрела применяемые политики безопасности;
- уделила больше внимания мониторингу ИБ-событий в настоящем времени;
- провела повторный инструктаж пользователей, в том числе довела до них категорический запрет на открытие непонятных писем.
Поскольку в ходе инцидента не произошло утечки данных, компания не понесла прямого ущерба. Её главная потеря — это рабочее время сотрудников в течение двух недель и стоимость привлечения сторонней организации для проведения профессионального ИБ-анализа.
Как отметил Виталий Масютин, именно отсутствие утечки данных объясняет, почему руководство дало добро на публичное оглашение инцидента. Было принято решение поделиться опытом на профессиональном форуме, помогая тем самым другим участникам рынка практикой обороны.
На вопрос из зала, удалось ли выявить APT-группу, которая могла участвовать в инциденте, представители Platformix сказали, что применённые ими методы и инструменты не позволяют конкретизировать участника. В то же время прозвучало заявление, что аналогичным кибератакам подвергся «ряд других российских компаний». По совокупности данных было высказано предположение, что атака координировалась «откуда-то с территории Украины».
Кибератака на Kaspersky («Операция Триангуляция»)
«Операция Триангуляция», о которой рассказал на секции SOC Forum 2023 Игорь Кузнецов из «Лаборатории Касперского», стала «бестселлером» прошлогоднего разбора. По слухам, Kaspersky устроила даже тур (roadshow) по российским министерствам, чтобы привлечь самое пристальное внимание к этой атаке и связанным с нею рискам.
В чём причина?
Пользователи техники Apple до сих пор опирались на мнение, что закрытую мобильную iOS заметно труднее взломать и скомпрометировать, чем открытую ОС Android. Теперь в Kaspersky с нетерпением ждут выхода аппаратов с кибериммунной KasperskyOS, о которой мы писали недавно.
Рисунок 6. Подозрительный трафик после работы iMessage
О самой «Операции Триангуляция» мы планируем выпустить отдельный материал. Там будет много технических подробностей атаки. Здесь же мы ограничимся только выводами, которые были сделаны в компании Kaspersky.
Несмотря на сбор полной картины работы эксплойта, получение списка заражённых устройств и контроль передаваемого вредоносного трафика, экспертам Kaspersky так и не удалось назвать конечную цель атакующих. Известно, что эксплойт осуществлял периодическую отправку подтверждающих сообщений об успешном присутствии и активном заражении.
Было высказано мнение, что против компании могли действовать несколько команд, каждая со своей целью. Экспертам Kaspersky удалось идентифицировать атакующих по их адресам электронной почты. Все адреса относились к юрисдикции США.
Информация об инциденте для проведения расследования была направлена в штаб-квартиру Apple, но ответной реакции от вендора не поступило. Это указывает на то, что реального персонального преследования атакующих до сих пор нет.
В ходе исследования экспертам Kaspersky удалось выявить только один канал заражения — через iMessage. При его отключении заразить устройство теоретически невозможно. Но было высказано мнение, что у атакующих могли быть и другие варианты внедрения вредоносного кода, например через кросс-платформенные мессенджеры.
Были выявлены модули, которые использовались для заражения устройств на базе iOS. Но поскольку для всех типов устройств Apple используется единая кодовая база, выявленный набор вредоносных инструментов теоретически можно применять и для заражения настольных устройств на базе macOS.
Закрытая экосистема iOS не позволяет другой стороне (сторонней компании) собирать данные о том, безопасно ли устройство в данный момент или нет. Закрытый формат не позволяет также установить полноценное средство для гарантии безопасности, которое могло бы выполнять мониторинг системы изнутри. Единственный способ обнаружения атаки — это контроль активности сетевых подключений извне.
В такой ситуации функцию обеспечения защищённости полностью берёт на себя производитель ОС (Apple). Если компания недостаточно активно работает на определённом рынке (Россия сейчас оказалась в условиях санкционного давления), то «принципиальная позиция безопасности», которую гарантирует Apple, ставит её в сомнительное положение (в нынешних условиях).
Kaspersky не даёт такой итоговой оценки явно, но, по всей видимости, именно это заставило компанию заявить об отказе от корпоративных устройств Apple и о переходе на Android с установкой средств управления мобильными устройствами (MDM). В перспективе Kaspersky намерена перейти на «собственные телефоны» (вероятно, имеются в виду устройства на базе KasperskyOS).
В своём выступлении ГК «Солар» заявила, что ей удалось выявить другие, аналогичные заражения российских компаний. Однако ни одна из них не называется.
Kaspersky со своей стороны заявила, что выявить взлом можно только путём создания бэкапа (резервирования) файловой системы смартфона. Последующий анализ этой копии и даёт возможность выявить следы кибератаки.
Рисунок 7. Схема атаки «Операция Триангуляция»
Kaspersky выпустила специальную утилиту, которая позволяет найти признаки заражения. Очевидный вопрос: что может служить таким признаком, если внутренняя система Apple закрыта от внешней диагностики? По словам Игоря Кузнецова, «проверка касается выявления того, был ли отработан на телефоне процесс с именем “Backup Agent”». Назван также косвенный признак, по которому можно судить о заражении «похожим вирусом»: «на взломанном устройстве могут ломаться обновления, не позволяющие дойти до их полного завершения».
Таким образом, хотя ажиотаж по поводу «Операции Триангуляция» прошёл, говорить о том, что угроза управляема, похоже, рано.
Типовая кибератака на инфраструктуру российской компании
Доклад на SOC Forum от компании Positive Technologies сделал Денис Гойденко, руководитель отдела реагирования на угрозы ИБ экспертного центра безопасности PT ESC.
Несмотря на то что в его выступлении «Кейсы факапов из ИТ и ИБ» отсутствовало упоминание какого-либо конкретного примера, ценность представляло содержание доклада. По сути, это была структурированная методика для кросс-проверки элементов программной инфраструктуры с точки зрения ИБ.
Как отметил Денис Гойденко, «за 9 месяцев 2023 года количество киберинцидентов в России выросло на 60 % по сравнению с 2022 годом». Из его слов понятно, что хотя вал инцидентов, направленных на полное или частичное уничтожение инфраструктур российских компаний, пришёлся на 2022 год, подобные атаки всё ещё встречаются на практике. Среди трендов — высокая активность APT-группировок, распространение APT-утилит, использование шифровальщиков.
Рисунок 8. Инфографика угроз на российском рынке (с учётом их активности)
Денис Гойденко представил список основных, наиболее часто встречающихся ошибок в настройке программных средств и их функций. Ими активно пользуются злоумышленники для реализации кибератак.
Рисунок 9. Схема угроз снаружи корпоративных систем
Зоны особого внимания для ИБ-ошибок, которые возникают снаружи:
- Контроль подрядчиков (интеграторов, производителей софта).
- Поиск непропатченных сервисов веб-служб. Например, львиная доля заражений среди российских компаний (более 60 % всех корпоративных атак) приходится на «Битрикс», который не обновляется у многих клиентов. Причины бывают самыми разными: старая версия ОС, устаревшая версия PHP и пр.
- Контроль Microsoft Exchange (почта OWA).
- Контроль аппаратных систем под Citrix.
- Контроль незащищённых функций RDP.
- Отсутствие VPN и двухфакторной аутентификации.
- Отсутствие журналирования.
- ОС Windows 2003 (ещё нередко встречается на практике).
- Отдельные ветки корпоративных систем, которые создают для себя разработчики.
Рисунок 10. Схема угроз изнутри корпоративных систем
Угрозы, которые возникают внутри корпоративных систем, разделены на несколько контуров.
Корпоративная сеть:
- Отсутствие контроля конфигураций для Exchange.
- Хранение паролей на вики-ресурсе (позволяет изучить структуру компании и её клиентов, узнать, как получить доступ к ним).
- Хранение полной информации обо всех бизнес-процессах на вики-ресурсе.
- Передача учётных записей в открытом виде через почту.
- Использование общих ресурсов для разных контуров.
- Отсутствие сегментации участков корпоративной сети, выполняющих разные прикладные функции.
Контур для разработчиков:
- Отсутствие сегментации участков сети.
- Полный доступ на узлах.
- Полный доступ к соседним подрядчикам из сети-песочницы.
- Наличие тестовых участков.
- Неконтролируемый доступ в интернет.
- Отсутствие журналирования VPN.
- Администрирование при помощи утилит удалённого управления (RAT).
- Применение утилит двойного назначения.
Контроль закрытого контура корпоративной сети:
- Наличие более чем двух сетевых карт на АРМ.
- Использование общих ресурсов с открытым контуром.
- Отсутствие сегментации.
- Полный доступ на узлах.
- Полный доступ к соседним подрядчикам из сети-песочницы.
- Тестовые ресурсы.
- Неконтролируемый доступ в интернет.
- Отсутствие журналирования VPN.
Открытый контур:
- Отсутствие контура управления (VM).
- Хранение бэкапов в одной сети с узлами, которые подвергаются резервному копированию.
- Управление закрытой инфраструктурой из менее защищённых контуров.
- Отсутствие контроля трафика.
Кибератака на инфраструктуру российского телеком-оператора
Ещё один доклад — «Щелчок Таноса для оператора связи» — представил Игорь Залевский из ГК «Солар». Речь шла об инциденте, с которым столкнулся неназванный российский телеком-оператор. На три дня он полностью лишился возможности вести бизнес. Направленная против него кибератака вывела из строя все поддерживаемые сервисы: мобильную связь, широкополосный доступ в интернет, IP-телевидение.
Этот кейс заслуживает упоминания потому, что раскрыть его помог внешний оператор — «Солар». Он имеет возможность контролировать извне обстановку на магистральных каналах, используя собранные индикаторы компрометации. Например, когда компания Kaspersky указала в результате расследования «Операции Триангуляция» веб-адреса, которыми пользовались злоумышленники, «Солар» смогла оценить масштабы атаки, применяя полученные адреса как индикаторы компрометации.
Рисунок 11. Серверы вредоносного управления, выявленные при «Операции Триангуляция»
Атака на неназванного телеком-оператора была выявлена аналогичным образом. В апреле 2022 года на панель мониторинга «Солара», где вёлся контроль работы сервиса DNS Tunnel, попал подозрительный туннель. Он шёл от определённого набора организаций. Злоумышленники явно интересовались российскими государственными структурами и телеком-операторами.
Параллельно «Солару» американская компания Infoblox, занимающаяся разработкой средств защиты на базе анализа DNS-трафика, объявила о детектировании очень похожей неизвестной активности, которой было дано название «Decoy Dog».
Ядром проводимой кампании стал открытый фреймворк Pupy RAT, написанный на Python. Он был доступен на GitHub, но не поддерживался уже на протяжении нескольких лет. Во фреймворке использовался кросс-платформенный код, что позволяло собирать дистрибутивы под Windows и Linux. К фреймворку прилагались более 100 вредоносных модулей, которые можно было распространять по умолчанию. Имелась также возможность написания собственных модулей, что делало его применение непредсказуемым и особенно опасным.
Рисунок 12. Вредоносные функции Pupy RAT
Расследование непонятного трафика в телеком-компании началось после того, как у части её клиентов пропала мобильная связь. Уже на первых шагах стало ясно, что хакеры давно присутствуют в инфраструктуре и даже успели получить доступ абсолютно ко всему, что было у оператора: почте, сетевой инфраструктуре.
Как оказалось, хакеры вторглись в работу базовых станций на основе устройств Huawei iMaster MAE-M, но не поняли, как те функционируют, и просто уничтожили все данные, рассчитывая на полный отказ мобильной связи.
То, что оператор не сумел заранее выявить взлом, объяснялось просто: вся документация для устройств Huawei являлась закрытой, а режим их работы — проприетарным.
Обнуление данных не привело ко мгновенной остановке работы оператора. Благодаря виртуализации мобильные данные были доступны ещё в течение суток. Это дало команде исследователей время на поиски.
На следующий день проблема приобрела катастрофический характер. Мобильная сеть пропала. Действия хакеров привели к уничтожению аутентификационных данных на 52 коммутаторах. Из-за этого пользовательский трафик перестал попадать к оператору.
В это время хакеры запустили червя на базе Open Source Wiper Worm по всей корпоративной Linux-инфраструктуре телеком-оператора. Червь проработал в течение нескольких часов и уничтожил 90 % всех данных на Linux-серверах. Злоумышленники получали лог выполняемого удаления инфраструктуры. После этого они стали уничтожать ещё работавшую виртуализацию.
Предотвратить полное разрушение помогла... ошибка айтишников. Поскольку хакеры «сидели» в инфраструктуре около девяти месяцев, они сумели перехватить только новые пароли. Оказалось, что один из серверов выпал из поля их зрения, и на нём сохранился пароль, введённый ещё до прихода хакеров. Этот работающий сервер автоматически восстанавливал удалённые данные, что сильно помогло при починке инфраструктуры.
На восстановление ушло три-четыре дня. За это время оператор сумел поднять часть сервисов, после чего пользователи смогли выйти в интернет.
Выводы
Данные об инцидентах в российских компаниях редко попадают в общественный доступ. Эксперимент, проведённый на SOC Forum, показал, что такая осведомлённость помогает другим компаниям лучше понимать ситуацию и заранее быть готовыми к инцидентам, а не встречать их один на один, не имея сведений о том, как другие компании противостояли им.
