How to Use Penetration Testing to Prevent IPMI Service Vulnerabilities

Penetration testing is a key part of mitigating risk when using the IPMI service to monitor environmental system controls. In this blog, we use the Tenable Nessus Professional vulnerability scanner and our own solutions to demonstrate how IPMI vulnerabilities can be prevented, surfaced and addressed.

Many organizations proactively scan and monitor for network-based vulnerabilities as part of an ongoing vulnerability management program. Dozens of commercial vulnerability scanning engines exist. One vulnerability that’s often overlooked due to a seemingly low risk level is the Intelligent Platform Management Interface (IPMI) service. While these vulnerabilities may not allow for full system takeover, the potential effects on a critical system could be devastating.

We rely heavily on the Tenable Nessus Professional vulnerability scanner for network vulnerability scans and exploitation-based activities. The purpose of this blog is not to endorse a scanner. Rather, we wish to provide you with additional tools and resources for testing and validating vulnerabilities.

We are going to take a deep dive into the Intelligent Platform Management Interface (IPMI) service (Nessus plugin IDs 68931 and 80101). The IPMI services provide system monitoring and configuration capabilities in the absence of a specific operating system.

The Attack: Part One

The IPMI service is used to monitor environmental system controls such as internal temperatures, voltage, fans, and power supplies. It can also enable remote system starts and restarts.

This specific attack relates to two common vulnerabilities associated with the IPMI service, including IPMI v2.0 Password Hash Disclosures (Plugin ID 80101) and IPMI Cipher Suite Zero (Plugin ID 68931).

To validate the IPMI v2.0 Password Hash Disclosure (Plugin ID 80101), a module exists (auxiliary/scanner/ipmi/ipmi_dumphashes). When run, the module attempts to dump password hashes for user accounts into a file format supported by HashCat or John the Ripper. More often than not, these default credentials are left on systems. The following is a list of known default IPMI credentials based on manufacturer.

The cool thing about the ipmi_dumphashes Metasploit module is that it will automatically detect whether a default password exists. It attempts to crack the password hash using a password dictionary comprised of the default passwords listed above. Note that HP is among the only manufacturers that uses a secure(ish) default password.

The Attack: Part Two

In addition to the IPMI v2.0 Password Hash Disclosure, another commonly observed vulnerability is IPMI Cipher Suite Zero Authentication Bypass (Plugin ID 68931). IPMI Cipher Suite Zero allows an attacker to log in to the IPMI service with only a valid username. The attacker then bypasses the authentication mechanism put in place.

In our experience, Nessus does a poor job of detecting this vulnerability. Anytime we detect the IPMI service running on TCP/623, we scan the vulnerability using an NMAP script. The following command will perform a targeted vulnerability scan against the IPMI service to look for the IPMI Cipher Suite Zero vulnerability:

Nmap --script=ipmi-cipher-zero <TARGET> -p 623

In addition to the Nmap script, a Metasploit module (auxiliary/scanner/ipmi_cipher_zero) exists to scan specific systems or whole subnets for the vulnerability. After identifying the vulnerability, you can use the ipmitool to log into the IPMI service via a command terminal.

Ipmitool -l <INTERFACE> -C 0 -H <TARGET> - U <USERNAME> -P <PASSWORD> <IPMI COMMAND>

After successfully validating the Cipher Suite Zero vulnerability, post-exploitation activities can be performed. You can add a user to the IPMI service, thereby establishing a backdoor into the system. You’d use the following IPMI commands to add a user to the system:

User set name 2 <USERNAME> User set password 2 <PASSWORD> User priv 2 4 User enable 2

Upon completion, you will have successfully established a backdoor into the IPMI service. You should then be able to Secure Shell Sign-on (SSH) into the service as an administrator.

The Risk of Using the IPMI Service

The IPMI service does not typically house sensitive data such as personal identifiable information (PII) or personal health information (PHI). However, a persistent backdoor into a system at any level is never a good thing, even though an attacker is going to have a limited vantage point within the IPMI service. Possible risks include:

• An attacker remotely shuts down and restarts the system using the IPMI service. This causes a loss of data or a denial-of-service.
• People reusing passwords if the IPMI password hashes can be dumped, cracked, and then used in other areas of the network.
• An attacker disables environmental alerts or alarms. If they disable environmental alerting of the internal temperature of the system, the system may overheat. This causes damage to internal components.
• An attacker uses the backdoor to gather internal intelligence as part of a larger network attack.

Thankfully, there are some quick and easy things you can implement to harden the IPMI service to mitigate these attacks.

The IPMI Service Risk Mitigation

First and foremost, if you are not using IPMI for a business function, disable the service. The easiest way to mitigate a vulnerability in any environment is to disable unneeded and unnecessary services.

• Ensure you disable all default accounts (even HP’s). Each user who may access or monitor the service should be provided their own unique account. The passwords should follow internal password policies. NIST’s current guidance calls for at least 15 characters when a password is the only login factor.
• Implement access control lists (ACLs) to only allow specific systems to access the IPMI service. If Bob from accounting does not need to access the IPMI service, block him.
• Disable Cipher Suite Zero bypass. I cannot for the life of me think of a valid business reason to provide unauthenticated access to a network-based service. Should you have one, we recommend including this in any risk assessments and creating a security exception. Review on an annual basis to ensure you still have a business requirement and need for the configuration.
• Keep BMC firmware current and isolate IPMI on a dedicated management network. CISA and NSA’s joint guidance on hardening baseboard management controllers (BMCs), the hardware that runs IPMI, calls for both. The risk is current. In June 2025, CISA added CVE-2024-54085, a critical authentication bypass in AMI MegaRAC BMC firmware, to its catalog of vulnerabilities attackers are actively exploiting.

Use Penetration Testing to Prevent IPMI Service Vulnerabilities

IPMI is a common service we find within just about every enterprise network we test. While the service may seem benign, companies can potentially do a lot of damage if they abuse it.

While it may not allow direct foothold into a system or give an attacker local admin access, you should examine IPMI-based vulnerabilities, nonetheless. Penetration testing functions as a proactive defense mechanism. This allows you to detect and rectify your system’s vulnerabilities before hackers can take advantage of them.