16.07.2026

Data, honeypots and cybersecurity

How can a single unpatched server cost the economy hundreds of thousands of euros?

Picture the scene. Late on a Friday night – or during a Latvian national holiday, when most of us are off work – an attacker, probably somewhere in Western Europe, sits down at a computer and launches an automated scanner. Not a state-sponsored hacking group. Not a sophisticated APT operation. A beginner with less than a year of experience, who had already attacked companies elsewhere in the world and publicly documented each step on a hacker forum as a trophy.

He finds a single unpatched server. That is enough for Latvia’s largest state-owned company, with annual revenue of EUR 604 million, to disconnect its external and internal systems for several days; suffer a public data breach; see backups deleted; face the risk of ransomware encryption; and later receive a publicly posted ransom demand worth several hundred thousand euros. Suddenly, this becomes the biggest challenge on your desk for the next several weeks – or even months.

I have worked in cybersecurity for more than 15 years. The incident itself did not surprise me. What is unusual – and valuable – is how much it can teach us.

The attacker did not need sophisticated technology. Only patience – and time, while the rest of us were enjoying the holidays. A classic scenario.

How could this happen?

In attacks like this, the initial entry point is often one of the company’s internet-facing resources used by customers or partners – in other words, a publicly exposed service or application. One such server was running with a two-year-old, unpatched vulnerability. The attacker only had to find that single, slightly neglected system and turn it into an open gate, with a thousand ways to disrupt operations, inflict serious financial and operational losses, and damage the company’s reputation.

From that foothold, an attacker will typically move laterally through the internal network, exploiting other old vulnerabilities – sometimes six to eight years old – and outdated software versions. They gain access to critical resources such as the central identity and access directory, which effectively means control over the rest of the IT environment. The next step is privilege escalation: granting themselves administrative rights and, with them, control over the wider infrastructure and users’ workstations. From there, the path leads to backup systems, email, source code and password managers.

Targeting backup systems is standard ransomware practice. If there are no recoverable backups, the victim has few options. In this case, the company refused to pay, stating that some backups had survived. The stolen data was nevertheless released publicly.

Anatomy of the attack: a timeline

Phase 1: Reconnaissance – the attacker scans publicly accessible systems and finds an unpatched server.
Phase 2: Initial access – exploitation of the vulnerability, with no phishing or social engineering required.
Phase 3: Lateral movement – compromise of Active Directory, vCenter and backup systems.
Phase 4: Data exfiltration – double extortion: data is both stolen and encrypted.
Phase 5: Ransomware deployment – timed for a holiday, with fewer staff present and slower response.
Phase 6: Ransom demand – posted publicly on a forum with screenshots and a six-figure demand. MITRE ATT&CK: TA0001, T1190, TA0004, TA0008, TA0010, T1486.

Why do these attacks happen on weekends and public holidays?

Holiday attacks are not a coincidence. They are a strategy. Attackers know that IT teams are smaller, response is slower and senior decision-makers are harder to reach. That is exactly how this incident unfolded.

The recovery process took so long that, even days after the incident, the company could not restore its systems because it first had to be sure no malware remained. That caution is understandable. But while the investigation continued, services were unavailable, partners had no access and employees had to work manually.

An organisation with 24/7 SOC monitoring would not have ended up in this situation. Not because a SOC makes an organisation impossible to breach, but because an L1 analyst working during the holiday would have noticed unusual activity on the public-facing server and begun investigating while the attacker was still looking for a route to Active Directory.

We often say cybersecurity is a 24-hour problem. We talk far less about the fact that our defences often operate for only eight hours a day.

Honeypots: what could we have learned if the attack had targeted a simulated cyber decoy?

Here I want to pause on a concept that is still used far too rarely in Latvia. A honeypot is a deliberately created decoy resource – a server, account or document that looks real and valuable but contains nothing of value. By definition, any attempt to access it is suspicious.

If a honeypot server designed to resemble the real public platform had been deployed alongside it, the attacker’s automated scanner would probably have found both. The first connection to the honeypot would have triggered an immediate SOC alert. Before the attacker reached the real system, the analyst would already have seen the attack method, vulnerability identifier and source IP address.

More important, however, is what the attacker would reveal. In a honeypot environment, attackers expose their tactics. Which reconnaissance tool are they using? Which lateral-movement route do they choose after gaining access? That information allows the organisation to adapt its defences in real time – before the attack reaches the real target.

In this case, honeypot elements inside Active Directory – decoy administrator accounts with convincing names – would have triggered during the lateral-movement phase. Honeytoken documents with embedded web beacons could have helped track exfiltrated data even after it left the network. A decoy backup server would have exposed attempts to destroy backups long before the ransomware was activated.

WHAT A HONEYPOT MEANS IN PRACTICE

A honeypot is not an off-the-shelf product, but an architectural principle. It can take the form of decoy servers at the network perimeter, fake Active Directory accounts with plausible names, decoy documents containing beacon technology, or false backup resources. Datakom SOC’s Active Defense component uses honeypots and digital fingerprinting as part of the overall defence architecture.

Open-source tools - and their limitations

We also need to be honest about one point. Many state-owned companies and public-sector organisations across Latvia and Europe rely on widely respected open-source security tools such as Wazuh, Security Onion, Elastic SIEM and Velociraptor, along with many other free and open-source solutions. These are technically capable tools, and using them is entirely reasonable – provided they are properly managed.

The problem begins when an organisation mistakes installing tools for having security. A tool without an analyst is a log repository. An alert nobody sees effectively does not exist. Automated detection without automated response means that a valuable alert raised on Sunday night waits until Monday morning.

System recovery took days longer than it should have because the organisation could not rapidly check every server for remaining malware. A commercial EDR platform with centralised forensic capabilities could have performed that check across all systems in parallel, within hours.

This is not an argument against open-source solutions. It is an argument that tools must sit inside a broader system – one with people who monitor them, automation that responds, and processes that ensure continuity

We often say cybersecurity is a 24-hour problem. We talk far less about the fact that our defences often operate for only eight hours a day.

What every organisation can learn from this

This incident is not unique. It is not the first, and it will not be the last. It is a symptom. The attacker exploited a vulnerability that had been publicly known for years. They struck during a holiday. They entered through one forgotten server and used it to gain full control. Every one of those steps can be detected – and prevented.

Three questions I recommend asking yourself – or your IT manager – today:

Do you know how many unpatched vulnerabilities are present in your environment right now, including in systems that are normally excluded from routine patch management?
If something similar were happening in your systems at this very moment, would anyone notice? How quickly?
If your IT team is on holiday or off for the weekend, does security monitoring continue without them?

If you cannot answer any one of these questions clearly and confidently, you are in the same risk category. The attacker who eventually finds you will not need sophisticated technology. Only time – and one open window.

We often say cybersecurity is a 24-hour problem. We talk far less about the fact that our defences often operate for only eight hours a day.

Datakom's perspective - and our responsibility

I have worked in cybersecurity long enough to know that the strongest arguments for a Security Operations Centre, or SOC, rarely come from PowerPoint presentations. They come from real incidents.

The LVM case is exactly that: a real incident in a real organisation, with real consequences. I do not want to use it as a scare story. I would rather use it as a mirror – and a reminder to review the state of our own digital environment.

Because almost every public institution, large company and smaller business has a server that nobody has thought about for at least two years. A system that falls outside routine patch management. An alert delivered to an inbox at night and left unread until morning.

That is why cybersecurity must be understood as more than a tool or platform. It is not enough to ask whether an organisation has a SIEM, EDR, vulnerability scanner or backup solution. The more important question is whether these elements together create the ability to detect, understand and stop an incident before it becomes a crisis.

When developing our cybersecurity services, we paid particular attention to how they would work in practice – not only in the ideal scenario, when everyone is at work, every alert is reviewed immediately and every system is fully visible, but also when an incident happens at night, over a weekend or during a public holiday; when the IT team is operating with reduced staffing; and when there are many alerts, but only one may point to a real threat.

In practice, cybersecurity capability is not a single tool or platform. It is a combination of continuous monitoring; people who can separate a meaningful signal from noise; automation that helps contain a threat before manual action begins; regular vulnerability management; active-defence measures such as honeypots; and thorough incident documentation.

Incident documentation is just as important as effective action, because organisations must be able to demonstrate what they have done – especially in the context of NIS2 and Latvia’s National Cybersecurity Law. It is not enough to say that security is being managed. An organisation must be able to show how it monitors risk, responds to incidents, manages vulnerabilities and makes decisions about security improvements.

The LVM incident began on Midsummer morning. The latest amendments to the National Cybersecurity Law entered into force on 18 June. In October, a new wave of companies will fall within the scope of the law. This is therefore not only a story about one incident. It is a question of whether organisations will use this moment to build genuine cybersecurity capability – or merely meet the requirements on paper.

Autors:
Artūrs Filatovs
Drošības risinājumu produktu vadītājs