D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Автор student / мой_телеграмм_канал
Источник: https://xss.is
Привет! Вот и продолжение. Если вы не читали прошлые части, то рекомендую ознакомиться 1 часть 2 часть
Занятие 3. ААА в Windows
AAA (Authentication, Authorization, Accounting)
Winlogon - это системный процесс, который выполняет процедуры входа и выхода на компьютере Windows.
Вот его функции.
Схема локальной аутентификации.
1 User (Пользователь) вводит свое имя пользователя и пароль на своем компьютере.
2 Client (Клиент) --username, challenge--> Server (Сервер), передает имя пользователя и challenge-сообщение на сервер.
3 Server (Сервер) --username, challenge--> Domain Controller (Контроллер Домена), передаёт имя пользователя и challenge-сообщение на контроллер домена.
4 Domain Controller (Контроллер домена) --username--> NTDS.dit, обращается к базе данных NTDS.dit для получения хешированного пароля пользователя.
5 Domain Controller (Контроллер домена) расшифровывает challenge-сообщение с использованием хешированного пароля из NTDS.dit.
6 Domain Controller (Контроллер домена) --authentication result--> Server (Сервер), передает результат аутентификации обратно на сервер.
7 Server (Сервер) --access granted--> Client (Клиент), предоставляет клиенту доступ к ресурсам при успешной аутентификации.
Давайте представим, что у вас пользователь с именем Alice, и она хочет получить доступ к серверу, чтобы извлечь некоторые данные. Вот гипотетический пример:
1 Alice (Пользователь) вводит свое имя пользователя ('Alice') и пароль ('password') на своем компьютере.
2 Клиентский компьютер (Client) генерирует случайное число (допустим, '12345') и шифрует его с помощью пароля Alice. Это зашифрованное значение ('encrypted') и имя пользователя ('Alice') отправляются на сервер.
3 Сервер (Server) получает зашифрованное значение ('encrypted') и имя пользователя ('Alice') и отправляет их на Контроллер домена.
4 Контроллер домена (Domain Controller) обращается к базе данных NTDS.dit и ищет запись для пользователя Alice. Он находит зашифрованный пароль, связанный с Alice ('hashedPassword').
5 Контроллер домена (Domain Controller) затем использует 'hashedPassword' для расшифровки 'encrypted' значения. Если одно битовое значение эквивалентно другому, что подтверждает, что пароль Alice верен, Контроллер домена передает
это подтверждение обратно на сервер.
6 Сервер (Server) получает подтверждение, что пароль Alice верен. Он передает это подтверждение обратно на компьютер Alice.
7 Alice теперь аутентифицирована и может получить доступ к запрашиваемым данным на сервере.
Здесь важно понимать, что зашифрованное значение и зашифрованный пароль представляют собой грубое упрощение того, как происходит процесс шифрования. В реальности используются более сложные техники для генерации этих значений и
обеспечения безопасности данных пользователя.
В целом, NTLMv2 представляет собой усовершенствованную версию NTLM, которая обеспечивает большую безопасность и гибкость. Однако стоит отметить, что оба протокола считаются устаревшими, и рекомендуется использовать более современные протоколы аутентификации, такие как Kerberos.
Kerberos - это протокол основанный на билетах, обеспечивающий надежную аутентификацию пользователей. Работает в формате двух пользователей и третьей доверенной стороны.
Основные термины, которые будут использоваться в схемах, чтобы было понятно
1. Клиент (Client) - Это пользователь или служба, которые запрашивают доступ к ресурсу или услуге в сети.
2. Сервер (Server) - Это узел в сети, который предоставляет ресурсы или услуги (например, файлы, печать, приложения) клиенту.
3. Выдавший билет TGS (Ticket Granting Server) - Сервер, который выдает временные билеты клиенту после успешной аутентификации при запросе билета TGT.
4. Билет (Ticket) - Зашифрованная информация, содержащая данные аутентификации, как правило, выдаваемая KDC или TGS для подтверждения аутентификации и авторизации при обращении к серверу.
5. TGT (Ticket Granting Ticket) - Билет, который выдается клиенту KDC после успешной аутентификации и который используется для получения билетов доступа к другим службам.
6. Ключ (Key) - Секретное значение, используемое для шифрования и дешифрования данных.
7. KDC (Key Distribution Center) - Центр распределения ключей, который выполняет функции аутентификации и выдачи билетов в Kerberos.
8. Kerberos - Протокол аутентификации в компьютерных сетях, обеспечивающий безопасность передачи данных между клиентом и сервером.
9. Сеансовый ключ (Session Key) - Ключ, используемый для защиты данных, передаваемых между клиентом и сервером в рамках одной сессии.
10. Аутентификация (Authentication) - Процесс проверки и подтверждения подлинности личности пользователя или службы в сети.
Надоелоп*здить заимствовать чужие схемы, поэтому буду рисовать свои
этап 1
этап 2
этап 3
этап 4
этап 5
этап 6
этап 7
этап 8
этап 9
этап 10
Logon Types
В Windows существует несколько типов входа (logon types), которые указывают на способ, которым пользователь аутентифицируется на системе. Ниже перечислены основные типы входа в Windows:
1. Logon Type 2 (Interactive): Пользователь входит в систему интерактивно через консоль или удаленный рабочий стол.
2. Logon Type 3 (Network): Пользователь входит в систему через сетевое соединение, например, при обращении к ресурсам файловой службы.
3. Logon Type 4 (Batch): Используется для задач, выполняемых планировщиком задач, как правило без визуального отображения окна входа.
4. Logon Type 5 (Service): Используется для сервисов, которые входят в систему под учетной записью службы.
5. Logon Type 7 (Unlock): Пользователь разблокирует рабочую станцию, например, после периода неактивности или блокировки.
6. Logon Type 8 (NetworkCleartext): Используется для сетевого взаимодействия с использованием текстового пароля, обычно в небезопасной среде.
7. Logon Type 9 (NewCredentials): Используется для переключения пользователя на другую учетную запись без выхода из системы. Например запустить от имени...
8. Logon Type 10 (RemoteInteractive): Пользователь заходит в систему интерактивно через удаленное соединение, например, при помощи RDP.
9. Logon Type 11 (CachedInteractive) соответствует сценарию, при котором пользователь входит в систему, используя кэшированные учетные данные. Это происходит, когда компьютер не имеет доступа к доменному контроллеру во время входа в систему, и поэтому использует ранее сохраненные учетные данные для аутентификации пользователя. Подобный тип входа возникает в ситуациях, когда ноутбук или компьютер уже вошел в систему ранее, связался с доменом для аутентификации, а затем был перенесен в то место, где соединение с доменным контроллером недоступно. В таких случаях, учетные данные пользователя кэшируются локально на компьютере и используются для входа при отсутствии доступа к доменному контроллеру. Этот тип входа является специфичным для сценариев без связи с доменным контроллером и позволяет пользователям продолжать работу на компьютере, несмотря на временное отсутствие связи с доменом. Каждый тип входа имеет свои особенности и может указывать на различные способы взаимодействия пользователя с системой, что важно учитывать при анализе событий аудита безопасности в Windows.
Учетные данные в реестре Windows могут появляться из различных источников, в зависимости от способа аутентификации и действий пользователя. Например, при использовании системы аутентификации Windows Integrated Authentication или при входе в систему с учетной записи Microsoft, авторизационные данные могут быть сохранены в реестре для последующего использования. Другим примером является хранение учетных данных (логин и пароль) в виде хэшированных значений в реестре для доступа к зашифрованным данным или сервисам. Также, при использовании специфических приложений или служб, они могут сохранять учетные данные в реестре для удобства последующего доступа, однако это может повлечь риски безопасности, если данные не хранятся в зашифрованном виде или доступ к реестру не ограничен. Важно отметить, что хранение учетных данных в реестре может быть не безопасным способом управления данными, поэтому рекомендуется использование безопасных способов хранения учетных данных, таких как управление цифровыми сертификатами, использование специализированных инструментов управления учетными данными или хранилищами паролей.
Практика
суть войти под учеткой. Сделать дамп памяти lsass. Перенести на kali linux, извлечь данные с помощью pypykatz. Это скучно. И так много раз делал. Странно, что в такой конторе серьезной такая никчемная практика. Суть в том, что если мы войдем условно под учеткой Olga, выйдем с нее и переключимся на Oleg и запустим какой-нибудь софт от имени админа и введем данные админа, то Olga не будет сохранена. В lsass будет хранится только Oleg и админ.
Память процесса lsass будет содержать учетные данные и ADMPetr, и Petr, так как эти пользователи были активны в момент создания дампа процесса. Под активностью понимается не только прямая сессия с ПК, но и действия, совершаемые по сети, а так же запуск процессов на ПК (как локальный запуск, так и удалённый)
Продолжение следует....
Источник: https://xss.is
Привет! Вот и продолжение. Если вы не читали прошлые части, то рекомендую ознакомиться 1 часть 2 часть
Занятие 3. ААА в Windows
План занятия
- Права безопасности объектов в домене
- Аутентификация в доменной среде Windows
- Локальная аутентификация
- Протоколы аутентификации
- Сетевая аутентификация NTLM
- Kerberos
- Типы входа Windows
- Учетные данные в реестре
AAA (Authentication, Authorization, Accounting)
- Идентификация (identification) позволяет уникально идентифицировать объект безопасности (например, пользователя, группу, компьютер, учетную запись службы)
- Аутентификация (authentication) или проверка подлинности проверяет частную информацию для аутентификации (например, пароль и PIN-код)
- Авторизация (authorization) подтверждает подлинность субъекта безопасности
- Отчетность (accounting) позволяет сохранять события авторизации в предназначенные для этого журналы
Winlogon - это системный процесс, который выполняет процедуры входа и выхода на компьютере Windows.
Вот его функции.
- Работоспособность и защита рабочего стола
- Контроль скринсейвера
- Загрузка пользовательских профилей
- Обеспечение безопасности пользовательских данных
- Поддержка входа и выхода пользователя из системы
Схема локальной аутентификации.
1 User (Пользователь) вводит свое имя пользователя и пароль на своем компьютере.
2 Client (Клиент) --username, challenge--> Server (Сервер), передает имя пользователя и challenge-сообщение на сервер.
3 Server (Сервер) --username, challenge--> Domain Controller (Контроллер Домена), передаёт имя пользователя и challenge-сообщение на контроллер домена.
4 Domain Controller (Контроллер домена) --username--> NTDS.dit, обращается к базе данных NTDS.dit для получения хешированного пароля пользователя.
5 Domain Controller (Контроллер домена) расшифровывает challenge-сообщение с использованием хешированного пароля из NTDS.dit.
6 Domain Controller (Контроллер домена) --authentication result--> Server (Сервер), передает результат аутентификации обратно на сервер.
7 Server (Сервер) --access granted--> Client (Клиент), предоставляет клиенту доступ к ресурсам при успешной аутентификации.
Давайте представим, что у вас пользователь с именем Alice, и она хочет получить доступ к серверу, чтобы извлечь некоторые данные. Вот гипотетический пример:
1 Alice (Пользователь) вводит свое имя пользователя ('Alice') и пароль ('password') на своем компьютере.
2 Клиентский компьютер (Client) генерирует случайное число (допустим, '12345') и шифрует его с помощью пароля Alice. Это зашифрованное значение ('encrypted') и имя пользователя ('Alice') отправляются на сервер.
3 Сервер (Server) получает зашифрованное значение ('encrypted') и имя пользователя ('Alice') и отправляет их на Контроллер домена.
4 Контроллер домена (Domain Controller) обращается к базе данных NTDS.dit и ищет запись для пользователя Alice. Он находит зашифрованный пароль, связанный с Alice ('hashedPassword').
5 Контроллер домена (Domain Controller) затем использует 'hashedPassword' для расшифровки 'encrypted' значения. Если одно битовое значение эквивалентно другому, что подтверждает, что пароль Alice верен, Контроллер домена передает
это подтверждение обратно на сервер.
6 Сервер (Server) получает подтверждение, что пароль Alice верен. Он передает это подтверждение обратно на компьютер Alice.
7 Alice теперь аутентифицирована и может получить доступ к запрашиваемым данным на сервере.
Здесь важно понимать, что зашифрованное значение и зашифрованный пароль представляют собой грубое упрощение того, как происходит процесс шифрования. В реальности используются более сложные техники для генерации этих значений и
обеспечения безопасности данных пользователя.
В целом, NTLMv2 представляет собой усовершенствованную версию NTLM, которая обеспечивает большую безопасность и гибкость. Однако стоит отметить, что оба протокола считаются устаревшими, и рекомендуется использовать более современные протоколы аутентификации, такие как Kerberos.
Kerberos - это протокол основанный на билетах, обеспечивающий надежную аутентификацию пользователей. Работает в формате двух пользователей и третьей доверенной стороны.
Основные термины, которые будут использоваться в схемах, чтобы было понятно
1. Клиент (Client) - Это пользователь или служба, которые запрашивают доступ к ресурсу или услуге в сети.
2. Сервер (Server) - Это узел в сети, который предоставляет ресурсы или услуги (например, файлы, печать, приложения) клиенту.
3. Выдавший билет TGS (Ticket Granting Server) - Сервер, который выдает временные билеты клиенту после успешной аутентификации при запросе билета TGT.
4. Билет (Ticket) - Зашифрованная информация, содержащая данные аутентификации, как правило, выдаваемая KDC или TGS для подтверждения аутентификации и авторизации при обращении к серверу.
5. TGT (Ticket Granting Ticket) - Билет, который выдается клиенту KDC после успешной аутентификации и который используется для получения билетов доступа к другим службам.
6. Ключ (Key) - Секретное значение, используемое для шифрования и дешифрования данных.
7. KDC (Key Distribution Center) - Центр распределения ключей, который выполняет функции аутентификации и выдачи билетов в Kerberos.
8. Kerberos - Протокол аутентификации в компьютерных сетях, обеспечивающий безопасность передачи данных между клиентом и сервером.
9. Сеансовый ключ (Session Key) - Ключ, используемый для защиты данных, передаваемых между клиентом и сервером в рамках одной сессии.
10. Аутентификация (Authentication) - Процесс проверки и подтверждения подлинности личности пользователя или службы в сети.
Надоело
этап 1
этап 2
этап 3
этап 4
этап 5
этап 6
этап 7
этап 8
этап 9
этап 10
Logon Types
В Windows существует несколько типов входа (logon types), которые указывают на способ, которым пользователь аутентифицируется на системе. Ниже перечислены основные типы входа в Windows:
1. Logon Type 2 (Interactive): Пользователь входит в систему интерактивно через консоль или удаленный рабочий стол.
2. Logon Type 3 (Network): Пользователь входит в систему через сетевое соединение, например, при обращении к ресурсам файловой службы.
3. Logon Type 4 (Batch): Используется для задач, выполняемых планировщиком задач, как правило без визуального отображения окна входа.
4. Logon Type 5 (Service): Используется для сервисов, которые входят в систему под учетной записью службы.
5. Logon Type 7 (Unlock): Пользователь разблокирует рабочую станцию, например, после периода неактивности или блокировки.
6. Logon Type 8 (NetworkCleartext): Используется для сетевого взаимодействия с использованием текстового пароля, обычно в небезопасной среде.
7. Logon Type 9 (NewCredentials): Используется для переключения пользователя на другую учетную запись без выхода из системы. Например запустить от имени...
8. Logon Type 10 (RemoteInteractive): Пользователь заходит в систему интерактивно через удаленное соединение, например, при помощи RDP.
9. Logon Type 11 (CachedInteractive) соответствует сценарию, при котором пользователь входит в систему, используя кэшированные учетные данные. Это происходит, когда компьютер не имеет доступа к доменному контроллеру во время входа в систему, и поэтому использует ранее сохраненные учетные данные для аутентификации пользователя. Подобный тип входа возникает в ситуациях, когда ноутбук или компьютер уже вошел в систему ранее, связался с доменом для аутентификации, а затем был перенесен в то место, где соединение с доменным контроллером недоступно. В таких случаях, учетные данные пользователя кэшируются локально на компьютере и используются для входа при отсутствии доступа к доменному контроллеру. Этот тип входа является специфичным для сценариев без связи с доменным контроллером и позволяет пользователям продолжать работу на компьютере, несмотря на временное отсутствие связи с доменом. Каждый тип входа имеет свои особенности и может указывать на различные способы взаимодействия пользователя с системой, что важно учитывать при анализе событий аудита безопасности в Windows.
Учетные данные в реестре Windows могут появляться из различных источников, в зависимости от способа аутентификации и действий пользователя. Например, при использовании системы аутентификации Windows Integrated Authentication или при входе в систему с учетной записи Microsoft, авторизационные данные могут быть сохранены в реестре для последующего использования. Другим примером является хранение учетных данных (логин и пароль) в виде хэшированных значений в реестре для доступа к зашифрованным данным или сервисам. Также, при использовании специфических приложений или служб, они могут сохранять учетные данные в реестре для удобства последующего доступа, однако это может повлечь риски безопасности, если данные не хранятся в зашифрованном виде или доступ к реестру не ограничен. Важно отметить, что хранение учетных данных в реестре может быть не безопасным способом управления данными, поэтому рекомендуется использование безопасных способов хранения учетных данных, таких как управление цифровыми сертификатами, использование специализированных инструментов управления учетными данными или хранилищами паролей.
Практика
суть войти под учеткой. Сделать дамп памяти lsass. Перенести на kali linux, извлечь данные с помощью pypykatz. Это скучно. И так много раз делал. Странно, что в такой конторе серьезной такая никчемная практика. Суть в том, что если мы войдем условно под учеткой Olga, выйдем с нее и переключимся на Oleg и запустим какой-нибудь софт от имени админа и введем данные админа, то Olga не будет сохранена. В lsass будет хранится только Oleg и админ.
Память процесса lsass будет содержать учетные данные и ADMPetr, и Petr, так как эти пользователи были активны в момент создания дампа процесса. Под активностью понимается не только прямая сессия с ПК, но и действия, совершаемые по сети, а так же запуск процессов на ПК (как локальный запуск, так и удалённый)
Продолжение следует....