#security #proxy #networking #ad
Давно не было постов. Последние несколько месяцев изучают безопасность виндовой инфраструктуры. И вот совсем недавно столкнулся с интересным кейсом о том, как халатное отношение к внутренней конфигурации инфраструктуры и банальная лень могут привести к компрометации всей корпоративной сети. Решил написать об этом.
Если вы когда-нибудь изучали безопасность виндовых локалок, то наверняка пользовались инструментом Responder. Это довольно удобный и мощный инструмент. В его состав входит возможность отравления запросов к wpad.local - автоконфигурации прокси.
Опытный безопасник наверняка уже понял в чем суть, однако этот пост для молодых специалистов. Поэтому расскажу как это работает и что собственно потенциальный злоумышленник может сделать.
Proxy Auto Configuration (PAC) - очень удобный инструмент, который позволяет с лёгкостью настроить корпоративный прокси сервере для балансировки нагрузки, фильтрации контента и многое другое, но в IT существует извечный конфликт между безопасностью и удобством.
Получить wpad.dat файл можно несколькими способами. Операционная система делает это автоматически:
[1] От DHCP сервера
[2] Через широковещательный запрос к wpad.local
[3] Через запрос к доменному имени wpad.example.com
Именно третий случай был в моём кейсе. Примечательно, что в инфраструктуре заказчика происходила утечка доменного имени из Active Directory. Именно это и послужило вектором атаки. ADшка была настроена на доменное имя лет 5-6 назад. Но к сожалению про это доменное имя забыли. Его аренда истекла и нас удалось взять его под контроль.
Какого же было наше удивление, когда в логах веб сервера мы стали замечать обращения за файлом wpad.dat. После этого смело можно было утверждать о наличии утечки домена.
Помимо того, что пользователи из локальный сети отдавали свои NetNTLMv2 хеши при попытке получить wpad.dat (а в хеше логин и пароль пользователя), нам также удалось навязать пользователям свой прокси сервер через специальный файл конфигураций. Мы просто дали им то, что они хотели :)
Далее появилась возможность перехватывать трафик, идущий из локальной сети через наш прокси. Такие дела.
Давно не было постов. Последние несколько месяцев изучают безопасность виндовой инфраструктуры. И вот совсем недавно столкнулся с интересным кейсом о том, как халатное отношение к внутренней конфигурации инфраструктуры и банальная лень могут привести к компрометации всей корпоративной сети. Решил написать об этом.
Если вы когда-нибудь изучали безопасность виндовых локалок, то наверняка пользовались инструментом Responder. Это довольно удобный и мощный инструмент. В его состав входит возможность отравления запросов к wpad.local - автоконфигурации прокси.
Опытный безопасник наверняка уже понял в чем суть, однако этот пост для молодых специалистов. Поэтому расскажу как это работает и что собственно потенциальный злоумышленник может сделать.
Proxy Auto Configuration (PAC) - очень удобный инструмент, который позволяет с лёгкостью настроить корпоративный прокси сервере для балансировки нагрузки, фильтрации контента и многое другое, но в IT существует извечный конфликт между безопасностью и удобством.
Получить wpad.dat файл можно несколькими способами. Операционная система делает это автоматически:
[1] От DHCP сервера
[2] Через широковещательный запрос к wpad.local
[3] Через запрос к доменному имени wpad.example.com
Именно третий случай был в моём кейсе. Примечательно, что в инфраструктуре заказчика происходила утечка доменного имени из Active Directory. Именно это и послужило вектором атаки. ADшка была настроена на доменное имя лет 5-6 назад. Но к сожалению про это доменное имя забыли. Его аренда истекла и нас удалось взять его под контроль.
Какого же было наше удивление, когда в логах веб сервера мы стали замечать обращения за файлом wpad.dat. После этого смело можно было утверждать о наличии утечки домена.
Помимо того, что пользователи из локальный сети отдавали свои NetNTLMv2 хеши при попытке получить wpad.dat (а в хеше логин и пароль пользователя), нам также удалось навязать пользователям свой прокси сервер через специальный файл конфигураций. Мы просто дали им то, что они хотели :)
Далее появилась возможность перехватывать трафик, идущий из локальной сети через наш прокси. Такие дела.
GitHub
GitHub - lgandx/Responder: Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication…
Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authenticat...