Еще несколько лет назад бот-атаки связывали в основном с крупными интернет-магазинами и банками. Теперь целью может стать любой доступный из интернета ресурс: боты перебирают сервисы подряд, а инструменты для атак и обхода защиты доступны по подписке.
По данным Imperva Bad Bot Report 2025, боты создают 51% обращений к веб-ресурсам, причем 37% общего трафика приходится на вредоносных ботов. Под угрозой оказываются процессы, доступные клиентам и партнерам через браузер, мобильное приложение или API.
О том, как устроены массовые бот-атаки, почему привычные средства не всегда с ними справляются и как выстроить защиту корпоративных сервисов, рассказал эксперт компании «Логстрим» Максим Ёлкин.
Как устроены массовые бот-атаки
Бот обращается к сервису как обычный пользователь: открывает страницы, заполняет формы, нажимает кнопки и вызывает методы API. При этом он работает круглосуточно, в тысячи раз быстрее и одновременно в тысячах сессий. Современные инструменты запускают полноценный браузер, исполняют JavaScript, сохраняют cookies и имитируют движения мыши.
Отдельный запрос обычно не вызывает подозрений. Автоматизацию видно по всему потоку, когда множество сессий выполняет одни и те же операции с одинаковой интенсивностью. Поэтому анализировать нужно действия пользователей за определенный период.
Массовая активность ботов не всегда относится к DDoS. Задача DDoS-атаки — перегрузить канал или инфраструктуру, тогда как боты чаще действуют на уровне приложения: авторизуются, регистрируются, ищут и скачивают данные. Сервис может оставаться доступным, пока они подбирают пароли или собирают информацию.
В 2025 году Curator (ранее Qrator Labs) зафиксировала рост одного ботнета для атак на приложения с 1,33 млн до 5,76 млн IP-адресов за полгода.
Какие корпоративные сервисы атакуют чаще всего
Чаще всего боты обращаются к публичным сайтам и личным кабинетам, где после авторизации доступны персональные данные, документы, история операций и финансовые функции. По числу таких инцидентов лидируют финансовые, телекоммуникационные и ИТ-компании.
Каждый запрос к форме регистрации, авторизации или восстановления пароля может создавать запись в базе, обращаться к почтовому или СМС-шлюзу, запускать отправку уведомления либо кода подтверждения.
В интернет-магазинах и сервисах бронирования боты работают с оплатой, корзинами, промокодами, товарами, билетами и слотами записи.
Мобильное приложение можно разобрать и обращаться к серверным методам напрямую, минуя интерфейс. Его также запускают на эмуляторах или фермах устройств. API нередко защищают слабее сайта, хотя злоумышленники могут использовать его штатные функции без поиска уязвимостей.
Среди менее очевидных точек входа — порталы поставщиков, электронные торговые площадки, формы загрузки документов и аккредитации, чаты и обращения в поддержку, страницы единого входа, вебхуки и интеграционные шлюзы партнеров. Такие ресурсы часто не учитывают при настройке защиты.
Какие задачи решают злоумышленники с помощью ботов
Чаще всего боты подбирают учетные данные. Они проверяют пары «логин — пароль» из утечек в расчете на то, что пользователи вводят один пароль в разных сервисах. Компрометация учетных данных стала самым частым способом первоначального проникновения.
Боты также массово создают учетные записи для получения бонусов, рассылки спама, накрутки, отмывания украденных средств и подготовки следующих атак. При парсинге они собирают цены, сведения об остатках, содержимое каталогов, контакты и персональные данные. Компания теряет коммерческую информацию и оплачивает дополнительную нагрузку на инфраструктуру.
Автоматизация используется и для искажения показателей: боты публикуют отзывы, кликают по рекламе, голосуют, ставят лайки и заполняют формы заявок. В результате компания получает недостоверную аналитику.
При СМС-накачке боты запрашивают коды подтверждения на номера мошенников, а отправку сообщений оплачивает компания. К этой же группе относятся злоупотребления промокодами и программами лояльности, выкуп дефицитных товаров и проверка украденных банковских карт небольшими платежами. Сервис при этом не взламывают: он выполняет предусмотренные операции в интересах злоумышленника.
Почему обычных средств защиты может быть недостаточно
Черные списки IP-адресов и ограничения на число запросов не справляются с атаками через резидентные прокси и ботнеты из миллионов домашних устройств. Каждый адрес может отправлять один запрос в минуту и не превышать заданный лимит, поэтому на уровне отдельного IP такая активность не выглядит подозрительной.
WAF обнаруживает известные инъекции, эксплойты и запросы с признаками вредоносной нагрузки. Если бот использует штатные функции сервиса, технически корректный запрос не распознается как атака. CAPTCHA тоже не гарантирует защиту: задания решают автоматические сервисы и фермы операторов, а в классификации угроз OWASP ее обход выделен в отдельную категорию.
Жесткая фильтрация повышает риск ложных блокировок. За одним адресом мобильного оператора или корпоративного прокси могут находиться тысячи пользователей, а партнерские интеграции работают автоматически. Поэтому при принятии решения нужно учитывать поведение всей сессии и операцию, которую пытается выполнить пользователь.
Как отличить бота от реального пользователя
Технические признаки оценивают по характеристикам соединения и устройства. Отпечатки TLS-рукопожатия JA3 и JA4 помогают обнаружить автоматизированные библиотеки, которые представляются обычным браузером. Также проверяют заголовки запроса, версию браузера, шрифты, разрешение экрана, часовой пояс, исполнение JavaScript, хранение cookies, репутацию IP-адреса и тип сети. В мобильных приложениях Play Integrity и App Attest позволяют выявлять эмуляторы, взломанные устройства и переупакованные приложения.
К поведенческим признакам относятся скорость заполнения формы, прокрутка страницы, траектория мыши, ритм нажатия клавиш и паузы между действиями. Человек обычно действует неровно, а бот повторяет одну траекторию и выдерживает одинаковые интервалы.
Одного признака недостаточно: IP-адрес можно сменить через прокси, отпечаток устройства — через антидетект-браузер, движения мыши — воспроизвести по сценарию. Поэтому решение принимают по совокупной оценке риска и с учетом пути пользователя. Человек может начать с главной страницы, прочитать информацию, перейти к форме, допустить ошибку и исправить данные. Бот чаще сразу открывает целевой адрес, не загружает часть ресурсов и многократно повторяет одну последовательность действий через равные промежутки времени.
Дополнительная проверка требуется при входе с нового устройства или из другой страны, смене контактов и пароля, оплате, массовых действиях и повторном запросе кода подтверждения. В этих операциях ошибка может привести к захвату учетной записи, финансовым потерям или изменению критичных данных. Основанием для проверки служит общая оценка риска сессии.
Как выстроить защиту корпоративных сервисов
Защита должна работать на нескольких уровнях: каждый решает свою задачу и не заменяет остальные. Объемные атаки останавливают на сетевом периметре, направляя трафик через сеть очистки. На российском рынке такие услуги предлагают Curator, DDoS-Guard, StormWall, Servicepipe, Kaspersky DDoS Protection, Variti и Yandex Smart Web Security. Узлы очистки внутри страны сокращают задержки и позволяют выполнять требования 152-ФЗ о локализации данных.
На уровне приложения анализируют отпечатки устройства и соединения, поведение и последовательность действий пользователя. Сам сервис учитывает частоту запросов кода, создания корзин и обращений к API для конкретной учетной записи, устройства или токена, а также скорость просмотра каталога. Для API проверяют структуру запроса и допустимый порядок вызова методов. Ограничений по IP для этого недостаточно.
Отдельный уровень — аутентификация. Кроме второго фактора можно использовать passkeys на базе FIDO2. Они привязаны к домену, поэтому одного украденного пароля для входа недостаточно.
Ответное действие зависит от сигналов со всех уровней и критичности операции. Подозрительной сессии можно разрешить просмотр каталога, но при смене пароля или проведении платежа запросить подтверждение. Запрос блокируют автоматически при известной сигнатуре инструмента атаки, отсутствии исполнения JavaScript, несовпадении отпечатка TLS-соединения с заявленным браузером или резком росте обращений к одному методу.
При средней оценке риска можно запросить второй фактор, снизить лимит, замедлить ответ или вернуть кэшированные данные. Если оснований для автоматической блокировки недостаточно, но риск высок, потребуется ручное подтверждение. Иногда боту не сообщают, что его обнаружили: задержка или бесполезный ответ дольше вводят атакующего в заблуждение, чем прямой отказ.
Для обычных пользователей проверки по возможности оставляют незаметными и усиливают только при подозрении. Разрешенных ботов и партнерские интеграции вносят в доверенные списки, а правила настраивают отдельно для каждой точки сервиса.
Для государственных информационных систем действуют требования приказа ФСТЭК России № 117. Защита значимых объектов критической информационной инфраструктуры регулируется Федеральным законом № 187-ФЗ. Для коммерческих компаний эти документы показывают общее направление развития требований к защите.
Что меняется после запуска защиты
Настройки защиты требуют постоянного контроля. Боты меняют инструменты, снижают частоту запросов и ищут другие точки входа, а после релиза в сервисе могут появиться новая форма или метод API. Новые правила сначала запускают без блокировки. Действующие пересматривают после релизов, во время сезонной нагрузки и при изменении подозрительного трафика.
Не весь автоматический трафик вредоносен. С сервисами уже работают ИИ-агенты, запущенные по поручению пользователей. Для проверки таких запросов разрабатывается Web Bot Auth: агент подписывает запрос, а сервис проверяет отправителя. Это позволяет отделить разрешенную автоматизацию от атаки.
Ложные срабатывания выявляют по обращениям в поддержку, изменениям конверсии и числа регистраций, жалобам партнеров. Часть заблокированных сессий разбирают вручную.
ИТ отвечает за доступность сервиса и работу защитных средств после релизов. Специалисты по информационной безопасности анализируют атаки, настраивают правила и взаимодействуют с провайдером защиты. Владельцы бизнес-процессов определяют нормальное поведение пользователей и допустимый уровень дополнительных проверок. Командам нужно регулярно сверять результаты, чтобы правила не пропускали атаки и не блокировали легитимных пользователей.
С чего начать
Сначала составляют реестр внешних точек входа. Для каждой точки указывают владельца, доступные операции и последствия их автоматического выполнения. Риск связан не только со взломом: ущерб может возникнуть и при многократном использовании штатной функции сервиса.
Затем собирают данные о нормальном трафике: журналы запросов, распределение обращений по времени суток и функциям сервиса, долю неудачных входов, количество отправленных писем и СМС. Отдельно фиксируют долю автоматизированного трафика, нагрузку на инфраструктуру, расходы, время реакции на инциденты и конверсию. Также составляют перечень партнерских интеграций и разрешенных ботов.
На основе собранных данных выбирают два-три приоритетных сценария. По каждому восстанавливают путь атакующего, определяют признаки автоматизации и ответное действие сервиса. Разбор покажет, каких данных и инструментов не хватает.
До запуска защиты рассчитывают затраты на подписку, настройку и сопровождение. Их сопоставляют с возможным ущербом: потерями от простоя в часы пик, расходами на компенсации клиентам, паразитный трафик и отправленные по запросу мошенников сообщения, штрафами за утечки и затратами рабочего времени специалистов. По оценке эксперта, одна серьезная атака в большинстве случаев обходится дороже годовой защиты.
