1C_shell для «1С» 🦞

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

Самым терпеливым и любопытным может помочь связка инструментов для работы с кэшем RDP (который, как известно, хранится в Windows по адресу C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\Cache), состоящая из парсера кэша bmc-tools и инструмента для «склеивания» фрагментов изображения RdpCacheStitcher.

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

Практика показывает, что однозначной закономерности в расположении отдельных фрагментов внутри кэша нет, но, как правило, соседние фрагменты могут располагаться в пределах окна в 20–30 последовательных изображений. Тем не менее полностью автоматизировать «склеивание» этих пазлов — задача нетривиальная.

🔎 Итак, что же любопытного можно обнаружить внутри подобного кэша?

1. Следы внезапно проснувшегося интереса пользователя к разного рода сомнительным инструментам (скриншоты 1, 2);

2. Следы запуска подозрительных файлов с еще более подозрительными параметрами (скриншот 3);

3. Выполнение до боли знакомых команд, которые, казалось бы, простой бухгалтер выполнять не должен (скриншот 4);

4. Нечто крайне подозрительное, интересное (скриншот 5).

При обнаружении такого рода данных следует внимательно изучить соседние фрагменты — там, как правило, можно обнаружить какое-то развитие наметившейся идеи (скриншоты 6, 7, 8).

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

Несмотря на то, что механизмы работы подобных «внешних обработок» системы «1С» были уже давно описаны в материале «Взломать за 60 секунд!» и докладе «„1С“ глазами пентестера», а все соответствующие рекомендации сформулированы, схема продолжает работать и по сей день.

#ir #dfir #malware
@ptescalator

Используете ли вы криптографию правильно? 🔓

Группе исследования сложных угроз департамента Threat Intelligence часто приходится решать интересные задачи в процессе реверса ВПО. Этот раз не стал исключением. Существует такая техника, как Execution Guardrails: Environmental Keying, — она нужна для ограничения выполнения ВПО только в конкретной целевой среде. Например, ее использует группировка Decoy Dog в своих операциях.

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

☠️ Выяснилось, что ВПО «падает» при попытке вызова функции LoadLibraryA с переданным именем библиотеки в качестве неотображаемых байтов. Этот набор байтов должен представлять собой имя библиотеки, которая расшифровывается в цикле; при каждой итерации берется символ от имени компьютера, с помощью логических операций приводится в необратимый вид, а после уже гаммируется с зашифрованным текстом и его однобайтовой константой.

Чтобы вычислить промежуточный ключ (который формируется в результате логических операций), мы прибегнули к атаке на основе открытого текста. Возвращаясь к функции LoadLibraryA: мы знаем, что имя библиотеки будет составлять 13 байт в кодировке ASCII + '\x00'; так мы смогли восстановить треть ключа, а далее по аналогии уже с другими строками восстановили оставшуюся часть ключа.

Дешифрование строки:
F(sym_comp_name) ^ sym_enc ^ cnst_enc = sym_dec
F(sym_comp_name) — логические операции

Получение промежуточного ключа:
sym_dll_name ^ sym_enc ^ cnst_enc = irr_sym_key
irr_sym_key — промежуточный байт ключа, необратимый

Группа исследования сложных угроз рекомендует одну из платформ для изучения криптоанализа — cryptohack.org.

#tips #reverse #malware #cryptography #TI
@ptescalator

@Вредонос попал в систему...
@Вредонос хочет сделать пакость...
@Вредонос вызывает WinAPI и...
@EDR-система обнаруживает его и начинает очень громко орать...

😱 Не самое приятное развитие событий для вирусописателей. Как же они борются с подобными ситуациями?

Один из способов — вызывать необходимую функцию Windows не через WinAPI, а через системные вызовы (system calls). Многие EDR-системы перехватывают вызовы WinAPI-функций, но далеко не всегда они определяют использование system calls. Этой особенностью можно воспользоваться для обхода защитных механизмов.

SysWhispers

Зачем самому реализовывать механизм вызова syscall, если добрые люди уже это сделали за тебя? Правильно, будем использовать готовое решение — SysWhispers (в этом посте будем говорить про его вторую версию). Стоит отметить, что помимо предоставления удобного интерфейса, с помощью которого можно вызывать syscall, SysWhispers также хеширует их.

Выглядит это так: вызываем функцию SW2_GetSyscallNumber, в которую передаем хеш необходимого syscall. В ответ функция возвращает номер системной функции, которую мы и вызываем с помощью инструкции syscall. Более подробно этот процесс показан на скриншоте 1 (на нем приведен пример вызова функции NtWriteVirtualMemory).

🧐 И вот теперь приходит исследователь, которому нужно это отреверсить. Как же ему понять, какой syscall используется?

Напрямую получить номер нужной системной функции мы не можем: он захеширован, поэтому придется что-то придумать. Можно написать скрипт, который будет реализовывать тот же алгоритм хеширования, что и SysWhispers (по сути, в нем используется XOR имени функции по случайному значению). Но можно пойти другим путем: с помощью механизма Appcall в IDA Pro (Appcall работает только в режиме отладки, поэтому с вредоносами лучше работать в виртуальной машине) напрямую вызвать SW2_GetSyscallNumber, передав ей хеш необходимой функции. Мы все также получим номер функции, но при этом процесс пройдет значительно быстрее.

Просто сравните — написать скрипт, который будет воссоздавать хеш-функцию, или одну строчку кода на Python:

syscall_id = idaapi.Appcall.SW2_GetSyscallNumber(hash).value

👋 Угу, номер syscall у нас есть, а что дальше, как узнать его имя?

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

Код скрипта, реализующего эту логику, представлен в публикации ниже. Основная идея заключается в том, что все функции-обертки над системными вызовами однотипны и выглядят примерно так, как показано на скриншоте 2. Перед вызовом инструкции syscall происходит передача номера нужной функции в регистр EAX (вторая инструкция). Мы можем взять вторую инструкцию функции-обертки, получить ее операнд — это и будет номер системного вызова. Далее остается сравнить его с тем, что ищем мы, и вывести результат (скриншот 3).

😮‍💨 Вот таким незамысловатым образом реверсер может облегчить себе жизнь, когда ему попадется вредонос с SysWhispers. Напоследок еще раз (на всякий случай) скажем, что представленный скрипт будет работать только в режиме отладки, поэтому, если речь заходит про анализ чего-то зловредного, то лучше делать это в виртуальной машине. Так что стоит отметить, что IDA работает со многими отладчиками, в нашем же случае все разрабатывалось и проверялось с использованием WinDbg.

#reverse #malware #tip
@ptescalator

Большой браузер следит за тобой 👹

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

Злоумышленники рассылают фишинговые письма с тематикой СВО, содержащие вложенные архивы с вредоносным HTA-файлом (скриншот 1). Этот файл содержит обфусцированный код и имеет название, совпадающее с темой письма. При его открытии запускается документ-приманка (скриншот 2), а вместе с ним — вредоносный код (посредством события window_OnLoad).

ВПО пытается мимикрировать под Яндекс Браузер. Вредоносный скрипт создает VBA-файлы по пути %USERPROFILE%\AppData\Local\YandexUpdate, добавляет полезную нагрузку в реестр HKCU\Software\YandexUpdate (скриншоты 3, 4), прописывает VBA-файлы в автозагрузку через реестр HKCU\Software\Microsoft\Windows\CurrentVersion\Run, а также регистрирует задания в планировщике с помощью schtasks.

🔤 Изначально злоумышленники использовали три скрипта:

• log01.vbs — выполняет обход директорий пользователей, анализирует содержимое определенных папок и сохраняет файлы с заданными расширениями (.pdf, .txt, .doc, .docx, .rtf, .odt, .xls, .xlsx, .ods, .csv, .jpg, .png, .zip, .rar).
• log02.vbs — похищает учетные данные из Telegram и браузеров (из Chrome, Edge, Opera, Яндекс Браузера).
• log03.vbs — передает собранные данные на командный сервер.

👾 В последних атаках группировка модифицировала и расширила функциональность ВПО:

• В crash_report.vbs (ранее — log01.vbs) увеличен список расширений файлов для сбора (.vsdx, .vdx, .7z, .tar, .jpeg, .cdr, .kmz, .kml, .aqe). Важно, что были добавлены расширения .kml и .kmz, используемые в военной топографии.
• С помощью service_report.vba злоумышленники пытались получить список всех флеш-накопителей, но скрипт оказался нерабочим.
• Добавлен механизм самозащиты: update_logging.vbs восстанавливает удаленные вредоносные файлы, подгружая их содержимое из реестра.

⚠️ Важно отметить, что VBA-скрипты не детектируются антивирусными решениями, так как считывают значения из реестра и запускают вредоносный код напрямую. Это усложняет процесс обнаружения (скриншот 5).

Анализ атаки указывает на развитие методики злоумышленников. Кроме того, стоит отметить, что группировка проявляет интерес к расширениям, связанным с картографией. Это может свидетельствовать о специфической цели или о стратегическом интересе в указанной области.

IoCs

Домен
vm-tiktok.org

Хеш-суммы
096c340e9a20476a191721e6eaeedcc2
0debff602f2912127c562839c7fcd3d7
e25042fba726356d7e88efe0608a4e36
290a4cff70029ca2a0095a3e3a8b19e7
65ef77db51277a046f76f21a59dee9e0
80bc350629a1ba59b2a19b9029feece5 
d0f9fadbf157a8236b88cfc03f17a811 
4feaa6c50348641799a8f56e76cd52e7

#TI #APT #Malware #Phishing
@ptescalator

Уже не Rezet, или Новые атаки Rare Wolf 🐺

Группа киберразведки PT ESC продолжает фиксировать атаки группировки Rare Wolf: так, в конце мая злоумышленники рассылали фишинговые письма от имени antey-almaz-info.site в адрес компаний военно-промышленного комплекса. Текущая кампания очень похожа на ту, что мы описывали в конце января (скриншот 1).

Группировка все так же доставляет вредоносный SCR-файл внутри архива, пароль к которому указан в тексте письма. При запуске SCR-файл отвлекает внимание жертвы, открывая документ-приманку, и одновременно скачивает на узел архив с PowerShell- и BAT-скриптами. В этот раз для распаковки скриптов используется скрытая папка C:\Users\admin\Window (скриншоты 2–3).

Rare Wolf по-прежнему собирает системную информацию, в том числе дампы реестров SAM и SYSTEM, сканирует локальные подсети в попытке скопировать файлы с других устройств и скрытно устанавливает AnyDesk для удаленного доступа.

🕗 Следует отметить, что сканирование локальной подсети проходит по жестко заданным IP-адресам и занимает около 9–10 минут, что существенно превышает лимиты динамического анализа большинства публичных песочниц. Обычно такие сервисы ограничивают время эмуляции несколькими минутами (от 1 до 6), а в расширенных режимах — не более 10–12 минут. Вероятно, цель подобных задержек — не дать песочницам зафиксировать дальнейшие действия вредоносных файлов.

🙅‍♂️ Единственными заметными изменениями стали отказ от файла rezet.cmd, использовавшегося ранее в атаках, и переход с публичного туннелирования через ngrok на собственный обратный SSH-туннель с использованием Tuna и штатного sshd — это повышает скрытность и надежность канала связи с C2-сервером.

Для этого злоумышленники устанавливают на зараженном устройстве демон sshd и исполняемый файл tuna.exe, прописывают в firewall разрешение на входящий TCP-порт 22 и настраивают ключевую аутентификацию, обеспечивая автоматический запуск службы sshd при старте системы и поддерживая обратное SSH-соединение с сервером управления. Tuna при этом инициирует исходящее соединение к C2 и проксирует весь трафик на локальный демон sshd, обеспечивая скрытый и защищенный канал.

😠 При попытке вручную вызвать tuna (например, выполнить в командной строке tuna tcp 22), можно увидеть адрес электронной почты, который используют злоумышленники. На скриншоте также видна ошибка, сообщающая, что учетная запись неактивна — возможно, они просто забыли продлить оплату (скриншот 4).

В марте этого года группировка также предпринимала попытку рассылки вирусного ПО, однако пароль от архива не совпал с тем, что был указан злоумышленниками в тексте письма. А используемый домен almaz-antey-info.online представлял слегка измененный вариант домена, используемого в майских атаках (скриншот 5).

IoCs

[email protected]

almaz-antey-info.online
antey-almaz-info.site

b7543b3e0c3fa6bd8973dde12258c7f7
fc0b6c43185061c2b3b11ab0bfdf924f 
9eb2c87299e3b1d86268ab1752b83502

#TI #APT #phishing #malware #ioc
@ptescalator

По следам 1C_Shell. Расследуем атаки с помощью журнала регистрации 🐾

В одном из предыдущих постов мы писали об обнаружении атак на систему «1С», в которых злоумышленники использовали инструмент 1C_shell. Он представляет собой внешнюю обработку, позволяющую запустить произвольный код на сервере «1С:Предприятие».

Подобные атаки интересны тем, что оставляют мало очевидных следов в скомпрометированных системах. В частности, тяжело определить источник атаки, особенно в условиях ротации журналов событий Windows.

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

💡 Журнал регистрации — механизм в системе «1С», предназначенный для логирования действия пользователей, в том числе начала и завершения сессий.

Чтобы просмотреть журнал регистрации, перейдем в конфигуратор и на вкладке «Администрирование» выберем соответствующий пункт (скриншот 1).

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

Файлы журнала регистрации в случае клиент-серверного варианта информационной базы по умолчанию хранятся в рабочей папке кластера:

C:\Program Files\1cv8\srvinfo\reg_****\****\1Cv8Log

Логи имеют необычный формат и плохо пригодны для ручного анализа. О формате можно почитать в статье «Инфостарт»: описание актуально для «1С:Предприятия» версий 8.1 и 8.2, но с тех пор формат изменился незначительно.

💡 Актуальная структура журнала регистрации описана в Руководстве администратора «1С:Предприятия» — однако доступ к документу ограничен.

Для того чтобы распарсить файлы журнала регистрации, можно воспользоваться встроенной консольной утилитой ibcmd, предназначенной для администрирования сервера «1С». Она входит в комплект, поставляемый при установке «1С:Предприятия», и, начиная с версии 8.3.25, имеет функциональность для обработки файлов журнала регистрации.

Утилита расположена в папке C:\Program Files\1cv8\<version>\bin. Папку можно скопировать и использовать на другом компьютере без необходимости устанавливать систему «1С».

Документацию утилиты также можно найти в Руководстве администратора.

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

ibcmd.exe eventlog export -f json --skip-root -o C:\<output_path> \output.jsonl C:\<path_to_1Cv8Log>

Пример выходной строки:

{"ApplicationName":"1CV8C","ApplicationPresentation":"Тонкий клиент","Comment":"","Computer":"DESKTOP-QBF9N0A","Connection":"25","Data":null,"DataPresentation":"","Date":"2025-06-02T17:38:31","Event":"_$Session$_.Start","EventPresentation":"Сеанс. Начало","Level":"Information","Metadata":"00000000-0000-0000-0000-000000000000","MetadataPresentation":"<Не определено 00000000-0000-0000-0000-000000000000>","Port":"1560","ServerName":"WIN-UB4CFT0Q9FN","Session":"1","SessionDataSeparation":null,"SessionDataSeparationPresentation":null,"SyncPort":"0","TransactionID":"","TransactionStatus":"NotApplicable","User":"071523a4-516f-4fce-ba4b-0d11ab7a1893","UserName":""}
{"ApplicationName":"1CV8C","ApplicationPresentation":"Тонкий клиент","Comment":"","Computer":"DESKTOP-QBF9N0A","Connection":"0","Data":null,"DataPresentation":"","Date":"2025-06-02T17:38:57","Event":"_$Session$_.Finish","EventPresentation":"Сеанс. Завершение","Level":"Information","Metadata":"00000000-0000-0000-0000-000000000000","MetadataPresentation":"<Не определено 00000000-0000-0000-0000-000000000000>","Port":"0","ServerName":"","Session":"1","SessionDataSeparation":null,"SessionDataSeparationPresentation":null,"SyncPort":"0","TransactionID":"","TransactionStatus":"NotApplicable","User":"071523a4-516f-4fce-ba4b-0d11ab7a1893","UserName":""}

#ir #detect #dfir #malware
@ptescalator

В дополнение к предыдущему посту хотим рассказать о некоторых других потенциальных способах детектирования выполнения вредоносного кода в системе «1С» 😳

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

В таком случае мы можем найти в логах IIS полезную информацию, в частности — обращение к информационной базе и загрузку внешней обработки:

2025-06-17 13:15:20 192.168.80.130 GET /mybase/ - 80 - 192.168.80.129 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/137.0.0.0+Safari/537.36+Edg/137.0.0.0 - 200 0 0 2

2025-06-17 13:18:55 192.168.80.130 GET /mybase/ru/e1cib/logForm cmd=elements&formId=urn:form:ext:0:ce244e8a-6d30-4e49-a244-c6d80d2ea085@n=%22%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0.%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B01%22;v=%223bb1cd7e449b0540951594ef9f12fb6d00000000%22&altFormId=urn:form:ext:8:add30da0-7627-464c-b936-820f49ac3e75@n=%22%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0.%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B01%22;v=%223bb1cd7e449b0540951594ef9f12fb6d00000000%22&sysver=8.3.18.1208&confver=3bb1cd7e449b0540951594ef9f12fb6d00000000&rolesId=0&clang=ru 80 - 192.168.80.129 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/137.0.0.0+Safari/537.36+Edg/137.0.0.0 https://192.168.80.130/mybase/ru/ 200 0 0 37

После декодирования URL запроса выше мы получим строку, которая говорит о взаимодействии с внешней обработкой:
"ВнешняяОбработка.ВнешняяОбработка1";v="3bb1cd7e449b0540951594ef9f12fb6d00000000"

• Другой способ обнаружить следы вредоносной активности — проанализировать процесс rphost.exe. В случае выполнения кода через 1C_shell в памяти процесса остаются фрагменты кода внешней обработки (скриншот 2).

Стоит отметить, что этот метод не принесет результата, если сервер или процесс rphost.exe будут перезапущены после выполнения вредоносного кода.

#ir #detect #dfir #malware
@ptescalator

Нефритовый металл: уже не новая группа Telemanmilconfav атакует военные организации? 🪖

В марте исследователи из F6 опубликовали материал о группировке Telemancon, атаковавшей промышленные организации. Группа была названа в честь использования сервиса telegra.ph, man — от слова manufactory, con — из-за сохранения нагрузки в %userprofile%\Contacts\.

Нами были обнаружены несколько файлов, связанных с этой группой. Один из них — Письмо_в_АО_УАПО_запрос_РКМ_и_закл_ВП.scr 📬

При запуске, как и в случае с семплами, описанными F6, SCR-скрипт открывал decoy-документ PDF и вредоносный PowerShell-скрипт в той же %userprofile%\Contacts\, в честь которой назвали эту группу: тематика decoy-документа была связана с войсками национальной гвардии и оборонными заказами

Но больший интерес представляет обнаруженный архив Гуманитарная_помощь_накладные_июнь_2025_1.zip. Он содержит пять SCR-скриптов: четыре из них маскируются под XLSX-файлы, один — под картинку (скриншот 1).

После запуска каждый из них дропает два файла: PowerShell-скрипт (в папку %userprofile%\Favorites\) и легитимный XLSX-файл (в одном из пяти случаев это картинка). Excel-документы и картинка отсылали к информации о гуманитарной помощи для военных (скриншот 2).

🫤 Сами инструменты претерпели изменения: их стало сложнее анализировать и они повысили устойчивость к защитным механизмам. Основные изменения коснулись TMCDropper. Раньше код имел структуру с отдельными зашифрованными модулями, а в новой версии используется VM-based obfuscation.

Сам же TMCShell не претерпел больших изменений: в него добавили дополнительную проверку на наличие файлов с расширением .ps1, чтобы избежать автозапуска на виртуальных машинах.

Ключевым изменением является использование глобальной переменной, например $qvwml (для каждого скрипта они разные), которая управляет процессом расшифровки полезной нагрузки. Изначально $qvwml = 0, но после успешных проверок (включая .ps1 и отключение AMSI) ее значение увеличивается:

$qvwml += 2

Эта переменная влияет на regex-маску в цикле расшифровки:

foreach($ucbxt in $cjzuc){
    "$ucbxt -replace ('.(.'+'.'*$qvwml+')'),('$'+$(h)+55/55)"|iex|iex
}

После изменения $qvwml повторно запустить скрипт невозможно, так как regex-маска больше не соответствует исходному шаблону.

TMCShell получает содержимое страницы c telegra.ph и из первой строки декодирует адрес С2, а из второй — цифровую подпись (скриншот 3; ответ, который парсит TMCShell). Сам C2-сервер на момент анализа имел IP-адрес 212.80.206.125, который принадлежит израильской AS 44709 (O.m.c. Computers & Communications Ltd), как почти во всех зафиксированных случаях, связанных с этой группировкой.

🏮 Самый интересный момент заключается в том, что Excel-документы содержали метаданные, которые указывают, что документ редактировался последний раз (вероятно, и создан) в системе с китайской локалью в WPS Office, аналоге Microsoft Office, созданной китайской компанией Kingsoft. Сам WPS Office поддерживает несколько языков, включая русский и английский, но в русской или английской версии в поле Heading Pairs должно быть указано Лист1 или Sheet1, в то время как во всех четырех документах-приманках поле Heading Pairs содержало 工作表, 1, где 工作表 означает «рабочий лист» (скриншот 4).

IoCs:

f8f096d2e94bbdbfd20aae45432af58a7bdf3406fa4dde568154b930cac855ca
20b0faa0f058cd71be39075ed1a0294e2a9e7c2f670b7ba5e3e35e6581907122
37bff1efb37a61f1e4d9f9fda43f33db852da01b22b623faedcef20173ee78fa
7c29891b5eacc464620db0a23b2e05b47373b98524aebba05cf3bd8c2b5f42fe
63b7073a8b74dd7810493700881b9afea3627126cbcb1d942e7a01d573207129
4102a0bec73711e754a5ad067d1779cb8c71628b0c38384e41b2041e64ffddba
5df092a5f3d088043cd5724197b63ba239b12edc8cd6dbcf7e3f9d7ce8594426

212.80.206.125

#TI #APT #malware #ioc
@ptescalator