# **Windows_Basic-Яртыбаш_Дмитрий-Практика-6**

# *Практическая работа №6.1. Базовые атаки на инфраструктуру Windows*

**Этап 1. Анализ базы NTDS**
*1.1 Бэкап NTDS*
* Активируем процесс Install From Media, позволяющий сделать копию нашего NTDS с необходимыми ветками реестра. Для этого введем в командную строку необходимые команды:

*1.2 Перенос NTDS*
* С помощью SMB зайдем с машины kali на dc1 и скопируем на kali дамп базы NTDS:

*1.3 Анализ NTDS*
* Перейдем в домашнюю директорию пользователя, скачаем с гитхаба набор инструментов impacket, увидим, что у нас уже установлена актуальная версия pip, перейдем в директорию impacket и установим его:

* Увидим сообщение об успешной установке impacket:

* Для анализа дампа базы NTDS применим команду:

**Этап 2. Path-the-hash**
*2.1 Crackmapexec*
* Воспользуемся функционалом Crackmapexec. Просканируем сеть:

* Затем выполним команду whoami на удаленной машине:

* Просмотрим список сетевых папок, доступных администратору:

* С помощью утилиты smbexec получим доступ к командной строке windows на удаленной машине. SMB сессия прерывается, но с третьей попытки у нас получается исполнить команду:

* Видим, что в нашем случае psexec работает гораздо стабильнее и исполняет команды быстрее. Это может быть связано с тем, что psexec создает на удаленной машине windows-службу, которая с помощью исполнения бинарного файла открывает RPC-подключение:

*2.2 XFreeRDP*
* Для подсключения по RDP дадим доступ на удаленное подключение администраторам домена:

* Попробуем зайти с kali на dc1:

* Kali говорит нам что подключение запрещено адмнистративными инструментами сервера:

* Чтобы отключить политику restricted admin, изменим на dc1 параметр реестра с помощью PoSH:

* В журнале аудита Powershell найдем событие, отражающее исполнение этой команды:

* Теперь мы можем получить доступ к рабочему dc1:

**Этап 3. Атаки на базовые протоколы Windows**
**NBT-NS & LLMNR & mDNS**

*Анализ инфраструктуры через responder*

* Запускаем Responder, который начинает отслеживать события:

* На dc1 пытаемся получить доступ к сетевому ресурсу с некорректным именем \\pt-file. Responder притворяется сетевым ресурсом и просит нас авторизоваться:

* В выводе респондера появляется перехваченный аутентификацонный токен, который можно в дальнейшем брутфорсить:

*mitm6*

* Просмотрим конфигурацию сети на Win10 перед атакой. Видим, что указано 2 DNS-сервера:

* Устанавливаем mitm6 и запускаем атаку:

* Видим, что в конфиге Win10 добавился неизвестный DNS-сервер:

* Не прерывая атаку mitm, с помощью скрипта создаем свой SMB-сервер:

* Пытаемся получить доступ к сетевым ресурсам домена:

* Видим перехваченные аутентификационные данные:

---

# *Практическая работа №6.2 Компрометация доменной Windows-инфраструктуры.*

* Активируем политику аудита машинных учетных записей:

* И обновим политику через командную строку:

**Эксплуатация уязвимостей контроллера домена**

* Скачаем репозиторий с эксплоитом zerologon, прочитаем README:

* С помощью команды, указанной в README, обнулим пароль машинной учетки контроллера домена:

* С помощью пакета утилит impacket, а конкретнее - secretsdump, сдампим базу NTDS контроллера домена:

* С помощью полученных хешей учетных данных выполним тестовую команду на удаленной машине:

**Поиск следов эксплуатации уязвимостей**

* В журнале System видим появление ошибки Netlogon:

* В журнале Security видим событие 4742 "Изменения машинной учетной записи":

* Проанализируем его. Нас настораживает ANONYMOUS LOGON и дата/время в поле Password Last Set - пароль УЗ был изменен:

* Пароль на машинной учетной записи может менять только служба NETWORK SERVICE при плановом обновлении паролей. Когда это происходит, в журнале System появляется событие 5823. Найдем это событие через фильтр:

* Видим что последнее такое событие было сгенерировано намного раньше при плановой смене пароля. Для того, чтобы подтвердить, что это было плановое событие, найдем событие 4742 за тот же день, что и событие 5823:

* Также увидим, что в журнале событий Directory Service появилось события дампа NTDS: