Как взломали инфраструктуру Tez Tour — и почему проблема оказалась глубже, чем просто взлом сайта
17 сентября 2026 года стало известно об атаке на инфраструктуру туристического оператора Tez Tour. Группа DataSuckers заявила о компрометации серверов компании, краже большого объёма данных и уничтожении части информации.
Сам Tez Tour подтвердил факт киберинцидента, но сообщил, что признаков утечки данных на тот момент не обнаружил. По словам представителей компании, атаку удалось локализовать, часть систем была временно отключена, а действующие бронирования сохранились.
Но эта история интересна не только как очередной случай взлома крупной компании.
Она показывает, насколько быстро проблема в одном веб-сервисе может превратиться в проблему всей IT-инфраструктуры.
Всё могло начаться с обычной загрузки файла
По данным, опубликованным атакующей группировкой, первоначальной точкой входа мог стать сервис загрузки файлов.
На первый взгляд это обычная функция: пользователь прикрепляет документ, изображение или другой файл, а сервер принимает его и сохраняет.
Но именно такие функции требуют особенно внимательной защиты.
Если сервер недостаточно проверяет содержимое загружаемого файла, атакующий потенциально может попытаться загрузить специально подготовленный объект и добиться выполнения собственного кода.
Дальше атака может развиваться уже внутри инфраструктуры.
По утверждению DataSuckers, после получения первоначального доступа злоумышленники обнаружили конфигурационные файлы и учётные данные, которые помогли им получить доступ к другим системам.
И здесь появляется главный урок.
Взлом редко заканчивается там, где он начался.
Один доступ может открыть путь к десяткам систем
Современная IT-инфраструктура компании редко состоит из одного сервера.
Обычно между собой связаны:
- сайт;
- CRM;
- ERP;
- базы данных;
- платёжные сервисы;
- внутренние API;
- системы бронирования;
- файловые хранилища;
- панели администраторов;
- сервисы аналитики;
- резервные копии.
Если злоумышленник получает доступ к одному компоненту, его следующей задачей становится не сам сайт.
Его цель — расширить свои права и попасть дальше.
По заявлению DataSuckers, они сохраняли доступ к инфраструктуре Tez Tour около двух недель и постепенно расширяли свои возможности внутри сети.
Это называется lateral movement — перемещение внутри инфраструктуры.
Именно поэтому безопасность сайта нельзя рассматривать отдельно от безопасности всей системы.
А что произошло с данными?
Заявления атакующей стороны выглядят масштабно.
Группа утверждала, что получила доступ к сотням миллионов записей, среди которых якобы были данные бронирований, заказов, гостиниц и финансовых операций.
Также хакеры заявили о получении паспортных данных, номеров телефонов, адресов и банковской информации.
Однако важно разделять заявления атакующих и подтверждённые факты.
На момент публикации Tez Tour сообщал, что признаков утечки данных не обнаружил. Компания также заявила, что ERP-система была изолирована и не пострадала, а действующие бронирования сохранились.
Поэтому говорить о полном подтверждённом объёме украденных данных пока некорректно.
Самая опасная часть — резервные копии
Есть ещё один момент, который особенно важен для бизнеса.
По словам атакующей группировки, резервные копии находились на тех же серверах, что и основные системы.
Если это действительно так, возникает серьёзная проблема.
Представьте:
Основная база → резервная копия → один сервер → один доступ
В такой архитектуре резервная копия перестаёт быть полноценной защитой.
Если злоумышленник получает достаточные права на сервер, он потенциально может воздействовать и на backup.
Поэтому резервная копия должна защищать бизнес даже в ситуации, когда основная инфраструктура полностью скомпрометирована.
Это означает отдельные хранилища, ограниченный доступ, разные уровни прав и возможность восстановить систему независимо от атакованной инфраструктуры.
Задайте вопрос или оставьте заявку
Есть вопросы по теме статьи? Расскажите о своей задаче команде Qazaqsoft.
Отправляя форму, вы соглашаетесь с обработкой персональных данных.
Почему нельзя просто «закрыть дыру»
После обнаружения атаки компания обычно первым делом отключает подозрительный сервис, блокирует доступы и начинает расследование.
Но если злоумышленник уже находился внутри системы некоторое время, одной блокировки первоначальной уязвимости недостаточно.
Нужно проверить:
Какие аккаунты были скомпрометированы?
Какие ключи и пароли могли быть раскрыты?
Куда перемещался атакующий?
Какие серверы были затронуты?
Остались ли дополнительные точки доступа?
Можно ли доверять существующим резервным копиям?
Именно поэтому после серьёзного инцидента восстановление инфраструктуры может занять гораздо больше времени, чем устранение первоначальной уязвимости.
Что эта история означает для обычного бизнеса?
Необязательно быть крупным туроператором, чтобы столкнуться с подобной проблемой.
У небольшого бизнеса тоже могут быть:
- база клиентов;
- CRM;
- онлайн-оплата;
- личные кабинеты;
- API;
- сервер с файлами;
- административная панель;
- интеграции с другими сервисами.
Чем больше систем связано между собой, тем важнее контролировать не только отдельные компоненты, но и связи между ними.
Минимальный чек-лист для бизнеса
Проверяйте загрузку файлов
Не доверяйте расширению файла. Проверяйте тип, содержимое, размер и права на выполнение.
Не храните секреты в открытых конфигурациях
API-ключи, пароли и токены не должны находиться там, где их легко получить вместе с исходным кодом или конфигурацией.
Разделяйте доступы
Сервис, которому нужен доступ только к одной базе, не должен автоматически получать права администратора всей инфраструктуры.
Делайте изолированные резервные копии
Backup должен оставаться доступным для восстановления даже после компрометации основного сервера.
Следите за логами
Если никто не анализирует логи, система может быть взломана, а компания узнает об этом только после появления очевидных последствий.
Обновляйте используемое ПО
Устаревшие компоненты могут содержать известные уязвимости, которые уже давно используются в реальных атаках.
Проверяйте не только сайт
Безопасность сайта бессмысленно рассматривать отдельно, если через него можно попасть в CRM, базу данных или внутренние сервисы.
Главный вывод
История с Tez Tour — это не только история про взлом одного сайта.
Это пример того, как одна точка входа потенциально может стать началом гораздо более масштабной атаки.
Поэтому при разработке IT-системы недостаточно спросить:
«А защищён ли наш сайт?»
Гораздо важнее спросить:
«Что произойдёт, если наш сайт всё-таки взломают?»
Если после этого вопроса компания всё ещё может восстановить данные, изолировать системы и быстро отключить скомпрометированные доступы — инфраструктура действительно подготовлена к инциденту.
А если вся система держится на одном сервере, одном наборе паролей и резервной копии рядом с основной базой — проблема начинается задолго до самого взлома.
