Почему взламывают сайты туроператоров и как защитить туристический бизнес от кибератак
Разбираем атаку на TEZ TOUR, риски для туристических компаний и ключевые элементы защиты сайта, бронирований, персональных данных, серверов и внутренней IT-инфраструктуры.
Атака на TEZ TOUR: что известно на данный момент
Вечером 15 сентября 2026 года посетители сайта TEZ TOUR увидели вместо привычной страницы сообщение от хакерской группировки DataSuckers. Атакующие заявили, что получили доступ к инфраструктуре туроператора, скачали данные и уничтожили часть информации. В сообщении фигурировали десятки миллионов записей о бронированиях и заказах и сотни миллионов финансовых транзакций.
Сам факт кибератаки TEZ TOUR подтвердил. Последствия инцидента компания описывает значительно осторожнее. Коммерческий директор туроператора Воскан Арзуманов сообщил, что после обнаружения несанкционированной активности были предприняты меры по локализации, ERP-систему своевременно изолировали, а признаков компрометации данных туристов и партнёров на момент заявления не выявили. Действующие бронирования, по данным компании, сохранились. Информацию о позиции туроператора публиковал «Интерфакс».
Кибератака произошла. Работа сайта была затронута, компания локализовала инцидент, изолировала ERP-систему и начала восстановление цифровых сервисов.
Заявленный атакующими объём похищенных или уничтоженных данных, компрометация паспортной и платёжной информации и полная техническая цепочка проникновения.
Версия DataSuckers значительно серьёзнее. Группировка заявила примерно о 395,5 млн скомпрометированных записей, среди которых называла 45,4 млн записей бронирований, 21,5 млн заказов туров, более 52 млн бронирований отелей и 252,3 млн финансовых транзакций. Подробности версии атакующих опубликованы в материале Habr.
При этом перечисленные категории арифметически дают другую сумму — около 371 млн. Кроме того, количество записей в связанных таблицах нельзя трактовать как количество отдельных туристов: один клиент или одна поездка могут присутствовать сразу в нескольких массивах данных.
Ключевой момент: по состоянию на 17 сентября подтверждена сама атака, но публичного независимого подтверждения заявленной утечки паспортных и банковских данных туристов нет. Эти сведения исходят от атакующей стороны.
Как могла развиваться атака
Техническая сторона истории особенно показательна для бизнеса, потому что демонстрирует возможную разницу между ситуациями «взломали сайт» и «получили точку входа во внутреннюю инфраструктуру».
По версии DataSuckers, первоначальный доступ был получен через сервис загрузки файлов. Группировка утверждает, что приложение позволило загрузить файл, который веб-сервер впоследствии обработал как PHP-код. Это якобы дало возможность выполнять команды внутри Docker-контейнера.
Далее, по версии атакующих, из контейнера оказалась доступна часть внутренней сети. Там были обнаружены корпоративные сервисы, учётные данные от SVN-репозиториев, исходный код и конфигурации с паролями к базам данных. Позднее злоумышленники, как они утверждают, получили доступ к Tomcat Manager и возможность выполнять код уже в производственной среде.
Это пока именно версия DataSuckers. Публичного независимого технического отчёта, подтверждающего такую последовательность событий, на момент подготовки материала нет.
Взлом веб-сервера не должен автоматически означать доступ ко всему бизнесу
Последствия атаки определяются архитектурой: какие системы видит веб-сервер, какими правами обладает приложение, где находятся секреты, к каким API и базам данных оно может обращаться и насколько хорошо разделены внешние и внутренние сервисы.
Почему туристическая инфраструктура особенно чувствительна к таким атакам
Туристическая бронь обычно содержит больше информации, чем стандартный заказ в интернет-магазине. Для оформления международных поездок могут использоваться фамилия и имя пассажира, пол, дата рождения, гражданство, серия и номер загранпаспорта, срок его действия и контактная информация.
К этому добавляются номера заявок, состав туристов, направления и даты поездок, данные об отелях и перелётах, страховые документы, договоры, информация о партнёрах, турагентствах и взаиморасчётах.
Персональные данные
Паспортные сведения, контакты, данные пассажиров и другая информация, необходимая для оформления поездки.
Бронирования
Маршруты, даты, отели, перелёты, состав туристов и статусы оплаченных заявок.
Финансовые данные
Взаиморасчёты, платежи, партнёрская информация и другие коммерчески значимые сведения.
Корпоративные доступы
Учётные записи сотрудников, технические аккаунты, токены, ключи и права на внутренние системы.
Исходный код
Репозитории, конфигурации, интеграции и техническая информация о внутренней архитектуре.
Данные партнёров
Информация о турагентствах, поставщиках, отелях и других участниках туристической цепочки.
TEZ TOUR — не единственный пример: что произошло с FUN&SUN
19 июня 2026 года FUN&SUN сообщил о «технической аномалии» в инфраструктуре, которая затронула сайт и отдельные IT-сервисы. Компания продолжала выполнять обязательства по действующим турам, но часть цифровых функций оказалась недоступна.
Для клиентов и турагентов последствия были вполне практическими: возникали сложности с получением маршрутных квитанций, страховых документов и ваучеров через личные кабинеты. Сайт и приложение долгое время работали с ограничениями, а восстановление происходило поэтапно.
Подробности процесса восстановления публиковала Ассоциация туроператоров: материал АТОР о восстановлении IT-инфраструктуры FUN&SUN.
Объединяет эти ситуации другое: сайт крупного туроператора давно перестал быть отдельной страницей с каталогом. За ним находятся системы бронирования, личные кабинеты, документы, интеграции, CRM или ERP, платёжные сервисы и другие критичные для работы элементы инфраструктуры.
Почему взламывают сайты туроператоров
Причина успешной атаки редко сводится к одной ошибке. Реальный инцидент может состоять из нескольких последовательных этапов, а первоначально найденная уязвимость нужна злоумышленнику только для того, чтобы закрепиться в системе и искать дальнейшие возможности.
Устаревшее программное обеспечение
CMS, веб-фреймворки, библиотеки, серверы приложений, плагины и вспомогательные сервисы регулярно получают обновления безопасности. Когда компонент с известной уязвимостью остаётся доступным из интернета, вероятность автоматизированного поиска и последующей эксплуатации возрастает.
Небезопасная загрузка файлов
Туристические сервисы работают с документами, изображениями и другими файлами. Сама функция загрузки не является проблемой, но её реализация требует строгого контроля.
Компрометация учётных записей
Не каждый взлом начинается с программной ошибки. Административный доступ можно потерять через фишинг, повторное использование паролей, ранее произошедшую утечку учётных данных или заражённое рабочее устройство.
Пароли и ключи внутри исходного кода
Опасная архитектурная ошибка — хранить пароли к базам данных, API-ключи, токены, SSH-ключи и другие секреты непосредственно в коде или конфигурационных файлах, попадающих в общий репозиторий.
Недостаточная сегментация инфраструктуры
Если после компрометации публичного веб-сервера атакующий получает прямую сетевую доступность ERP, баз данных, систем резервного копирования, репозиториев и административных сервисов, одна веб-уязвимость превращается в инфраструктурный инцидент.
Уязвимые API и интеграции
Современный туроператор использует множество интеграций: поиск туров, бронирование, платежи, страхование, авиаперевозчиков, отели, CRM, ERP, кабинеты турагентов и мобильные приложения.
Почему защищать только сайт недостаточно
Распространённая ошибка — воспринимать информационную безопасность как набор отдельных инструментов. У сайта есть SSL-сертификат, перед ним установлен WAF, CMS обновлена — и задача считается решённой.
Эти меры действительно нужны, но каждая из них закрывает только часть рисков. WAF не исправит ошибочную архитектуру прав, SSL не мешает использовать украденную административную учётную запись, а резервное копирование не поможет, если атакующий способен удалить одновременно production и все доступные копии.
Информационная безопасность — это архитектура, процессы и постоянный контроль
Защита сайта должна быть частью общей системы: управление доступами, сегментация сети, контроль секретов, резервное копирование, журналирование, мониторинг, реагирование на инциденты и восстановление.
Как правильно защищать сайт и IT-инфраструктуру туроператора
Работа начинается не с покупки ещё одного защитного продукта, а с понимания собственной архитектуры. Компания должна знать, какие сервисы доступны из интернета, какие системы связаны между собой, где находятся чувствительные данные, кто имеет административный доступ и какие внешние подрядчики подключены к инфраструктуре.
Веб-приложение и сервер
CMS, фреймворки, серверные компоненты и зависимости необходимо своевременно обновлять. Неиспользуемые плагины, старые административные панели, тестовые сайты и временные сервисы следует удалять или закрывать от внешнего доступа.
Учётные записи и административный доступ
Для администраторов сайта, серверов, репозиториев, облачных платформ, VPN и других критичных сервисов MFA должна стать обязательной.
Секреты и исходный код
Пароли к базам данных, API-ключи, токены и приватные ключи должны храниться в предназначенных для этого системах управления секретами.
Сеть и серверная инфраструктура
Публичный веб-контур должен быть отделён от критических корпоративных систем. Разрешения между сегментами необходимо строить по принципу «запрещено всё, кроме действительно необходимого».
Резервная копия должна пережить атаку вместе с бизнесом
Наличие ежедневного бэкапа ещё не означает, что инфраструктура сможет восстановиться после серьёзного инцидента.
Три копии
Основные данные и как минимум две дополнительные резервные копии.
Два типа хранения
Копии не должны зависеть от одного и того же носителя или инфраструктурного контура.
Одна копия отдельно
Критичный резерв необходимо хранить изолированно от основной инфраструктуры.
Что туроператору стоит проверить прямо сейчас
- Есть ли актуальный список всех сайтов, поддоменов, API и административных сервисов, доступных из интернета?
- Когда последний раз обновлялись CMS, фреймворки, серверное ПО и зависимости?
- Используется ли MFA для всех административных и привилегированных учётных записей?
- Остались ли активные доступы у бывших сотрудников или подрядчиков?
- Может ли публичный веб-сервер напрямую обращаться к критичным внутренним системам?
- Какие права имеет приложение при работе с базами данных и корпоративными API?
- Хранятся ли пароли, API-ключи или токены в репозиториях и конфигурационных файлах?
- Проверяются ли загружаемые пользователями файлы?
- Где физически и логически расположены резервные копии?
- Когда последний раз выполнялось тестовое восстановление из резервной копии?
- Сохраняются ли логи авторизаций, административных действий и изменений прав?
- Кто получит уведомление о критичной подозрительной активности ночью или в выходной?
Безопасность сайта туроператора начинается с архитектуры
Кибератака на TEZ TOUR ещё расследуется. По состоянию на 17 сентября 2026 года подтверждён сам инцидент, но нет независимого подтверждения заявленной атакующими утечки паспортных и банковских данных или названного ими объёма скомпрометированной информации.
Для других компаний туристической отрасли этот случай важен прежде всего как повод проверить собственную инфраструктуру: серверную конфигурацию, API, загрузку файлов, административные учётные записи, доступы сотрудников и подрядчиков, репозитории, хранение секретов, резервные копии и мониторинг.
Технический аудит сайта и связанной IT-инфраструктуры
НС Диджитал может провести комплексную техническую проверку сайта и связанных с ним систем: оценить состояние веб-приложения и серверной конфигурации, административные доступы, интеграции, хранение секретов, резервное копирование и архитектуру взаимодействия между сервисами.
По результатам аудита можно определить потенциально опасные места, разделить выявленные проблемы по уровню риска и подготовить конкретный план работ.