If a server is joined to the domain and accepts login through AD (or other LDAP service), a possible vector of compromise is an AD account with stolen credentials. It is helpful to have external information when trying to figure out if a server is compromised. This could be any monitoring software – firewall, VMware dashboard, Kubernetes tools, SIEM – or, if you have the appropriate records and information in place, the e-mail response from automated tools from other domains that your server has attacked.

This assumes that you have said information and place, and that you are certain that the server has been compromised.

The first step should always be looking at logs. First, look at authentication logs in /var/log/auth.log for initiated sessions with successful login. This could be done with cat auth.log | grep session for automatic sorting or with tail auth.log  for manual sorting. If there is a user that is not recognized that initiated session and the logout happens a second or less after logging in, it is most likely a bot

Check the top consuming processes with top. If the server is compromised, most likely than not a process with a lot of CPU % usage will exist. Keep mind of the user that the process belongs to, as well as the name of the process.

Go to the mentioned user directory (the exact path will vary according to implementation) and see what’s in the directory with ls -la; look into the files and hidden files to see if the contents should be there or not. If the user has never initiated session before the compromise, all files are most likely of the bot. If the user had a directory prior to the compromise, care should be taken to delete the proper files, or caution if deleting the whole directory

Kill the processes belonging to the user. Use pkill -9 -u USERNAME to end all processes and log out the offending user.

To avoid re-logging, change the user’s password or deactivate the account. According to the type of account (local or domain, and their sub types) this could prompt other actions. Best case scenario, it is a local or domain account that is not used anymore; worst case scenario, it is a domain admin or service account that affects a plethora of other services as well.

Please note that this specific course of actions makes sense for restricting access and killing processes, but it might not cover the full scope of the compromise. Other actions are relevant according to the type of user; this actions assume that the user is not a sudoer. If the user is a sudoer, it would be harder to tell the extent of the damage, and the server should be quarantined for proper sanitation, or decommissioned and rebuilt if possible.