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

Последний раз деятельность Winnti попадала в наше поле зрения, когда мы анализировали модификации бэкдоров ShadowPad и PlugX в рамках расследования атак на государственные учреждения стран Центральной Азии. Оба эти семейства оказались схожи концептуально и имели примечательные пересечения в коде. Сравнительному анализу ShadowPad и PlugX был посвящен отдельный материал.

В сегодняшней статье мы разберем бэкдор Spyder именно так окрестили найденный вредоносный модуль наши вирусные аналитики. Мы рассмотрим алгоритмы и особенности его работы и выявим его связь с другими известными инструментами APT-группы Winnti.

Чем примечателен Spyder

Вредоносный модуль представляет собой DLL-библиотеку, которая на зараженном устройстве располагалась в системной директории C:\Windows\System32 под именем oci.dll. Таким образом, модуль был подготовлен для запуска системной службой MSDTC при помощи метода DLL Hijacking. По нашим данным, файл попал на компьютеры в мае 2020 года, однако способ первичного заражения остался неизвестным. В журналах событий мы обнаружили записи о создании служб, предназначенных для старта и остановки MSDTC, а также для исполнения бэкдора.

Log Name: SystemSource: Service Control ManagerDate: 23.11.2020 5:45:17Event ID: 7045Task Category: NoneLevel: InformationKeywords: ClassicUser: Computer: Description:A service was installed in thesystem.Service Name: IIJVXRUMDIKZTTLAMONQService File Name: net start msdtcService Type: user mode serviceService Start Type: demand startService Account: LocalSystem

Log Name: SystemSource: Service Control ManagerDate: 23.11.2020 5:42:20Event ID: 7045Task Category: NoneLevel: InformationKeywords: ClassicUser: Computer: Description:A service was installed in thesystem.Service Name: AVNUXWSHUNXUGGAUXBREService File Name: net stop msdtcService Type: user mode serviceService Start Type: demand startService Account: LocalSystem

Также мы нашли следы запуска других служб со случайными именами, их файлы располагались в директориях вида C:\Windows\Temp\<random1>\<random2>, где random1 и random2 являются строками случайной длины из случайных символов латинского алфавита. На момент проведения исследования исполняемые файлы этих служб отсутствовали.

Интересной находкой стала служба, свидетельствующая об использовании утилиты для удаленного исполнения кода smbexec.py из состава набораImpacket. С её помощью злоумышленники организовали удаленный доступ к командной оболочке в полуинтерактивном режиме.

Исследуемый вредоносный модуль oci.dll был добавлен в вирусную базу Dr.Web как BackDoor.Spyder.1. Это название пришло к нам из артефактов бэкдора. В одном из найденных образцов остались функции ведения отладочного журнала и сами сообщения, при этом те из них, которые использовались при коммуникации с управляющим сервером, содержали строку Spyder.

Бэкдор примечателен рядом интересных особенностей. Во-первых, oci.dll содержит основной PE-модуль, но с отсутствующими файловыми сигнатурами. Заполнение сигнатур заголовка нулями предположительно было сделано с целью затруднения детектирования бэкдора в памяти зараженного устройства. Во-вторых, полезная нагрузка сама по себе не несет вредоносной функциональности, но служит загрузчиком и координатором дополнительных плагинов, получаемых от управляющего сервера. С помощью этих подключаемых плагинов бэкдор выполняет основные задачи. Таким образом, это семейство имеет модульную структуру, как и другие семейства бэкдоров, используемые Winnti, упомянутые ранее ShadowPad и PlugX.

Анализ сетевой инфраструктуры Spyder выявил связь с другими атаками Winnti. В частности инфраструктура, используемая бэкдорами Crosswalk и ShadowPad, описанными в исследовании Positive Technologies, перекликается с некоторыми образцами Spyder. График ниже наглядно показывает выявленные пересечения.

Принцип действия

Бэкдор представляет собой вредоносную DLL-библиотеку. Имена функций в таблице экспорта образца дублируют экспортируемые функции системной библиотеки apphelp.dll.

Функционально образец является загрузчиком для основной полезной нагрузки, которую хранит в секции .data в виде DLL, при этом некоторые элементы DOS и PE заголовков равны нулю.

Работа загрузчика

Загрузка выполняется в функции, обозначенной как malmain_3, вызываемой из точки входа DLL через две промежуточные функции-переходника.

Далее следует стандартный процесс загрузки PE-модуля в память и вызов точки входа загруженного модуля (DllMain) с аргументом DLL_PROCESS_ATTACH, а после выхода из нее повторный вызов с DLL_PROCESS_DETACH.

Работа основного модуля

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

• IMAGE_DOS_HEADER.e_magic

• IMAGE_NT_HEADERS64.Signature

• IMAGE_NT_HEADERS64.FileHeader.Magic

Кроме того, TimeDateStamp и имена секций также имеют нулевое значение. Остальные значения корректны, поэтому после ручной правки необходимых сигнатур файл можно загрузить для анализа в виде PE-модуля.

Анализ основного модуля затруднен, так как периодически используются нетипичные способы вызова функций. Для хранения и обработки структур используется библиотека UT hash. Она позволяет преобразовывать стандартные C-структуры в хеш-таблицы путем добавления одного члена типа ut_hash_handle. При этом все функции библиотеки, такие как добавление элементов, поиск, удаление и т. д., реализованы в виде макросов, что приводит к их принудительному разворачиванию и встраиванию (inline) компилятором в код основной (вызывающей) функции.

Для взаимодействия с управляющим сервером используется библиотека mbedtls.

Функция DllMain

В начале исполнения проверяется наличие события Global\\BFE_Notify_Event_{65a097fe-6102-446a-9f9c-55dfc3f45853}, режим исполнения (из конфигурации) и командная строка, затем происходит запуск рабочих потоков.

Модуль имеет встроенную конфигурацию следующей структуры:

structcfg_c2_block{inttype;charfield_4[20];charaddr[256];}structcfg_proxy_data{DWORDdw;charstr[256];charproxy_server[256];charusername[64];charpassword[32];charunk[128];};structbuiltin_config{intexec_mode;charurl_C2_req[100];charhash_id[20];charstring[64];charfield_BC;cfg_c2_block srv_1;cfg_c2_block srv_2;cfg_c2_block srv_3;cfg_c2_block srv_4;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;intCA_cert_len;charCA_cert[cert_len];};

Поле hash содержит некое значение, которое может являться идентификатором. Это значение используется при взаимодействии с управляющим сервером и может быть представлено в виде строки b2e4936936c910319fb3d210bfa55b18765db9cc, которая по длине совпадает с SHA1-хешами.

Поле string содержит строку из одного символа: 1.

CA_cert сертификат центра сертификации в формате DER. Он используется для установки соединения с управляющим сервером по протоколу TLS 1.2.

В функции DllMain предусмотрено создание нескольких рабочих потоков в зависимости от ряда условий.

• Основной поток thread_1_main

• Поток запроса нового сервера thread_2_get_new_C2_start_communication

• Поток исполнения зашифрованного модуля thread_4_execute_encrypted_module

Основной поток

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

В структуру funcs_struc типа funcs_1 заносятся 3 указателя на функции, которые будут поочередно вызваны внутри функции init_global_funcs_and_allocated_cfg.

В функции set_global_funcs_by_callbacks происходит вызов каждой функции-инициализатора по очереди.

Общий порядок формирования структур выглядит следующим образом:

1) каждой функции передаются две структуры: первая содержит указатели на некоторые функции, вторая пустая;

2) каждая функция переносит указатели на функции из одной структуры в другую;

3) после вызова функции-инициализатора происходит очередное перемещение указателей на функции из локальной структуры в глобальный массив структур по определенному индексу.

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

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

Сложные преобразования копирование локальных структур с функциями и их перенос в глобальные структуры вероятно, призваны усложнить анализ вредоносного образца.

Затем бэкдор при помощи библиотеки UT hash формирует хеш-таблицу служебных структур, ответственных за хранение контекста сетевого соединения, параметров подключения и т. д.

Фрагмент кода формирования хеш-таблицы.

Стоит отметить, что здесь располагается значение сигнатуры, которое позволяет определить используемую библиотеку: g_p_struc_10->hh.tbl->signature = 0xA0111FE1;.

Для рассматриваемого бэкдора характерно распределение значимых полей и данных по нескольким создаваемым для этого структурам. Эта особенность при анализе затрудняет создание осмысленных имен для структур.

После подготовительных действий переходит к инициализации подключения к управляющему серверу.

Инициализация соединения с управляющим сервером

После ряда подготовительных действий бэкдор разрешает хранящийся в конфигурации адрес управляющего сервера и извлекает порт. Адреса в конфигурации хранятся в виде строк: koran.junlper[.]com:80 и koran.junlper[.]com:443. Далее программа создает TCP-сокет для подключения. После этого создает контекст для защищенного соединения и выполняет TLS-рукопожатие.

После установки защищенного соединения бэкдор ожидает от управляющего сервера пакет с командой. Программа оперирует двумя форматами пакетов:

• пакет, полученный после обработки протокола TLS, транспортный пакет;

• пакет, полученный после обработки транспортного пакета, пакет данных. Содержит идентификатор команды и дополнительные данные.

Заголовок транспортного пакета представлен следующей структурой.

structtransport_packet_header{DWORDsignature;WORDcompressed_len;WORDuncompressed_len;};

Данные располагаются после заголовка и упакованы алгоритмом LZ4. Бэкдор проверяет значение поля signature, оно должно быть равно 0x573F0A68.

После распаковки полученный пакет данных имеет заголовок следующего формата.

structdata_packet_header{WORDtag;WORDid;WORDunk_0;BYTEupdate_data;BYTEid_part;DWORDunk_1;DWORDunk_2;DWORDlen;};

Поля tag и id в совокупности определяют действие бэкдора, то есть обозначают идентификатор команды.

Данные структуры заголовков используются в обоих направлениях взаимодействия.

Порядок обработки команд сервера:

• верификация клиента;

• отправка информации о зараженной системе;

• обработка команд по идентификаторам.

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

Этап верификации

Для выполнения этапа верификации значения полей tag и id в полученном от управляющего сервера первичном пакете должны быть равны 1.

Процесс верификации состоит в следующем:

1. Бэкдор формирует буфер из 8-байтного массива, который следует после заголовка пакета и поля hash_id, взятого из конфигурации. Результат можно представить в виде структуры:

struct buff{BYTEpacket_data[8];BYTEhash_id[20];}

2. Вычисляется SHA1-хеш данных в полученном буфере, результат помещается в пакет (после заголовка) и отправляется на сервер.

Отправка информации о системе

Следующий полученный пакет от управляющего сервера должен иметь значения tag, равное 5, и id, равное 3. Данные о системе формируются в виде структуры sysinfo_packet_data.

structsession_info{DWORDid;DWORDState;DWORDClientBuildNumber;BYTEuser_name[64];BYTEclient_IPv4[20];BYTEWinStationName[32];BYTEdomain_name[64];};structsysinfo_block_2{WORDfield_0;WORDfield_2;WORDfield_4;WORDsystem_def_lang_id;WORDuser_def_lang_id;DWORDtimezone_bias;DWORDprocess_SessionID;BYTEuser_name[128];BYTEdomain_name[128];DWORDnumber_of_sessions;session_info sessions[number_of_sessions];};structsysinfo_block_1{DWORDunk_0;//0DWORDbot_id_created;DWORDdw_const_0;//0x101DWORDos_version;WORDdw_const_2;//0x200BYTEcpu_arch;BYTEfield_13;DWORDmain_interface_IP;BYTEMAC_address[20];BYTEbot_id[48];WCHARcomputer_name[128];BYTEcfg_string[64];WORDw_const;//2WORDsessions_size;};structsysinfo_packet_data{DWORDid;sysinfo_block_1 block_1;sysinfo_block_2 block_2;};

Поле sysinfo_packet_data.id содержит константу 0x19C0001.

Примечателен процесс определения бэкдором значений MAC-адреса и IP-адреса. Вначале программа ищет сетевой интерфейс, через который прошло наибольшее количество пакетов, затем получает его MAC-адрес и далее по нему ищет IP-адрес этого интерфейса.

Версия ОС кодируется значением от 1 до 13 (0, если возникла ошибка), начиная с 5.0 и далее по возрастанию версии.

В поле sysinfo_packet_data.block_1.cfg_string помещается значение string из конфигурации бэкдора, которое равно символу 1.

Обработка команд

После верификации и отправки системной информации BackDoor.Spyder.1 приступает к обработке главных команд. В отличие от большинства бэкдоров, команды которых имеют вполне конкретный характер (забрать файл, создать процесс и т. д.), в данном экземпляре они носят скорее служебный характер и отражают инструкции по хранению и структурированию получаемых данных. Фактически все эти служебные команды нацелены на загрузку новых модулей в PE-формате, их хранение и вызов тех или иных экспортируемых функций. Стоит отметить, что модули и информация о них хранятся в памяти в виде хеш-таблиц с помощью UT-hash.

После обработки каждого полученного от сервера пакета бэкдор проверяет разницу между двумя значениями результата GetTickCount. Если значение превышает заданное контрольное значение, то отправляет на сервер значение сигнатуры 0x573F0A68 без каких-либо дополнительных данных и преобразований.

Заключение

Рассмотренный образец бэкдора для целевых атак BackDoor.Spyder.1 примечателен в первую очередь тем, что его код не исполняет прямых вредоносных функций. Его основные задачи скрытое функционирование в зараженной системе и установление связи с управляющим сервером с последующим ожиданием команд операторов. При этом он имеет модульную структуру, что позволяет масштабировать его возможности, обеспечивая любую функциональность в зависимости от нужд атакующих. Наличие подключаемых плагинов роднит рассмотренный образец с ShadowPad и PlugX, что, вкупе с пересечениями сетевых инфраструктур, позволяет нам сделать вывод о его принадлежности к деятельности Winnti.

В конце сентября 2020 года в вирусную лабораторию Доктор Веб за помощью обратился один из российских научно-исследовательских институтов. Сотрудники НИИ обратили внимание на ряд технических проблем, которые могли свидетельствовать о наличии вредоносного ПО на одном из серверов локальной сети. В ходе расследования мы установили, что на НИИ была осуществлена целевая атака с использованием ряда специализированных бэкдоров. Изучение деталей инцидента показало, что сеть института была скомпрометирована задолго до обращения к нам и, судя по имеющимся у нас данным, не одной APT-группой.

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

Восстанавливаем события

Мы считаем, что найденные в сети бэкдоры принадлежат двум разным хакерским группировкам. Для удобства обозначим их как APT-группа 1 и APT-группа 2.

В ходе расследования было установлено, что APT-группа 1 скомпрометировала внутреннюю сеть института осенью 2017 года. Первичное заражение осуществлялось с помощьюBackDoor.Farfli.130 модификации бэкдора, также известного как Gh0st RAT. Позднее, весной 2019 года в сети был установлен Trojan.Mirage.12, а в июне 2020 BackDoor.Siggen2.3268.

APT-группа 2 скомпрометировала сеть института не позднее апреля 2019, и в этот раз заражение началось с установки бэкдораBackDoor.Skeye.1. В процессе работы мы также выяснили, что примерно в то же время в мае 2019 года Skeye был установлен в локальной сети другого российского НИИ.

Тем временем в июне 2019 года компания FireEye опубликовала отчет о целевой атаке на государственный сектор ряда стран центральной Азии с использованием Skeye. Позднее, в период с августа по сентябрь 2020 года вирусные аналитики Доктор Веб зафиксировали установку различных троянов APT-группой 2 в сети пострадавшего НИИ, включая ранее не встречавшийся DNS-бэкдорBackDoor.DNSep.1, а также хорошо известный BackDoor.PlugX.

Более того, в декабре 2017 года на серверы НИИ был установленBackDoor.RemShell.24. Представители этого семейства ранее были описаны специалистами Positive Technologies в исследовании Operation Taskmasters. При этом мы не располагаем такими данными, которые позволили бы однозначно определить, какая из двух APT-групп использовала этот бэкдор.

Кто стоит за атаками?

Деятельность первой APT-группы не позволяет нам однозначно идентифицировать атаковавших как одну из ранее описанных хакерских группировок. При этом анализ используемых вредоносных программ и инфраструктуры показал, что эта группа активна как минимум с 2015 года.

Второй APT-группой, атаковавшей НИИ, по нашему мнению является TA428, ранее описанная исследователями компании Proofpoint в материале Operation Lag Time IT. В пользу нашего вывода говорят следующие факты:

1) в коде бэкдоров BackDoor.DNSep и BackDoor.Cotx имеются явные пересечения и заимствования;

2) BackDoor.Skeye.1 и Trojan.Loader.661 использовались в рамках одной атаки, при этом последний является известным инструментом TA428;

3) бэкдоры, проанализированные нами в рамках этих атак, имеют пересечения в адресах управляющих серверов и сетевой инфраструктуре с бэкдорами, используемыми группировкой TA428.

Теперь подробнее рассмотрим выявленные связи. На графе приведена часть задействованной в атаке инфраструктуры с пересечениями бэкдоров Skeye и другим известным APT-бэкдором PosionIvy:

На этом графе изображены пересечения в инфраструктуре бэкдоров Skeye и Cotx:

Детальный анализ бэкдора DNSep и его последующее сравнение с кодом бэкдора Cotx выявили сходство как в общей логике обработки команд от управляющего сервера, так и в конкретных реализациях отдельных команд. Мы рассмотрим их ниже.

Другой интересной находкой этого исследования стал бэкдор Logtu, один из его образцов мы ранее описывали в рамках расследования инцидента в Киргизии. Адрес его управляющего сервера совпал с адресом сервера бэкдора Skeye atob[.]kommesantor[.]com. В связи с этим мы также провели сравнительный анализ BackDoor.Skeye.1 с образцами BackDoor.Logtu.1 и BackDoor.Mikroceen.11.

Подробный разбор алгоритмов работы найденных бэкдоров читайте в нашем исследовании на сайте.

Сравнительный анализ кода DNSep и Cotx

Несмотря на то, что каналы связи с управляющим сервером у Cotx и DNSep кардинально различаются, нам удалось найти интересные совпадения в коде обоих бэкдоров.

Функция, отвечающая за обработку команд от управляющего сервера, принимает аргументом структуру:

structst_arg{_BYTE cmd;st_string arg;};

При этом, если нужная функция принимает несколько аргументов, то они все записаны в поле arg с разделителем |.

Набор команд BackDoor.Cotx.1 обширнее, чем у BackDoor.DNSep.1, и включает все команды, которые есть у последнего.

Ниже видно почти полное совпадение кода некоторых функций бэкдоров. При этом следует учитывать, в Cotx используется кодировка Unicode, а в DNSep ANSI.

Обработчик команды на отправку листинга каталога или информации о диске

Функция получения информации о дисках

Функция перечисления файлов в папке

Функция сбора информации о файлах в папке

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

Сравнительный анализ кода бэкдоров Skeye, Mikroceen, Logtu

В процессе исследования бэкдора Skeye мы обнаружили, что адрес его управляющего сервера также используется бэкдором семейства Logtu. Для сравнительного анализа мы использовали ранее описанные нами образцы BackDoor.Logtu.1 и BackDoor.Mikroceen.11.

Функции логирования

Логирование во всех случаях так или иначе обфусцировано.

• BackDoor.Mikroceen.11 сообщения в формате %d-%d-%d %d:%d:%d <msg>\r\n записываются в файл %TEMP%\WZ9Jan10.TMP, где <msg> случайная текстовая строка. В образце 2f80f51188dc9aea697868864d88925d64c26abc сообщения записываются в файл 7B296FB0.CAB;

• BackDoor.Logtu.1 сообщения в формате [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n перед записью в файл %TEMP%\rar<rnd>.tmp шифруются операцией XOR с ключом 0x31;

• BackDoor.Skeye.1 сообщения в формате %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n записываются в файл %TEMP%\wcrypt32.dll.

Общая логика последовательности записи сообщений в журнал также схожа у всех трех образцов:

• начало исполнения фиксируется;

• в Logtu и Mikroceen в журнал записывается прямое подключение к управляющему серверу;

• в каждом случае указывается, через какой прокси выполнено подключение к серверу;

• в случае ошибки на этапе получения прокси из того или иного источника в журнале фиксируется отдельная запись.

Следует заметить, что настолько подробное и при этом обфусцированное логирование встречается крайне редко. Обфускация заключается в том, что в журнал записываются некоторые коды сообщений и в ряде случаев дополнительные данные. Кроме того, в данном случае прослеживается общая схема последовательности записи событий:

• начало исполнения;

• попытка подключения напрямую;

• получение адресов прокси;

• запись о подключении через тот или иной сервер.

Поиск прокси-сервера

Последовательность соединения с управляющим сервером также выглядит похожей у всех 3 образцов. Первоначально каждый бэкдор пытается подключиться к серверу напрямую, а в случае неудачи может использовать прокси-серверы, адреса которых находятся из трех источников помимо встроенного.

Получение адресов прокси-серверов BackDoor.Mikroceen.11:

• из файла %WINDIR%\debug\netlogon.cfg;

• из собственного лог-файла;

• путем поиска соединений с удаленными хостами через порты 80, 8080, 3128, 9080 в TCP-таблице.

Поиск прокси в своем лог-файле:

Поиск в активных соединениях:

Получение адресов прокси-серверов BackDoor.Logtu.1:

• из реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;

• из раздела HKU реестра по SID активного пользователя;

• с помощью WinHTTP API WinHttpGetProxyForUrl путем запроса к google.com.

Получение адресов прокси-серверов BackDoor.Skeye.1:

• из раздела HKCU Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;

• из раздела HKU по SID активного пользователя;

• путем поиска соединений с удаленными хостами через порты 80, 8080, 3128, 9080 в TCP-таблице.

Пересечения в сетевой инфраструктуре

Некоторые образцы совместно использовали одну и ту же сетевую инфраструктуру. Фрагмент графа наглядно показывает взаимосвязь между семействами.

Идентификаторы

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

Кроме того, в значительном числе образцов данный идентификатор равен значению TEST или test.

Пример в BackDoor.Logtu.1 (9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

Пример в BackDoor.Mirkoceen.11 (81bb895a833594013bc74b429fb1f24f9ec9df26):

Таким образом, сравнительный анализ выявил у рассмотренных семейств сходства в:

• логике ведения журнала событий и его обфускации;

• логике подключения к управляющему серверу и алгоритмах поиска адресов прокси;

• используемой сетевой инфраструктуре.

Заключение

В ходе расследования атак на российские НИИ наши вирусные аналитики нашли и описали несколько семейств целевых бэкдоров, включая ранее неизвестные образцы. Следует отдельно отметить длительное скрытое функционирование вредоносных программ в скомпрометированной сети пострадавшей организации несанкционированное присутствие первой APT-группы оставалось незамеченным с 2017 года.

Характерной особенностью является наличие пересечений в коде и сетевой инфраструктуре проанализированных образцов. Мы допускаем, что выявленные связи указывают на принадлежность рассмотренных бэкдоров к одним и тем же хакерским группировкам.

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

Индикаторы компрометации