Full Report
Local media reports three weakly protected accounts at small IT biz whose access to national register was abused
Analysis Summary
# Incident Report: Abuse of National Register Access via Weak Credentials
## Executive Summary
A threat actor compromised Denmark’s Central Register of Persons (CPR) by exploiting three weakly protected accounts belonging to a small IT service provider, Pays ApS. The attacker leveraged administrative access secured by the password "123456" to conduct 14 million automated searches, impacting the data of 8.8 million individuals. The breach was only identified weeks later during a financial review of service invoices.
## Incident Details
- **Discovery Date:** October 2, 2026
- **Incident Date:** September 10 – September 20, 2026
- **Affected Organization:** Pays ApS (Third-party vendor) / Danish Central Register of Persons (CPR)
- **Sector:** Public Sector / IT Services
- **Geography:** Denmark
## Timeline of Events
### Initial Access
- **Date/Time:** September 10, 2026
- **Vector:** Credential Stuffing/Brute Force (Weak Credentials)
- **Details:** The attacker gained access to at least three accounts, including an administrator profile, belonging to the firm Pays ApS. The accounts were reportedly secured with the password "123456."
### Lateral Movement
- **Details:** The attacker utilized Pays ApS’s legitimate, authorized API/portal access to bridge into the national CPR system.
### Data Exfiltration/Impact
- **Date/Time:** September 10 – September 20, 2026
- **Details:** The attacker ran 14 million automated searches against the register, accessing records for 8.8 million people (including active residents, deceased persons, and those abroad).
### Detection & Response
- **October 2, 2026:** Discovery of the breach by a government staffer noticing an unusually high invoice for CPR queries linked to Pays ApS.
- **October 4, 2026:** Notification sent to the Danish Data Protection Authority (Datatilsynet).
- **October 5, 2026:** Public disclosure of the incident.
- **October 9, 2026:** Pays ApS confirms their access was the point of compromise.
## Attack Methodology
- **Initial Access:** Valid Accounts (Weak Passwords).
- **Persistence:** Not explicitly detailed; likely maintained via valid session tokens or repeated logins using known credentials.
- **Privilege Escalation:** Use of a compromised administrator account.
- **Defense Evasion:** Use of legitimate third-party access channels to blend in with authorized traffic.
- **Credential Access:** Likely simple brute force or manual guessing ("123456").
- **Discovery:** Use of automated scripts to query the national register.
- **Collection:** Automated searching/scraping of the CPR database.
- **Exfiltration:** Data was accessed/viewed via 14 million queries; the attacker claimed no intention to sell the data.
- **Impact:** Massive data exposure of nearly the entire Danish population.
## Impact Assessment
- **Financial:** High operational cost for government response; unknown fines for Pays ApS.
- **Data Breach:** Exposure of sensitive CPR data (PII) for 8.8 million individuals.
- **Operational:** Pays ApS website taken offline; third-party access to the CPR likely suspended or restricted.
- **Reputational:** Significant public outcry regarding the lack of Multi-Factor Authentication (MFA) on sensitive national infrastructure.
## Indicators of Compromise
- **Network indicators:** N/A (Legitimate traffic from authorized IPs).
- **File indicators:** N/A.
- **Behavioral indicators:**
- Volume-based anomaly: 14 million searches over a 10-day period.
- Financial anomaly: Unusually high billing/invoicing for API usage.
## Response Actions
- **Containment:** Pays ApS access to the CPR system was disabled.
- **Eradication:** Pays ApS took its own website and internal systems offline.
- **Recovery:** Public notification and briefing of the Data Protection Authority.
## Lessons Learned
- **Key takeaways:** Third-party vendors are a critical weak point; administrative access to national databases must be governed by strict security standards.
- **What could have been done better:** The 12-day delay between the end of the attack and discovery highlights a lack of real-time monitoring and alerting for anomalous API activity.
## Recommendations
- **Enforce MFA:** Mandate Multi-Factor Authentication for all third-party entities accessing national registers.
- **Password Policies:** Implement and audit strong password policies (complexity and uniqueness) for all vendor accounts.
- **Rate Limiting/Throttling:** Implement automated alerts and "kill switches" for API accounts that exceed normal query thresholds.
- **Third-Party Risk Management (TPRM):** Conduct regular security audits of small IT vendors who hold privileged access to sensitive government data.