On Wed, Apr 2, 2025 at 11:31 AM Adrian Klaver <adrian.kla...@aklaver.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!
