On Wed, Apr 2, 2025 at 11:31 AM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
On 4/2/25 08:18, Bharani SV-forum wrote:
> Hello MVP's
> Good Morning
> Any industry best practise to overcome this specific malware "pg_mem".
>
> url = ""> > https://www.aquasec.com/blog/pg_mem-a-malware-hidden-in-the-postgres-processes/ <https://www.aquasec.com/blog/pg_mem-a-malware-hidden-in-the-postgres-processes/>
From above:
"The first stage is a simple brute force attack. We observe several
login attempts to the PostgreSQL database being refused until the brute
force attack successfully guesses the honeypot’s username and password
(which were intentionally set to be easy to guess)."
After the threat actor successfully guess the user and password, the
attack sequence commenced. The following set of SQL commands, were
executed: ...
"
The first command being creating a role with SUPERUSER privileges which
depends the hacked role being a SUPERUSER itself.
So the solution is basic practices:
1) Don't expose the database anymore then necessary. It other words keep
access to the instance as restricted as possible, e.g. behind firewall.
Besides deny-by-default firewalls, be strict with pg_hba.conf entries.
2) Don't use easy passwords
openssl rand -base64 24
WordList=($(egrep '^.{4,9}$' /usr/share/dict/words | shuf -n2 --random-source=/dev/urandom | tr -d [:punct:] | sort));
First=${WordList[0]^};
Second=${WordList[1]};
Number=`printf "%02d\n" $(shuf -i00-99 -n1)`;
echo ${First}.${Second}${Number}
First=${WordList[0]^};
Second=${WordList[1]};
Number=`printf "%02d\n" $(shuf -i00-99 -n1)`;
echo ${First}.${Second}${Number}
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
