ТОП-5 векторов атак на российские компании за год: тренды нашего отдела пентеста
Обновлено: 27.03.2026
Проникновение в ИТ-инфраструктуру может вызвать серьезные последствия для компании - от финансовых и репутационных потерь до санкций контролирующих органов и разрушения ИТ-инфраструктуры. Специалисты нашего отдела пентеста подготовили топ-5 наиболее распространенных векторов проникновения в российские компании по итогам 2025 года. Рейтинг составлялся на основании фактически реализованных проектов за этот период времени. Если развитие атаки включало в себя сразу несколько техник, то фиксировался первичный вектор - он и попадал в подборку.
В качестве бонуса мы сформулировали базовые рекомендации по устранению и / или минимизации рисков, связанных с каждым вектором.
№1 - Компрометация учетных данных
Компрометация учетных данных или учетных записей - неизменно занимает высокие позиции в рейтингах векторов проникновения в ИТ-инфраструктуру компаний. Речь идет о ситуациях, когда информация для аутентификации (логины, токены, пароли) становятся доступными третьим лицам - например, хакерам.
Чаще всего учетные данные компрометируются при реализации следующих сценариев:
- Брутфорс - или просто подбор пароля на внешнем периметре. Подобрать пароль можно, перебирая простые пароли к веб-интерфейсам, используя списки популярных паролей или организовать атаку по «словарю», учитывая личную информацию пользователя.
- Повторное использование пароля - чтобы не путаться, некоторые пользователи используют один и тот же пароль на разных сервисах, копируют пароль от личного аккаунта и применяют на работе или используют вариации одного пароля с небольшими изменениями (например, заменяют букву, добавляют / убирают один или несколько символов).
- Утечка данных из внешних источников - чаще всего это происходит, если хакеры взломали базу данных сервера, где использовались учетные данные. Также возможны такие варианты, как фишинг с кражей учетных данных, вредоносы и кейлоггеры на пользовательских устройствах и дампы паролей, опубликованные в даркнете.
Рекомендации по защите:
- внедрить многофакторную аутентификацию не только для ключевых, но и для “второстепенных” направлений (для администраторов и удаленных рабочих мест MFA - это жизненная необходимость);
- предусмотреть SSO в комплексе с единой политикой доступа - здесь нельзя забывать об ограничениях географического характера / ASN, временным промежуткам, устройствам и рисковым входам;
- обеспечить защиту от брутфорса на периметре;
- разработать и внедрить строгую парольную политику с учетом необходимости запрета скомпрометированных и распространенных паролей;
- обеспечить реагирование и детектирование аномальной и подозрительной активности (в том числе невозможных перемещений, резкого всплеска неудачных попыток авторизации, оповещение по атакам с распылением паролей).
№2 - Утечки секретов
«Секретом» в ИТ называют любые данные, которые позволяют получить доступ к ресурсам, в том числе:
- API-ключи;
- токены доступа;
- пароли БД;
- ключи шифрования;
- приватные SSH-ключи.
Наиболее вероятными сценариями утечки секретов считаются:
- В документации - скриншоты интерфейсов с четко видимыми токенами, руководства и инструкции с примерами конфигурации с использованием реальных данных, примеры запросов с использованием реальных API-ключей.
- В репозиториях кода - здесь также возможны варианты, например:
- размещение файлов окружения в публичном доступе;
- использование примеров кода с тестовыми ключами;
- коммиты с конфигурационными файлами, содержащими «секрет».
Мобильные приложения и их окружение нередко становятся источником утечек «секретов», потому что часть чувствительных данных оказывается в клиентской части или в побочных артефактах разработки/эксплуатации.
Также «секрет» может утечь через баг-трекер с логами, корпоративные мессенджеры и чаты (Slack/Teams и аналоги) с пересылкой ключей или бэкапы, размещенные в открытом доступе.
Если «секреты» утекли и компания долго их не отзывает, то злоумышленники могут получить полноценный доступ к внутренним ИТ-сервисам, интеграциям, облаку, и, как следствие, спровоцировать киберинцидент с серьезными последствиями.
Рекомендации по защите:
- Создать централизованное хранилище “секретов”. Все “секреты” переносятся в специализированные системы - например, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault. Никогда и ни при каких обстоятельствах не допускать хранение “секретов” в открытом виде в коде, конфигурационных файлах и переменных окружения.
- Обеспечить периодическое сканирование репозиториев и CI/CD, чтобы сделать попадание “секрета” в репозиторий физически невозможным. Это можно обеспечить путем внедрения автоматических сканеров, таких, как Gitleaks, Trufflehog, GitHub Secret Scanning.
- Проводить код-ревью, проверять документацию и все публичные материалы перед публикацией. Все инструкции, скриншоты, примеры кода (в особенности, если он размещается в открытом доступе) необходимо тщательно проверять на присутствие реальных паролей, ключей, токенов.
№3 - Эксплуатация уязвимостей в интернет-приложениях
Это один из наиболее «стабильных» и распространенных векторов, так как приложения с теми или иными выявленными либо еще не обнаруженными уязвимостями используются практически всеми компаниями. Злоумышленники могут эксплуатировать как zero-day уязвимости до появления патча и публичного описания, так и n-day-уязвимости - уже известные уязвимости с зарегистрированными CVE, которые остаются не закрытыми в компании из-за задержек патч-менеджмента или ошибок в управлении активами. При этом риск усиливается, если на внешнем периметре есть сервисы, о которых компания не знает или которые не входят в контур регулярных обновлений.
К проникновению через уязвимости веб-приложений также приводят сбои в управлении обновлениями, когда разработчик уязвимость уже отработал, но компания по каким-то причинам продолжает пользоваться уязвимой версией и даже незнание того, какие сервисы есть у компании на внешнем периметре. Получив первоначальный доступ в ИТ-инфраструктуру, хакеры получают возможность развивать атаку внутрь системы.
Рекомендации по защите:
- Проводить регулярные инструментальные сканирования уязвимостей - автоматизированные сканеры (Nuclei, OpenVAS, коммерческие аналоги) следует запускать не только после выкатки нового кода (деплоя), любых обновлений, но также предусматривать периодические проверки в “штатном” режиме.
- Организовать и обеспечить контроль регулярного процесса патч-менеджмента - он должен включать в себя четко регламентированные сроки обновления компонентов на внешнем периметре.
- Использовать WAF (Web Application Firewall) - этот шаг позволит заблокировать наиболее распространенные классы атак на веб-приложения — SQL-инъекции, XSS, эксплуатацию уязвимых компонентов.
- Составить и вести актуальный реестр внешних ресурсов - компания должна четко знать, какие сервисы и приложения доступны из интернета в каждый момент времени. Своевременно применять необходимые патчи получится только в том случае, если инвентаризация внешнего периметра будет представлять собой не разовые “акции”, а регулярный процесс.
- Проводить регулярные пентесты и анализ кода (SAST/DAST) - автоматические сканеры эффективны, однако не могут обнаружить все возможные уязвимости. В частности, логические и специфичные для конкретного приложения уязвимости могут остаться незамеченными при автоматическом сканировании, тогда как ручной пентест и анализ кода позволяют их обнаруживать.
№4 - Периметровые сервисы удаленного доступа (VPN/RDP/FTP и др.) без должной защиты
Первопричиной проникновения по данному вектору может стать утечка пароля, однако злоумышленнику, как правило, необходимо войти через сервис удаленного доступа. Если периметровый сервис хорошо защищен, единичный утекший пароль не даст возможности развить полноценную масштабную атаку.
Чаще всего подвергаются атакам такие периметровые сервисы, как:
- VNC - их нередко используют с примитивными или вовсе пустыми паролями;
веб-панели управления; - FTP/SFTP-серверы - для них распространена проблема слабых учетных данных или наличие анонимного доступа;
- SSH - уязвим для брутфорс-атак, если не предусмотрено ограничение количества попыток входа;
- VPN-серверы - если для них использованы слабые методы шифрования или устаревшие протоколы, вполне могут стать удобным «входом» для киберпреступника;
- RDP - пользуется популярностью у хакеров из-за частого использования слабых паролей и отсутствия многофакторной аутентификации.
Рекомендации по защите:
Меры “блокировки” этого вектора аналогичны приведенным в разделе №3:
- проводить регулярные инструментальные сканирования;
- организовать патч-менеджмент;
- использовать WAF;
- вести реестр внешних ресурсов;
- проводить пентесты и анализ кода на регулярной основе.
№5 - Неконтролируемый внешний периметр и “забытые” сервисы
Этот вектор появляется как следствие того, что в компании нет нормального управления attack surface. К неконтролируемому периметру можно отнести любые точки входа в ИТ-инфраструктуру, которые доступны из сети Интернет, если эти точки:
- своевременно не обновляются и не «патчатся»;
- не проходят регулярный ИБ-аудит;
- не значатся в реестрах активов;
- не имеют ответственных за них «владельцев».
«Забытыми» считают сервисы, которые были опубликованы в интернете, но:
- об их существовании не помнят / не знают администраторы и специалисты по ИБ;
- их не поддерживают по каким-то причинам - например проект, с которым они связаны, уже не актуален (завершился или приостановлен надолго);
- их сохраняли на «всякий случай», но случай так и не наступил.
Примеров «забытых» сервисов, которые способны стать удобной «дверью» в ИТ-инфраструктуру с точки зрения злоумышленника, много - это временные серверы с демо-контентом, устаревшие сервисы, временные решения (прокси для срочного доступа, облачные инстансы для «пилотов», тестовые API-эндпойнты), неучтенные устройства (опасность может представлять даже неучтенный сетевой принтер), контейнеры Docker с открытыми портами. Не стоит забывать и об «унаследованных системах» - ранее интегрированных сервисах бывших партнеров, сервисах, поддерживаемых сотрудниками, которые давно не работают в компании - список можно продолжать долго.
Рекомендации по защите:
Создать и поддерживать актуальный реестр внешних активов - каждый имеющийся у компании сервис с доступом из интернета должен значиться в этом реестре, также следует для каждого такого сервиса прописать ответственного владельца и регламент обслуживания.
Внедрить непрерывный мониторинг периметра (ASM) - это позволит обнаруживать новые и изменившиеся активы на внешнем периметре, включая те, которые по каким-то причинам “выпали” из поля зрения специалистов по ИБ. Помочь в решении этой задачи могут инструменты класса Attack Surface Management (Censys, Shodan-мониторинг, коммерческие ASM-платформы).
Разработать и внедрить процедуру вывода сервисов из эксплуатации. В компании должен действовать четкий регламент, в соответствии с которым любые временные сервисы, тестовые эндпойнты, пилотные инстансы после завершения проекта должны удаляться.
Проводить регулярную инвентаризацию с привлечением внешних экспертов - собственная команда без всякого злого умысла может упустить и не заметить нечто важное на периметре. Сторонний пентестер в этой ситуации смотрит на инфраструктуру глазами хакера и ничего не упустит.
Вывод:
Как правило, в одной и той же компании есть возможность проникнуть в ИТ-инфраструктуру сразу по нескольким векторам, и, «закрыв одну дверь» для хакеров, нельзя быть уверенным, что со временем не появится другая.
Большинство успешных атак на компании начинается с относительно простых векторов — фишинга, уязвимостей веб-приложений и ошибок конфигурации инфраструктуры. Регулярные пентесты позволяют выявить такие точки входа до того, как ими воспользуются злоумышленники.