Malicious PostgreSQL Extensions in the Wild

After our team discovered a way to load malicious extensions in PostgreSQL that enabled remote code execution (RCE), we had to answer the next logical question: Are threat actors already loading malicious extensions into PostgreSQL? And if so, what do these campaigns look like?

So, we went hunting. What came back surprised us: a cross-platform campaign by  a known cryptomining group whose roots go back to 2018. The Linux versions weren’t detected by a single antivirus engine. 

In this blog, we’ll cover how malicious PostgreSQL extensions work, how we found them, and who’s behind the expansive campaign.

Key Findings

• We discovered 20 malicious extensions: 16 for Windows, 4 for Linux.
• The campaign infrastructure dates back to 2018.
• It’s a cross-platform operation: Windows and Linux share three of four C2 domains. 
• The campaign supports a cryptomining operation.
• Infrastructure for the campaign (C2 domain d1.pool4883.pw) was still live during our research.

Why Malicious PostgreSQL Extensions Are a Blind Spot

Databases are central points in organizations that often hold huge amounts of sensitive data related to customers, employees, secrets, and more. That's why they’re the crown jewels for threat actors and a critical piece of defense efforts.

PostgreSQL is an especially big target because it's the most popular database in Stack Overflow's Developer Survey, a title it’s held since 2023. All deployments of PostgreSQL have an option to load binary extensions except for Database-as-a-Service (DBaaS). But a 2024 survey found only 41.3% of the PostgreSQL community hosted it as DBaaS.

That means many PostgreSQL instances are exposed to a scenario where a threat actor places a malicious extension and steals their data.

Here is a simple example of a malicious extension:

Seven lines of code, without signing or verification. Once loaded, malicious code runs inside PostgreSQL itself, with no process to catch and no standalone executable to flag.

How We Spotted Problematic Extensions

To answer our questions, we developed a systematic hunting methodology. We separated our methodology into three stages:

• Use YARA rules to find the needles in a huge haystack.
• Cluster the different artifacts based on metadata and VirusTotal enrichments.
• Reverse-engineer the most interesting samples using Ghidra.

We turned to VirusTotal intelligence to gain access to potentially malicious PostgreSQL extensions.

From there, we used a simple YARA rule to pull as many PostgreSQL extensions as possible. It looks for Pg_magic_func:

This rule matches any PE or ELF binary exporting the PostgreSQL magic function.

Our starting point was to search for Pg_magic_func, the macro every PostgreSQL extension must export. After that, we checked all available metadata for each to better understand the file's meaning.

How did we examine the metadata? Imphash (Import Hash) groups binaries by the DLLs and functions they import, so the same Imphash often means the same codebase or builder. PE timestamps showed when the binary was compiled — five samples compiled within five minutes told us they were likely connected. Sandbox reports showed which domains the binary contacted and which files it dropped.

In this phase, our purpose was to try clustering them to hopefully identify and reveal the different groups of Trojans. Who uses them? Cryptominers? APTs? Script kiddies? Professional attack groups?

We reverse-engineered the interesting extensions with Ghidra. For sandboxing and efficiency, we ran Ghidra MCP on EC2 with an SSH tunnel to our laptops, and built a custom skill that handles the full RE workflow automatically.

The Campaign We Found

We found 20 malicious PostgreSQL extensions that all seemed to be part of one campaign.

More interesting than the number of extensions is that Windows and Linux samples share the same C2 domains and the same purpose. One campaign, two platforms.

Timeline

The infrastructure behind this campaign goes back to at least June 2018. The PostgreSQL extensions themselves first appeared in October 2023:

During our research, we found that the domain d1.pool4883.pw was still alive and the resolved IP was 209.99.186.219.

So, how does the malware work?

Windows: Three-Stage Chain

Stage 1: The PostgreSQL Extension — gc_manager.dll

A legitimate-looking extension exporting a valid Pg_magic_func. But inside is an XOR-encrypted payload. On load, it decrypts the payload and uses process hollowing: it finds the host executable path, launches it suspended, and replaces its memory with Stage 2.

Stage 2: The Downloader

WinHTTP-based C2 communication with four backup .pw domains. Downloads from https://<domain>/win/min/c64.exe.

This architecture lets the attacker choose any payload. Stage 2 downloads whatever the C2 serves: a credential stealer, ransomware, a crypto miner, or anything else.

During our research, we checked what they're currently serving and downloaded this binary from the one live domain.

Stage 3: The Miner — c64.exe

5.1 MB, compiled December 2025.

The final payload is XMRigCC, a fork of XMRig with remote command and control capabilities. Eight hardcoded mining pools with the same worker ID across all of them.

The miner uses defense evasion techniques to avoid detection and reduce its impact on users. It monitors running processes and pauses when it detects Task Manager, Process Explorer, or Process Hacker to stay invisible. It also pauses when it detects games like Dota 2, CS:GO (Counter-Strike), GTA V, Overwatch, and more to avoid degrading performance and alerting the user.

Each Windows sample was flagged by some AV engines. But flagging a file as suspicious isn't the same as identifying a campaign. They all share the same builder and C2 domains, so the pieces were there, but no one had connected them yet.

Linux: Similar Chain, Zero Detection

Four samples, all named gcmanager-1.so, targeting PostgreSQL 14.0-17.0. Detection rate: 0/65 in VirusTotal.

Stage 1: The PostgreSQL Extension — gcmanager-1.so

The trick is that most malware runs on load; this one runs on unload.

When the extension is unloaded, a destructor runs that:

• Extracts a zlib-compressed payload embedded in the .so file, writes it to disk, and executes it as a background daemon.
• Finds postgresql.conf and copies itself (the .so file) into the same directory.
• Parses shared_preload_libraries and session_preload_libraries from the configuration, then adds itself if missing.
• Writes the modified config back and signals PostgreSQL to reload it.

Stage 2: The Downloader

A zlib-compressed ELF extracted from the extension at runtime. On its own, 4/66 engines flag it. The extension that carries it, however, doesn’t raise a single flag.

It contains four hardcoded C2 domains and downloads the final payload from https://{domain}/lin/64/xmrig.

Stage 3: XMRigCC Miner

Searching VirusTotal for files contacting the same C2, we found related Linux malware whose sandbox execution dropped an XMRigCC miner. 

Three of the four C2 domains overlap with Windows, indicating that both are part of the same campaign.

Next, we followed the infrastructure to see if we could expand our understanding.

Different Campaign, Same Infrastructure

While investigating the C2 domains, we queried VirusTotal for files communicating with the same infrastructure. One domain, asq.d6shiiwz.pw, returned multiple patch.exe samples alongside the PostgreSQL extensions. These aren't part of the gc_manager infection chain; they're probably a parallel campaign by the same actor that uses a different initial access vector but the same C2 infrastructure.

Stage 1: The Defense Evasion Stage

• Disables Windows Defender real-time monitoring.
• Adds a registry key to disable AntiSpyware.
• Stops and disables the Windows Update service.
• Adds %TEMP%\drivers to Defender exclusions.
• Downloads a script from a GitHub Gist.
• Drops the stealer into the excluded %TEMP%\drivers.
• Self-deletes via ping delay.

Stage 2: AZORult Stealer

An obfuscated AutoIt-compiled payload steals browser credentials, cookies, and crypto wallets. It takes screenshots, collects system information, and exfiltrates to lubrpenal.xyz.

Two campaigns sharing infrastructure: one monetizes compute, the other monetizes credentials.

The next step was following the infrastructure trail to determine who's behind this.

The Attack Group

The actor behind this malware is Tor2Mine, a cryptocurrency mining group.

The infrastructure led us to a known cryptojacking operation. The domains asq.d6shiiwz.pw and asd.s7610rir.pw appear in Sophos Labs' published IOC list for Tor2Mine from 2021. Cisco Talos documented this group in 2020, noting their use of AZORult alongside mining, which is exactly what we found.

This isn't a new threat actor. It's a new attack vector for an established group.

What was already known about Tor2Mine:

• Active since at least 2018.
• Deploys AZORult stealer alongside XMRig mining.
• Russian-registered infrastructure (REG.RU Moscow).

As far as we can tell, this is the first published analysis of Trojanized PostgreSQL extensions as an attack vector in the wild.

Tor2Mine didn't disappear after 2021. They just added a new trick.

What Else Is Running Where Your Data Lives?

This investigation proves that threat actors are abusing PostgreSQL extensions and they have been for at least three years.

It’s important to remember that PostgreSQL is just one database, so this is only part of the picture. Redis has modules. MongoDB has server-side JavaScript. MySQL has user-defined functions (UDFs). Elasticsearch has extensions. Each one loads code into a process that touches your data. We found gc_manager because we looked. What's running inside your database?

Database servers are big targets. Go find what we missed.

Indicators of Compromise (IoC)

You can find the IOCs here.

Last verified: 2026-09-27.

gc_manager Campaign (PostgreSQL Extensions)

C2 Domains

Windows gc_manager.dll (16 Samples)

Linux gcmanager-1.so (4 Samples)

Embedded Payloads

Downloaded Miners (XMRigCC)

Mining Pools

• eu.minerpool.pw:443
• rig.zxcvb.pw:443
• rig.myrms.pw:443
• rs.fym5gserobhh.pw:443
• back123.brasilia.me:443
• 185.10.68.220:443
• 65.87.7.196:443
• 2.59.220.122:443

patch.exe Campaign (AZORult Stealer)

C2 Infrastructure

• lubrpenal.xyz/ynvs2/index.php
• interstart.xyz/hab3v13/index.php
• testarea.hostigger.com
• 195.123.234.33
• 141.98.117.69

patch.exe (6 Samples)

AZORult Stealer (Dropped Payload)

Note on Unsubmitted Hashes

• d3bb71a7554dbeeb248d35db4d03514ed84e4023b21ef7e21616cb0c6fb5a053 — the Windows Stage 2 exists only after in-memory decryption, so it is never written to disk.
• 47e777c4541044dd439bf065478bfadc5b6d7049f70a3114ca8386acb02d0b6a — retrieved directly from the C2 on 2026-07-26.