Исследование Flame продолжается

Исследование Flame продолжается

«Лаборатория Касперского» объявила о результатах нового исследования сложной вредоносной программы Flame, проведенного совместно с МСЭ-ИМПАКТ, CERT-Bund/BSI и компанией Symantec. В результате анализа нескольких командных серверов, которые использовались создателями Flame, эксперты обнаружили следы трех других вредоносных программ. Кроме того, они установили, что разработка платформы Flame началась еще в 2006 году.

 

Сложная программа Flame была обнаружена «Лабораторией Касперского» в мае 2012 года в ходе исследования, инициированного Международным союзом электросвязи. По его итогам партнер МСЭ в области кибербезопасности Международное многостороннее партнерство против кибергуроз (ИМПАКТ), передал 144 странам, входящим в его состав, информацию о способах блокирования и удаления данного вредоносного ПО. Его сложность, а также сходство с печально известным червем Stuxnet указывали на то, что Flame – это очередная масштабная кибероперация, реализованная при поддержке одного из государств. Вначале считалось, что Flame начал действовать в 2010 году, однако после проведения первого анализа инфраструктуры его командных серверов, охватывающей как минимум 80 известных доменных имен, эта дата сместилась на два года назад.

Результаты настоящего исследования основаны на анализе контента нескольких командных серверов, которые использовались Flame. Эту информацию удалось получить, несмотря на то, что инфраструктура управления Flame была отключена немедленно после обнаружения вредоносной программы специалистами «Лаборатории Касперкого». Все серверы работали на 64-битной версии операционной системы Debian с виртуализацией на базе контейнеров OpenVZ. Серверный код был по большей части написан на языке программирования PHP. Создатели Flame сделали интерфейс командного сервера похожим на обычную систему управления контентом (CMS), чтобы избежать подозрений со стороны хостинг-провайдера.

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

Еще один важный результат анализа – вывод о том, что работа над платформой командных серверов Flame началась еще в декабре 2006 года. Есть признаки того, что платформа по-прежнему находится в процессе разработки: на серверах были обнаружены упоминания нового еще не реализованного «Красного протокола» (Red Protocol). Последнее изменение серверного кода было внесено 18 мая 2012 года.

«Нам было сложно оценить объем данных, украденных Flame, даже после анализа его командных серверов. Создатели Flame умеют заметать следы. Однако, благодаря ошибке киберпреступников, нам удалось обнаружить на одном из серверов данные, которые позволили нам сделать вывод, что за неделю на этот сервер загружалось более пяти гигабайтов данных с более чем 5000 зараженных компьютеров. Эта информация дает все основания судить о масштабе всей кибершпионской кампании», – комментирует Александр Гостев, главный антивирусный эксперт «Лаборатории Касперского».

Основные результаты исследования:

  • Разработка платформы командных серверов Flame началась еще в декабре 2006 года.
  • Интерфейс командных серверов был сконструирован таким образом, чтобы имитировать обычную систему управления контентом (CMS), чтобы скрыть истинную цель проекта от хостинг-провайдеров и случайных проверок.
  • Серверы получали данные с зараженных компьютеров с использованием четырех различных протоколов, только один из которых применялся на компьютерах, зараженных Flame.
  • Наличие трех дополнительных протоколов, не используемых Flame, является доказательством существования по меньшей мере трех других вредоносных программ, связанных с Flame.
  • Одна из родственных Flame вредоносных программ в настоящее время продолжает активно распространяться.
  • Имеются признаки того, что разработка платформы командных серверов продолжается; в коде встречаются упоминания схемы передачи данных под названем «Красный протокол» (Red Protocol), однако эта схема пока не была реализована.
  • Признаки использования командных серверов Flame для управления другими известными вредоносными программами, например, Stuxnet или Gauss, так и не были обнаружены.

AppSec.Track научился проверять код, написанный ИИ

AppSec.Track добавил поддержку работы с ИИ и стал первым российским SCA-анализатором, который умеет проверять код прямо в связке с ИИ-ассистентами. Обновление рассчитано в том числе на так называемых «вайб-кодеров» — разработчиков, которые активно используют LLM и ИИ-редакторы для генерации кода.

Новый функционал решает вполне практичную проблему: ИИ всё чаще пишет код сам, но далеко не всегда делает это безопасно.

Модель может «галлюцинировать», предлагать несуществующие пакеты, устаревшие версии библиотек или компоненты с известными уязвимостями. AppSec.Track теперь умеет отлавливать такие ситуации автоматически.

Разработчик может прямо в диалоге с ИИ-ассистентом запросить проверку сгенерированного кода через AppSec.Track. Система проанализирует используемые сторонние компоненты, подсветит потенциальные угрозы и предложит варианты исправления. В основе механизма — протокол MCP (Model Context Protocol), который позволяет безопасно подключать инструменты анализа к LLM.

Как поясняет директор по продукту AppSec.Track Константин Крючков, разработчики всё чаще пишут код «по-новому», а значит, и инструменты анализа должны меняться. Редакторы вроде Cursor или Windsurf уже умеют многое, но им всё равно нужна качественная и актуальная база уязвимостей. Именно её и даёт AppSec.Track, включая учёт внутренних требований безопасности конкретной компании. В итоге даже разработчик без глубокой экспертизы в ИБ может получить более надёжный результат.

Проблема особенно заметна на фоне роста low-coding и vibe-coding подходов. Код создаётся быстрее, а иногда — почти без участия человека, но с точки зрения безопасности в нём могут скрываться неприятные сюрпризы: SQL-инъекции, логические ошибки или небезопасные зависимости. Как отмечает старший управляющий директор AppSec Solutions Антон Башарин, ИИ-ассистенты не заменяют классические практики DevSecOps — особенно когда речь идёт об open source, где информация об угрозах обновляется быстрее, чем обучаются модели.

Новый функционал AppSec.Track ориентирован на профессиональные команды разработки, которые уже внедряют ИИ в свои процессы. Он позволяет сохранить требования Secure by Design и снизить риски даже в условиях активного использования генеративного кода.

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