Skip to content
Cyber Threat
CTI Academy Sponsor CTI Academy
Ransomware victim Construction

pau.at

Listed by Safepay on · organisation based in Austria

pau.at

Disclosed
Dec 29, 2025
Leak-site listing date
Threat group
Safepay
634 victims listed
Country
Austria
#30 most targeted
Sector
Construction

ThreatAI analysis

Compiled from this incident record and the threat intelligence profile for Safepay. Figures and technique mappings are quoted from the source data, not inferred.

About the Safepay group

SafePay emerged in September 2024 as a rapidly growing ransomware operation that explicitly disavows the RaaS model and manages all operations internally, claiming over 300 victims worldwide by mid-2025 with a high-profile early attack against UK telematics firm Microlise stealing 1.2 TB of data. Safepay has listed 591 victims since November 2023.

How Safepay is documented to operate

Valid Accounts T1078 Stealth Persistence

Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Compromised credentials may be used to bypass access controls placed on various resources on systems within the network and may even be used for persistent access to remote systems and externally available services, such as VPNs, Outlook Web Access, network devices, and remote desktop. Compromised credentials may also grant an adversary increased privilege to specific systems or access to restricted areas of the network.

Mitigations: Application Developer Guidance, User Training, Password Policies, User Account Management, Privileged Account Management, Multi-factor Authentication

MITRE ATT&CK reference
Replication Through Removable Media T1091 Lateral Movement Initial Access

Adversaries may move onto systems, possibly those on disconnected or air-gapped networks, by copying malware to removable media and taking advantage of Autorun features when the media is inserted into a system and executes. In the case of Lateral Movement, this may occur through modification of executable files stored on removable media or by copying malware and renaming it to look like a legitimate file to trick users into executing it on a separate system. In the case of Initial Access, this may occur through manual manipulation of the media, modification of systems used to initially format the media, or modification to the media's firmware itself.

Mitigations: Limit Hardware Installation, Behavior Prevention on Endpoint, Disable or Remove Feature or Program

MITRE ATT&CK reference
Drive-by Compromise T1189 Initial Access

Adversaries may gain access to a system through a user visiting a website over the normal course of browsing. Multiple ways of delivering exploit code to a browser exist (i.e., Drive-by Target), including: A legitimate website is compromised, allowing adversaries to inject malicious code Script files served to a legitimate website from a publicly writeable cloud storage bucket are modified by an adversary Malicious ads are paid for and served through legitimate ad providers (i.e., Malvertising) Built-in web application interfaces that allow user-controllable content are leveraged for the insertion of malicious scripts or iFrames (e.g., cross-site scripting) Browser push notifications may als…

Mitigations: Restrict Web-Based Content, User Training, Application Isolation and Sandboxing, Exploit Protection, Update Software

MITRE ATT&CK reference
Exploit Public-Facing Application T1190 Initial Access

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration. Exploited applications are often websites/web servers, but can also include databases (like SQL), standard services (like SMB or SSH), network device administration and management protocols (like SNMP and Smart Install), and any other system with Internet-accessible open sockets. On ESXi infrastructure, adversaries may exploit exposed OpenSLP services; they may alternatively exploit exposed VMware vCenter servers.

Mitigations: Vulnerability Scanning, Limit Access to Resource Over Network, Filter Network Traffic, Network Segmentation, Privileged Account Management, Application Isolation and Sandboxing

MITRE ATT&CK reference

MITRE ATT&CK techniques attributed to Safepay across its recorded activity, not a finding about how pau.at was reached.

Incident analysis

pau.at was listed by Safepay ransomware, a group with 634 victims recorded in this database. The listing appeared on the group's leak site on December 29, 2025.

pau.at is based in Austria and operates in the Construction sector. Austria ranks #30 worldwide for ransomware disclosures, with 118 victims in this database.

Sector context. Construction firms often hold sensitive project data, client financials, and intellectual property. The industry's typically lean IT security teams can make them more vulnerable.

Safepay typically follows a double extortion model: data is exfiltrated from the victim's systems before files are encrypted, so the victim faces two demands at once — pay to restore access, and pay to keep stolen data unpublished. The leak site, where this listing appeared, is the lever for the second demand.

Source. Public leak-site disclosures aggregated via the ransomware.live API. The disclosure date is when the listing was published, which can differ from the date of compromise. This site does not publish or link to stolen data. Last updated .

Frequently asked questions

Was pau.at attacked by ransomware?

Yes. pau.at was listed as a victim of the Safepay ransomware group on December 29, 2025. The organisation is based in Austria and operates in the Construction sector. The disclosure appeared on the group's dark web leak site.

Which ransomware group attacked pau.at?

pau.at was attacked by Safepay ransomware. Safepay is one of the most active ransomware groups, having claimed 634 victims globally. The group typically employs a double-extortion model: encrypting the victim's files and threatening to publish stolen data.

When did the pau.at ransomware attack occur?

The ransomware attack on pau.at was disclosed on December 29, 2025. This date reflects when the victim was published on the threat group's leak site, which may differ from the actual date of initial compromise.

What data was stolen in the pau.at ransomware attack?

The specific data stolen from pau.at has not been independently verified by this platform. Ransomware groups typically exfiltrate data before encrypting systems and use the threat of publication to pressure victims. As a Construction organisation, pau.at likely held sensitive business data, client information, and operational records.

How can organisations protect against Safepay attacks?

To defend against Safepay and similar threat actors, organisations should: maintain regular offline backups tested for restoration; implement network segmentation to limit lateral movement; deploy multi-factor authentication on all remote access; use endpoint detection and response (EDR) tools; conduct regular phishing and security awareness training; and monitor threat intelligence feeds for indicators of compromise (IOCs) associated with active groups.