ESCalator

Собеседование → ПО на iPhone от «работодателя» → у вас больше нет смартфона 👋Новая старая схема блокировки iPhone через «режим пропажи» снова в ходу. Только теперь она стала изощреннее: в начале поста — реальный пример многоходовочки, который мы подробно описали в статье на Хабре.Там же — еще несколько случаев и разбор действий злоумышленника: как он получает доступ, блокирует устройство и переходит к требованию выкупа. И главное — инструкция о том, что делать, если вы уже оказались в такой ситуации: какие инструменты помогут, куда стоит написать, а к кому лучше не обращаться, чтобы не сделать еще хуже.😎 Бонус: мы подготовили наглядную схему восстановления доступа к iPhone. Она доступна в формате PDF с кликабельными ссылками — скачивайте и сохраняйте на разные устройства (на всякий случай).#ios #dfir #mobile@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:f8f096d2e94bbdbfd20aae45432af58a7bdf3406fa4dde568154b930cac855ca20b0faa0f058cd71be39075ed1a0294e2a9e7c2f670b7ba5e3e35e658190712237bff1efb37a61f1e4d9f9fda43f33db852da01b22b623faedcef20173ee78fa7c29891b5eacc464620db0a23b2e05b47373b98524aebba05cf3bd8c2b5f42fe63b7073a8b74dd7810493700881b9afea3627126cbcb1d942e7a01d5732071294102a0bec73711e754a5ad067d1779cb8c71628b0c38384e41b2041e64ffddba5df092a5f3d088043cd5724197b63ba239b12edc8cd6dbcf7e3f9d7ce8594426212.80.206.125#TI #APT #malware #ioc@ptescalator

Продолжаем искать файловый след из поста выше 🐾Чтобы понять, с какого DC реплицировался файл, нужно узнать, какому хосту соответствует указанный connId (это значение статично и соответствует однонаправленной связи между двумя машинами).Как это сделать1️⃣ Можно посмотреть таблицу соответствия в файле \System Volume Information\DFSR\Config\Replica_<GUID группы репликации>.XML. Поищем в нем наш connId и увидим примерно следующее:<DfsrConnection> <ConnectionGuid>C62DFB26-63FA-4E9F-B533-0F487BF8E043</ConnectionGuid> <...> <PartnerName>DC02</PartnerName> <...> <PartnerDns>dc02.corp.local</PartnerDns> <...></DfsrConnection>2️⃣ Можно поискать в логах DFSR события, содержащие одновременно интересующий нас connId и слова "partnerDns", "partnerName" или "partnerAddress". Можем обнаружить что-то типа:20250314 01:22:31.307 6304 DOWN 3959 [ERROR] DownstreamTransport::EstablishConnection EstablishConnection failed. Check that the connection partner is valid. If not then recreate the connection with valid partner. connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} rgName:Domain System Volume partnerName:DC02 partnerDns:dc02.corp.local3️⃣ Если DC «живы», то информацию о GUID’ах можно извлечь с помощью утилиты Dfsradmin. Этот способ разбирать не будем — более подробно про логи DFSR можно почитать по ссылке.Итак, в ходе расследования мы выяснили, что изначально вредоносный файл был размещен на DC02.Дело за малым — узнать, кто и откуда заходил на этот DC и положил туда этот файл. Журналы ОС и SUM в помощь — никто не обещал, что будет легко! 🙂#ir #dfir #DFSR@ptescalator

Вредоносы в SYSVOL: ищем источник 😐Допустим, мы расследуем инцидент с шифровальщиком. Для запуска шифровальщика хакеры использовали групповую политику (например, прописали задачу планировщика). Сам вредонос они положили в папку SYSVOL на контроллере домена (DC).🥷 Как понять, откуда действовал хакер? В этом посте сфокусируемся на файловом следе.Логика простая: чтобы положить файл в SYSVOL, хакер должен был так или иначе «зайти» на DC. Поэтому смотрим, когда был создан файл (кстати, поэтому важно сначала собрать данные для расследования, а потом уже зачищать системы), и соотносим эту информацию с входами в систему.Кажется, все просто, но есть нюанс: содержимое каталога SYSVOL реплицируется между DC с помощью DFSR (Distributed File System Replication). То есть хакеру достаточно положить вредоносный файл на один DC, а дальше система автоматически распространит его по всем остальным. Как понять, какой DC был исходным, особенно если DC много?Посмотрим отладочные логи DFSR на произвольном DC из тех, на которых вредонос попал в папку SYSVOL. Обычно эти логи находятся в папке %systemroot%\debug, имена файлов имеют вид Dfsrxxxxx.log и Dfsrxxxxx.log.gz (.gz в Windows? Да!). Логи текстовые, вполне поддаются грепу, но при этом некоторые события имеют многострочный формат, — учитывайте это, если не хотите потерять контекст.Поищем в логах имя нашего вредоноса (пусть это будет badfile.exe). Если мы нашли исходный DC с первого раза, мы должны найти в логах подобное сообщение:20250526 02:44:24.906 5628 USNC 2871 UsnConsumer::CreateNewRecord LDB Inserting ID Record:+ <...>+ name badfile.exeЕсли коротко, то оно свидетельствует о появлении нового файла в реплицируемой папке, то есть искомый файл был изначально размещен на этом DC. В этом случае можно переходить к последнему абзацу в посте ниже 🙂Можно на всякий случай перепроверить это в журнале $UsnJrnl:$J:badfile.exe,.exe,132035,6849,257939,4,.\Windows\SYSVOL\domain\scripts,52168700184,2025-05-25 23:44:23.6245532,FileCreate,Archive,436154648Видно, что файл создается на файловой системе (FileCreate). Если бы файл был реплицирован, это выглядело бы так:2025-03-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,FILE_CREATE,archive,7|1098852025-05-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,RENAME_OLD_NAME,archive,7|1098852025-05-25 23:44:25 +0000 UTC,badfile.exe,Windows\SYSVOL\domain\scripts\badfile.exe,RENAME_NEW_NAME,archive,5|269425Видно, что файл сначала создается в папке DFSR, а потом уже переносится в SYSVOL.Если же вредонос был реплицирован на исследуемый DC, мы увидим в логах DFSR подобное сообщение:20250526 02:44:24.949 4452 INCO 3065 InConnection::ReceiveUpdates Received: uid:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 gvsn:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 fileName:badfile.exe session:86382 connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} csId:{F0285778-7EF8-4808-85D7-68223AA11FB5} csName:SYSVOL ShareОчень интересно, но ничего не понятно.Продолжение в следующем посте 🔽#ir #dfir #DFSR@ptescalator

А у нас большое событие! 😡В PT ESC открылась Антивирусная лаборатория: мы объединили экспертизу «ВИРУСБЛОКАДА» с нашей, анализируем множество сэмплов и самостоятельно пишем сигнатуры для антивирусной базы. 🌚 Более того, на днях эксперт Позитива впервые создал детектирующую запись для антивирусного движка. А перед этим освоил теорию и практику новой для нас технологии и навык использования необходимого набора инструментов. Сможете угадать название детекта? Голосуйте в опросе ниже.Если у вас есть интересный вредонос, который надо проанализировать и для которого необходимо создать правила обнаружения в наших продуктах, то не стесняйтесь: avlab@ptsecurity.com#avlab@ptescalator