That’s one common way attackers get in.
mod_php means the code runs as the Apache user. It already has elevated permissions (not root, but more than a normal user in that Apache can read other user’s homes). mod_php has some protections and if the attacker wasn’t explicitly trying to gain access to other user homes, they may not have done anything in those other user homes. But, mod_php is known to be leaky, and because mod_php has been deprecated for many years and the PHP devs tell you not to use it (and there is never any reason to use, it is slower, bigger, and less secure than alternatives), it doesn’t get a lot of attention.
mod_php is not your big problem here. It is a problem. You shouldn’t have installed it, and you should uninstall it, and if you start over with a fresh server, I’d advise you make sure you don’t make that mistake again. But, it’s not how the attacker got in. If other users have been exploited, though, that’s possibly how it happened. Removing mod_php does nothing for your currently known exploited user, though, and manually going through and playing whack-a-mole with the files the exploit produces is probably not going to do anything useful. You have to prevent it from re-installing itself, and it probably has many mechanisms for doing that.
Attackers have toolkits they use to insure their exploits are sticky and hard to defeat. Once they’re in, they have a lot of mechanisms to make sure they stay in. It’s automatic and it’s probably quite fast. By the time you find one exploited file and fix it, some other file or process sees that change and puts it back (maybe with a randomized location and name, so you don’t immediately spot it again).
That’s why I’m saying the only way to be (mostly) sure would be a restore from a known-good backup (and, if you didn’t spot the exploit quickly, you may not know how far back you have to go to find a known good backup). Replacing all the files with known-good versions directly from the WordPress site or the plugin authors would maybe do the thing. You might have to make it all owned by root while you make those changes (because they may have cronjobs to bring their files back, they may have endpoints that allow them to trigger a reinstall).
Since you can see these processes means they probably don’t have root (if they had root, they could install la rootkit that would hide their cryptominer, or whatever, processes). So, you’ve got that going for you. It probably can be cleaned up, but it won’t happen by just deleting a few files that look suspicious.
I’m not able to provide private support with our Open Source software. I do the best I can to answer questions here in the public forum, given the time I have. And, I’ve told you what I know about the way attackers operate; I’m guessing without having looked at your system (and I’m not going to look at your system), but it’s guessing based on some experience with these kinds of exploits.
https://forum.virtualmin.com/guidelines
to fall into.