Full Report
Wiz Threat Research identified a malicious campaign targeting weakly configured and publicly exposed PostgreSQL servers to deploy a XMRig-C3 cryptominer. In observed attacks, the threat actor exploited exposed PostgreSQL instances, abused the COPY FROM PROGRAM function to exec...
Analysis Summary
# Incident Report: PostgreSQL Cryptomining Campaign via COPY FROM PROGRAM Abuse
## Executive Summary
Wiz Threat Research uncovered a malicious campaign targeting publicly exposed and weakly configured PostgreSQL servers. Threat actors gained initial access via brute-force credential stuffing, leveraged the vulnerable `COPY FROM PROGRAM` function for remote code execution, and deployed a fileless XMRig-C3 cryptominer executed primarily in memory using `memfd_create` to evade disk-based security solutions. The observed scope suggests compromise of over 1,500 machines across various organizations.
## Incident Details
- Discovery Date: February 27, 2025 (Wiz Pub. Date)
- Incident Date: Active campaign targeting older vulnerabilities and misconfigurations.
- Affected Organization: Multiple organizations with exposed PostgreSQL instances (Not individually disclosed).
- Sector: Varied (Organizations utilizing PostgreSQL databases).
- Geography: Global (Implied by threat actor scanning).
## Timeline of Events
### Initial Access
- Date/Time: Pre-Discovery (Occurred during active scanning/attack phase)
- Vector: Software Misconfiguration and Password Attack.
- Details: Threat actors scanned for publicly exposed PostgreSQL instances, often leveraging default weak credentials, followed by credential-stuffing attacks for authentication.
### Lateral Movement
- Date/Time: Post-Authentication
- Vector: Exploitation of PostgreSQL functions.
- Details: Once authenticated, the actor used the `COPY FROM PROGRAM` function to execute initial shell commands, leading to the download and execution of dropper scripts (`pg_core`).
### Data Exfiltration/Impact
- Date/Time: Post-Execution
- Vector: Resource Hijacking (Cryptomining).
- Details: The primary impact was resource hijacking for Monero (XMRig-C3) mining. The actor also created a rogue database role to ensure persistence and modified the default 'admin' user.
### Detection & Response
- Date/Time: Discovery Date (Feb 27, 2025)
- Vector: Threat Intelligence Research (Wiz Threat Research).
- Details: Discovery was made through analysis by the threat research team, identifying the unique TTPs including fileless execution and specific C2 infrastructure.
## Attack Methodology
- Initial Access: Misconfigured DB abuse, Password bruteforcing.
- Persistence: Creation of a rogue database role with elevated privileges; modification of the default 'admin' user by stripping superuser rights (`ALTER USER "admin" WITH NOSUPERUSER NOCREATEROLE`).
- Privilege Escalation: Achieved via exploiting the inherent capabilities of `COPY FROM PROGRAM` on privileged database accounts.
- Defense Evasion: **Executed binaries entirely in memory** using `memfd_create` syscall; utilized unique file hashes per victim; packed binaries using modified UPX.
- Credential Access: Initial authentication relied on guessing/stuffing weak/default credentials, not internal credential theft post-access.
- Discovery: Basic system checks using SQL commands referencing OS utilities like `whoami` and `uname`, and checking for `pg_core`.
- Lateral Movement: Not explicitly detailed beyond the initial RCE via SQL function abuse; movements are generally localized to the compromised database host.
- Collection: Limited collection detailed, focusing on gathering infrastructure details (IP, passwords used) to embed in the malware configuration.
- Exfiltration: Not the primary goal; resource hijacking for C2 communication (mining pool).
- Impact: Resource hijacking via cryptomining deployment (`XMRig-C3`).
## Impact Assessment
- Financial: Significant operational cost due to resource consumption (CPU cycles) on compromised servers.
- Data Breach: Not the primary goal; however, credentials used for access and configuration data related to the compromised host (IP, usernames) were handled/logged within the malware stages.
- Operational: Performance degradation on targeted PostgreSQL servers due to cryptomining load.
- Reputational: Potential reputational damage for affected organizations hosting the resource usage.
## Indicators of Compromise
- **C2/Network Indicators (Defanged):**
- C2 Server: `159.223.123.175`:36287
- Mining Pool: `mine.c3pool.com`:13333
- **File Indicators (Observed Payloads):**
- `pg_core` (Dropper binary)
- `postmaster` (Packed Golang binary, mimicking legitimate process)
- `cpu_hu` (The final XMRig miner binary)
- **Behavioral Indicators:**
- Abuse of `COPY FROM PROGRAM` function in PostgreSQL.
- Fileless execution leveraging `memfd_create`.
- Creation of persistence via rogue database roles and modification of the 'admin' user.
## Response Actions
- **Containment:** Immediate network isolation of compromised PostgreSQL servers. Disabling remote access to database ports (5432/TCP).
- **Eradication:** Removal of all dropped files (`pg_core`, `postmaster`, configuration files in `/tmp`). Revoking the newly created rogue database role. Forcing password resets for any compromised credentials related to PostgreSQL.
- **Recovery:** Restoring database configurations to known-good states. Patching PostgreSQL instances and ensuring strong credential policies are enforced. Deployment of security solutions capable of monitoring SQL function execution.
## Lessons Learned
- Misconfiguration (public exposure, weak credentials) remains the leading initial access vector for database compromise.
- Deep application awareness (e.g., recognizing misuse of functions like `COPY FROM PROGRAM`) is critical for detecting database-specific exploitation paths.
- Attackers are actively deploying fileless techniques (`memfd_create`) to bypass traditional endpoint detection relying on file hash reputation.
## Recommendations
1. **Network Segmentation & Hardening:** Strictly limit external network access to PostgreSQL instances to only essential services/IPs.
2. **Strong Authentication:** Mandate strong, unique password policies; disable default/weak accounts if possible. Implement two-factor authentication where feasible.
3. **Principle of Least Privilege (PoLP):** Ensure database users only have the minimum necessary permissions. Review and restrict usage of high-risk functions like `COPY FROM PROGRAM` to trusted administrative clients or roles.
4. **Advanced Monitoring:** Implement security monitoring capable of detecting syscall usage like `memfd_create` in atypical processes, and monitor PostgreSQL audit logs for suspicious command execution patterns.