Ransomware-атака на маленькую компанию через крупного подрядчика

Злоумышленники за две недели уничтожили всю инфраструктуру небольшой спортивной организации с помощью старой утечки у крупного подрядчика-интегратора ПО. В процессе атаки был обнаружен образец вредоносного ПО на .NET Framework, мимикрирующий под установленный в системах 1C.

Обзор инцидента

Осенью 2025 года к нам обратился заказчик с просьбой определить причины шифрования инфраструктуры.

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

Наше расследование показало, что доступ к системам был получен за 2 недели до момента шифрования. Первую неделю атакующие бездействовали, а начиная со второй выполняли активное сканирование инфраструктуры и подбор паролей учетных записей.

Мы обнаружили, что за 12 часов до шифрования произошли события успешного входа сервисной УЗ (с правами доменного администратора и, вероятно, слабым паролем) с нетипичного адреса, после чего, в час X, небольшая инфраструктура была уничтожена как по щелчку пальцев. Атакующие поочередно выполнили подключение к системам по RDP, отключили средства АВПО и запустили исполняемый файл Ransomware Hardbit v4.2.

Точкой входа оказались серверы RDS и 1C, которые были доступны из внешней сети по стандартным портам RDP. С разницей в несколько минут в обеих системах был совершен вход учетной записи подрядчика по RDP, после чего размещено ПО «C:\ProgramData\1C\1cv8\1cv8srv.exe», а также создана служба «1cv8srv» с отображаемым именем «1cv8 License Service» для его запуска. Без анализа и контекста событий можно было бы утверждать: «Подрядчик, который занимается обслуживанием нашей системы 1C, вероятно, обновил версию легитимного ПО. Ничего подозрительного».

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

Вернемся к нашему примеру. После заражения систем атакующие больше не использовали УЗ подрядчика и подключались к инфраструктуре напрямую через размещенные образцы Backdoor.

Заражен ли подрядчик на текущий момент — нам неизвестно, но в открытых источниках нам удалось найти, что несколько лет назад у него произошла утечка данных о клиентах, среди которых оказались и доступы к самим клиентам.

Для учетной записи подрядчика в уничтоженной инфраструктуре был установлен флаг DONT_EXPIRE_PASSWORD, из-за чего можно предположить, что пароль меняли не так часто, как следовало бы по современным нормам информационной безопасности. Вероятно, он мог вообще не меняться с момента создания УЗ и мог оказаться в той давней утечке подрядчика.

Техническое описание

1c8srv.exe

Нами был обнаружен загрузчик на .NET, имеющий интересную обфускацию имен, состоящую из 3–4 английских слов. Загрузчик закрепляется в системе в качестве сервиса, мимикрирующего под лицензионный сервер 1C.

Функционал загрузчика разделен на 4 класса:

1. KingfisherIndividualSpendEnvironmental — служит хранилищем статических переменных. Все основные параметры загрузчика вынесены сюда, включая имена создаваемой службы, внедренной dll, а также основного метода (EntryPoint) для запуска dll.

2. MyService — основной класс, описывающий вредоносную службу и являющийся наследником System.ServiceProcess.ServiceBase. При запуске службы выполняет метод TurnSharkListSenior для динамической загрузки .NET DLL из ресурсов приложения:

После подгрузки выполняет метод FatherStandardDunlinRedDeer из DLL, который является EntryPoint’ом следующей стадии.

3. WindowManSoWeek — реализует логику установки службы, наследуя класс System.Configuration.Install.Installer. В ходе установки создается служба 1cv8srv (отображаемое имя «1cv8 License Service») с автоматическим запуском. Метод OnAfterInstall переопределен для настройки механизма восстановления: при сбое службы система автоматически попытается перезапустить ее через 60 секунд.
4. Program — EntryPoint с методом Main для запуска MyService.

Таким образом, после запуска загрузчика он закрепляется в системе и выполняет запуск полезной нагрузки input.dll.

Input.dll

Файл input.dll является второй стадией загрузчика и имеет аналогичную обфускацию. При запуске пытается создать мьютекс, после чего пытается обратится к C2, с которого загружает полезную .NET нагрузку.

Функционал разделен на 6 классов:

1. TroubleResultPatientCityMeasure — хранилище статических переменных, в которое вынесены все основные параметры.

2. ParticularlyHeightDiscussionManagerMiss — основной класс второй стадии. Содержит метод WomanWonderWhitefishGreatGuanaco, который является главным циклом работы загрузчика.

В этом в цикле выполняется обращение к C2 для получения нагрузки, после чего она расшифровывается и запускается, а цикл «засыпает» на 2 минуты.

Нагрузка представляет собой зашифрованные AES-пакеты с .NET-библиотекой внутри.

Пакеты содержат ключ и вектор инициализации, которые парсятся с помощью метода RabbitFingerCityDream. Значение переменных:

• array3 — зашифрованный пейлоад
• array — ключ
• array2 — IV

3. MailDoorYearEverybodySeven — класс с единственным методом FamilyHotAbleRay, который выполняет расшифровку данных с помощью AES.
4. StructureMindThankFilmLion и TaxSomeGardenSecondSix — классы для методов-утилит, например, для получения GUID зараженной системы.
5. CultureSpoonbillForAnswerReindeer — класс с EntryPoint-методом, выполняющим запуск главного цикла ВПО — асинхронной функции WomanWonderWhitefishGreatGuanaco.

Таким образом, вторая стадия загрузчика реализована с использованием техники T1620 (Reflective Code Loading), при которой вредоносный код загружается и выполняется в памяти процесса без создания временных файлов на диске. Загрузчик получает зашифрованную .NET-нагрузку с удаленного сервера управления вредоносным ПО и выполняет ее в памяти процесса. К сожалению, на момент расследования нам не удалось получить образец подобной вредоносной нагрузки, но по активности в системе на момент атаки можно предположить, что следующая стадия реализовывала функционал RAT или Proxy.

Атрибуция

Ранее мы не сталкивались с деятельностью группировки. По имеющимся артефактам можем сделать вывод, что атакующие нападают на организации через шифрование данных и последующее вымогательство с целью финансовой наживы. Информации о географическом происхождении группировки нет, поэтому, следуя принципам таксономии Solar 4RAYS, мы назвали ее NGC8211.

Заключение

По итогам данного расследования хотим напомнить:

1. Не ведитесь на предложения выкупа данных. Злоумышленники либо попросту не отдадут дешифратор после перевода необходимой суммы, либо оставят «закладку» в системах, чтобы повторно зашифровать данные спустя время и потребовать выкуп снова. Помните знаменитое «скупой платит дважды»? Мы же не раз убеждались: случаев успешной расшифровки сильно меньше, чем переводов денег мошенникам.
2. При восстановлении систем из бэкапов проверьте, что в них нет вредоносного ПО из текущего инцидента.
3. Маленькая компания — не причина для атакующих игнорировать уязвимую инфраструктуру, которую можно зашифровать, и потребовать выкуп.
4. Подрядчик, через учетную запись которого попали в инфраструктуру, является достаточно крупной организацией и имеет множество клиентов. Вот почему при работе с «солидными» подрядчиками, вы, как заказчик, должны быть особенно внимательным, чтобы убедиться, что они соблюдают все требования современных стандартов ИБ.
5. В рассмотренном нами примере спортивной компанией было допущено множество ошибок, из-за которых случился инцидент, поэтому:
   • Доступ в инфраструктуру должен быть только через VPN со вторым фактором, а количество систем, доступных из интернета напрямую, должно быть минимальным.
   • Использование флага «DONT_EXPIRE_PASSWORD» не является хорошей практикой. Пользователи самостоятельно не сменят пароль, если система не заставит их это сделать.
   • Сервисные УЗ должны быть также защищены, как и любые другие. Использование стандартных паролей — недопустимо.
   • Нежелательно совмещать такие роли сервера, как «гипервизор» и «контроллер домена». Гипервизор должен быть отдельной системой с максимальным уровнем безопасности, обеспечивающим, например, ограничение сетевых доступов и доступов пользователей, а также дополнительную двухфакторную аутентификацию. В нашем же случае доступ к гипервизору был получен с системы, доступной из интернета.
   • Разновидностью предыдущей проблемы является отсутствие сегментации сети в целом. Даже если инфраструктура маленькая, сегментация необходима. Как минимум, должен быть отдельный сегмент для публично-доступных серверов.

IOC

Files

MD5

1952f6477626d797f671f2a1d5d77bb0
8f412e708f2df13f6e85fc3f06816cc7

SHA1

5845f9046ba1e9822c89896154031491ffbf27d9
8aa46d77c5491b1e407df9cdaf520937aa3a880b

SHA256

127bb4d31ac0bd83fa004971f745837cbcc1d5b524e2726b84448f9079a9d12e
24995b545dc6844e7ddb378ccf3f73c97fb3a563d6722ff7ed18bf31258f5c8f

IP

89[.]221[.]203[.]162 (shavezy[.]com)