Poorly protected PostgreSQL databases running on Linux machines are being compromised by cryptojacking attackers.
The attack – observed by Aqua Security researchers on a honeypot system – starts with the threat actors brute-forcing access credentials.
Once access is achieved, the threat actor:
- Creates a new user role with login capability and high privileges
- Strips the user role they compromised of superuser privileges (so that other attackers who may also gain access via brute-forcing will have restricted privileges)
- Starts collecting information about the underlying system
- Runs shell commands to download two files to the system
The first payload – PG_Core – is mostly aimed at removing cron jobs for the current user and killing processes related to other cryptomining malware (e.g., Kinsing, WatchDog, TeamTNT).
“The threat actor is stopping historic attacks of himself and others, this shows that he has some intel on competitors,” shared Assaf Morag, lead data analyst at Aqua’s Nautilus research team.
“Lastly, the threat actor deletes files such as the binary ‘pg_core’ and logs of the malware such as ‘ps_stat_good’ to evade defenses (such as volume-based scanners).”
Attack progression (Source: Aqua Security)
The second downloaded and deployed payload – PG_Mem – is a Linux dropper that contains the XMRIG cryptominer and stores it on the system.
“The cryptominer (…) is executed with the argument ‘deleted’ and in addition, the threat actor is creating a cron job with the execution of pg_mem and it inserts an empty value into the pg_hba configuration file,” he added.
A wide pool of potential targets
PostgreSQL is a widely used open-source relational database management system (RDBMS). It is often found deployed in the cloud, Kubernetes envrionments, and organizations’ own on-premises infrastructure.
Internet-exposed PostgreSQL databases are a favorite target of opportunistic cryptojacking groups and, occasionally, extortionists. They usually take advantage of lax security (e.g., weak passwords) or misconfigurations (e.g., a default configuration that binds PostgreSQL to all network interfaces, including the public one).
Currently, Shodan “sees” over 830,000 exposed PostgreSQL databases.
How to protect your PostgreSQL installations against cryptojacking?
“Exposing PostgreSQL directly to the internet is generally considered risky and is not recommended due to security concerns. However, there are a few reasons why some people might do it,” Morag told Help Net Security.
“Some organizations or individuals may need to access their PostgreSQL databases from different locations or through different services, making direct internet exposure seem convenient. And sometimes developers temporarily expose a PostgreSQL server during development or testing without considering the security implication.”
Some users set up their PostgreSQL server without implementing proper security measures, assuming that default configurations are sufficient, he added. Also, complexity and cost prevents small businesses or individuals with limited resources from setting up secure access methods like VPNs, SSH tunnels, or reverse proxies.
“To secure access to PostgreSQL databases, implement strong network security by using firewalls, VPNs, or SSH tunnels to restrict access, and ensure all users have strong passwords. Employ audit logs, intrusion detection systems, and secure backups. Additionally, disable unnecessary features and protect against SQL injection in applications,” he advises.
Additional best practices for securing PostgreSQL workloads can be found here.