A few weeks ago a report on CheckMK was posted on Pentest Party, and it doesn’t look good. The pen-tester was able to gain root access to multiple servers pretty easily via CheckMK:
https://pentest.party/posts/2025/checkmk/
I am fairly new to CheckMK, but if there aren’t ways to prevent what happened in this report, then this will be a show-stopper for me. Please tell me that this penetration could easily have been stopped by doing x, y, z…
The direct link is here: Lateral Movement via Checkmk - Pentest Party
And nothing new in this report.
The pentest starts by discovering the credentials of the automation account in the shell history of a monitored machine.
This is a user error. Do not use the automation account to register the agent updater or controller. Do not run the command with the credentials so that they end in your shell history.
From there it was easy to take over the Checkmk site by creating a new admin account via API.
And from there you can control everything. Including deploying additional software via agent updater to your hosts, execute arbitrary commands on the monitoring server or even get the credentials for monitored systems (like VMware).
This is quite obvious when you think about how Checkmk works and need to function. E.g. it needs credentials to access the vSphere API. These credentials should only have read access to VMware, but this is in your hand.
I can only say the same as @r.sander , don’t use admin credentials for scripting on clients.
The reports only shows what can happen if admin credentials laying around. That is not a real Pentest, more like what can i do if i have an admin account + signing credentials.
Seconding Robert’s & Andreas’s words. Always treat having admin access to CheckMK as having admin/root access to all monitored machines.
When using the agent updater.
Yes, exactly. That’s what the linked article used, therefore I simply omitted that condition.
That being said, I might even extend that to “if you’re using the CheckMK agent on your monitored devices”. The reason is that there has to be some way get those agents. At the moment there is no “pristine agent” package available for download directly from CheckMK-the-company. Therefore the only way to get an agent that can be installed is from your CheckMK installation. And unless already deployed agents will never, ever get updated, you have to get newer agent packages from time to time, too.
Therefore in such situations where you do not use the updater, even when only completely different teams have admin access to the monitored machines & install the agents there, you-the-attacker-with-CheckMK-admin-privileges can still upload malicious MKPs that inject malicious code into any agent baked in the future. Heck, you can even get shell access to the CheckMK server as the site’s user that way as so much plugin code is run automatically when the server starts.
Technically the admins of the monitored hosts could set up their own CheckMK server, bake an agent there & use that & not rely on the monitoring CheckMK host at all. But how many teams do you know that would go to such lengths?
So… yeah. I might phrase it as “CheckMK admin is eventually equivalent to admin access on monitored systems using the agent”. Only when not using the agent & only relying on other protocols such as application-specific APIs, Redfish, SNMP etc. are you able to separate this.
Thanks for your replies everyone. So, I think I need to fully understand what is the “automation account”, as you are saying do not use it to register the agent updater or controller.
To register the agent on clients I have used the following command, learned from the guides:
sudo cmk-agent-ctl register --hostname $AGENT_HOST --server $CHECKMK_SERVER:$REG_PORT --site cmk --trust-cert --user agent_registration --password $AGENT_PASS
The env vars are set, but they do of course end up in the command history for my Linux admin user. Is this an admin credential for checkmk?
Note: I don’t think I use “automation” for the agent updater; we have little enough PCs to monitor with agents, that I update them manually with wget and dpkg
You are using an API account called agent_registration for that task. This account usually only has permissions (via its roles) to register the agent. No harm can be done with it AFAIK.
To expand slightly on Robert’s answer: the CheckMK consists of a lot of functionality you also have via the web API. If you want to use all of it, e.g. for automatically creating rules or querying configuration, you need an account with full admin privileges. Often we use accounts that aren’t allowed to log in via the UI for such purposes, and the corresponding option in the user settings is called “automation account”.
However, the step of registering a freshly installed agent on a host machine only requires that single API endpoint that Robert mentioned. Therefore no full admin privileges are required for it.
Therefore, the exstence of automation accounts with admin privileges is fine as long as the credentials they use aren’t accessible to unauthorized people. The existence of an agent registration account is fine, too, and it’s even perfectly fine to spread those credentials among other people, as long as the registration account has the right permissions via its role assignments. There’s a built-in role called “agent registration user”, and that should be the only role assigned to it.
Note further that an account used for registering machines can be flagged as an “automation account”. “Automation account” only means “cannot log in via GUI, doesn’t have to use 2FA”; it has implications on permissions which are orthogonal. The permissions
are always set via the role assignments.
You can check existing roles & their assigned fine-granular permissions in “Setup” → “Users” → “Roles & Permissions”, and at “Setup” → “Users” → “Users” → click on user → you can see which roles are assigned to a specific user.
It is important to note that the elevated privileges were not obtained via a backdoor or exploit, but simply by reading a password from the shell history. Once a highly privileged account (e.g. an automation or admin user) is compromised, an attacker can effectively control the monitoring system and potentially all monitored hosts.
This is a good example of why dedicated users and roles with strict least-privilege permissions are essential, and why gents should run as non-root whenever possible.
To Checkmk’s credit, this has already been improved: agent-specific roles have been introduced, building/signing a new agent requires access to a signing key, and agents can be run as non-root users. Combined with proper role separation, this significantly reduces the blast radius in the event of a compromise.
One could argue that Checkmk should provide dedicated users and roles for different tasks out of the box, and that the automation user should be limited to local access by default and should not have the right to grant admin privileges. This would help prevent new, inexperienced users from reusing the default automation user for everything and reduce the risk of over-privileged accounts in real-world setups.
A freshly setup 2.4 site does not have an “automation” automation account any more.
Thanks again everyone, for all posts - I am reassured now 
I have checked my users, and I only have agent_registration and cmkadmin (latter only used for login to manage) so I think we’re good.
Like I said, make sure the agent_registration user only has the role agent registration user assigned.