Full Report
Exposed PostgreSQL instances are the target of an ongoing campaign designed to gain unauthorized access and deploy cryptocurrency miners. Cloud security firm Wiz said the activity is a variant of an intrusion set that was first flagged by Aqua Security in August 2024 that involved the use of a malware strain dubbed PG_MEM. The campaign has been attributed to a threat actor Wiz tracks as
Analysis Summary
# Incident Report: Widespread PostgreSQL Cryptojacking Campaign
## Executive Summary
An ongoing cryptojacking campaign, attributed to threat actor JINX-0126, has successfully compromised over 1,500 publicly-exposed PostgreSQL database servers globally. The attackers exploited weak or predictable credentials, leveraging the `COPY ... FROM PROGRAM` SQL command to achieve remote code execution, install fileless cryptocurrency miners (XMRig), and establish persistence. The campaign highlights the risk posed by misconfigured database services accessible via the internet.
## Incident Details
- **Discovery Date:** August 2024 (Initial intrusion set flagged by Aqua Security); Campaign details updated/re-emerged around April 2025 (Wiz reporting).
- **Incident Date:** Ongoing, variant first observed August 2024.
- **Affected Organization:** Over 1,500 organizations utilizing publicly exposed PostgreSQL instances.
- **Sector:** Various (Implied, targeting database services).
- **Geography:** Global (Based on the scope of compromised servers).
## Timeline of Events
### Initial Access
- **Date/Time:** Prior to August 2024 / Ongoing
- **Vector:** Exploitation of publicly-exposed PostgreSQL instances using weak or predictable credentials.
- **Details:** Attackers gain unauthorized access to the database server.
### Lateral Movement
- **Details:** Once access is obtained, the actor abuses the `COPY ... FROM PROGRAM` SQL command to execute arbitrary shell commands on the host system.
### Data Exfiltration/Impact
- **Details:** The primary impact is resource hijacking for cryptocurrency mining (targeting Monero via XMRig). Initial reconnaissance and deployment of malicious payloads occur first.
### Detection & Response
- **How it was discovered:** Identified by cloud security firm Wiz (building on prior work by Aqua Security). Detection relies on identifying the specific fileless execution techniques and mining activity.
- **Response actions taken:** Reporting and analysis provided by Wiz to detail techniques and scope. (Specific customer remediation actions are not detailed in the source text.)
## Attack Methodology
- **Initial Access:** Unauthorized access to PostgreSQL via weak/exploitable credentials.
- **Persistence:** Established via a cron job and creation of a new, elevated database role, alongside the deployment of the `postmaster` Golang binary.
- **Privilege Escalation:** Use of the `COPY ... FROM PROGRAM` command (Remote Code Execution capability provided by the database configuration).
- **Defense Evasion:** Deployment of binaries with a unique hash for every target; execution of the miner payload is done filelessly using the `memfd` technique to evade file hash reputation-based defenses.
- **Credential Access:** Not explicitly detailed, but initial access implies credential compromise or exploitation of configuration flaws.
- **Discovery:** Preliminary reconnaissance is conducted after initial shell access is achieved.
- **Lateral Movement:** Not explicitly detailed beyond gaining host access; the focus is on local resource compromise.
- **Collection:** Gathering information necessary to deploy the miner.
- **Exfiltration:** N/A (Focus is on CPU usage via mining, not data theft).
- **Impact:** Cryptojacking via deployment and execution of XMRig miner.
## Impact Assessment
- **Financial:** Indirect costs related to wasted compute resources and investigation/remediation for over 1,500 victims.
- **Data Breach:** Not the primary objective; the goal was system resource consumption.
- **Operational:** Reduced performance and instability on compromised PostgreSQL database servers due to resource contention from mining operations.
- **Reputational:** Damage to organizations running exposed, insecure PostgreSQL instances.
## Indicators of Compromise
- **Network indicators:** Connections associated with XMRig mining pool communication (Wallet IDs and Worker IDs are tied to the actor, but specific IPs/domains are not listed here).
- **File indicators:** Malicious binaries named `PG_CORE` and `cpu_hu`. Obfuscated Golang binary named `postmaster`.
- **Behavioral indicators:** Abuse of PostgreSQL `COPY ... FROM PROGRAM` SQL command. Use of the Linux `memfd` technique for fileless binary execution. Creation of persistence via cron jobs.
## Response Actions
- **Containment measures:** Not detailed in the source, but typically involves revoking compromised credentials, isolating affected hosts, and likely patching/disabling the `COPY ... FROM PROGRAM` functionality if inappropriately configured.
- **Eradication steps:** Removal of malicious binaries (`PG_CORE`, `postmaster`, `cpu_hu`), deletion of malicious cron jobs, and removal of the newly created elevated role.
- **Recovery actions:** Restoring PostgreSQL service integrity and verifying no remnants of the miner or persistence mechanisms remain.
## Lessons Learned
- Publicly exposing database services, especially those like PostgreSQL, creates a high-risk attack surface.
- Weak or predictable credentials remain a primary vector for initial access in opportunistic cloud/server attacks.
- Threat actors are actively leveraging fileless techniques (`memfd`) to specifically bypass defenses relying solely on file signature matching.
- The `COPY ... FROM PROGRAM` feature, while useful, is powerful and dangerous when database user permissions allow its abuse.
## Recommendations
- Immediately audit and restrict public internet exposure for all PostgreSQL instances. Access should be limited to necessary application servers via firewalls/Security Groups.
- Implement strong, unique credential policies for database users, utilizing strong passwords and/or multi-factor authentication where possible.
- Deploy advanced workload protection solutions capable of monitoring and alerting on suspicious system calls (like fileless execution techniques such as `memfd`) originating from database processes.
- Regularly review PostgreSQL configuration parameters to restrict dangerous functions like `COPY ... FROM PROGRAM` to trusted administrative users only.