Как ITG Security нашел backdoor и закрыли RCE: тест внешнего периметра страховой компании
Обновлено: 09.06.2026
О Клиенте
Компания работает на страховом рынке и оказывает все виды страхования.
Для компании внешний цифровой периметр имеет особое значение: через сайты, личные кабинеты, формы регистрации, сервисы авторизации и интеграционные узлы могут обрабатываться персональные данные клиентов, заявки, документы, страховые продукты и внутренние бизнес-процессы.
Клиенту требовалось оценить защищенность определенного набора узлов и приложений на внешнем периметре по модели GrayBox.
В отличие от полностью внешнего BlackBox-тестирования, в этом проекте команда работала с заранее согласованным набором ресурсов и обладала ограниченной исходной информацией о проверяемых узлах. Это позволяло глубже проверить не только публичную доступность сервисов, но и риски, связанные с конкретными технологиями, бизнес-функциями и сценариями эксплуатации.
В рамках проекта требовалось:
- Проверить защищенность внешних узлов и веб-приложений - Оценить безопасность согласованных сайтов, сервисов, порталов, VPN-узлов, административных интерфейсов и других компонентов внешнего периметра.
- Выявить уязвимости, которые могут привести к доступу к персональным данным - Особое внимание уделялось рискам получения доступа к ПДн пользователей компании, раскрытию чувствительной информации, ошибкам авторизации и уязвимостям в веб-приложениях.
- Проверить применимость известных CVE к внешним сервисам - В рамках работ требовалось оценить, присутствуют ли на периметре уязвимые версии компонентов и продуктов, включая CRM-систему, VPN-шлюз и возможно ли их практическое использование.
- Оценить риски компрометации внешнего периметра - Команда проверяла, могут ли отдельные уязвимости привести к выполнению произвольного кода, несанкционированному доступу к сервисам, чтению конфигурационных файлов, удалению файлов, SSRF или дальнейшему развитию атаки.
- Провести ретест после исправлений - После устранения уязвимостей клиентом требовалось повторно проверить найденные проблемы, подтвердить корректность исправлений и, при необходимости, дать более точные рекомендации по доработке патчей.
Особенности реализации
- Проверка заданного набора внешних ресурсов - Работы проводились не по всему внешнему периметру, а по определенному набору узлов и приложений. Это позволило сфокусироваться на наиболее важных для клиента сервисах и глубже проверить каждый из них.
- GrayBox-подход - Команда обладала ограниченной информацией о проверяемых системах, что позволило сочетать взгляд внешнего атакующего с более точной проверкой конкретных технологий, сценариев и функций.
- Наличие критичных веб-приложений и инфраструктурных узлов - В область проверки входили как веб-приложения, так и инфраструктурные компоненты: FTP-сервер, VPN-узлы, приложения в CRM и другие сервисы.
- Обнаружение вредоносного PHP-скрипта на сервере - Одной из наиболее значимых находок стал backdoor, оставленный злоумышленником на одном из сайтов. Это означало, что риск был не только теоретическим, один из ресурсов уже содержал вредоносный скрипт, который мог использоваться для несанкционированного доступа или дальнейшего закрепления на сервере.
- Работа с уязвимостями известных продуктов - В ходе тестирования проверялись и подтверждались уязвимости в распространенных компонентах, включая выполнение произвольного кода в CRM, выполнение произвольного кода на сервере, а также уязвимости VPN-шлюза, связанные с чтением файлов конфигурации, чтением динамической памяти и удалением файлов.
- Ретест и сопровождение исправлений - После того как клиент внес исправления, команда провела повторную проверку. Часть уязвимостей была устранена не полностью или некорректно: в патчах сохранялись обходные сценарии, недостаточная фильтрация, неполное закрытие доступа или другие проблемы. Поэтому специалисты взаимодействовали с клиентом и давали более точные рекомендации, чтобы довести исправления до рабочего состояния.
- Работа с персональными данными - Так как проверяемые сервисы страховой компании могли обрабатывать данные пользователей, отдельное внимание уделялось рискам доступа к ПДн, раскрытию чувствительной информации и ошибкам авторизации.
Решение
На первом этапе команда изучила согласованный перечень внешних узлов и приложений. Для каждого ресурса были определены доступные сервисы, используемые технологии, версии компонентов, формы входа, точки обработки пользовательского ввода, административные интерфейсы и потенциальные пути развития атаки.
Далее была проведена проверка веб-приложений и инфраструктурных сервисов на типовые и критичные риски: ошибки авторизации, неограниченное число попыток входа, перечисление пользователей, передачу чувствительных данных в GET-запросах, раскрытие служебной информации, SSRF, XSS, open redirect, небезопасное использование HTTP, открытый просмотр каталогов и включенный режим отладки на сервере приложения.
Отдельное внимание было уделено известным уязвимостям в используемых продуктах и компонентах. Команда проверила возможность эксплуатации уязвимостей, связанных с выполнением произвольного кода в CRM и сервер, а также уязвимостей VPN-шлюза, которые могли приводить к чтению файлов конфигурации, чтению динамической памяти устройства и удалению произвольных файлов.
В ходе анализа одного из сайтов был обнаружен вредоносный PHP-скрипт — backdoor, оставленный злоумышленником. Эта находка была особенно важной, поскольку указывала не просто на потенциальную возможность компрометации, а на признаки уже произошедшего несанкционированного вмешательства. Команда зафиксировала наличие скрипта, оценила его потенциальное влияние и передала клиенту рекомендации по удалению, расследованию причины появления и проверке связанных компонентов.
Также в рамках работ были выявлены уязвимости, которые могли привести к доступу к персональным данным пользователей компании, неавторизованному изменению пароля, неавторизованной отправке e-mail сообщений, обходу ограничений регистрации по номеру телефона, неавторизованному доступу к FTP-серверу, раскрытию чувствительной информации и чтению произвольных файлов.
После устранения части уязвимостей клиентом был проведен ретест. Команда повторно проверила исправленные участки и подтвердила, какие проблемы были закрыты корректно, а какие требовали доработки. В случаях, когда патчи оказались неполными или создавали новые обходные сценарии, специалисты предоставляли более точные рекомендации: как изменить логику проверки, где усилить валидацию, какие ограничения добавить и какие конфигурации пересмотреть.
Итоговый результат включал не только перечень уязвимостей, но и практическую оценку их влияния: какие проблемы могут привести к компрометации веб-приложения, какие — к доступу к ПДн, какие — к выполнению кода или доступу к конфигурациям, а какие требуют исправления в рамках общей гигиены внешнего периметра.
Результаты
- Заказчик получил подтвержденную картину защищенности выбранных внешних узлов - Проверка показала, какие сайты, сервисы и инфраструктурные компоненты на согласованном внешнем периметре создавали наибольший риск для компании.
- Были выявлены уязвимости, ведущие к доступу к персональным данным - Часть найденных проблем могла приводить к получению доступа к ПДн пользователей компании. Для страховой организации это особенно критично, поскольку такие данные относятся к чувствительным и требуют строгой защиты.
- Обнаружен вредоносный PHP-скрипт на сервере - На одном из сайтов был найден backdoor, оставленный злоумышленником. Эта находка позволила клиенту оперативно отреагировать не только на уязвимость, но и на возможный инцидент безопасности: удалить вредоносный код, проверить сервер и оценить причины компрометации.
- Подтверждены риски выполнения произвольного кода - В ходе работ были выявлены уязвимости, связанные с выполнением произвольного кода в CRM и сервере. Такие проблемы относятся к наиболее опасным, поскольку могут позволить атакующему получить контроль над серверной частью приложения.
- Проверены инфраструктурные уязвимости внешнего периметра - Команда обнаружила риски, связанные с FTP-сервером, VPN-шлюзом, использованием HTTP, слабой защитой от перебора, открытой регистрацией в Redmine, просмотром каталогов и раскрытием конфигурационных или служебных данных.
- Проведен ретест исправлений - После внесения изменений клиентом команда повторно проверила уязвимости. Ретест показал, что часть исправлений была выполнена корректно, а часть требовала доработки из-за неполных патчей, сохранения обходных сценариев или недостаточно точной реализации защитных механизмов.
- Клиент получил уточненные рекомендации по исправлению - В ходе взаимодействия команда помогла заказчику скорректировать подход к устранению уязвимостей: уточнить логику патчей, закрыть обходные варианты эксплуатации, усилить настройки сервисов и приоритизировать дальнейшие действия.
- Сформирован приоритизированный план снижения рисков - Все находки были классифицированы по уровню риска и влиянию на бизнес. Это позволило заказчику сосредоточиться на первоочередных мерах: удалении backdoor, устранении RCE, закрытии доступа к ПДн, обновлении уязвимых компонентов, настройке защиты от перебора и пересмотре конфигураций внешних сервисов.
Выводы для заказчиков
Тестирование внешнего периметра важно не только как профилактическая проверка, но и как способ обнаружить признаки уже произошедшей компрометации. В этом проекте одной из ключевых находок стал вредоносный PHP-скрипт на сервере — фактически backdoor, который мог использоваться злоумышленником для сохранения доступа к ресурсу.
Для страховой компании такие риски особенно значимы: внешние веб-приложения и инфраструктурные узлы могут быть связаны с персональными данными клиентов, учетными записями, документами, заявками и внутренними процессами. Поэтому уязвимости уровня выполнения произвольного кода, неавторизованного доступа, чтения конфигураций или обхода авторизации нельзя рассматривать как изолированные технические дефекты — они могут напрямую влиять на конфиденциальность данных и устойчивость цифровых сервисов.
Отдельную ценность дал ретест. Он показал, что исправление уязвимости — это не только установка патча или изменение отдельной проверки. Некоторые проблемы требуют повторной валидации, потому что неполное исправление может оставить обходные сценарии или создать ложное ощущение защищенности. Совместная работа с клиентом позволила уточнить рекомендации и довести исправления до более надежного состояния.