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

Fractal ID

19 июля, в «день CrowdStrike» произошел инцидент с неизвестной у нас ИБ-компанией Fractal ID, которая занимается децентрализованной системой управления идентификационной информацией для web3. Как пишет сама компания в бюллетене по этому взлому, 14 июля они обнаружили необычную активность в своих внутренних системах, когда оператор с правами админа стал сливать данные пользователей через имеющийся API. В течение 29 минут, пока его не заблокировали, он успел «слить» 0,5% всей пользовательской базы Fractal ID (6,3К учетных записей).

Компания поспешила обвинить самого оператора, который не проходил тренингов по ИБ и не следовал OpSec-практикам!

Из интересного:

• Обнаружили инцидент, когда зафиксировали попытку доступа к редко используемому узлу во внутренней сети предприятия, что намекает нам на то, что у компании была карта информационных потоков и частоты активности между ними, а также матрица соединений, которых быть не должно, которые мониторились с помощью решений класса NTA или схожих с ними (возможно, модуль в SIEM).
• Сотрудник, ставший точкой входа, повторно использовал пароль, который был ранее скомпрометирован, что намекает нам на отсутствие процесса контроля утекших паролей. Как по мне, так в этом виноват не сотрудник; или не только он.
• От взломщиков было требование выкупа, но компания не стала вступать в переговоры.
• Данные изначально хранились в зашифрованной базе данных, но так как доступ к ним был у оператора с правами админа, то все данные были расшифрованы в процессе загрузки.

Fractal ID неплохо описывает, что они сделали по итогам инцидента:

1. Ограничили число данных, к которым может получить один сотрудник в один интервал времени.
2. Ввели новый тип учетной записи, которая имеет доступ к ограниченному объему данных за счет более гибкой авторизации.
3. Усилили мониторинг за неудачными попытками входа и использованием атак по словарю.
4. Стали блокировать доступ, когда сотрудник подключается с нетипичного для него IP-адреса.

Мне кажется эти же меры можно будет применить и в самом последнем из описанных в заметке кейсов, так как он имеет схожую природу. В целом Fractal ID неплохо описывает, как они защищают данные свои клиентов, но есть одно «но» — для компании, специализирующейся на управлении идентификацией и аутентификацией, внедренные меры должны были быть внедрены раньше.

Leidos

Leidos — один из крупнейших ИТ-поставщиков услуг для МинОбороны США, НАСА, Министерства национальной безопасности и других, преимущественно американских, организаций, столкнулся с утечкой внутренних документов. Предположительно данные утекли не из инфраструктуры самой Leidos, а у ее подрядчика — компании Diligent, которая занимается «хранением информации, собранной в рамках внутренних расследований» и которая была взломана в 2023-м году. При этом представитель Diligent заявил, что утечка вероятно произошла в 2022-м году в ее дочерней компании Steele Compliance Solutions.

Этакая матрешка, когда одна компания ссылается на другую, а та еще на другую…

Больше никаких деталей по инциденту нет, кроме привычного «Никакой конфиденциальной информации клиентов не утекло. Клиенты не пострадали«. Комментариев со стороны МинОбороны США за прошедшие 5 дней с инцидента также не воспоследовало.

KnowBe4

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

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

Фейковый кандидат

Что интересного в этом инциденте:

• Загрузку вредоносного кода обнаружил установленный на ноутбуке EDR, что как бы намекает в важности этого инструмента.
• Интервью проходили удаленно — кандидата вообще никто не видел вживую.
  

  А как вы проверяете кандидатов, если проводите собеседования с ними удаленно?

• KnowBe4 называет «кандидата» прогосударственным хакером, но у меня лично это вызывает сомнения. Разве стал бы такой хакер сразу же внедрять вредоносное ПО, даже не проверив наличие на полученном ноутбуке средств защиты?
• Ноутбук направлялся, конечно, не в Северную Корею, а на так называемую «ферму ИТ-мулов«, к которой через VPN в ночное время (когда в США рабочий день) и подключались хакеры из Северной Кореи, которые отправляли свою большую зарплату в Северную Корею для финансирования нелегальной деятельности.
  

  Вот этот вывод KnowBe4 для меня оказался немного странноватым, но возможно он объясняется следующим пунктом.

• Госдеп США в мае уже предупреждал об этой проблеме и предлагал 5 миллионов долларов за информацию о северокорейских ИТ-работниках, которые маскируются под американцев. Об этом же, еще в прошлом октябре, предупреждал американский МинЮст, а OFAC писал еще в мае 2022-го. При этом чиновники Нового Света каким-то образом отследили, что северокорейские «ИТ-работники» физически находятся в России и Китае, откуда и подключаются к фермам ИТ-мулов.

Интересны советы, которые даются для предотвращения схожих инцидентов:

1. Сканируйте удаленные устройства, чтобы к ним никто не подключался удаленно!
2. Лучше проверять, что физическое местоположение кандидатов совпадает с тем, что они указывают в качестве места проживания.
3. Лучше проверять резюме на нестыковки в работе, которую выполняли кандидаты, а также в иных разделах резюме.
4. Регулярно проверять через вебкамеры, что работники реально работают; и в правильном месте.
5. Доставка ноутбука по адресу, отличному от указанных в резюме, является тригером.
6. Лучше проверяйте рекомендации кандидатов и не только по электронной почте.

Интересно, что многие из указанных советов давала ФБР еще в октябре 2023-го года. Но, как это часто бывает с рекомендациями регуляторов, их мало кто читает, пока не случается жопа.

CrowdStrike

Да, тот самый CrowdStrike, но это уже совсем другая история, отличная от  коллапса  19-го июля. 24-го числа хакер USDoD заявил о взломе компании и краже из ее инфраструктуры списка индикаторов компрометации (IoC), размером 250 миллионов записей о различных группировках и деталях по ним. В качестве доказательства выложен небольшой пробник, содержащий название группировки и ее псевдонимом, даты последней активности, статус (активна или нет), страна происхождения, отрасли-цели, страны-цели, тип группировки (криминальная, APT, хактивисты, спонсируемая государством) и ее мотивация.

Подтверждения со стороны CrowdStrike пока нет, ну да им не до того сейчас. Они продолжают разгребать последствия сбоя в своем EDR и косячат снова (с подарочными картами на 10 долларов, которые еще и не работают).

Аванпост

Вчера, в 12:45 украинская группировка [ Cyber.Anarchy.Squad ] сообщила о взломе российского ИБ-вендора «Аванпост», который подтвердил данный факт. Пока никаких деталей со стороны компании нет (и вряд ли стоило их ждать в первый день инцидента); поэтому спекулировать на тему кражи 60 ТБ данных, включая и исходники ПО и учетки в компании заказчиков, и шифрования всей инфраструктуры, включая рабочие станции работников, не буду. Подождем опубликования результатов расследования, которые ИБ-компания должна выложить, как это обычно делают в таких случаях, чтобы снять все сомнения.

Что объединяет все эти случаи? Не только то, что все это компании ИБ и что «никто из клиентов не пострадал», но и то, что в двух случаях из пяти (но по Leidos и Аванпост нет даже намеков на причину утечки информации), инцидент связан с процедурой проверки подлинности (как процесса и как технологии), а в двух обнаружить инцидент удалось с помощью мониторинга. Еще в двух случаях у нас нет вообще никаких деталей. Но самое главное, что эти пять кейсов нам говорят, что даже ИБ-компании сегодня ломают и поэтому так важно проверять всех подрядчиков, включая и тех, кто занимается кибербезом.

Может эти примеры подтолкнут всех задуматься о том, как обеспечивать доверие со стороны тех, кто должен нас защищать?! Как мониторить подключение со стороны ИБ-вендоров, имеющих доступ в наши инфраструктуры? Не надо ли от них требовать регулярного прохождения пентестов с публикацией результатов, а, в случае разработки ими ПО, еще и выкладывания его на платформы Bug Bounty? Не должны ли вендора нести ответственность или страховать ее за такого рода инциденты?