Киберразведка превратилась в ретроспективное расследование, когда аналитики компании Huntress, изучив свежие данные об инфраструктуре иранской APT-группы (Advanced Persistent Threat, целевая долгосрочная атака), обнаружили в своих архивах полную хронологию успешного вторжения. Инцидент, произошедший в январе 2026 года в инфраструктуре израильской компании, демонстрирует классический, но отточенный подход злоумышленников, связанных с кампанией MuddyWater. Атака началась с компрометации учётных данных для удалённого доступа, продолжилась созданием скрытых туннелей и завершилась внедрением вредоносного кода с помощью техники side-loading, что подчёркивает необходимость многослойной защиты даже от давно известных угроз.
Описание
Фактическим началом этой истории стало 4 марта 2026 года, когда Hunt.io опубликовал исследование, содержащее индикаторы компрометации (IoC), связанные с иранскими APT-группами. Специалисты Huntress использовали эти данные для ретроспективного поиска по всем доступным сигналам и отчётам об инцидентах в своей обширной клиентской базе. Этот поиск привёл к отчёту от 24 января, отправленному израильскому заказчику, в котором описывалась разведывательная активность и установленное злоумышленником SSH-соединение. Ключевым совпадением стала команда, содержащая IP-адрес 162.0.230[.]185, который ранее был задокументирован в отчёте Group-IB как часть инфраструктуры MuddyWater.
Уже на следующий день, 25 января, система мониторинга Huntress сгенерировала высокоприоритетный инцидент для того же компьютера, обнаружив исполнение файла "c:\Users\Public\Downloads\FMAPP.exe". Этот файл оказался легитимным приложением от Fortemedia Inc., однако использовался для техники подмены динамической библиотеки (DLL side-loading). Суть метода в том, что легитимный исполняемый файл "FMAPP.exe" при запуске ищет и загружает библиотеку "FMAPP.dll" из той же папки. Злоумышленники подменили эту библиотеку на вредоносную, которая после загрузки устанавливала соединение с управляющим сервером (C2) по адресу 157.20.182[.]49. Таким образом, вредоносная активность маскировалась под доверенный процесс.
Подробная хронология, восстановленная по данным обнаружения, рисует картину методичных и последовательных действий злоумышленника. Начальной точкой входа стал успешный вход через службу удалённых рабочих столов (RDP) с IP-адреса 173.16.10[.]1 24 января около 22:13. Попав в систему, оператор почти сразу приступил к разведке, изучая сетевую конфигурацию ("nslookup", "route print"), перечисляя группы и пользователей, в частности, ища членов групп «Администраторы» и «Пользователи удалённого рабочего стола». Примечательны несколько опечаток в командах, например, "whoami /pric" вместо "whoami /priv" или "net localgroup adminstraots", что может указывать на ручной ввод команд, а не на использование полностью автоматизированных скриптов.
Важным этапом атаки стало создание обратного SSH-туннеля для обеспечения постоянного доступа и обхода сетевых ограничений. Примерно через 9 минут после входа злоумышленник выполнил команду, устанавливающую туннель на порт 10841 через промежуточный сервер. Затем, после трёхминутной паузы, предположительно для проверки работоспособности туннеля, он запустил новый, более «чистый» процесс PowerShell и немедленно создал второй туннель на порт 8585. Этот манёвр, направленный на создание более стабильного и менее подозрительного канала связи, демонстрирует осознанное стремление к скрытности.
Процесс внедрения вредоносного загрузчика также не прошёл гладко, что видно по действиям оператора. После запуска "FMAPP.exe" он вручную проверил, появился ли процесс в списке задач ("tasklist | findstr FMAPP"), затем пропинговал IP-адрес управляющего сервера, чтобы убедиться в его доступности, и даже проверил внешний IP-адрес жертвы с помощью "curl ifconfig[.]me". Неуверенность в успехе операции привела к повторной попытке запуска "FMAPP.exe" почти через 20 минут. Эти действия выдают либо проблемы с настройкой вредоносного ПО, либо осторожность оператора, стремящегося убедиться в каждом шаге.
С точки зрения последствий, данная атака предоставила злоумышленникам прочный плацдарм в корпоративной сети израильской компании. Обладая правами администратора, установленным туннелем для командования и управлением, а также закреплённым в системе вредоносным загрузчиком, группа могла продолжить горизонтальное перемещение по сети, красть конфиденциальные данные или подготовить почву для диверсионных действий, таких как развёртывание программ-вымогателей. Тот факт, что активность была в конечном итоге обнаружена и пресечена, не отменяет серьёзности первоначального успеха атакующих.
Для специалистов по информационной безопасности этот кейс служит наглядным напоминанием о фундаментальных мерах защиты. Во-первых, критически важным является строгий контроль за удалённым доступом, включая использование многофакторной аутентификации для RDP, применение брокеров защищённого доступа и сегментацию сетей, чтобы ограничить область воздействия в случае компрометации. Во-вторых, необходимо внедрение политик ограничения прав, запрещающих выполнение приложений из непредназначенных для этого каталогов, таких как "C:\Users\Public\Downloads", что могло бы предотвратить успешную подмену DLL. В-третьих, постоянный мониторинг сетевой активности на предмет аномальных исходящих соединений, особенно SSH-туннелей на нестандартные внешние адреса, является обязательным элементом защиты. Наконец, интеграция актуальных индикаторов компрометации от авторитетных источников в системы мониторинга (SIEM) позволяет проводить проактивный поиск угроз и выявлять следы активности даже спустя время после событий, как это успешно сделала Huntress. Этот инцидент подтверждает, что даже группы с давно изученными тактиками остаются опасными, если базовые принципы защиты реализованы не в полной мере.
Индикаторы компрометации
IPv4
- 157.20.182.49
- 162.0.230.185
- 173.16.10.1
SHA256
- 589ecb0bb31adc6101b9e545a4e5e07ae2e97d464b0a62242a498e613a7740b6
- e25892603c42e34bd7ba0d8ea73be600d898cadc290e3417a82c04d6281b743b