Кампания FlashHole касается прежде всего организаций в Южной Корее, где CrossWeb EX используют для защиты финансовых операций и доступа к сайтам онлайн-банкинга и государственных служб. Для владельца сайта за пределами страны это не повод считать CrossWeb EX установленным на своей инфраструктуре: важнее понять, как доверенное ПО и привычный веб-трафик могут стать частью цепочки атаки.
Исследователи заметили подозрительную цепочку, начинавшуюся из процесса CrossWeb EX и приводившую к запуску вредоносного кода в памяти. Возможный путь к заражению — персонализированное письмо со ссылкой на поддельный сайт на GitHub Pages; посещение такой страницы, по оценке исследователей, с высокой вероятностью запускало цепочку. Но точный способ, которым злоумышленники задействовали CrossWeb EX, установить не удалось. Это важное ограничение: наблюдаемая связь не доказывает конкретную уязвимость или сценарий эксплуатации.
О кампании Securelist сообщил в разборе «Операция FlashHole»: Lazarus взламывает защиту и обходит контроль. Авторы связывают активность с Lazarus и отмечают сходство с прежней кампанией SyncHole, также нацеленной на Южную Корею. Они выявили как минимум три пострадавшие организации из разных отраслей. Для администраторов практический интерес здесь не в одном продукте, а в сочетании доверенного ПО, целевого фишинга и исполнения, которое оставляет мало следов на диске. Статья поможет отделить подтверждённые наблюдения от предположений исследователей и понять, какие признаки этой цепочки стоит учитывать при проверке сайта и систем организации.
Почему CrossWeb EX стал точкой входа
Защитный компонент с привилегированным доступом
CrossWeb EX — программное обеспечение, которое используют в Южной Корее для защиты финансовых операций. Оно работает на компьютере пользователя и участвует в обработке операций, поэтому его присутствие в системе само по себе не означает заражение. Но компрометация такого компонента может дать атакующим удобную точку входа: вредоносная активность оказывается рядом с ПО, которому пользователь уже доверяет и которое запускается в контексте финансовых действий.
Исследователи связывают с CrossWeb EX кампанию Lazarus под названием FlashHole. При этом они не установили, каким именно способом злоумышленники добились запуска вредоносного кода через этот продукт. Нельзя утверждать, что была использована уязвимость CrossWeb EX, его обновление или конкретный механизм установки. Известная связь с продуктом указывает на контекст заражения, а не раскрывает первоначальный вектор атаки.
Параллель с прежним злоупотреблением
Интерес к этому ПО объясняется и сходством с более ранней кампанией SyncHole: в ней Lazarus также злоупотребляла южнокорейским защитным программным обеспечением. Это не доказывает, что в FlashHole повторили тот же технический приём. Общая черта — выбор локального ПО, связанного с финансовыми операциями; способ проникновения в новой кампании остаётся отдельным, не подтверждённым вопросом.
Для владельца сайта и администратора здесь важна граница между наблюдаемым и предполагаемым. CrossWeb EX фигурирует в цепочке заражения, но сам факт его установки не является индикатором компрометации. Персонализированные сайты и сценарий доставки исследователи рассматривают как вероятное объяснение того, как жертву могли подвести к запуску вредоносного кода, а не как установленный способ эксплуатации продукта.
Поддельные портфолио под конкретных сотрудников
Страницы собирали под адресатов
Исследователи предполагают, что кампания FlashHole сочетала целевой фишинг с watering hole — размещением приманок на сайтах, которые могли посещать нужные сотрудники. Для этого использовали страницы на GitHub Pages с персонализированными резюме и портфолио. Такой подход связывает приманку с конкретным человеком: содержание выглядит уместным для его профессиональной роли, а не как массовое письмо с универсальной наживкой.
Персонализация сама по себе не доказывает, что злоумышленники заранее собрали сведения о каждом адресате или отправляли ему ссылку напрямую. Вариант с watering hole предполагает, что сотрудник мог попасть на страницу самостоятельно. Поэтому исследователи описывают вероятную схему доставки, а не установленный для каждого заражения маршрут.
Внешние скрипты усложняли анализ
На страницах обнаружили внешние JavaScript-файлы. Вынесенный скрипт позволяет менять поведение сайта отдельно от его основного содержимого и затрудняет проверку только по HTML-странице. Для защитника это означает, что сохранённая копия портфолио может не показать всю логику, которая выполнялась при посещении: нужно учитывать и загружаемые ресурсы, и их источники.
Исследователи также отметили признаки использования генеративного ИИ при подготовке материалов. Это оценка по обнаруженным страницам, а не подтверждение того, что ИИ создал всю приманку или участвовал в доставке вредоносного кода. Персональные детали и правдоподобный текст повышают убедительность, но не устанавливают технический способ заражения.
GitHub Pages здесь важен не как доказательство компрометации GitHub, а как площадка для правдоподобных страниц-приманок.
Для администраторов практический сигнал — не сам факт размещения портфолио на GitHub Pages, а сочетание адресной тематики, внешних скриптов и неожиданного поведения страницы. Связь этих приманок с дальнейшим запуском вредоносной цепочки исследователи считают вероятной; точный способ, которым CrossWeb EX оказался задействован, этим наблюдением не установлен.
Вредоносная цепочка начинается и продолжается в памяти
Переход от CrossWeb EX к загрузчику
По описанию исследователей, выполнение начинается в процессе CrossWeb EX: тот запускает штатный fsquirt.exe, связанный с Bluetooth File Transfer. Через механизм DLL sideloading этот процесс загружает вредоносный TechHub. Сам по себе запуск системного файла не доказывает заражение: важны родительский процесс, загруженные DLL и дальнейшая активность.
TechHub собирает сведения об устройстве и процессах, а также может выполнить полученный шелл-код прямо в памяти. Это сокращает число файлов, которые можно обнаружить обычным поиском по диску. При этом «работает в памяти» не означает «не оставляет следов»: запуск процессов, загрузка библиотек и сетевые обращения могут фиксироваться средствами мониторинга.
Закрепление через подменённые DLL
Для сохранения доступа цепочка использует TouchHub и TouchShift. Здесь снова важен DLL sideloading: легитимный процесс загружает библиотеку из доступного ему расположения, а вредоносная DLL получает выполнение в контексте этого процесса. Поэтому проверять нужно не только имя исполняемого файла, но и путь к нему, цепочку запуска и фактически загруженные библиотеки.
- Сопоставляйте запуск
fsquirt.exeс родительским процессом CrossWeb EX и проверяйте, какие DLL он загрузил. - Ищите неожиданные экземпляры
TouchHubиTouchShift, а также связанные с ними службы и изменения автозапуска. - Не считайте отсутствие подозрительного файла на диске признаком чистой системы: часть действий выполняется в памяти, а следы могут оставаться в телеметрии процессов и загрузки модулей.
Для администраторов ключевой признак — не отдельное имя файла, а связка событий: CrossWeb EX запускает системный процесс, тот загружает нетипичную DLL, после чего появляются компоненты закрепления.
TechHub превращает GitHub в канал управления
Команды проходят через закрытый репозиторий
TechHub использует закрытый репозиторий GitHub как промежуточное хранилище для обмена данными с операторами. Вредоносная программа получает задания через механизм GitHub Issues, а результаты работы отправляет обратно в репозиторий. GitHub здесь не просто место для хранения файлов: его штатная инфраструктура становится каналом управления, а обращения к ней могут выглядеть как обычная работа с веб-сервисом.
Для различения заражённых устройств TechHub использует идентификаторы узлов. Это позволяет адресовать задания конкретному узлу и связывать с ним полученные результаты. Данные, которыми обмениваются стороны, шифруются; поэтому сам факт обращения к GitHub не раскрывает содержание команд или ответов. При этом закрытый репозиторий ограничивает доступ к каналу, но не отменяет сетевых и поведенческих признаков его использования.
Файлы шифруются перед передачей
В наборе команд есть операции для сбора сведений об устройстве и процессах, создания файлов, а также загрузки и запуска кода в памяти. Отдельная команда архивирует указанный файл или каталог с помощью ZipCrypto и жёстко заданного пароля xdkiTajAAxc3i/w[<881fnC!G*cb1Dit2sh.gAk/. ZipCrypto — устаревший алгоритм, поэтому его наличие не следует считать признаком надёжной защиты данных: здесь важнее, что архивирование и шифрование затрудняют просмотр содержимого при передаче.
TechHub также может получать сведения о загруженных плагинах и шелл-коде, запускать их функции и выгружать компоненты. Это делает репозиторий частью рабочего цикла: через него передаются задания и данные, тогда как выполнение операций происходит на заражённом устройстве. Такой механизм нужно отличать от отдельного командного канала Cubridge: TechHub обеспечивает обмен через GitHub, а не заменяет собой оркестратор кампании.
Cubridge управляет плагинами, модулями и инструментами
Cubridge — не просто средство сбора данных, а оркестратор: он получает команды и управляет дополнительными компонентами. Запросы маскируются под обычный веб-трафик, а полезная нагрузка может загружаться в память, внедряться в другой процесс или подключаться как плагин. Поэтому возможности заражённой системы можно менять без установки отдельной программы для каждой задачи.
Команды меняют состав и поведение нагрузки
Набор команд позволяет Cubridge управлять плагинами и шелл-кодом по отдельности: загружать их, вызывать экспортируемые функции, получать сведения о загруженных компонентах и выгружать их. Для внедрения DLL предусмотрена рефлексивная загрузка; шелл-код можно поместить в целевой процесс через общие области памяти или загрузить непосредственно в память.
- Команда
0собирает сведения об устройстве, включая имя компьютера, часовой пояс и PID. - Команды
3и4связаны с DLL: первая внедряет переданную DLL в целевой процесс, вторая загружает плагин в формате DLL. Для команды3источник допускает, что это может быть плагин. - Команды
8и9загружают шелл-код в целевой процесс или непосредственно в память; команды10–12позволяют вызвать его функцию, получить сведения о загруженном коде или выгрузить его.
Дополнительные инструменты загружаются по задаче
Такой механизм даёт оператору выбор: использовать уже загруженный плагин, добавить новый или выполнить код в памяти. Среди возможностей — сбор сведений о системе, создание файлов и архивирование указанных файлов или каталогов. Для архивации применяется ZipCrypto с жёстко заданным паролем; это не следует путать с надёжным шифрованием данных.
Для администратора важен не отдельный тип команды, а сочетание признаков: неожиданные DLL и шелл-код в памяти, их загрузка в целевые процессы и сетевые запросы, похожие на обычный веб-трафик. Каждый признак по отдельности может иметь легитимное объяснение; оценивать его нужно вместе с контекстом процесса и источником нагрузки.
Что кампания говорит о целях и тактике Lazarus
Преемственность с SyncHole — в выборе точки входа
Исследователи относят кампанию FlashHole к Lazarus и сопоставляют её с SyncHole: в обеих кампаниях фигурирует южнокорейское ПО, связанное с защитой финансовых операций. Это важная тактическая параллель, но не доказательство одинакового способа заражения. Для FlashHole точный механизм компрометации CrossWeb EX не установлен; сходство инструмента не позволяет восстановить, как именно злоумышленники получили первоначальный доступ.
Цели вышли за пределы одной отрасли
По данным исследователей, пострадали как минимум три организации из разных отраслей. Это указывает на расширение круга целей по сравнению с кампанией, сосредоточенной на одном секторе, но само по себе не доказывает, что Lazarus отказалась от финансовой мотивации. Южнокорейское защитное ПО могло быть удобным входом к организациям, где оно установлено; выбор такого ПО не означает, что атакующие нацелены именно на его разработчика или на всех его пользователей.
В описанной цепочке GitHub использовался для связи с заражёнными узлами, а отдельный компонент управлял загрузкой модулей. Эти детали показывают ставку на гибкую инфраструктуру и возможность менять действия после проникновения, а не раскрывают конечную цель каждой атаки. Связь кампании с Lazarus — атрибуция исследователей; она не подтверждает конкретный путь первоначального доступа и не позволяет автоматически считать заражённой любую организацию, использующую CrossWeb EX.
Что администраторам проверить после этой кампании
Исследователи связывают кампанию с Lazarus, но точный способ первоначального заражения не установлен. Поэтому проверки стоит строить вокруг наблюдаемых следов и связей между ними, а не искать один обязательный признак.
Проверить сайты и загружаемые скрипты
- Изучите обращения сотрудников к GitHub Pages и другим сайтам с портфолио или резюме, особенно если страницы адресованы конкретным людям. Сверьте домены и внешние JavaScript-файлы с историей браузера, DNS- и прокси-журналами.
- Проверьте, не менялись ли скрипты на разрешённых сайтах и не загружают ли они код с внешних адресов. Само посещение GitHub Pages не доказывает компрометацию: важны контекст, цепочка загрузок и последующая активность на устройстве.
Сопоставить процессы, службы и загрузку DLL
Ищите необычную связь между процессом CrossWeb EX, запуском fsquirt.exe и появлением TechHub. Проверьте происхождение исполняемых файлов, родительские процессы, командные строки и сетевые соединения. Отдельно изучите службы и файлы TouchHub и TouchShift: их наличие в ожидаемом каталоге само по себе не подтверждает легитимность.
При подозрении на DLL sideloading сравните загруженные библиотеки с теми, которые должны использовать конкретный процесс. Обратите внимание на DLL из необычных каталогов и на расхождения между подписью, путём и поведением файла. В этой цепочке часть кода выполнялась в памяти, поэтому отсутствие очевидного исполняемого файла на диске не исключает заражения.
Проверить GitHub и индикаторы компрометации
Сопоставьте исходящие обращения к GitHub с обычной работой организации. Неожиданное использование закрытого репозитория, задачи GitHub как канала обмена или повторяющиеся обращения процесса, не связанного с разработкой, требуют проверки. Учитывайте, что легитимные инструменты тоже используют GitHub: оценивайте учётную запись, процесс-инициатор, время и содержимое сетевых событий.
Сверьте найденные артефакты с индикаторами компрометации из отчёта исследователей и сохраните журналы до очистки системы. Ни один отдельный индикатор не гарантирует обнаружение: память могла быть очищена, а инфраструктура и файлы — изменены.
