🧭 Как определить Domain Controller? Во внутренней сети одна из важных задач — понять, где находится Domain Controller.

📌 Domain Controller (DC) — это сервер, который обслуживает Active Directory: аутентификацию, Kerberos, LDAP, групповые политики и другие доменные функции.

🔎 На какие порты смотреть У Domain Controller часто открыты:

53    DNS
88    Kerberos
135   MSRPC
389   LDAP
445   SMB
464   Kerberos password change
636   LDAPS
3268  Global Catalog
3269  Global Catalog SSL

Особенно характерная связка:

53 + 88 + 389 + 445

Если видите её на одном Windows-сервере — это уже хороший кандидат на DC. 🛠 Проверка через Nmap

nmap -sV -p 53,88,389,445,464,636,3268,3269 192.168.1.10

В результатах могут появиться:

kerberos-sec
ldap
microsoft-ds
domain

🧠 Через DNS Active Directory публикует специальные DNS-записи. Например:

nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local

или:

nslookup -type=SRV _kerberos._tcp.example.local

Если DNS отвечает именем сервера — вы практически напрямую получаете адрес Domain Controller. 🪟 Если уже есть доступ к Windows-машине Можно посмотреть, какой DC обслуживает текущую доменную сессию:

echo %LOGONSERVER%

Например:

\\DC01

Ещё вариант:

nltest /dsgetdc:example.local

Команда может показать: — имя DC; — IP-адрес; — домен; — сайт Active Directory. 📌 Как выглядит логика поиска

Нашли Windows-сервер
        ↓
Проверили 53 / 88 / 389 / 445
        ↓
Увидели Kerberos + LDAP
        ↓
Проверили DNS SRV-записи
        ↓
Определили Domain Controller

🧠 Главная мысль Один открытый порт ещё ничего не доказывает. Но сочетание:

DNS
Kerberos
LDAP
SMB
Global Catalog

очень характерно для Domain Controller. #activedirectory #domaincontroller #ad #windows #nmap #ldap #kerberos #pentest

🔐 Что такое LDAP Injection? Мы уже разобрали, что такое LDAP и зачем он нужен в Active Directory. Но что произойдёт, если приложение неправильно обрабатывает пользовательский ввод при обращении к LDAP? В этом случае может возникнуть LDAP Injection.

📌 LDAP Injection — это уязвимость, при которой злоумышленник изменяет LDAP-запрос, отправляемый приложением, чтобы получить несанкционированный доступ к данным или изменить логику поиска.

По своей идее она очень похожа на SQL Injection. Только вместо SQL-запросов атакуется LDAP. Представим, что приложение формирует запрос так:

(&(uid=user)(password=123456))

Если пользовательский ввод не фильтруется должным образом, злоумышленник может изменить структуру запроса и повлиять на результат поиска. 💀 Чем это опасно? При успешной эксплуатации LDAP Injection можно: — обойти аутентификацию; — получить информацию о пользователях; — перечислить группы и объекты Active Directory; — извлечь внутренние данные каталога. Всё зависит от того, какие права имеет учётная запись, от имени которой приложение обращается к LDAP. 🧠 Почему это встречается реже, чем SQL Injection? Потому что далеко не каждое приложение работает напрямую с LDAP. Но корпоративные порталы, системы авторизации, внутренние веб-приложения и некоторые VPN-шлюзы довольно часто используют LDAP для проверки пользователей. И если разработчики не экранируют специальные символы, появляется риск LDAP Injection. 🛡 Как защититься? Основные рекомендации: — использовать параметризованные LDAP-запросы; — экранировать специальные символы; — не собирать запросы простой конкатенацией строк; — выдавать приложению минимально необходимые права на чтение LDAP.

📌 LDAP Injection встречается значительно реже SQL Injection, но в корпоративной инфраструктуре последствия могут быть очень серьёзными, особенно если приложение имеет широкий доступ к Active Directory.

#infra #ad #ldap #ldapinjection #websecurity