ЛК опубликовала подробности атаки на ядерный проект Ирана

ЛК опубликовала подробности атаки на ядерный проект Ирана

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

Эксперты «Лаборатории Касперского» делятся информацией о первых пяти жертвах, через которые Stuxnet попал в мировую сеть.

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

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

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

 

 

«Анализ сферы деятельности организаций, которые первыми стоят в списке жертв, позволяет нам понять, как была спланирована вся операция Stuxnet. Это яркий пример косвенной атаки через цепочки поставщиков, в рамках которой вредоносные программы попадают от предполагаемых бизнес-партнеров жертвы в ее инфраструктуру. Давно известно, что Stuxnet – одна из самых сложных и продуманных кибератак из тех, о которых мы знаем. Выбор первых целей позволяет наглядно понять, насколько тщательно была проведена подготовка к ней», – поясняет Александр Гостев, главный антивирусный эксперт «Лаборатории Касперского».

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

Вышла PT Container Security 0.8 с публичным API

Positive Technologies представила новую версию PT Container Security — 0.8. В этом релизе продукт получил несколько заметных изменений, которые должны упростить работу SOC-команд и повысить устойчивость защиты контейнерных сред. Главное новшество — появление публичного API.

Теперь продуктом можно управлять не только через веб-интерфейс, но и автоматически: отправлять HTTPS-запросы из скриптов, интегрировать с SIEM или другими инструментами.

Это позволяет оператору SOC обрабатывать события рантайма в привычных системах и автоматизировать создание правил по всей инфраструктуре.

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

В PT Container Security 0.8 появилось больше параметров для настройки правил в admission controller и мониторинга рантайма: теперь можно указывать конкретные поды, контейнеры, ноды, образы и репозитории. Это помогает точнее реагировать на инциденты и снижает нагрузку на систему, исключая лишние проверки.

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

Работа с сертификатами для TLS-соединений между компонентами теперь реализована средствами Helm. Сертификаты создаются автоматически и прописываются в values.yaml, но при желании можно хранить их в отдельном файле — это упрощает администрирование.

Новые возможности станут доступны пользователям после обновления PT Container Security до версии 0.8.

RSS: Новости на портале Anti-Malware.ru