---
# System prepended metadata

title: Windows системы занятие №3 AAA в Windows

---

# Windows системы занятие №3 AAA в Windows
AAA- это:
1. Аутентификация(Authentication)
2. Авторизация(Avtorization)
3. Отчетность(Accounting)

## Права безопасности объектов в домене
Один из важных параметров безопасности - **object SID**. Относительно него обеспечивается доступ и проверка объекта на возможность взаимосвязи с другими объектами.
![](https://i.imgur.com/9SGTfO9.png)

## Модель ААА
Она предполагает, что сначала пройдет идентификация объекта. То есть проверится, что такое имя вообще существует в базе данных сервера.
После этого идет процесс аутентификации- это проверка учетных данных и подлинности объекта
Авторизация - подтверждение подлинности субъекта безопасности.
Отчетность - позволяет вести журналы аутентификации и авторизации
![](https://i.imgur.com/8T7abWd.png)
## Winlogon
Это системный процесс, который выполняет процедуры входа и выхода на компьютере Windows. 
Рассмотрим, как работает **локальная аутентификация**:
Когда мы ввели пароль, наши учетные данные отправились в процесс **lsass.exe**. Он обрабатывает учетные данные, преобразует пароли в хэш, сравнивает их с учетными данными из базы и подтверждает вход пользователя.
Как процесс поймет, что наши учетные данные валидны? Он обратиться к локальной базе учетных данных SAM, отправит туда username нашего пользователя и достанет хэш-пароль. После этого он сравнит хэш-пароль из базы данных и хэш от пароля, который предоставил пользователь. Если все хорошо, то учетные данные будут закэшированы в хранилище LSA. Кэширование нужно для того, чтобы при обращении к каким-то процессам компьютера не приходилось все время вводить свои учетные данные.
![](https://i.imgur.com/u8zTY77.png)

## Lan Manager
Это протокол, позволяющий аутентифицироваться на различных ресурсах. На данный момент он устарел и не используется, но в современных системах он поддерживается для совместимости со старыми системами.
Минусы - максимальная длина - 14 символов, так же преобразовывается в хэш, но его легко взломать. Еще один недостаток - он регистронезависимый(сначала все переводит в верхний регистр, и лишь потом хэширует). 
На смену этому протоколу пришел NT Lan Manager (NTLM)
## NT Lan Manager
Преимущества перед Lan Manager:
* Формируется по алгоритму MD4
* Пароль может быть длиной до 128 символов
* Пароль регистрозависимый
* Может содежать как ASCII-символы, так и Unicode

Рассмотрим, как он работает. 
Для того, чтобы обратиться к какому-то ресурсу, необходимо отправить имя пользователя. Это нужно для того, чтобы ресурс увидел, а есть ли вообще такой пользователь в его базе данных или нет(рассматриваем случай, когда такой ресурс не является доменом)
Если сервер нашел в своей базе данных пользователя с указанным именем пользователя, он отправляет в ответ специальный запрос. Это случайно сгенерированное число. 
Мы шифруем с помощью этого пароля наш хэш-пароль и отправляем на сервер
Сервер проделывает то же самое, доставая хэш пароля из своей базы данных, и если строки совпали, то мы аутентифицировались в системе.
![](https://i.imgur.com/CGcjYP9.png)

На данный момент этот протокол так же не актуален, так как MD4 уже не новый алгоритм, и он поддается брутфорсу.
Более того, он подвергается ряду атак. Например - атака, связанная с временным накоплением данных. Если злоумышленник долго будет просматривать трафик, то у него получится примерно восстановить строчку хэша. 

Данный протокол- это уже сетевая аутентификация и для того, чтобы она корректно работала, предусмотрена служба Netlogon

## Netlogon
Эта служба позволяет безопасно идентифицироваться на сетевых ресурсах. Она работает автоматически. Кроме того, она будет проверять, есть ли у нас доступ к каким-то ресурсам на основе SID.
Она работает в рамках нашего доменного взаимодействия. Рассмотрим, как будет работать тот же NTLM в таком случае:
1. Первые шаги аналогичны - отправляем имя пользователя, получаем запрос сервера, шифруем с помощью него хэш нашего пароля и отправляем на сервер
1. Далее наш сервер пересылает на домен-контроллер наш ответ и свой запрос.
1. После этого уже домен-контроллер, достав из базы данных наши учетные данные и взяв запрос сервера, зашифрует это и сравнит это с нашим ответом. Если все хорошо, то домен-контроллер отправит в ответ, что аутентификация прошла успешна. 
![](https://i.imgur.com/5dNLLnx.png)

## NTLMv2
Перейдем к более новому протоколу. Его отличия от предыдущего:
* Использует MD5
* Добавлена метка времени

Принцип работы:
1. Работает он аналогично NTLM, но теперь мы отправляем в сторону сервера метку времени. Берем метку времени и объеденяем с запросом сервера.
1. Берем от этой суммы хэш (в windows это называется HMAC-MD5)
1. После этого, мы хэшируем наш хэш с помощью специального ключа.
1. Сервер аналогично пересылает эти данные в домен, которые он так же должен сверить. Только на этот раз на сервер посылается ответ и уже захэшированная строчка из запроса сервера и запроса клиента. Остальные действия аналогичны

 ![](https://i.imgur.com/nyQXWz2.png)
 
 Этот протокол так же имеет свои уязвимости, и не всегда рекомендуется использовать его как единственный протокол аутентификации в домене. Для решения проблем этого протокола существует протокол Kerberos. Одна из проблем, которую данный протокол решает, это подтверждение обоих сторон. Ведь в данном протоколе ничто не мешает злоумышленнику провести spoofing атаку для сервера и представиться для клиента сервером, подменив его IP адрес и выведя оригинальный сервер  из строя с помощью, к примеру, DDoS-атаки.

## Kerberos

Протокол, обеспечивающий надежную аутентификацию пользователей.
Особенности:
* Основан на билетах(по умолчанию он действует 8 часов)
* Работает в формате двух пользователей и третьей доверенной стороны
* Предусматривает, что обмен информации происходит в незащищенной среде, а передаваемые пакеты могут быть перехвачены и модифицированы

**Key-distribution center** - служба в контроллере домена, позволяющая проводить такого рода аутентификацию.

Этапы работы протокола Kerberos:
1. **Получение TGT** - tiket granting ticket - это билет для получения билетов. Это наша аутентификация на ресурсе домена и подверждение что мы - это мы.
Отправляем на домен-контроллер наш username для подтверждения аутентификации. В данной реализации наш домен-контроллер являеся key distribution center. Он распространяет те самые билеты по нашему домену.
Когда мы отправили имя, домен-контроллер достал из базы данных NTDS хэш нашей учетной записи и хэш KKDC - **Key of Key Dictribution Center(или хэш KDC)**. На втором занятии мы смотрели учетную запись krbtgt. У нее есть кэш, который используется как раз для аутентификации Kerberos.
![](https://i.imgur.com/rOUnYc0.png)

2. После этого, домен начинает формировать сессию для работы с нашим комьютером. Первое что он создает - это ключ, с помощью которого будут шифроваться данные от сервера к клиенту и от клиента к серверу. Далее такой ключ шифруется с помощью хэша учетной записи.
3. Когда домен-контроллер получит наши данные, он присылает нам TGT. Разберем, что находится внутри TGT. Там есть три параметра:
    * Ключ общения с нашим компьютером. Они уникальны для каждой сессии с другим компьютером. Сам TGT шифровать нет смысла, так как без владения KKDC злоумышленник не сможет расшифровать данные внутри.
    * Имя пользователя
    * Время выдачи билета чтобы понимать, что билет уже не действителен

Теперь рассмотрим такую ситуацию:
**Получение Service Key c помощью TGS**. Итак, на нашем компьютере уже есть TGT и DSK(ключ сессии с компьютером). Мы себя идентифицировали, теперь мы должны обратиться к контроллеру домена чтобы, к примеру, обратиться к файловому хранилищу FS1.
**1 Этап**. Отправляем в сторону контроллера домена TGT а так же зашифрованные данные о том, к кому мы обращаемся и время, в которое мы обращаемся. Когда сервер получит эту информацию, он сформирует билет на получение доступа к данному сервису. 
**2 Этап.** Формирование TGS - он состоит из имени пользователя, который обратился к серверу, имени ресурса, времени создания билета, срока жизни билета и service key(ключ сесии)
**3 Этап**. Формирование тикета для FS1. Это надо для того, чтобы решить проблему взаимного шифрования. Для этого берется сам билет, шифруется с помощью машинной учетной записи fs1 и отправляется на pc1. В результате у нас на компьютере два ключика - один для fs1, а другой для самой Windows. Вся эта последовательность шифруется с помощью ключа общения с доменом.
**4 Этап.** Windows предоставляет полученную информацию серверу FS1. Свой билет он шифрует с помощью Service Key, отправляя дополнительно уже зашифрованный TGS key. Теперь наше соединение установлено. Более того, теперь наше соединение будет зашифровано с помощью Service key. Именно такая система позволяет общаться между устройствами, не позволяя злоумышленнику что-либо сделать
![](https://i.imgur.com/gY1TG74.png)

:::danger
Если время между сервером и машиной отличается более чем на 5 минут, аутентификация переходит на старые протоколы, тем самым снижая защиту.
:::

## Типы входа Windows
**logon type** - этот параметр в журнале событий отвечает за то, как была вызвана учетная запись.
![](https://i.imgur.com/pWYJoqQ.png)

![](https://i.imgur.com/arB5MZW.png)

По умолчанию данные кэшируются до 10 раз.

## Mimikatz
Mimikatz — это приложение с открытым исходным кодом, которое позволяет пользователям просматривать и сохранять учетные данные аутентификации, такие как тикеты Kerberos.

## Практика - анализ процесса lsas.exe
1. Открываем архив с приложениями SysinternalsSuite и запускаем PsExec64.
2. Открываем консоль от имени администратора, переходим в папку с программой выше
3. Запускае программу командой: ``PsExec64.exe -i -s regedit.exe``. У нас должен запуститься реестр.
4. Запускаем диспетчер задач от имени администратора.
5. Находим процесс lsass и пытаемся его сдампить. Будет создан файл.
6. Теперь нам необходимо передать сдампенный файл на линукс-машину. Для этого переходим в Kali и донастраиваем ее следующим образом:
    * Добавляем и конфигурируем настройки ip адреса
    * С помощью команды ``systemctl status ssh`` проверям состояние SSH соединения. По умолчанию оно выключено
    * Если протокол выключен - запускаем его комнадой 
    ``systemctl start ssh``
    ``systemctl enable ssh`` 
7. Запускаем cmd из под администраторской учетной записи в Windows
8. Находим lsasdump и передаем его через SCP в линукс с помощью команды `scp lsass.DMP root@*ip-адрес Kali-Linux*:*расположение, где должен лежать наш файл*`
9. Вводим логин/пароль, после чего наш файл начинает загружаться. После всех этих пунктов скачиваем на нашу Kali-Linux программу pypykatz из GitHub. Используем команду для скачивания этой программы: ``git clone *ссылка на github*`` и появляется pypykatz.
10. Запускаем скрипт выше с помощью команды `` python setup.py install``
11.  После установки pypykatz вводим команду pypykatz lsa minidump lsass.DMP. Опция lsa minidump позволяет проанализировать локальный файл дампа. И после этого скрипт выводит актуальную информацию этого дампа
Дамп - это слепок оперативной памяти процесса. lsas арендует для себя какие-то адреса из оперативной памяти и в них хранит свои данные. 

Что мы видим в нашем дампе?
1. Хэши NT, SHA1, DRAPI
1. SID учетной записи
2. Имя домена
3. Пароль от учетной записи самого компьютера

Что же нам дает знание логина/пароля учетной компьютерной записи?
* Через нее можно вызывать WinAPI для того, чтобы красть оттуда какие-то данные

Интересное: 
*  ``\\*название комьютера*\*название диска*$`` - так мы можем обратиться непосредственно к самому диску, но эта опция доступна только администраторам.
*  Служба lsas запускается в любой инсталяции Windows
*  Mimikatz крадет пароли не только из памяти lsas, но и из реестра.
* Перезапуск компьютера очищает дамп памяти lsas
# Итоги:
1. Увидели, что процесс lsas хранит в своей памяти определенные данные. Их оттуда можно достать и их необходимо защищать.