Of course it does. The attacker obtained access as the user the domain runs as. They were able to add cronjobs, other scripts with different names, etc.
Killing one process is not what cleaning up an exploited user account looks like.
As I said above:
Restoring from a known-good backup of the domain, and then immediately updating the apps and plugins and removing any you aren’t very confident you can trust, would be one way to get there. You probably want to backup the current database before doing that, so you don’t lose any data added since the attack occurred. But, beware that databases can also execute code and can run malware, and someone with domain level access could also find out passwords for databases and anything else stored in config files in the user home. I don’t think I’ve ever seen databases used as a reinfection vector, and it would require problematic application code to escape, but we already know you have problematic application code, since the attacker got into multiple sites. (For instance, if the site has a maintenance or queue processing cronjob, it may be exploitable by something in the database to run commands on the system.)
Attackers have “kits” of tools they install, which sets up various processes and cronjobs, and modified files within your app, to reinstall their malware whenever you remove any single file. The domain index.php and many other pages may have been modded to reinstall the malware, there may be cronjobs, a remote shell so they can login and poke around if the system stops phoning home, various files that look harmless but aren’t.
If you leave any of the attackers files, they can probably get back in. If you leave the application(s) in the state they were in, they can (probably) get back in (some attackers patch the exploit they came through so nobody else can take over their new botnet member). But, they also install some new backdoors of their own.
The only sure-fire way to clean up is to backup everything important, delete the whole domain, recreate it, reinstall the applications fresh from the upstream sources (installing WordPress with Virtualmin grabs it from the WordPress download servers), and restoring databases and data…but, not any of the application/plugin code from the exploited site (because none of it is trustworthy without going over it with a fine-toothed comb).
You’re fixated on this one file, l.php. That one file is not the problem. The problem is that one file proves the attacker was able to create executable files on your system. If they can do that, they can do anything the user can do.
The good news is that they probably did not escalate to root (root escalation is not usually easy, on an up to date Linux system), since if they did they would be able to hide all their files and CPU usage from you. You can only be (somewhat) sure about an absence of root-level exploit via external observation. Either booting from a trusted read-only filesystem and looking around, or observing network data in and out, since people exploit systems for reasons, usually mundane reasons like sending spam or participating in DDoS attacks or crypto mining.
You can’t trust anything in those domain’s home directories at this point, especially anything in executable directories.
