Re: Any industry best practise to overcome this specific malware "pg_mem"

On Wed, Apr 2, 2025 at 11:31 AM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
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}

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!