stihl не предоставил(а) никакой дополнительной информации.
В этой статье я покажу несколько атак на Active Directory, порекомендую утилиты для эксплуатации и расскажу об индикаторах, на которые нужно обращать внимание при расследовании инцидентов. А упражняться будем на лабораторных работах Sherlocks с площадки Hack The Box.
Помимо этого, в интернете можно найти множество материалов по реализации как простых, так и продвинутых атак на AD. Поэтому любой скрипт‑кидди, вооружившись парой утилит, может рискнуть и попробовать свои силы в хакинге, что уж говорить про серьезных киберпреступников.
Все это способствует тому, что ребятам из блю‑тима важно обладать знаниями в сфере безопасности инфраструктуры и уметь быстро реагировать на подобные инциденты, а также находить ошибки в конфигурации AD.
Протокол Kerberos в Active Directory используется для аутентификации пользователей и предоставления доступа к службам. Когда пользователь пытается получить доступ к ресурсу, который управляется именем субъекта‑службы (SPN), при использовании Kerberos контроллер домена создает сервисный билет (ST) и шифрует его с использованием хеша пароля SPN. После этого веб‑сервер расшифровывает и подтверждает подлинность ST.
Однако, если запрос на получение сервисного билета исходит от самого контроллера домена, проверка того, имеет ли пользователь необходимые права для доступа к предоставляемым SPN ресурсам, не выполняется.
Теперь о самом интересном: злоумышленники, зная конкретную службу (или SPN), которую они намерены атаковать, могут отправить запрос на ST с контроллера домена и получить обратно ST, зашифрованный хешем пароля соответствующего SPN.
Часто для проведения атаки Kerberoasting используют утилиту GetUserSPNs из комплекта достаточно мощного инструмента аудита Impacket. Таким образом, злоумышленник получает хеш SPN, который он может пробрутить в автономном режиме и завладеть паролем учетки в открытом виде. Если коротко, то в этом и заключается вся суть описанной атаки. В рамках MITRE ATT&CK Kerberoasting она относится к Для просмотра ссылки Войдиили Зарегистрируйся.
или Зарегистрируйся, скачиваем архив, распаковываем его и видим, что нам предоставлены prefetch-файлы машины жертвы, журналы событий рабочей станции и контроллера домена.
Начнем поиск иголки в стоге сена с просмотра событий с кодом 4769 в журнале безопасности на контроллере домена. Этот код обозначает запрос билета службы Kerberos.
Даже в средней по размеру инфраструктуре Active Directory такие запросы могут происходить больше тысячи раз за пару минут, поэтому отфильтруем средство просмотра событий по ID 4769, что значительно упростит наш поиск.
Для просмотра ссылки Войдиили Зарегистрируйся
Теперь нам предстоит отсеять обычные операции AD от подозрительных. Для этого рассмотрим форму события поподробнее.
Для просмотра ссылки Войдиили Зарегистрируйся
Здесь мы видим, что учетная запись DC01$ запросила сервисный билет для сервиса, названного DC01$. В Windows имена, заканчивающиеся символом доллара ($), обычно являются учетными записями служб и машинными учетными записями. Аналогично служба DC01$ связана с этой учетной записью службы.
Все это относится к стандартным операциям AD. Ниже мы можем увидеть параметр под названием «Тип шифрования билета» со значением 0x12, что эквивалентно AES256-CTS-HMAC-SHA1-96. В легитимных случаях использования операций с билетами Kerberos тип шифрования будет 0x12 или 0x11.
Если мы увидим тип шифрования 0x17, что соответствует потоковому шифру RC4, это будет поводом глубже изучить ситуацию: злоумышленник может запросить билет с таким типом шифрования, потому что это позволит ему взломать пароль, затратив меньше усилий.
Запомним идентификаторы, которые помогут быстро отследить необходимое событие с подозрением на Kerberoasting, поэтому обращаем внимание на следующие важные моменты.
Для просмотра ссылки Войдиили Зарегистрируйся
Видно, что учетная запись домена alonzo.spire запросила билет для службы MSSQLService с типом шифрования 0x17 с компьютера, имеющего IP-адрес 172.17.79.129. Запомним эти индикаторы компрометации, поскольку дальнейший анализ будет основываться на построении таймлайна от этого события с использованием IP-адреса и имени учетной записи.
Попробуем разобраться с тем, какие действия происходили от имени учетки alonzo.spire. Для этого откроем журнал событий PowerShell. Дата и время ранее найденного нами события Kerberoasting — 2024-05-21 03:18:09 (и да, не забываем переводить время в UTC). В журнале событий PowerShell на хосте ищем подозрительную активность примерно в это же время.
Подозревая, что вредоносные действия были совершены с использованием powershell.exe, отфильтруем события по ID 4104 (в этих событиях можно будет увидеть тело выполняемого скрипта).
И действительно, находим подозрительное событие с байпасом выполнения сценария PowerShell буквально за пару минут до совершения атаки.
Для просмотра ссылки Войдиили Зарегистрируйся
Такое действие позволяет выполнять сценарии в сеансе PowerShell. Из дальнейшего анализа событий видно, что все они были частью одного сценария.
Для просмотра ссылки Войдиили Зарегистрируйся
Обнаружены доказательства зловредности сценария PowerView.ps1, который использовался для совершения действий на этапе постэксплуатации.
Пришло время проанализировать файлы предварительной загрузки. Для этого воспользуемся утилитой PECmd Эрика Циммермана. Преобразуем prefetch-файлы в .csv:
PECmd.exe -d "путь/к/папке/с/файлами/предварительной/загрузки" --csv . --csvf нашксвфайл.csv
Для более удобного анализа с помощью Timeline Explorer открываем .csv и фильтруем дату инцидента по последнему запуску.
Для просмотра ссылки Войдиили Зарегистрируйся
Сопоставив временные метки событий, находим, что в интересующий нас промежуток времени запускался RUBEUS.EXE — инструмент, используемый при пентесте и атаках на AD.
Для просмотра ссылки Войдиили Зарегистрируйся
Для привилегированных служб рассмотри возможность применять управляемые группы сервисных учетных записей (GMSA), чтобы гарантировать использование длинных, сложных паролей, которые часто меняются.
Реализация управления привилегированным доступом (PAM) также поможет ограничить воздействие привилегированных учетных данных и уменьшить поверхность атаки для Kerberoasting, одновременно обеспечивая мониторинг всех изменений разрешений для групп безопасности.
Когда система убедится, что клиент прошел авторизацию, она отправит ему ответ от сервера аутентификации (AS-REP), содержащий сеансовый ключ и пропускной билет (TGT). Этот сеансовый ключ зашифрован с помощью хеша пароля пользователя, так что только он может его расшифровать и использовать снова.
А теперь об интересном. Если пользователи в домене настроены пропускать процесс предварительной аутентификации, то злоумышленники могут отправлять запрос AS (AS-REQ) от имени этих пользователей, потому что AS-REP содержит сеансовые ключи, зашифрованные их парольными хешами. В результате злоумышленник может получить хеш пароля любого юзера в системе. Да, интересно, зачем же отключать процесс предварительной аутентификации? На деле админы иногда выключают эту функцию на время выполнения отладочных работ или тестов, а потом попросту забывают включить ее обратно.
Задачу взломщикам очень сильно упрощает утилита GetNPUsers из набора инструментов Impacket. Затем хакеры могут начать брутфорсить пароли, чтобы расшифровать сеансовый ключ. В случае успеха атакующий узнает пароль пользователя.
Специалисты по информационной безопасности часто называют этот зашифрованный сеансовый ключ хешем, но он на самом деле таковым не является. Однако такие инструменты, как Hashcat и John the Ripper, могут очень быстро подбирать пароли к подобному «хешу». AS-REP Roasting сопоставлен с Для просмотра ссылки Войдиили Зарегистрируйся в рамках MITRE ATT&CK.
или Зарегистрируйся. Выполняем стандартные процедуры: качаем архив, распаковываем его и видим, что перед нами файл журнала событий Security.evtx (если что, этот файл взят с контроллера домена).
Так же как и в предыдущей лабораторной, правильная работа с фильтрами и понимание того, на что нужно обратить внимание, поможет нам сократить время исследования и реагирования на угрозу.
Первое, что мы сразу же начинаем анализировать, — события с ID 4768. Это идентификатор события, записываемый в журналах безопасности на контроллере домена каждый раз, когда запрашивается билет проверки подлинности Kerberos.
Для просмотра ссылки Войдиили Зарегистрируйся
Рассмотрим подробнее форму одного из событий.
Для просмотра ссылки Войдиили Зарегистрируйся
Уже традиционно обращаем внимание на использование определенного типа шифрования. Если мы увидим тип шифрования 0x17, который представляет собой RC4, то это будет подсказкой — такой тип позволяет злоумышленникам быстрее расшифровать пароль.
Сокращаем количество требующих расследования событий — отбрасываем все имена служб, кроме krbtgt. Это связано с тем, что во время атаки злоумышленник получает билет аутентификации — точно так же, как это сделала бы законная учетка пользователя, а krbtgt — это стандартная служба AD, которая обрабатывает поток аутентификации в Active Directory.
Показателем того, что хакер успешно провел атаку AS-REP (неважно, удалось ему взломать хеш или нет), служит значение типа предварительной проверки подлинности в результирующих журналах.
Передовой способ поиска угроз для этой атаки — просто найти тип предварительной аутентификации = 0, означающей, что она отключена. Таким образом мы уберем большую часть бесполезных событий в журналах, оставив для анализа более детальные результаты.
Давай еще раз перечислим все необходимое для успешного детекта. Изначально мы отслеживаем все события 4768, но берем во внимание те, где:
Для просмотра ссылки Войдиили Зарегистрируйся
Становится ясно, что юзер arthur.kyle был скомпрометирован, однако существует еще одна взломанная учетка, от лица которой выполнялась атака.
У нас есть IP-адрес машины, с которой поступил запрос, поэтому будем искать события билетов службы Kerberos, так как каждая учетная запись пользователя домена запрашивает их либо во время входа в систему (при аутентификации), либо при обычном использовании домена.
Отфильтруем журнал по ID 4769 (запрос билета службы Kerberos) и рассмотрим события, происходившие во время вредоносной активности.
Через минуту после обнаруженного AS-REP Roasting происходит событие с учетки happy.grunwald с того же IP-адреса 172.17.79.129.
Для просмотра ссылки Войдиили Зарегистрируйся
Казалось бы, это обычный ивент и здесь нет ничего подозрительного. Но, учитывая, что вход в систему под юзером happy.grunwald выполнялся во время атаки AS-REP Roasting и исходил с той же машины, можно предположить, что и эта учетка была скомпрометирована. Этот факт однозначно расширяет масштаб всего инцидента.
К сожалению, лабораторная работа не предоставляет нам дополнительные артефакты, поэтому никак не удастся расследовать эту кибератаку полностью.
Чтобы предотвратить атаки AS-REP Roasting, крайне важно убедиться, что предварительная аутентификация включена для каждой учетной записи.
LLMNR позволяет разрешать как адреса IPv4, так и IPv6 без необходимости наличия DNS-сервера в локальной сети. Если запрос к DNS-серверу не выполняется (например, если DNS-сервер недоступен), отправляется LLMNR-запрос по локальной сети.
Суть в том, что LLMNR не требует аутентификации, поэтому любой компьютер в локалке может выполнить запрос LLMNR. Если кто‑то прослушивает локальную сеть, он может отвечать на эти запросы, представляя устройство своим IP-адресом и перенаправляя трафик. Все это может привести к потенциально опасному поведению и атакам, таким как LLMNR Poisoning.
Если в сети происходит событие LLMNR и злоумышленник его прослушивает, то он может получить конфиденциальную информацию о жертве, такую как IP-адрес, имя пользователя и хеш пароля. Затем хакеры могут попытаться взломать полученный хеш и получить пароль в открытом виде либо передать этот хеш для аутентификации в определенной службе. LLMNR/NBT-NS Poisoning и SMB Relay сопоставлены с Для просмотра ссылки Войдиили Зарегистрируйся в MITRE ATT&CK.
или Зарегистрируйся сразу спойлерит, что мы будем иметь дело с LLMNR-отравлением. Для работы нам предоставляют файл с дампом трафика.
Открываем .pcap и фильтруем его по LLMNR-трафику, чтобы увидеть, какие хосты участвовали во взаимодействиях, а также отметить используемые IP-адреса.
В самом начале отфильтрованного трафика видно, что хост 172.17.79.136 выполнил DNS-запрос DCC01, а другой хост 172.17.79.135 ответил на этот запрос.
Для просмотра ссылки Войдиили Зарегистрируйся
Представим (а позже и докажем), что запрос DCC01 — опечатка в обращении к DC01, это могло привести к сбою в работе DNS-сервера и использованию протокола LLMNR, запрос которого перехватил злоумышленник.
Следует убедиться в том, что 172.17.79.135 — IP-адрес злоумышленника. Для этого проверим DHCP-трафик с соответствующим фильтром dhcp. Находим DHCP-запрос между подозреваемым IP и DHCP-сервером. Мы видим имя хоста машины, которая арендовала IP-адрес 172.17.79.135.
Для просмотра ссылки Войдиили Зарегистрируйся
Докажем кражу учетных данных, проанализировав SMB-трафик с фильтром smb2.
Для просмотра ссылки Войдиили Зарегистрируйся
Здесь мы видим несколько NTLM-аутентификаций юзера john.deacon, идущих друг за другом за короткий промежуток времени. Посмотрим, какие имена у взаимодействующих хостов.
Перейди в раздел «Просмотр → Разрешение имен» и включи «Разрешение сетевых адресов». Теперь будут отображаться имена хостов.
Для просмотра ссылки Войдиили Зарегистрируйся
Мы помним, что DCC01 не реальный хост. Имя хоста Kali в сети интерпретировалось в SMB-трафике, поэтому компьютер жертвы Wkstn002, чьи данные были украдены, думает, что машина Kali — это хост DCC01.
Посмотрим, к какому файловому ресурсу пыталась обратиться жертва, так и не осознав того, к чему привела ее опечатка.
Для просмотра ссылки Войдиили Зарегистрируйся
Давай рассмотрим процесс получения пароля из скомпрометированного хеша.
Внимательно изучим трафик с фильтром ntlmssp и поймем, что здесь присутствует NTLM Relay. Аутентификация NTLM выполняется взаимодействием из трех пакетов:
или Зарегистрируйся
У хеша NTLMv2 есть определенная форма, которая выглядит так:
Заполним ее данными из пакетов аутентификации:
или ЗарегистрируйсяДля просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся
Подставляем найденное в форму и получаем:
Остается только сбрутить полученный хеш, используя Hashcat или John the Ripper, и узнать пароль от учетной записи.
Но если по каким‑то причинам твоя организация не может отключить LLMNR/NBT-NS, рассмотри возможность использования систем сетевого контроля доступа (NAC) и установки сложных паролей для минимизации риска их взлома.
Почему стоит уделить особое внимание именно атакам на Active Directory?
Инфраструктура многих компаний построена на основе службы каталогов Active Directory. Даже с учетом того, что сеть может содержать небольшое количество хостов, серверов, сервисов и служб, за достаточно короткий промежуток времени в системе происходят тысячи событий, из‑за чего становится затруднительно анализировать компьютерные инциденты.Помимо этого, в интернете можно найти множество материалов по реализации как простых, так и продвинутых атак на AD. Поэтому любой скрипт‑кидди, вооружившись парой утилит, может рискнуть и попробовать свои силы в хакинге, что уж говорить про серьезных киберпреступников.
Все это способствует тому, что ребятам из блю‑тима важно обладать знаниями в сфере безопасности инфраструктуры и уметь быстро реагировать на подобные инциденты, а также находить ошибки в конфигурации AD.
1. Kerberoasting
Перед тем как мы приступим к разбору первой лабораторной работы, начнем с небольшого экскурса в теорию, чтобы знать врага в лицо.Протокол Kerberos в Active Directory используется для аутентификации пользователей и предоставления доступа к службам. Когда пользователь пытается получить доступ к ресурсу, который управляется именем субъекта‑службы (SPN), при использовании Kerberos контроллер домена создает сервисный билет (ST) и шифрует его с использованием хеша пароля SPN. После этого веб‑сервер расшифровывает и подтверждает подлинность ST.
Однако, если запрос на получение сервисного билета исходит от самого контроллера домена, проверка того, имеет ли пользователь необходимые права для доступа к предоставляемым SPN ресурсам, не выполняется.
Теперь о самом интересном: злоумышленники, зная конкретную службу (или SPN), которую они намерены атаковать, могут отправить запрос на ST с контроллера домена и получить обратно ST, зашифрованный хешем пароля соответствующего SPN.
Часто для проведения атаки Kerberoasting используют утилиту GetUserSPNs из комплекта достаточно мощного инструмента аудита Impacket. Таким образом, злоумышленник получает хеш SPN, который он может пробрутить в автономном режиме и завладеть паролем учетки в открытом виде. Если коротко, то в этом и заключается вся суть описанной атаки. В рамках MITRE ATT&CK Kerberoasting она относится к Для просмотра ссылки Войди
Campfire-1
Итак, читаем описание лабораторной работы Для просмотра ссылки ВойдиНачнем поиск иголки в стоге сена с просмотра событий с кодом 4769 в журнале безопасности на контроллере домена. Этот код обозначает запрос билета службы Kerberos.
Даже в средней по размеру инфраструктуре Active Directory такие запросы могут происходить больше тысячи раз за пару минут, поэтому отфильтруем средство просмотра событий по ID 4769, что значительно упростит наш поиск.
Для просмотра ссылки Войди
Теперь нам предстоит отсеять обычные операции AD от подозрительных. Для этого рассмотрим форму события поподробнее.
Для просмотра ссылки Войди
Здесь мы видим, что учетная запись DC01$ запросила сервисный билет для сервиса, названного DC01$. В Windows имена, заканчивающиеся символом доллара ($), обычно являются учетными записями служб и машинными учетными записями. Аналогично служба DC01$ связана с этой учетной записью службы.
Все это относится к стандартным операциям AD. Ниже мы можем увидеть параметр под названием «Тип шифрования билета» со значением 0x12, что эквивалентно AES256-CTS-HMAC-SHA1-96. В легитимных случаях использования операций с билетами Kerberos тип шифрования будет 0x12 или 0x11.
Если мы увидим тип шифрования 0x17, что соответствует потоковому шифру RC4, это будет поводом глубже изучить ситуацию: злоумышленник может запросить билет с таким типом шифрования, потому что это позволит ему взломать пароль, затратив меньше усилий.
info
Все основные инструменты с открытым исходным кодом, такие как Impacket и Rubeus, запрашивают билеты с типом шифрования RC4.Запомним идентификаторы, которые помогут быстро отследить необходимое событие с подозрением на Kerberoasting, поэтому обращаем внимание на следующие важные моменты.
- Учетные записи, которые не являются учетной записью службы или машины (и не заканчиваются символом $). Следовательно, под подозрением любая стандартная учетная запись домена пользователя (эта учетная запись была скомпрометирована, и с ее помощью злоумышленник совершил атаку).
- Названия служб, которые не заканчиваются символом $.
- Тип шифрования билета 0x17, что соответствует шифрованию RC4, которое позволит злоумышленникам легко взломать хеш.
Для просмотра ссылки Войди
Видно, что учетная запись домена alonzo.spire запросила билет для службы MSSQLService с типом шифрования 0x17 с компьютера, имеющего IP-адрес 172.17.79.129. Запомним эти индикаторы компрометации, поскольку дальнейший анализ будет основываться на построении таймлайна от этого события с использованием IP-адреса и имени учетной записи.
Попробуем разобраться с тем, какие действия происходили от имени учетки alonzo.spire. Для этого откроем журнал событий PowerShell. Дата и время ранее найденного нами события Kerberoasting — 2024-05-21 03:18:09 (и да, не забываем переводить время в UTC). В журнале событий PowerShell на хосте ищем подозрительную активность примерно в это же время.
Подозревая, что вредоносные действия были совершены с использованием powershell.exe, отфильтруем события по ID 4104 (в этих событиях можно будет увидеть тело выполняемого скрипта).
И действительно, находим подозрительное событие с байпасом выполнения сценария PowerShell буквально за пару минут до совершения атаки.
Для просмотра ссылки Войди
Такое действие позволяет выполнять сценарии в сеансе PowerShell. Из дальнейшего анализа событий видно, что все они были частью одного сценария.
Для просмотра ссылки Войди
Обнаружены доказательства зловредности сценария PowerView.ps1, который использовался для совершения действий на этапе постэксплуатации.
Пришло время проанализировать файлы предварительной загрузки. Для этого воспользуемся утилитой PECmd Эрика Циммермана. Преобразуем prefetch-файлы в .csv:
PECmd.exe -d "путь/к/папке/с/файлами/предварительной/загрузки" --csv . --csvf нашксвфайл.csv
Для более удобного анализа с помощью Timeline Explorer открываем .csv и фильтруем дату инцидента по последнему запуску.
Для просмотра ссылки Войди
Сопоставив временные метки событий, находим, что в интересующий нас промежуток времени запускался RUBEUS.EXE — инструмент, используемый при пентесте и атаках на AD.
Для просмотра ссылки Войди
Меры предотвращения
Чтобы предотвратить такие атаки, важно использовать длинные и сложные пароли для учетных записей служб. Это значительно замедлит взлом хешей.Для привилегированных служб рассмотри возможность применять управляемые группы сервисных учетных записей (GMSA), чтобы гарантировать использование длинных, сложных паролей, которые часто меняются.
Реализация управления привилегированным доступом (PAM) также поможет ограничить воздействие привилегированных учетных данных и уменьшить поверхность атаки для Kerberoasting, одновременно обеспечивая мониторинг всех изменений разрешений для групп безопасности.
2. AS-REP Roasting
А теперь еще немного теории, чтобы понять, что это за зверь такой — AS-REP Roasting. Запрос сервера аутентификации (AS-REQ) обычно называют предварительной аутентификацией Kerberos. Первое, что происходит во время аутентификации внутри Kerberos, — это запрос аутентификации к контроллеру домена, чтобы можно было проверить юзера, пытающегося пройти аутентификацию.Когда система убедится, что клиент прошел авторизацию, она отправит ему ответ от сервера аутентификации (AS-REP), содержащий сеансовый ключ и пропускной билет (TGT). Этот сеансовый ключ зашифрован с помощью хеша пароля пользователя, так что только он может его расшифровать и использовать снова.
А теперь об интересном. Если пользователи в домене настроены пропускать процесс предварительной аутентификации, то злоумышленники могут отправлять запрос AS (AS-REQ) от имени этих пользователей, потому что AS-REP содержит сеансовые ключи, зашифрованные их парольными хешами. В результате злоумышленник может получить хеш пароля любого юзера в системе. Да, интересно, зачем же отключать процесс предварительной аутентификации? На деле админы иногда выключают эту функцию на время выполнения отладочных работ или тестов, а потом попросту забывают включить ее обратно.
Задачу взломщикам очень сильно упрощает утилита GetNPUsers из набора инструментов Impacket. Затем хакеры могут начать брутфорсить пароли, чтобы расшифровать сеансовый ключ. В случае успеха атакующий узнает пароль пользователя.
Специалисты по информационной безопасности часто называют этот зашифрованный сеансовый ключ хешем, но он на самом деле таковым не является. Однако такие инструменты, как Hashcat и John the Ripper, могут очень быстро подбирать пароли к подобному «хешу». AS-REP Roasting сопоставлен с Для просмотра ссылки Войди
Campfire-2
Пойдем разбираться с тем, как же это все детектить, на примере лабораторной работы Для просмотра ссылки ВойдиТак же как и в предыдущей лабораторной, правильная работа с фильтрами и понимание того, на что нужно обратить внимание, поможет нам сократить время исследования и реагирования на угрозу.
Первое, что мы сразу же начинаем анализировать, — события с ID 4768. Это идентификатор события, записываемый в журналах безопасности на контроллере домена каждый раз, когда запрашивается билет проверки подлинности Kerberos.
Для просмотра ссылки Войди
Рассмотрим подробнее форму одного из событий.
Для просмотра ссылки Войди
- Имя учетной записи: учетная запись пользователя, запросившая билет проверки подлинности у контроллера домена.
- Имя службы: имя службы, обработавшей билет.
- Тип шифрования билета: отображает используемый алгоритм шифрования билета (например, AES, RC4).
- Тип предварительной проверки подлинности: код состояния показывает, была ли отключена или включена предварительная аутентификация для указанного объекта (Имя учетной записи).
Уже традиционно обращаем внимание на использование определенного типа шифрования. Если мы увидим тип шифрования 0x17, который представляет собой RC4, то это будет подсказкой — такой тип позволяет злоумышленникам быстрее расшифровать пароль.
Сокращаем количество требующих расследования событий — отбрасываем все имена служб, кроме krbtgt. Это связано с тем, что во время атаки злоумышленник получает билет аутентификации — точно так же, как это сделала бы законная учетка пользователя, а krbtgt — это стандартная служба AD, которая обрабатывает поток аутентификации в Active Directory.
Показателем того, что хакер успешно провел атаку AS-REP (неважно, удалось ему взломать хеш или нет), служит значение типа предварительной проверки подлинности в результирующих журналах.
Передовой способ поиска угроз для этой атаки — просто найти тип предварительной аутентификации = 0, означающей, что она отключена. Таким образом мы уберем большую часть бесполезных событий в журналах, оставив для анализа более детальные результаты.
Давай еще раз перечислим все необходимое для успешного детекта. Изначально мы отслеживаем все события 4768, но берем во внимание те, где:
- Тип предварительной проверки подлинности равен 0, то есть аутентификация отключена. Это важное условие, которое необходимо выполнить, поскольку без этого атака невозможна.
- Имя службы — krbtgt, поскольку только krbtgt может выполнять процессы аутентификации в AD.
- Тип шифрования билета — 0x17, соответствующий шифрованию RC4, что позволит злоумышленникам легко взломать хеш.
Для просмотра ссылки Войди
Становится ясно, что юзер arthur.kyle был скомпрометирован, однако существует еще одна взломанная учетка, от лица которой выполнялась атака.
У нас есть IP-адрес машины, с которой поступил запрос, поэтому будем искать события билетов службы Kerberos, так как каждая учетная запись пользователя домена запрашивает их либо во время входа в систему (при аутентификации), либо при обычном использовании домена.
Отфильтруем журнал по ID 4769 (запрос билета службы Kerberos) и рассмотрим события, происходившие во время вредоносной активности.
Через минуту после обнаруженного AS-REP Roasting происходит событие с учетки happy.grunwald с того же IP-адреса 172.17.79.129.
Для просмотра ссылки Войди
Казалось бы, это обычный ивент и здесь нет ничего подозрительного. Но, учитывая, что вход в систему под юзером happy.grunwald выполнялся во время атаки AS-REP Roasting и исходил с той же машины, можно предположить, что и эта учетка была скомпрометирована. Этот факт однозначно расширяет масштаб всего инцидента.
К сожалению, лабораторная работа не предоставляет нам дополнительные артефакты, поэтому никак не удастся расследовать эту кибератаку полностью.
info
Атака AS-REP Roasting возможна только при наличии списка пользователей (то есть если ты получил его из нулевого сеанса SMB). Но если ты просто используешь инструмент вроде GetNPUsers.py или Rubeus, тебе потребуется активная учетная запись пользователя для запроса списка юзеров (все это происходит в фоновом режиме при запуске атаки). Это означает, что атака может быть выполнена без какой‑либо аутентификации, если злоумышленник каким‑либо образом заполучил список пользователей (к примеру, перебором учеток с помощью Kerbrute).Меры предотвращения
Всегда внедряй надежную политику паролей с использованием сложных паролей, которые регулярно меняются. Если есть возможность, то повысь безопасность, включив 2FA для аутентифицированных сервисов.Чтобы предотвратить атаки AS-REP Roasting, крайне важно убедиться, что предварительная аутентификация включена для каждой учетной записи.
3. LLMNR Poisoning
Раньше в сетях Windows использовался протокол Network Basic Input/Output System (NetBIOS) для выполнения операций через сеть. Важной частью этого протокола был NetBIOS Name Service (NBT-NS), отвечавший за регистрацию и разрешение имен. LLMNR (Link-Local Multicast Name Resolution) — это прямой преемник NBT-NS. Он выполняет ту же функцию, что и его предшественник, — разрешение имен хостов в той же локальной сети.LLMNR позволяет разрешать как адреса IPv4, так и IPv6 без необходимости наличия DNS-сервера в локальной сети. Если запрос к DNS-серверу не выполняется (например, если DNS-сервер недоступен), отправляется LLMNR-запрос по локальной сети.
Суть в том, что LLMNR не требует аутентификации, поэтому любой компьютер в локалке может выполнить запрос LLMNR. Если кто‑то прослушивает локальную сеть, он может отвечать на эти запросы, представляя устройство своим IP-адресом и перенаправляя трафик. Все это может привести к потенциально опасному поведению и атакам, таким как LLMNR Poisoning.
info
Responder — популярный инструмент, входящий в пакет утилит Kali Linux, для проведения атак с отравлением LLMNR.Если в сети происходит событие LLMNR и злоумышленник его прослушивает, то он может получить конфиденциальную информацию о жертве, такую как IP-адрес, имя пользователя и хеш пароля. Затем хакеры могут попытаться взломать полученный хеш и получить пароль в открытом виде либо передать этот хеш для аутентификации в определенной службе. LLMNR/NBT-NS Poisoning и SMB Relay сопоставлены с Для просмотра ссылки Войди
Noxious
Описание лабораторной работы Для просмотра ссылки ВойдиОткрываем .pcap и фильтруем его по LLMNR-трафику, чтобы увидеть, какие хосты участвовали во взаимодействиях, а также отметить используемые IP-адреса.
info
LLMNR по умолчанию работает на порте UDP 5355. Поэтому фильтр будет выглядеть так: udp.port == 5355.В самом начале отфильтрованного трафика видно, что хост 172.17.79.136 выполнил DNS-запрос DCC01, а другой хост 172.17.79.135 ответил на этот запрос.
Для просмотра ссылки Войди
Представим (а позже и докажем), что запрос DCC01 — опечатка в обращении к DC01, это могло привести к сбою в работе DNS-сервера и использованию протокола LLMNR, запрос которого перехватил злоумышленник.
Следует убедиться в том, что 172.17.79.135 — IP-адрес злоумышленника. Для этого проверим DHCP-трафик с соответствующим фильтром dhcp. Находим DHCP-запрос между подозреваемым IP и DHCP-сервером. Мы видим имя хоста машины, которая арендовала IP-адрес 172.17.79.135.
Для просмотра ссылки Войди
Докажем кражу учетных данных, проанализировав SMB-трафик с фильтром smb2.
Для просмотра ссылки Войди
Здесь мы видим несколько NTLM-аутентификаций юзера john.deacon, идущих друг за другом за короткий промежуток времени. Посмотрим, какие имена у взаимодействующих хостов.
Перейди в раздел «Просмотр → Разрешение имен» и включи «Разрешение сетевых адресов». Теперь будут отображаться имена хостов.
Для просмотра ссылки Войди
Мы помним, что DCC01 не реальный хост. Имя хоста Kali в сети интерпретировалось в SMB-трафике, поэтому компьютер жертвы Wkstn002, чьи данные были украдены, думает, что машина Kali — это хост DCC01.
Посмотрим, к какому файловому ресурсу пыталась обратиться жертва, так и не осознав того, к чему привела ее опечатка.
Для просмотра ссылки Войди
Давай рассмотрим процесс получения пароля из скомпрометированного хеша.
Внимательно изучим трафик с фильтром ntlmssp и поймем, что здесь присутствует NTLM Relay. Аутентификация NTLM выполняется взаимодействием из трех пакетов:
- NTLMSSP_NEGOTIATE;
- NTLMSSP_CHALLENGE;
- NTLMSSP_AUTH.
У хеша NTLMv2 есть определенная форма, которая выглядит так:
User::Domain:ServerChallenge:NTProofStr:NTLMv2ResponseЗаполним ее данными из пакетов аутентификации:
- User и Domain можно получить из пакета NTLMSSP_NEGOTIATE;
- ServerChallenge найдем в пакете NTLMSSP_CHALLENGE;
- NtProofStr находится в пакете NTLMSSP_AUTH;
- NTLMv2Response содержит в начале тот же NtProofStr, поэтому убираем из него первые 16 байт (32 символа), а его значение берем из того же пакета NTLMSSP_AUTH.
Подставляем найденное в форму и получаем:
Код:
john.deacon::FORELA:601019d191f054f1:
c0cc803a6d9fb5a9082253a04dbd4cd4:
010100000000000080e4d59406c6da01cc3dcfc0de9b5f2600000000020008004e
0042004600590001001e00570049004e002d00360036004100530035004c003100
470052005700540004003400570049004e002d00360036004100530035004c0031
0047005200570054002e004e004200460059002e004c004f00430041004c000300
14004e004200460059002e004c004f00430041004c00050014004e004200460059
002e004c004f00430041004c000700080080e4d59406c6da010600040002000000
0800300030000000000000000000000000200000eb2ecbc5200a40b89ad5831abf
821f4f20a2c7f352283a35600377e1f294f1c90a00100000000000000000000000
0000000000000900140063006900660073002f0044004300430030003100000000
0000000000Остается только сбрутить полученный хеш, используя Hashcat или John the Ripper, и узнать пароль от учетной записи.
Меры предотвращения
Если использование LLMNR/NBT-NS не требуется в твоей среде, лучше всего полностью отключить эти протоколы в целях безопасности.Но если по каким‑то причинам твоя организация не может отключить LLMNR/NBT-NS, рассмотри возможность использования систем сетевого контроля доступа (NAC) и установки сложных паролей для минимизации риска их взлома.