Сталкивались с ситуацией, когда в организации грамотно настроен выход в интернет?
Сценарий такой:
🔒 По умолчанию доступ в интернет с хостов запрещен.
🌐 Есть корпоративный прокси-сервер с обязательной аутентификацией.
🤔 Да ещё и только по протоколу Kerberos (Negotiate), и не каждому пользователю разрешён выход.
Итак, что делать, если вы получили доступ к хосту от имени доменного пользователя, которому разрешён выход в интернет? Мне сразу же хочется пробросить сессию наружу, запроксироваться и закрепиться тихо и надолго. 😄
💡 Поиск решения
Я перебрал много известных инструментов, но не нашёл ничего подходящего. Большинство решений поддерживают только NTLM или Basic аутентификацию, либо вообще не умеют работать с прокси.
Пришла идея написать небольшой прокси-сервер-прослойку, который бы принимал соединения без аутентификации и сам проходил её на корпоративном прокси. Но встал вопрос: откуда брать учетные данные?
🛠 Первые шаги
Нашёлся старый, но рабочий репозиторий — win-auth-proxy (ссылка). Автор реализовал извлечение дескриптора учётных данных из текущей сессии пользователя с помощью winapi функции AcquireCredentialsHandle, а затем использовал InitializeSecurityContext для аутентификации на проксе.
Скомпилировал его, почти ничего не меняя, и — о чудо, всё завелось! ✨ Но тащить два бинаря на хост показалось не очень элегантным решением.
🚀 Идеальный инструмент
Тут я вспомнил про замечательный инструмент reverse_ssh (ссылка). Он тихий и поддерживает всё, что нужно:
- Интерактивную сессию
- Проксирование
- Проброс портов
- Передачу файлов
В общем, всё, что может обычный SSH. Я форкнул репозиторий и добавил необходимые доработки для аутентификации на прокси с использованием текущих учётных данных пользователя Windows.
Отдельно стоит упомянуть гибкость транспортов. Инструмент умеет работать не только по чистому TCP, но и заворачивать трафик в HTTP, HTTPS, TLS, WS (WebSocket) и WSS. Это критически важно для обхода DPI и маскировки под легитимный веб-трафик в жестко контролируемых сетях.
Позже один молодой эксперт (nollium) доработал инструмент, добавив аутентификацию через NTLM с указанием кредов. Что удобно для запуска, например с linux систем.
💪 Финальный штрих
Я столкнулся с проблемой, когда прокси-сервер находится в одном домене AD, а пользователь — в другом. Происходила ошибка из-за неверного выбора realm. Эту проблему я тоже исправил.
Чтобы использовать фичу, достаточно добавить флаг
--use-kerberos при генерации агента:link --https --name main_agent --use-kerberos --proxy http://proxy.example.com:8080 --goos windows
Теперь у нас есть мощный инструмент, который поможет пробить стену!
PS. Все изменения уже доступны в оригинальном репозитории. Пользуйтесь на здоровье!
#pentest #redteam #proxy #kerberos #ssh #infosec #bypass #auth #negotiate