Фундамент безопасности Windows и сетевых протоколов

1. Архитектура безопасности Windows: LSASS, SAM, реестр и логи событий

Архитектура безопасности Windows: LSASS, SAM, реестр и логи событий

Безопасность операционной системы Windows — это не абстрактное понятие, а совокупность конкретных процессов, файлов и записей в реестре. Чтобы защищать инфраструктуру или проводить тестирование на проникновение, необходимо понимать, где именно система хранит секреты, как она проверяет пользователей и какие следы оставляет после этих действий.

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

1. LSASS: Хранилище секретов в оперативной памяти

LSASS (Local Security Authority Subsystem Service) — это процесс lsass.exe, который является «сердцем» аутентификации в Windows. Когда вы вводите пароль при входе в систему, именно LSASS проверяет его правильность, создает токены доступа и обеспечивает работу принципа единого входа (SSO — Single Sign-On).

Почему LSASS критичен?

Чтобы пользователю не приходилось вводить пароль каждый раз при доступе к сетевой папке или принтеру, LSASS хранит необходимые учетные данные в оперативной памяти. В зависимости от версии Windows и настроек, в памяти процесса могут находиться:

* NT-хеши паролей (используются для протокола NTLM). * Kerberos тикеты (TGT и TGS). * LM-хеши (в очень старых системах). * Пароли в открытом виде (если активен WDigest или CredSSP).

Вектор атаки: Credential Dumping

Поскольку секреты лежат в памяти, процесс lsass.exe становится главной целью злоумышленников после получения прав локального администратора. Самый известный инструмент для извлечения этих данных — Mimikatz.

Атака обычно выглядит так:

Злоумышленник получает права Debug (SeDebugPrivilege).

Он читает память процесса lsass.exe.

Извлекает хеши или тикеты для проведения атак Pass-the-Hash (вход без знания пароля, только по хешу) или Pass-the-Ticket.

Согласно habr.com, существуют разные методы создания дампа памяти LSASS, от использования диспетчера задач до утилиты Procdump или вызова comsvcs.dll. Современные антивирусы (EDR) активно следят за попытками доступа к памяти этого процесса.

Защита LSASS

Microsoft внедрила механизмы защиты, такие как RunAsPPL (Protected Process Light) и Credential Guard (использует виртуализацию для изоляции секретов). Однако в базовых конфигурациях старых систем эти функции могут быть отключены.

2. SAM: Локальная база учетных записей

Если компьютер не подключен к домену или если мы говорим о локальных администраторах, то их учетные данные хранятся в базе SAM (Security Accounts Manager).

* Расположение на диске: C:\Windows\System32\config\SAM * Расположение в реестре: HKLM\SAM

Файл SAM заблокирован для чтения, пока операционная система работает. Вы не можете просто скопировать его проводником. Внутри SAM хранятся имена пользователей и их NT-хеши (хеш пароля). Сами пароли в открытом виде там не лежат.

Извлечение данных из SAM

Злоумышленники используют обходные пути для получения содержимого этой базы:

Теневое копирование (VSS): Создается теневая копия диска C:, откуда файл копируется, так как в копии он не заблокирован.

Через реестр: Утилита reg.exe позволяет выгрузить ветки реестра в файлы.

Пример команд для сохранения веток реестра для последующего офлайн-взлома:

Имея эти файлы, атакующий может извлечь хеши локальных пользователей с помощью инструментов вроде secretsdump.py из пакета Impacket. По данным habr.com, существуют и более новые методы извлечения данных из реестра напрямую из памяти, минуя создание файлов на диске, что усложняет детектирование.

3. Реестр: Ключевые параметры безопасности

Реестр Windows — это не просто настройки интерфейса, это панель управления безопасностью. Основная ветка, отвечающая за параметры LSA (Local Security Authority):

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Критически важные ключи:

* Security Packages: Список загружаемых пакетов аутентификации (например, kerberos, msv1_0). Внедрение сюда сторонней DLL позволяет злоумышленнику перехватывать пароли при входе. * RunAsPPL: Если значение установлено в 1, это включает защиту процесса LSASS от чтения памяти неподписанными процессами. * LimitBlankPasswordUse: Ограничивает использование пустых паролей только консольным входом (удаленно зайти с пустым паролем не получится). * CrashOnAuditFail: Если этот параметр включен и журнал безопасности переполнен, система принудительно выключится (BSOD), чтобы не допустить действий, которые не могут быть залогированы.

4. Логи событий: Следы активности

В Windows «черным ящиком» является журнал событий, в частности журнал Security (Security.evtx). Анализ логов — единственный способ постфактум узнать, что происходило в системе.

Согласно learn.microsoft.com, расширенные политики аудита позволяют детально настроить, какие именно события будут записываться, чтобы избежать зашумления журнала.

Ключевые Event ID для безопасности

Ниже приведена таблица самых важных событий, которые должен отслеживать любой администратор безопасности или SOC-аналитик.

События Kerberos (на контроллере домена)

Для диагностики проблем и атак на протокол Kerberos (например, Kerberoasting) важны следующие события:

* 4768: Запрос тикета TGT (Ticket Granting Ticket). Начало аутентификации. * 4769: Запрос тикета TGS (Ticket Granting Service). Доступ к конкретному сервису. * 4771: Ошибка предварительной аутентификации Kerberos. Аналог 4625 для Kerberos (часто означает неверный пароль).

> События системных журналов в формате EventLog уже имеют некоторую начальную нормализацию и содержат следующие поля: Дата, Категория, Уровень, ID безопасности Windows. > > habr.com

Итоги

LSASS хранит учетные данные в оперативной памяти для удобства работы (SSO), но это делает его главной целью для кражи паролей и хешей (атаки Mimikatz).

SAM — это база данных локальных пользователей. Файл заблокирован системой, но его копии можно извлечь через реестр или теневые копии тома.

Реестр (HKLM


SYSTEM
CurrentControlSet
Control
Lsa

) управляет конфигурацией подсистемы безопасности и может быть модифицирован для защиты (RunAsPPL) или атаки (внедрение вредоносных пакетов).

Логи событий (Event Logs) — основной источник информации об инцидентах. Знание кодов 4624/4625 (вход), 4720 (создание юзера) и 4768/4769 (Kerberos) обязательно для мониторинга.

2. Сетевые протоколы аутентификации: Kerberos, NTLM, LDAP и SMB

Сетевые протоколы аутентификации: Kerberos, NTLM, LDAP и SMB

В предыдущей статье мы разобрали, как Windows хранит секреты локально (в LSASS и SAM). Теперь пришло время понять, как эти секреты используются для доступа к ресурсам по сети. Когда вы открываете общую папку на файловом сервере или входите в домен, происходят сложные процессы обмена данными.

Понимание этих протоколов — это фундамент для выявления атак. Большинство современных атак (Kerberoasting, NTLM Relay, SMB Relay) эксплуатируют не «баги» в коде, а логику работы этих стандартов.

1. Kerberos: Золотой стандарт Active Directory

Kerberos — это основной протокол аутентификации в доменных сетях Windows (начиная с Windows 2000). Его главная особенность: он позволяет подтвердить личность, не передавая пароль по сети (даже в зашифрованном виде).

Как это работает: KDC, TGT и TGS

Kerberos работает на основе «билетов» (tickets). Представьте, что вы пришли в парк аттракционов. Вы не платите наличными на каждой карусели. Вы один раз покупаете абонемент в кассе, а затем показываете его контролерам.

В Active Directory роль «кассы» выполняет KDC (Key Distribution Center), который работает на каждом контроллере домена. Процесс входа выглядит так:

Аутентификация (AS-REQ / AS-REP): Пользователь вводит пароль. Его компьютер шифрует текущее время (timestamp) хешем пароля и отправляет на KDC. Если KDC может расшифровать это (значит, пароль верный), он выдает пользователю TGT (Ticket Granting Ticket). TGT — это ваш «глобальный пропуск» в систему. Он зашифрован ключом, который знает только KDC (хеш пароля учетной записи krbtgt).

Запрос доступа к услуге (TGS-REQ / TGS-REP): Когда вы хотите открыть папку на файловом сервере, вы предъявляете свой TGT контроллеру домена и просите доступ к конкретному сервису. KDC проверяет TGT и выдает вам Service Ticket (Сервисный билет).

Доступ (AP-REQ): Вы отправляете Сервисный билет самому файловому серверу. Сервер расшифровывает билет (своим собственным ключом) и пускает вас.

Согласно learn.microsoft.com, KDC использует базу данных Active Directory для хранения ключей безопасности.

Время жизни тикетов

Тикеты имеют ограниченный срок действия (обычно 10 часов). Это сделано для безопасности: если злоумышленник украдет ваш билет, он сможет им пользоваться только до истечения срока. После этого требуется перевыпуск (renewal).

SPN (Service Principal Name)

Чтобы Kerberos знал, для какого именно сервиса выписывать билет, используется SPN — уникальный идентификатор службы.

Пример SPN для файлового сервера: CIFS/FileServer.corp.local

Если SPN не настроен или указан неверно, Kerberos не сработает, и система попытается откатиться на протокол NTLM.

2. NTLM: Наследие и уязвимости

NTLM (New Technology LAN Manager) — более старый протокол, который работает по принципу «Запрос-Ответ» (Challenge-Response). Он используется, когда Kerberos недоступен (например, при доступе по IP-адресу, а не по имени, или в рабочих группах).

Принцип Challenge/Response

Клиент: «Я хочу войти как User1».

Сервер: «Докажи. Вот тебе случайное число (Challenge), зашифруй его своим паролем».

Клиент: Берет хеш своего пароля, шифрует им Challenge и отправляет результат (Response).

Сервер: Проверяет результат (сам или пересылает его контроллеру домена).

Почему NTLM небезопасен: Pass-the-Hash

Главная проблема NTLM в том, что для генерации ответа (Response) клиенту не нужен сам пароль в открытом виде. Ему нужен только NT-хеш пароля.

Если злоумышленник извлек хеш из памяти LSASS (как мы обсуждали в прошлой статье), он может использовать этот хеш, чтобы отвечать на запросы сервера. Эта атака называется Pass-the-Hash. Сервер не увидит разницы, так как математически ответ будет верным.

Согласно habr.com, существует две версии протокола: NTLMv1 (критически небезопасен) и NTLMv2 (более устойчив, но все еще уязвим для Relay-атак).

3. LDAP vs LDAPS: Доступ к каталогу

LDAP (Lightweight Directory Access Protocol) — это язык, на котором клиенты и серверы общаются с Active Directory. Когда вы ищете коллегу в адресной книге Outlook или когда приложение проверяет членство пользователя в группах, используется LDAP.

Разница в портах и шифровании

* LDAP (TCP 389): Передает данные в открытом виде. Если администратор выполняет привязку (bind) с логином и паролем через обычный LDAP, злоумышленник с Wireshark может перехватить эти учетные данные в чистом тексте. * LDAPS (TCP 636): Это LDAP, завернутый в SSL/TLS туннель. Весь трафик шифруется.

Необходимость сертификатов

Чтобы включить LDAPS, на контроллере домена должен быть установлен цифровой сертификат. Обычно для этого в домене разворачивают собственный центр сертификации (Enterprise CA). Без доверенного сертификата безопасное соединение установить невозможно.

4. SMB: Файловый обмен и подписи

SMB (Server Message Block) — протокол для доступа к файлам, принтерам и удаленного управления (через Named Pipes).

Версии SMB

* SMBv1: Устаревший и крайне опасный протокол. Именно через уязвимость в SMBv1 распространялись вирусы WannaCry и NotPetya. В современных сетях он должен быть полностью отключен. * SMBv2 / SMBv3: Актуальные версии с поддержкой шифрования и оптимизацией производительности.

Подпись SMB (SMB Signing)

Это механизм защиты целостности пакетов. Каждый пакет подписывается цифровой подписью отправителя.

* Зачем нужно: Защищает от атак SMB Relay. В такой атаке хакер встает посередине (Man-in-the-Middle), перехватывает NTLM-аутентификацию от админа и пересылает её на целевой сервер. Если подпись включена, сервер отвергнет пакеты хакера, так как у того нет ключа для генерации верной подписи. * Цена безопасности: Подпись создает нагрузку на процессор (около 10-15%), поэтому по умолчанию она обязательна только на контроллерах домена.

5. DNS: Фундамент Active Directory

В среде Windows фраза «Нет DNS — нет Active Directory» является аксиомой. Клиенты находят контроллеры домена именно через DNS.

Записи SRV

Как компьютер узнает, какой IP-адрес у контроллера домена, отвечающего за Kerberos? Он делает DNS-запрос на специальные SRV-записи (Service Records).

Пример запроса клиента: _kerberos._tcp.dc._msdcs.corp.local

Если эти записи отсутствуют или указывают на выключенный сервер, вход в домен будет невозможен (или будет очень долгим).

Secure Dynamic Updates

В Active Directory компьютеры сами обновляют свои DNS-записи (например, при смене IP). Чтобы хакер не мог подменить запись важного сервера своим IP-адресом, включается режим Secure Only. В этом режиме DNS-сервер принимает обновления только от аутентифицированных компьютеров, чьи права проверены через Kerberos.

DNS Aging and Scavenging

Со временем в DNS накапливается мусор (записи старых, уже удаленных компьютеров). Механизм Aging and Scavenging (Устаревание и очистка) автоматически удаляет старые записи. Если его не настроить, возможны конфликты имен и проблемы с репликацией.

Итоги

Kerberos — приоритетный протокол. Использует билеты (TGT, TGS) и требует наличия SPN. Не передает пароли по сети.

NTLM — запасной протокол (Challenge/Response). Уязвим к атакам Pass-the-Hash и Relay, так как серверу достаточно хеша для проверки.

LDAP (389) передает данные открытым текстом. Для безопасности необходимо использовать LDAPS (636) с сертификатами.

SMBv1 должен быть уничтожен. Для защиты от перехвата сессий (Relay) необходимо использовать SMB Signing.

DNS критичен для работы AD. Клиенты ищут сервисы через SRV-записи, а безопасность зоны обеспечивается через безопасные динамические обновления.