Registrų centras: 600,000 Records Leaked — and How to Prevent It on Your Server

Between January and April 2026, more than 600,000 records were stolen from Lithuania’s national real estate registry: personal identification codes (asmens kodai), addresses, and property ownership data. Registrų centras is Lithuania’s central state registry, maintaining records on real estate, legal entities, and the population. The breach wasn’t caught by monitoring, by CERT, or by a security team — it was spotted by the mayor of Neringa, Darius Jasaitis. Registrų centras gives every citizen the ability to check who has queried their data in the registry and when. On February 18, Jasaitis used that feature — and among the familiar entries (notaries, journalists) he saw connections from the Vidaus reikalų ministerija (Ministry of Internal Affairs) at odd hours. That seemed off: why would the Interior Ministry be pulling his property data in the middle of the night? He raised the question with the relevant authorities. No one responded. The data kept leaking for another two months.

The scale and fallout were significant. Registrų centras director Adrijus Jusas stepped down three days after the breach became public. The Prosecutor General’s Office opened a criminal investigation. The NKSC classified the incident as major and launched an audit. The president’s national security adviser called the security measures that had been in place “completely ineffective.” The attack is believed to have been organized from a foreign state — no official attribution has been made, and the investigation is ongoing.

HOW THE ATTACK WORKED

The attack was simple and effective precisely because it required no technical sophistication. The attackers obtained the logins and passwords of two Migracijos departamentas (Migration Department) employees — presumably by compromising their personal email accounts. Migration Department director Indrė Gasperė confirmed at a press conference that the connections to Registrų centras were made using real email addresses and passwords belonging to real department staff. Whether the passwords were lost carelessly by the employees themselves or stolen through other means is still being established by investigators.

From there it was purely mechanical. Registrų centras provides API access to its registries for more than 20,000 users — government agencies, notaries, journalists. Authentication was login and password only, with a required password change every three months. No MFA. With the credentials of two Migration Department employees in hand, the attackers logged in as legitimate users and methodically pulled records from the real estate registry — at night, on weekends, returning to the same properties multiple times. February data on one property, April data on another. Four months.

The Migration Department’s own systems, according to the department itself, were never breached — the attackers simply used stolen credentials to connect directly to Registrų centras’s API, bypassing the source institution entirely. That’s an important distinction: nothing was hacked in the conventional sense. They walked through the front door with someone else’s key.

TIMELINE

January 2026 — first unauthorized connections to the Registrų centras API using Migration Department employee credentials. February 2026 — Neringa mayor Darius Jasaitis reviews the query history on his data in the registry and finds connections from the Vidaus reikalų ministerija (Ministry of Internal Affairs) outside business hours. He contacts the authorities. No response.

April 2026 — Registrų centras finally detects the breach, blocks the compromised accounts, and reports the incident to law enforcement and the National Cybersecurity Centre (NKSC). A decision is made not to notify citizens until the circumstances are clarified. May 2026 — the 15min news portal asks Registrų centras about the breach, and the company confirms the incident. The Prosecutor General’s Office immediately announces a criminal investigation. Citizens are given the ability to check whether their data was affected.

Bottom line: the breach ran for around four months. Citizens were kept in the dark for roughly two months after Registrų centras itself became aware of it. The director steps down three days after public disclosure.

WHY IT MATTERS

An asmens kodas in Lithuania isn’t just a number. It’s used everywhere: banking identification, government portals, medical records, notarial transactions. The attackers walked away with names, surnames, personal codes, dates of birth, addresses, and property data — enough to convincingly impersonate someone in official communications or locate them physically. For an ordinary citizen this is an unpleasant leak. For certain categories of people, it’s a physical safety risk.

The scale of access makes this a systemic problem. Twenty thousand users with direct API access to state registries, authenticated by password alone — that’s not one vulnerability, that’s 20,000 potential entry points. You don’t need to attack Registrų centras directly. Compromise any one of the connected institutions and you’re in. That’s exactly what happened: the attackers never touched the central system — they slipped through a side door that nobody was guarding.

And then there’s the response. The first signal appeared in February, from a citizen, not from a monitoring system. Nothing happened. The data leaked for two more months. When Registrų centras finally caught the breach in April, citizens still weren’t notified for another two months, with the justification that the facts needed to be verified first. GDPR requires notifying the supervisory authority within 72 hours of discovering a breach. About two months passed.

HOW TO PREVENT IT

This incident is worth analyzing not because the attack was sophisticated — it wasn’t. It’s worth analyzing because every single failure that made it possible shows up in half the corporate and government systems running right now.

Start with MFA. A password that gets rotated every three months protects you right up until the moment it’s stolen. After that, the attacker has up to three months of legitimate access — which is exactly what happened here. MFA closes that scenario entirely: a stolen password without the second factor is worthless. For any API touching citizens’ personal data, MFA shouldn’t be optional — it should be a hard requirement for access. No exceptions for “internal” institutions, because internal institutions turned out to be the attack vector. One caveat worth noting: for a small personal server where SSH is key-only, that’s already a solid level of protection. MFA becomes mandatory when you have many users from different organizations, and nobody is monitoring how each of them stores their credentials. That was exactly the architecture at Registrų centras — 20,000 users from dozens of institutions, and not a single second factor anywhere.

Next: behavioral monitoring. A government agency pulling thousands of records from a real estate registry on a Saturday night isn’t normal behavior. That pattern should automatically trigger an alert and session block pending review. Registrų centras was writing logs — citizens could check their own query history, which means the data was being recorded. But nobody was watching it in real time. An audit log nobody monitors is an archive for post-mortems, not a security tool. The difference between those two things was four months of data walking out the door.

Then there’s rate limiting. Six hundred thousand records over four months is thousands of requests. A notary pulls one specific property for a client’s transaction. A journalist checks a few properties for a story. No legitimate user bulk-downloads the entire registry. A per-session or per-day request cap is an elementary control that physically limits the damage even when an account is fully compromised. It wasn’t there.

Finally — least privilege. Twenty thousand users with access to the real estate registry isn’t an architectural decision, it’s the absence of one. A Migration Department employee needs access to data on specific migrants, not the entire national property registry. A notary needs access to a specific property on request, not the whole database. Granular permissions by role and institution would have reduced the potential blast radius by orders of magnitude — even if every other control had failed.

WHAT TO DO

If you’re administering systems with API access to personal data — check the following right now. Is MFA enabled for all external users? Are there alerts for connections outside business hours? Is there rate limiting on the number of records per session? When was the last time you audited active accounts and their privilege levels?

Start with SSH — check whether MFA is configured or at minimum whether passwords are disabled:

# Verify passwords are disabled and key-based auth is the only option
grep "PasswordAuthentication\|PubkeyAuthentication\|AuthenticationMethods" /etc/ssh/sshd_config

# Expected output:
# PasswordAuthentication no
# PubkeyAuthentication yes

If passwords aren’t disabled, that’s the first thing to fix. If you want to add a second factor on top of keys — install libpam-google-authenticator and set AuthenticationMethods publickey,keyboard-interactive in sshd_config. A stolen key without the TOTP code is useless — and that’s exactly what the Migration Department employees were missing.

For Lithuanian citizens: Registrų centras has opened a way to check whether your data was affected through the company’s self-service system at registrucentras.lt — electronic identification is required. If the query history shows connections from unfamiliar institutions outside business hours, your data was likely among those accessed. That’s exactly how the mayor of Neringa spotted the breach.

It’s worth being specific about what was actually leaked. According to Registrų centras’s official statement, only data from real estate registry extracts was exposed: name, surname, asmens kodas, date of birth, address, and property details. Phone numbers, email addresses, bank accounts, payment data, court rulings, and cadastral documents were not affected. ESET security expert Ramūnas Liubertas clarified in an LRT interview that a fraudster can’t take out a loan with just a name, surname, and asmens kodas. But an asmens kodas combined with an address and property data is already enough for convincing social engineering.

Social engineering is the main threat for ordinary people. The mechanics are simple: a fraudster calls or messages you, drops your name, asmens kodas, exact address, and property details — and that creates the impression that they’re legitimate, that they’re from an official institution, that they can be trusted. Those details used to be known only to you and to government agencies. Now they’re available to anyone who has this database.

Here’s what it looks like in practice. A call: “Good afternoon, this is Swedbank, we’re seeing suspicious activity on your account. To verify your identity, please provide your internet banking password” — and they mention your exact address to convince you it really is the bank. Or a letter from a “notary” with your asmens kodas and property address: “Your presence is required for a real estate transaction at address X” — with a link asking you to confirm your identity. Or a message from “Valstybinė mokesčių inspekcija” with accurate details about your property: “A debt has been identified, pay within 24 hours to avoid penalties.”

In all these scenarios, personal data isn’t used for direct theft — it’s used to establish trust, after which the victim hands over what’s actually needed: a password, a confirmation code, money. That’s social engineering — manipulating the person, not breaking the system.

The rule for protecting yourself: any unsolicited contact that uses your personal data to prove its own legitimacy is a red flag, not a sign of trust. A real bank doesn’t call you first and ask for your password or confirmation code. A real tax authority sends official letters through portals with digital signatures, not SMS links. If you’re not sure — hang up and call the institution yourself using the official number from their website.

At the system level, this incident should prompt a review of access architecture for all government registries — not just in Lithuania. Federated identity with MFA, behavioral monitoring, rate limiting, granular permissions by role — these aren’t cutting-edge technologies. They’re basic hygiene for 2026. The fact that 20,000 users had access to sensitive data with only a password isn’t technical debt — it’s an architectural decision that needs to be revisited.

If you’re running a service with API access to data — here are concrete examples of what should be in place right now.

Rate limiting in nginx: cap the number of requests to API endpoints by IP and by authenticated user. Without this control, an attacker with valid credentials can pull data at network speed:

# Rate limiting zone — 100 requests per minute per user
limit_req_zone $http_authorization zone=api_user:10m rate=100r/m;

server {
    location /api/ {
        limit_req zone=api_user burst=20 nodelay;
        limit_req_status 429;

        # Log rate limit hits separately for alerting
        access_log /var/log/nginx/api_ratelimit.log combined;
    }
}

Monitoring for anomalous patterns in nginx logs — finding accounts with suspiciously high request volumes:

# Top 10 IPs by request count in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | \
  sort | uniq -c | sort -rn | head -10

# Requests outside business hours (10 PM - 6 AM)
grep -E ' (2[2-9]|0[0-6]):[0-9]{2}:[0-9]{2} ' /var/log/nginx/access.log | \
  awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20

Blocking in nftables after a rate limit is hit — automated response to anomalous activity. The nginx + fail2ban + nftables stack closes the scenario where the rate limit fires but requests keep coming from the same IP:

# /etc/fail2ban/filter.d/nginx-api-ratelimit.conf
[Definition]
failregex = ^<HOST> - - \[.*\] "GET /api/.*" 429

# /etc/fail2ban/jail.d/nginx-api.conf
[nginx-api-ratelimit]
enabled  = true
port     = http,https
filter   = nginx-api-ratelimit
logpath  = /var/log/nginx/api_ratelimit.log
maxretry = 10
findtime = 60
bantime  = 3600
action   = nftables-multiport[name=nginx-api, port="http,https"]

Audit logging for sensitive file and directory access via auditd. In the Registrų centras case, logs were being written — but nobody was watching them in real time. With the right auditd rules, alerts fire immediately:

# Monitor access to the user data directory
auditctl -w /var/lib/app/userdata/ -p rwxa -k userdata_access

# Monitor bulk file reads by a single process
auditctl -a always,exit -F arch=b64 -S open,openat -F dir=/var/lib/app/userdata/ \
  -F success=1 -k bulk_read

# View alerts in real time
ausearch -k userdata_access --start today | aureport -f -i

# Top processes accessing data today
ausearch -k bulk_read --start today | awk -F'comm=' '/comm=/{print $2}' | \
  awk '{print $1}' | sort | uniq -c | sort -rn

Quick check for active sessions and unusual connections right now:

# Active connections by IP count — an abnormally high number is suspicious
ss -tn state established | awk '{print $5}' | cut -d: -f1 | \
  sort | uniq -c | sort -rn | head -20

# Connections to the API port from external IPs (example for port 8443)
ss -tnp | grep ':8443' | awk '{print $5}' | cut -d: -f1 | \
  sort -u

# Last 50 unique IPs that connected to the API
awk '{print $1}' /var/log/nginx/access.log | \
  sort -u | tail -50

WHAT HAPPENS NEXT

The incident isn’t closed — it’s still unfolding. The NKSC has announced a cybersecurity audit of Registrų centras to establish the exact breach mechanism and what needs to change. The Ministry of Economy and Innovation, which owns Registrų centras, has opened a search for a new director — with an explicit statement that cybersecurity is now the top priority. Lithuania’s Data Protection Inspectorate (VDAI) has already indicated that the company could face a fine of up to 60,000 euros under GDPR — for failing to notify affected citizens in time. The Prosecutor General’s Office continues its investigation, with details under pre-trial confidentiality.

One question that’s been on many people’s minds: can the asmens kodas be changed? The official answer is no. Registrų centras spokesperson Mindaugas Samkus stated clearly in an LRT interview that the asmens kodas is governed by legislation — citizens can’t change it the way they’d change a password. That makes this breach fundamentally different in character: a compromised password takes a minute to reset, a compromised identifier stays with a person permanently. Which is exactly why awareness of social engineering matters more here than any technical fix on the victim’s side.

Lithuania isn’t an outlier in this incident — it’s part of a systemic European problem. Government registries with broad API access, weak authentication, and insufficient monitoring have been targeted in other countries too. What makes this case distinctive is that the attack vector wasn’t a code vulnerability or a direct intrusion — it was compromising credentials at a connected institution. That means any government system with tens of thousands of external users carries the same risk if it isn’t running MFA and behavioral monitoring. The Registrų centras incident is a warning for every government registry in Europe.

HOW TO PREVENT THIS ON YOUR SERVER

Registrų centras is a government registry, but the vulnerabilities that led to this breach show up on any server with API access to data. Here are three levels where protection needs to be built.

Process level — organization, not just technology. Technical controls without processes don’t work. Specifically: define who receives alerts from fail2ban and auditd — and make sure that person actually reads them, not just has access to the inbox. Set up regular access reviews — every quarter, check who has API access, look for long-departed employees with active tokens, verify whether user roles have changed. Document an incident response plan: what to do in the first 30 minutes after detecting an anomaly, who to notify, when to block access. At Registrų centras, the first signal came in February — and disappeared into silence precisely because there was no process for handling it.

Architecture level — Zero Trust for inter-system access. The assumption that “the internal network is a trusted zone” is obsolete. When 20,000 users from dozens of institutions have direct API access via password, that’s not an internal network — it’s a public interface with the illusion of isolation. The right architecture: federated identity through a central identity provider (Keycloak or equivalent), where each institution authenticates through its own IdP rather than direct credentials. Access is granted at the scope level — specific operations for specific roles, not blanket registry access. Between systems — short-lived tokens with automatic rotation, not long-lived passwords. That’s Zero Trust in practice: trust nothing by default, verify every request.

Pre-launch checklist for an API handling personal data. If you’re deploying or auditing such a service — run through this list:

• MFA enabled for all users — not just administrators
• Passwords disabled where keys or tokens are used
• Rate limiting configured — request caps per user and per IP
• Audit logging enabled with alerts set for anomalous patterns
• Least privilege applied — each role accesses only what it needs
• Off-hours monitoring in place — requests at 2 AM should trigger an alert
• Access review procedure documented and scheduled
• Incident response plan exists and is known to the team
• Alert delivery tested — confirm alerts actually reach the right people

None of these require expensive solutions. Every single one was missing at Registrų centras — and that’s why the breach ran for four months.

CONCLUSIONS

The Registrų centras breach isn’t a story about a sophisticated APT attack with zero-day exploits. It’s a story about a stolen password, no MFA, and monitoring that wasn’t working. The attackers didn’t break anything — they walked through the front door with someone else’s key and methodically carried data out for four months. The system didn’t notice. A citizen did.

The most uncomfortable takeaway from this incident: the asmens kodas of 600,000 Lithuanians is now in someone else’s hands permanently. It can’t be reset like a password. The property data won’t change. It’s a long-term resource for whoever has it — whether that’s fraudsters or intelligence services.

For everyone administering systems that handle personal data — this case is worth printing out and pinning above your monitor. Not as a scare story, but as a checklist of what should be in place by default: MFA, anomaly detection, rate limiting, least privilege, audit logging with alerts. Any one of those controls, on its own, could have stopped this attack.

UPDATES

June 2, 2026. Registrų centras officially stated that the company did not independently analyze the breach — it has not examined which specific data was stolen or whether there are any patterns. All information has been handed over to the Prosecutor General’s Office. Spokesperson Mindaugas Samkus: “Registrų centras has not analyzed any of the data disclosed as a result of this incident. We have transferred all available information to the law enforcement authorities conducting the investigation.”

June 2, 2026.Minister of Economy and Innovation Edvinas Grikšas told the Seimas that the incident was not an isolated failure but the result of financial, technological, and governance problems accumulated over many years: “Signals about growing risks in the security of state information resources have been visible and reported for a long time.” According to him, IT problems in the public sector were only addressed when the situation became critical.

June 5, 2026. Registrų centras published an official incident timeline. The breach was formally classified as a personal data violation on May 7 — before that, the company was collecting responses from government agencies to establish the circumstances. The VDAI was notified the same day. The Prosecutor General’s Office opened a preliminary investigation on April 15 and only authorized public disclosure on May 22 — until then, all parties were bound by communication restrictions under the active investigation. According to VDAI, just over 600,000 registry extracts were leaked, but the number of affected citizens is approximately 500,000 — some individuals appear in multiple extracts. Preliminary damages are estimated at a minimum of 111,000 euros.

June 5, 2026. According to TV3 and LRT, the breach was first detected not by a monitoring system or the mayor of Neringa — but by a private financial group. Its representatives contacted law enforcement after noticing that someone from Interior Ministry structures was checking the personal data and property records of their executives and family members during nights and weekends. This report triggered the official investigation in April. Neringa mayor Darius Jasaitis had flagged the anomaly back in February — but nobody acted on it at the time. It has also been confirmed that one Migracijos departamentas employee account was used, not several as previously reported.

June 16, 2026. A detail has emerged that explains why the attack wasn’t stopped sooner. The Interior Ministry was aware of suspicious activity in early 2026, but when it requested information from Registrų centras, the registry demanded payment for the extract. The price: 2.64 euros. Interior Minister Vladislavas Kondratovičius told the Seimas: “I didn’t have 2.64 euros at that moment, so I couldn’t find out who was using the information system.” Once the ministry paid, Registrų centras identified which account had been compromised — and that’s when the breach was stopped. Registrų centras subsequently billed the Interior Ministry 100,000 euros for additional services. Kasčiūnas in the Seimas: “We asked whether a crisis management structure had been set up. It’s clear that no such structure had even been planned.”

June 19, 2026. President Gitanas Nausėda in his annual address to the Seimas: “Less than a month ago — far later than it should have been — everyone learned about the data theft from Registrų centras. The malicious activity was not only not identified and stopped in time, but also created even greater danger for Lithuanian residents due to the excessively slow response of state institutions.” The Seimas voted on June 19 to establish a parliamentary investigation commission — 61 in favor, 21 against. The commission will review the security of state registries for the period 2020–2026.

PS

This incident makes one thing clear: cutting corners on IT security isn’t saving money — it’s deferring a bill that always comes due with interest. We live in a world where new vulnerabilities are discovered every day. Patches, audits, monitoring, MFA — these aren’t expenses, they’re infrastructure. A government that skimps on protecting its citizens’ data is transferring that risk onto the citizens themselves. And when the bill arrives, it isn’t paid by officials — it’s paid by 600,000 people whose data is now in someone else’s hands permanently. Symbolic detail: the breach couldn’t be stopped sooner in part because one government agency couldn’t pay another 2.64 euros for information about the compromised account.