MicrosoftЗлоумышленники распространяют на GitHub вредоносное ПО под видом инструментов для проверки безопасности систем и анализа журналов. Об этой кампании сообщила компания «Доктор Веб». Атакующие прячут опасные команды в файлах проектов Visual Studio и исходном коде Python и Go. Эти команды запускают цепочку заражения Windows: на компьютер попадают трояны для удалённого управления, кражи данных и подмены адресов криптокошельков в буфере обмена. По данным исследователей, на момент анализа жертвами кампании стали владельцы более 2000 компьютеров.
От ботов для криптоигр к инструментам безопасности
По данным «Доктор Веб», первые заражённые репозитории этой кампании появились примерно за два года до публикации исследования. Сначала злоумышленники привлекали пользователей криптоигр: размещали проекты Visual Studio с ботами и читами, в том числе для Telegram-игры Catizen. К ним прилагали инструкции по установке среды разработки и клонированию репозитория.
Теперь приманками стали проекты для специалистов по информационной безопасности. Один из приведённых исследователями примеров маскировался под скрипт для разбора, очистки и форматирования результатов сканера Fscan. Это не означает, что сам Fscan скомпрометирован: речь идёт о стороннем проекте, использующем его название и результаты работы.
В проектах Visual Studio злоумышленники размещали команду PowerShell в файлах .suo и использовали событие PreBuildEvent в .csproj, чтобы выполнить вредоносный код перед компиляцией. В файлах .py и .go опасные вставки прятали за длинными последовательностями пробелов, затрудняя их обнаружение при беглом просмотре.
Сборка проекта – выполнение инструкций, которые подготавливают приложение к запуску. В них могут входить произвольные команды, поэтому наличие исходного кода само по себе не делает проект безопасным.
Microsoft прямо предупреждает о рисках недоверенных проектов MSBuild: выполнение постороннего кода возможно при сборке, восстановлении зависимостей и открытии проекта в Visual Studio. Проверять нужно не только основной исходный код, но и файлы сборки, импортируемые настройки и подключаемые пакеты.
«Доктор Веб» не приводит разбивку более 2000 заражённых ПК по профессиям владельцев. Поэтому считать все эти устройства компьютерами специалистов по ИБ оснований нет.
Как на компьютер попадает Microsoft.exe
На первом этапе работает скрипт, который Dr.Web определяет как PowerShell.Packed.270. Среди обнаруженных исследователями путей его размещения:
C:\Users\Public\Pictures\t.ps1 C:\Users\Public\Pictures\L.ps1
Скрипт обращается к инфраструктуре злоумышленников либо к размещённым на легитимных площадках данным. В исследовании перечислены YouTube, Telegram, Google Документы, GitCode и Pastebin. Полученная зашифрованная строка после расшифровки превращается в адрес архива Quixo.7z.
Архив загружается с сервера атакующих или GitHub и распаковывается в каталог:
C:\ProgramData\Windows.Microsoft.Photos
Внутри находится Microsoft.exe – приложение на Electron, которое Dr.Web определяет как Trojan.Loader.3261. На момент исследования его версия имела номер 1.4.5. Название файла и каталога маскирует постороннюю программу под компонент Windows.
Загрузчик получает архив Nexara.7z с зашифрованными модулями и настройками, собирает сведения о компьютере и отправляет их через Telegram-бота. Он также закрепляется в автозагрузке и содержит два способа повышения привилегий. Исследователи описывают функции отключения Microsoft Defender, контроля учётных записей UAC, уведомлений, восстановления системы и службы теневого копирования VSS, а также добавления исключений антивируса.
Кроме того, вредоносное ПО пытается удалить ESET, McAfee и Malwarebytes. В файл hosts оно добавляет записи, блокирующие домены антивирусных разработчиков. Из каталога Windows\System32\drivers\etc удаляются остальные файлы и папки, за исключением hosts, networks, protocol, services и lmhosts.sam. По оценке исследователей, это должно помешать восстановлению из находящихся там резервных копий; речь не идёт об удалении всех резервных копий пользователя.
Удалённый доступ, подмена кошельков и кража данных
Основная цепочка запускает несколько компонентов с разными задачами:
- BackDoor.AsyncRAT.115 предоставляет злоумышленникам удалённый доступ к компьютеру. В процессы внедряются две одинаковые копии с разными портами подключения. Исследователи предполагают, что это позволяет двум операторам работать одновременно, но не представляют это как установленный факт.
- Trojan.InjectNET.14 внедряет Trojan.Clipper.688 в процесс regasm.exe. Клиппер подменяет адреса криптокошельков в буфере обмена. При подмене он делает снимок экрана и отправляет его в Telegram вместе с версией клиппера, названием активного окна, именем пользователя и IP-адресом.
- JS.Stealer.191, ещё одно приложение на Electron, извлекается из Nexara/Nvdia.7z. Оно проверяет, не запущено ли в песочнице или виртуальной машине, собирает данные системы и похищает пользовательские файлы.
В число целей стилера входят данные браузеров, XML-файлы FileZilla, MobaXterm.ini, wcx_ftp.ini программы Total Commander, конфигурации VPN, файлы мессенджеров, данные учётных записей игр и игровых сервисов, токены Discord. Собранную информацию вредоносное ПО архивирует и передаёт через Telegram-бота.
Для пользователя это означает, что удаление загрузчика не возвращает уже похищенные данные. При подтверждённом заражении необходимо отдельно оценивать доступ злоумышленников к учётным записям и рабочим ресурсам.
Как троян пытается обходить защиту
Для запуска модулей разработчики предусмотрели четыре режима. Самый сложный, Mode3, сочетает несколько техник, которые мешают средствам защиты отслеживать вредоносную активность:
- PPID spoofing – подмена идентификатора родительского процесса, чтобы запуск выглядел связанным с explorer.exe.
- Воздействие на Smart App Control – попытка обойти проверку доверия к приложениям изменением параметра VerifiedAndReputablePolicyState в реестре.
- Снятие перехватов ntdll.dll – сравнение библиотеки в памяти с копией на диске и восстановление изменённых участков, через которые защитное ПО могло контролировать обращения к системе.
- Halo's Gate – получение номеров системных вызовов и прямое обращение к функциям Windows, затрудняющее перехват со стороны средств обнаружения и реагирования EDR.
- Изменение ETW – вмешательство в EtwEventWrite в памяти процесса для подавления телеметрии.
- Изменение AMSI – вмешательство в AmsiScanBuffer, чтобы скрипты внутри затронутого процесса не проходили обычную антивирусную проверку через этот интерфейс.
Наличие этих техник не доказывает, что троян успешно обходит любую конфигурацию Windows или любое EDR-решение. В исследовании описаны механизмы конкретного образца, а не сравнительное испытание всех защитных продуктов.
| Режим | Как запускается вредоносная нагрузка |
|---|---|
| Mode3 | Использует перечисленные техники обхода и внедряет модули в RegAsm.exe, dwwin.exe или dwm.exe. Зашифрованные компоненты находятся в файлах boot_f, kernel_f и thread_f; ключи берутся из Nexara/manifest/config.json, из полей b_f, k_f и t_f. |
| Mode2 | Служит запасным вариантом. Расшифровывает библиотеки thumbcache_{11..20}.dll, добавляет regasm.exe и dwm.exe в исключения Defender и запускает из временного каталога скрипт PowerShell.Inject.245, который внедряет модули в RegAsm.exe. |
| Mode3non | Повторяет логику Mode3 без перечисленных техник обхода защиты. |
| Handler | Использует схему, похожую на Mode2, но содержит параметры непосредственно в коде и не обращается к конфигурациям. Исследователи допускают, что это оставшийся в проекте старый вариант запуска. |
В Mode3 и Mode2 троян проверяет связь с управляющим сервером с помощью PowerShell и Netstat; в Mode3 предусмотрен отчёт об ошибке через Telegram, если внедрение одного из компонентов не удалось. В Mode2 также есть ветка для файла cryptwizard и процесса dwwin.exe, однако на момент анализа файл отсутствовал, а флаг запуска имел значение false.
Отдельно исследователи нашли неиспользуемый код для загрузки Lodge.7z. В нём находился разрабатываемый Electron-компонент WUDFHost.exe с функциями создания службы через sc.exe, контроля наличия Microsoft.exe и его повторной загрузки, проверки автозапуска и установки обновлений. Эти возможности описаны как задел на будущее, а не подтверждённый действующий механизм заражения.
Как проверять незнакомые проекты
До открытия проекта в IDE стоит просмотреть его файлы как текст: обратить внимание на .csproj, .suo, события сборки, вызовы PowerShell и загрузку исполняемых файлов. Для MSBuild проверка также должна охватывать импортируемые .props и .targets, Directory.Build.props, Directory.Build.targets, Directory.Build.rsp и подключаемые NuGet-пакеты. Microsoft указывает, что инструкции сборки могут подхватываться и из родительских каталогов.
В Visual Studio 2022 и более новых версиях доступны настройки доверия к файлам и папкам. По умолчанию предупреждение связано с интернет-меткой Mark of the Web, но запрос доверия можно сделать обязательным для содержимого вне доверенных расположений.
- В интерфейсе с классическим окном настроек откройте Tools > Options > Environment > Security и выберите Always require a trust decision.
- В интерфейсе с новой панелью настроек путь проходит через Tools > Options > All Settings > Environment > Security > Trust. Включите Require a trust decision before opening content и установите Always ask.
- Проверьте список доверенных расположений. Не добавляйте в него непроверенный репозиторий или общий каталог загрузок только ради снятия предупреждения.
Для анализа подозрительного проекта используйте отдельную изолированную среду без рабочих учётных данных и доступа к важным ресурсам. Обнаруженная у стилера проверка виртуализации также означает, что отсутствие заметной активности в виртуальной машине ещё не подтверждает безопасность файла.
Что делать при подозрении на заражение
Если после работы с таким проектом появились подозрительные процессы, скрипты или предупреждения защиты, прекратите запуск файлов и отключите компьютер от сети. На рабочем устройстве сообщите об инциденте службе ИБ, чтобы сохранить материалы для расследования и проверить доступ к корпоративным ресурсам.
Запустите полную проверку обновлённым антивирусом. «Доктор Веб» сообщает, что Dr.Web Security Space и Dr.Web Desktop Security Suite распознают описанную угрозу. Для дополнительной разовой проверки можно использовать свежезагруженную утилиту Dr.Web CureIt!; она не заменяет постоянную защиту и не обновляет свои базы автоматически.
С другого, заведомо чистого устройства смените пароли важных учётных записей и проверьте доступные настройки завершения сеансов. Для разработчиков и специалистов по ИБ отдельно важны потенциально раскрытые ключи и токены. GitHub рекомендует отзывать скомпрометированные учётные данные: смена пароля сама по себе не заменяет отзыв отдельного токена доступа.
При расследовании необходимо проверить автозагрузку, исключения антивируса, состояние защитных компонентов и файл hosts. Удаление одного Microsoft.exe не охватывает внедрённые модули и изменения настроек системы.
В исследовании перечислены следующие адреса инфраструктуры злоумышленников. Запись [.] разрывает адрес, чтобы он не становился активной ссылкой:
muckanthropic[.]com muckduck.duckdns[.]org muckcoding[.]com muckdeveloper[.]com 130.12.182[.]172
Эти адреса, имена архивов и пути полезны для поиска следов в журналах. Отсутствие совпадений не исключает заражение: авторы меняют код и инфраструктуру, а отдельное имя файла без контекста не доказывает компрометацию.
Вывод
Проверка незнакомого инструмента должна начинаться до открытия проекта в среде разработки: команды могут находиться в настройках сборки и зависимостях. Если вредоносный код уже выполнялся, восстановление защиты компьютера нужно дополнить проверкой учётных записей и отзывом раскрытых токенов. Смена тематики приманок на инструменты ИБ делает такую осторожность необходимой и для опытных пользователей.
