The Tez Tour breach: a file upload form, a flat network and backups next to the website
On 15 September 2026 the DataSuckers group claimed to have compromised the infrastructure of tour operator Tez Tour. A message about the seizure of its servers appeared on the company's homepage. The company confirmed the breach but rates the consequences far more mildly.
We look at what is known, where the two sides disagree, and which systemic mistakes in
this story repeat from incident to incident.
---
## What the attackers claim
The defaced Tez Tour homepage carried a message to the company's customers and
administrators, along with a list of data allegedly downloaded and destroyed:
| Category | Claimed volume |
|---|---|
| Booking records | 45.4 million |
| Tour orders | 21.5 million |
| Hotel bookings | 52 million |
| Financial transactions | 252 million |
| **Claimed total** | **more than 395 million records** |
According to DataSuckers, access to the infrastructure was gained about two weeks
before the public statement, after which the attackers gradually escalated their
privileges. They also claim that the administrators ran outdated software with known
vulnerabilities and that backups were stored on the same server as the website.
## What the company says
Tez Tour confirmed the incident to Interfax but describes it differently. According to
commercial director Voskan Arzumanov, the incident affected the website, but no signs
of a leak of tourists' or partners' data have been found.
The company's key points:
- immediately after unauthorized activity was detected, measures were taken to
contain the incident and protect the information systems;
- **the ERP system was isolated in time and was not affected**;
- existing bookings remain in place, and obligations to customers are being met as
usual.
## The claimed attack chain
An important caveat: **all technical details come solely from DataSuckers**. There is
no independent audit or forensic report at the time of publication. Below is a
reconstruction based on the attackers' claims, not an established fact.
**1. Entry point — a file upload service.** The service allowed a file to be uploaded
that the web server later executed as PHP code. A classic unrestricted file upload
followed by code execution: the application checked what can be faked (the extension,
the declared MIME type) and didn't check what matters — the actual content and how the
server would interpret the file.
**2. Command execution inside a Docker container.** The attackers were able to run
commands in the container serving the web application.
**3. A flat internal network.** The container itself, according to the group, was
isolated. But the company's internal network with corporate services was reachable
from it. This is the critical point of the whole story, and we'll come back to it
separately.
**4. Credentials in the source code.** From the internal network the attackers reached
SVN repositories with source code and configuration files containing database
passwords.
**5. Tomcat Manager and production.** Access to the Tomcat Manager interface let them
deploy and run code directly in the production environment.
---
## What really matters in this story
### Container isolation is not network segmentation
The most valuable lesson of the incident is in point 3. The container was isolated —
and it didn't help at all.
Containerization solves process and file-system isolation. It **does not** solve
network segmentation. If a web container in the DMZ has network access to internal
corporate services, any code execution in that container automatically becomes a
foothold inside the perimeter.
The practical conclusion: every container and every publicly reachable workload needs
an explicit, documented list of where it's allowed to connect. Everything else is deny
by default. You verify this not with an architecture diagram but with an actual
connectivity test from inside the container.
### Passwords in configs in version control
An SVN repository with configuration files containing production database passwords
isn't a one-day vulnerability. It's accumulated technical debt that turns any access to
the repository into a full data compromise.
Three things help here: moving secrets into a dedicated store (HashiCorp Vault, cloud
KMS, or at the very least encrypted environment variables), automatic secret scanning
of repositories in CI/CD, and — without fail — rotating every secret that has ever
made it into the commit history. Deleting a file from HEAD doesn't delete the password
from history.
### Backups on the same server
According to the attackers, backups were stored on the same server as the website. If
that's confirmed, compromising the web server meant losing both production and the
means to recover it at the same time.
The 3-2-1 rule exists for exactly this scenario: three copies of the data, on two
different media, one off-site — and at least one copy must be logically unreachable
from the production environment (offline, immutable storage or WORM).
### An exposed Tomcat Manager
An application server management interface reachable from the internal network
without additional controls is a direct road to code execution in production.
Administrative interfaces (Tomcat Manager, CI/CD panels, hypervisor consoles, database
web UIs) should be reachable only from a dedicated administrative segment, behind MFA
and with every session logged.
### Two weeks of presence
A claimed dwell time of about two weeks isn't about the attackers' sophistication.
It's about the lack of detection. Gradual privilege escalation, internal network
reconnaissance, access to SVN, deployment through Tomcat Manager — each of these steps
produces telemetry. The problem is that nobody collected or analyzed it.
---
## A short checklist
If you're reading this as an IT or security lead, here are six questions worth asking
your team today:
1. Which public forms accept files, and do we check the content rather than the
extension?
2. Where can our web container actually reach on the network? Verified by a test,
or assumed?
3. Are there passwords in our repositories — including the commit history?
4. Is there at least one backup copy that can't be reached from production?
5. Who can open Tomcat Manager, the CI/CD panel or the hypervisor console, and from
where?
6. If an attacker spends two weeks in our network, which specific alert will we see?
The sixth question is the most uncomfortable and the most important.
---
*This article is based on the parties' public statements. The technical details of the
attack chain are given as claimed by the DataSuckers group and have not been confirmed
by an independent audit. The company's position is cited from Interfax:
https://www.interfax.ru/russia/1116299*