В прошлом году, после дропа lnk-файлов, было актульно на одном из этапов использовать AutoIt 🤖

В статье и тут описываются TTP одной из APT 🥷, которые в своем арсенале используют AutoIt.

Страшно ли это для нас?) Скорее нет 🤡, чем да, при правильно настроенном сборе событий, мы можем обнаружить такую активность:

ProviderName="Microsoft-Windows-Sysmon» and EventId = 1 and  OriginalFileName = "autoIt*.exe" 

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and Image = ".*\\autoIt*.exe" 

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and (Description = "autoIt*.exe" or Product "autoIt*.exe")

ProviderName="Microsoft-Windows-Sysmon» and  EventId = 11 and (TargetFilename endswith ".au3" or endswith TargetFilename ".a3x")

#ttp@detectioneasy

Всем привет! 👋

Мы описали пример, как определить источники требований к мониторингу. Давайте попробуем кратко описать этот процесс для выдуманной компании World of detection.

1. Описание источника требования:
🔤 Департамент информационной безопасности (ИБ) компании World of detection.
Контактное лицо: Иван Иванов (Telegram: @ivan_ib, email: ivan.ib@detectionworld.com), Петр Иванов (Telegram: @petr_ib, email: petr.ib@detectionworld.com)

2. Что должно быть обнаружено:
🔤 Активность: Попытки подбора учетных данных (bruteforce) к корпоративным VPN-серверам.

🔤 Техническое описание:
Адреса VPN серверов: 1.1.1.1:1337, 1.1.1.2:3334, 1.1.1.3:31337

Множественные попытки аутентификации с одного IP-адреса в течение короткого промежутка времени (более 30 попыток за 5 минут).

Подключение клиента более чем с одного IP-адреса.

3. Причина для проработки нового обнаружения:
🔤 Источник требования: Результаты последнего тестирования Red Team показали, что текущие правила не обнаруживают атаки методом bruteforce на VPN-серверы.
🔤 Риск: Злоумышленники могут получить доступ к корпоративной сети, что может привести к утечке данных или компрометации критически важных систем.

4. Исключения из правила:
🔤 Белый список: IP-адреса офисов компании

5. Дополнительные данные:
🔤 Логи: Пример логов с попытками bruteforce, если есть.
🔤 PCAP-файлы: Пример сетевого трафика, если доступен.

Если у вас есть вопросы или хотите узнать больше, пишите в комментариях! 🛡️

#notes@detectioneasy
#detection@detectioneasy

Интересно, что у нас по дроперам 🦔?)

Скажем спасибо швиндовсу 🏠 за прекрасный формат *.msc, который описывает в xml оснастки. Мотивированные ребята придумали способ, как исполнять процессы, используя их, и назвали его - GrimResource.

На GitHub есть билдер, который позволяет создавать такие нагрузки.

Что это значит для нас? Ничего страшного, мониторинг - это просто))

Какие варианты обнаружения 🔭?

🔤 Появление новых файлов с расширением .msc в директориях пользователя (например, C:\Users\<Username>\Downloads)

ProviderName="Microsoft-Windows-Sysmon» and  EventId = 11 and (TargetFilename endswith «.msc» and TargetFilename «?:\\Users\.*\.msc»)

🔤 Запуск mmc.exe с оснасткой не из системной директории

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and Image = ".*\mmc.exe"  and CommandLine not in ["?:\\Windows\\System32\\*.msc",
        "?:\\Windows\\SysWOW64\\*.msc",
        "?:\\Program files\\*.msc",
        "?:\\Program Files (x86)\\*.msc»]

🔤 Родительский процесс - это mmc.exe и оснастка не из системной директории

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and ParentImage = ".*\mmc.exe"  and ParentCommandLine not in ["?:\\Windows\\System32\\*.msc",
        "?:\\Windows\\SysWOW64\\*.msc",
        "?:\\Program files\\*.msc",
        "?:\\Program Files (x86)\\*.msc»]

Как не стать жертвой такой техники? 😿
Реализовать тестирование самим, нужно подготовить несколько сценариев, например:
🔤 письмо с вложенным msc
🔤 письмо с упакованным msc в несколько контейнеров
🔤 письмо с линком на msc
🔤 письмо с линком на упакованный msc в несколько контейнеров

Если у тебя по результатам 4х тестов будет 4+ детекта значит использование этой процедуры мы обнаружим своевременно)

🔤 к выше описанным детектам можно добавить вердикт твоего AV-решения, как хостового, так и почтового

Дополнительно можем похантить:
🔤 в директориях пользователей ищем *.msc
🔤 в Prefetch ищем MMC*.pf (кроме серверных версий Windows)
🔤 в MFT ищем создание *.msc
🔤 можем поискать ярой

Если у вас есть вопросы или хотите узнать больше, пишите в комментариях! 🛡️

#ttp@detectioneasy
#detection@detectioneasy

Продолжаем настройку NetFlow 📞
https://habr.com/ru/articles/873382/

MalDev Academy представили POC для скрытия и извлечения исполняемого файла из PNG-картинки. Для запуска используется LNK-файл, который запускает powershell.exe с аргументами:

🔤 для запукска dll

$data=[IO.File]::ReadAllBytes('{opng_fname}');$key=$data[{xor_key_offset}];$file=$env:TEMP+'\\{otpt_pe_file_name}';$i=[Text.Encoding]::ASCII.GetString($data).LastIndexOf('IDAT')+4;$xdata = ($data[$i..$data.Length] | ForEach-Object {{ $_ -bxor $key }}); [IO.File]::WriteAllBytes($file, $xdata); rundll32.exe $file {runtime_exprtdfnc_args}

🔤 для запукска exe

$data=[IO.File]::ReadAllBytes('{opng_fname}');$key=$data[{xor_key_offset}];$file=$env:TEMP+'\\{otpt_pe_file_name}';$i=[Text.Encoding]::ASCII.GetString($data).LastIndexOf('IDAT')+4;$xdata = ($data[$i..$data.Length] | ForEach-Object {{ $_ -bxor $key }}); [IO.File]::WriteAllBytes($file, $xdata); cmd /c $file

Для скрытия обнаружения при анализе файла, перед аргументами вставляется 512 символов пробела.

Можем ли мы обнаружить такое поведение?)) 🔭

#ttp@detectioneasy
#detection@detectioneasy

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

Подозрительная активность может начинаться с дропа LNK-файла в дирректорию пользователя или в %TEMP%.

Если мы рассматриваем такую сборку как первый стейдж, скорее всего доставка будет в архиве, т.к. вряд ли у кого-то на почтовом шлюзе еще не заблокирована доставка LNK 🙃. Аналогичная ситуация при загрузке с линка, пользователю необходимо загружать два файла (+ браузер может заблокировать загрузку), что неудобно, поэтому атакующим нужно выдавать нагрузку в архиве.

При запуске LNK из архива реализация команды в POC работать не будет 😉. Атакующим нужно убедить жертву распаковать архив.

Порассуждали, можем обнаружить 🔭

🔤 Обнаружим создание LNK в дирректории пользователя

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 11 and TargetFilename = "?:\Users\.*\.lnk"

🔤 Проверим аргументы с которыми запускается powershell

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and CommandLine = ".*-bxor.*" and CommandLine = "0x.*" and CommandLine = ".*WriteAllBytes" and Image=".*powershell.exe"

🔤 Не забудем проверить -bxor 0x в base64

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and CommandLine = ".*IAAtAGIAeABvAHIAIAAwAHgA.*" and Image=".*powershell.exe"

🔤 И добавим детект на основе ADS NTFS

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 15 and TargetFilename = "?:\Users\.*\.lnk:Zone.Identifier" and Contents=".*ZoneId=3.*"

#ttp@detectioneasy
#detection@detectioneasy

🔤🔤 Этап 1 — Формирование требований

Привет всем 😏! Сегодня продолжаем тему Detection Engineering. Мы уже разобрали источники требований на разработку контента обнаружения в компании World of Detection, и рассмотрели пример организации этого процесса.

Для формирования требований на разработку правил обнаружения можно использовать платформы для управления проектами или Help Desk. Важно ❗️организовать процесс подачи запросов на создание правил, а также проверку, что такое правило ещё не существует.

Это особенно критично ☝️, если внедрением SIEM/EDR/XDR/NTA/NDR/IDS (и других решений, где используются правила) занимается сторонняя организация. Вы должны чётко понимать, какие правила уже применяются, и каково покрытие актуальных для вас уязвимостей и TTP, они обеспечивают. Это поможет избежать пробелов в обнаружении угроз.

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

Отдельная проблема — поддержка контроля версий контента. Не все SIEM позволяют писать контент в виде кода 🤨. Некоторые предлагают только конструктор правил, что усложняет управление версиями и отслеживание изменений.

Итак, у организации World of Detection должна быть возможность:

🔤 Формировать запросы на разработку правил в какой-либо платформе
🔤 Понимать, какие правила уже используются
🔤 Обеспечивать контроль версий

#ttp@detectioneasy
#detection@detectioneasy

Использование Python 🐍 для компрометации систем всем известная техника. Для ее реализации необходимо приносить интерпретатор (если его еще нет😁) или компилировать скрипт в исполняемый на целевой машине формат.

Небольшой обзор применения Python-скриптов

Сможем обнаружить вовремя?) 🔭

#ttp@detectioneasy

А вы знаете в чем отличие между python.exe и pythonw.exe ⁉️
pythonw.exe - позволяет запускать скрипты без открытия окна консоли, что не привлечет внимания пользователя.

Что с обнаружением?) Ничего сверхъестественного 🪄 мы не увидим, но нужно профилировать, особенно, если у вас ведется разработка ПО на python.

🔤 обнаруживаем создание файлов py? или python

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 11 and (TargetFilename = "?:\Users\.*\.py.?" or TargetFilename = "?:\Users\.*\\python.?\.exe")

🔤 обнаруживаем в аргументах командой строки python

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 1 and CommandLine = «.*\\python.?\.exe"

🔤 обнаруживаем запуск переименованного интерпретатора python

ProviderName="Microsoft-Windows-Sysmon" and  OriginalFileName = "python.?" and Image != ".*\\python.?\.exe"

🔤 обнаруживаем запуск интерпретатора python

ProviderName="Microsoft-Windows-Sysmon" and  Image = ".*\python.?\.exe" and OriginalFileName = "python.?"

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

#detection@detectioneasy

🔤🔤 Этап 2 — Сортировка требований на разработку

Всем привет 👋!
Продолжаем формировать процесс Detection Engineering в компании World of Detection. К этому моменту у нас уже внедрен трекер задач для учета и ведется активная разработка и доработка правил обнаружения. Однако аналитики не успевают справляться с поступающими задачами.

Рассмотрим ситуацию)
У компании World of Detection используется Exchange, а OWA (Outlook Web Access) доступна из интернета. В трекер задач поступил запрос на разработку правила для обнаружения эксплуатации уязвимости 🤬 (unauth RCE via OWA), эксплойт для которой доступен на GitHub. Администраторы сообщили, что обновление системы в данный момент невозможно, и придется ждать выходных. Тем временем аналитики продолжают разбирать поступающие запросы, и неизвестно, когда они доберутся до задачи, связанной с Exchange.

Хакеры 😈, естественно, воспользовались уязвимостью, взломали почтовый сервер, проникли во внутреннюю сеть и зашифровали часть инфраструктуры.

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

Что мы упустили?
Один из ключевых этапов — triage (сортировка и приоритизация задач). В созданной нами ранее карточки не предусмотрено поле для критичности (срочности).

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

#detection@detectioneasy

Неплохой вариант для фишинга 🧐?)

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

🔤 По старинке, смотрим создавались ли у нас файлы с расширением theme

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 11 and TargetFilename = "?:\Users\.*\.theme"

🔤 Обращение explorer.exe и rundll32.exe на 445 порт за пределы сети

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 3 and DestinationIp not in [10.0.0.0/8
, 172.16.0.0/12, 169.254.0.0/16] and DestinationPort = 445 and (Image endswith "explorer.exe" or Image endswith "rundll32.exe")

🔤 Загрузка DLL с удаленного ресурса

ProviderName="Microsoft-Windows-Sysmon" and  EventId = 10 and Image endswith "rundll32.exe" and ImageLoaded startswith = '\\\\'

Хочется верить, что уже у всех закрыт доступ по WebDAV и SMB за пределы корпоративной сети)

#ttp@detectioneasy
#detection@detectioneasy

Наткнулся на удобную утилиту для извлечения и расшифровки 😎😈 данных браузера (macOS, Windows, Linux).

#ttp@detectioneasy

Всем привет 👋)
Популярна тема скрытия от обнаружения, для этого нам нужно, чтобы телеметрия от хоста не дошла до сервера управления ✋

И мне кажется топ самых простых способов:

🔤 DNS-Sinkhole, добавляем имя сервера управления в hosts и указываем ему адрес 127.0.0.1 😱

🔤 Хостовой МСЭ, добавим правило, блокирующее доступ до адреса сервера управления 🔥

🔤 Таблица маршрутизации) мы можем сделать blackhole route 🛣

#ttp@detectioneasy

Всем привет 🙂
Еще один пример использования *.lnk для доставки 💼 малвари и скрытия своих действий)

powershell -windowstyle hidden ($o)bf_lnkpath = Get-Child(It)em *.lnk ^| where(-)object {$_.length -eq 0(0)395530} ^| Select-Object -Exp(a)ndProperty FullName;$o(b)f_file = [system.io(.)file]::ReadAll(B)ytes($obf_lnkpath);$obf_path = '%TEMP%\tmp'(+)(Get-Random)+'(.)zip';$obf_path = [Envir(o)nment]::Expa(n)dEnvironmentVa(r)iables($obf_path);$obf_dir = [System.IO(.)Path]::GetDire(c)toryName($obf_path);[Syste(m).IO.File]::WriteA(l)lBytes($obf_path, $obf_file[003412..($obf_file.length)]);cd $obf_dir;Expand-Archive -Path $obf_path -DestinationPath . -EA Sile(n)tlyContinue -Force ^| Out-Null;Remove-Item -Path $obf_path -EA SilentlyCo(n)tinue -Force ^| Out-Null;^& .\svchost(.)exe



Компания World of detection, больше не боится такого поведения 😁

Примеры обнаружения были ранее 🔭 но хакеры использовали ещё одну технику 😎

#ttp@detectioneasy