Firmware Security Realizations – Part 2 – Start Your Management Engine

Subscribe to Eclypsium’s Threat Report

Start Your Management Engine

In the process of scanning my systems for firmware vulnerabilities, I discovered that my Intel-based machines are vulnerable to a wide range of issues related to Intel’s Management Engine (ME). As it turns out this is a fairly common problem as one of our programs that have scanned over 100 machines identified Intel ME as one of the most popular sources for critical vulnerabilities. I wanted to understand the background behind Intel ME, and as with Secure Boot, this led me down another rabbit hole!

Intel ME (also historically referred to as IME) was introduced in June 2006 and is known today as CSME (Converged Security and Manageability Engine). Intel ME has undergone a few evolutions over the years but remains a small, independent subsystem that runs inside your computer. Intel ME has its own CPU, SRAM, and microkernel (though shares storage on the SPI flash with UEFI and uses an isolated region of the system DRAM) and has direct access to all other hardware in the computer. There have been a few major hardware and software changes to Intel ME:

  • First introduced in 2006 on Intel’s 965 Express Chipset Family, ME versions 1.x – 5.x used an ARC hardware architecture
  • Intel ME versions 6.x – 10.x (Nahelam through Broadwell) also used an ARC architecture and the embedded subsystem now resides in the PCH (Platform Controller Hub)
  • Intel ME starting with 11.x through 14.x (the latest version available today) switched to a Quark x86-based platform and runs a customized version of the MINIX operating system

Intel ME provides functions that support the secure booting of the platform, hardware DRM, secure loading of firmware for other components, security services such as TPM, and out-of-band platform management. The out-of-band management is handled by Intel AMT (Active Management Technology), a feature set that can be enabled in Intel ME that includes a network stack and the ability to access the computer as long it receives power (e.g. the computer can be turned off or suspended, however, the embedded controller still receives power to enable remote management or even a full rebuild of the computer). When you buy an Intel-based computer with the vPro label it means some additional Intel firmware components such as AMT are present in the system. Some of these features work transparently, but others, like AMT, have additional configurations. AMT can be enabled vs disabled and can also be enabled, but not yet provisioned.

Before we dive into the vulnerabilities and remediation techniques I’d like to highlight some opinions on Intel’s ME technology, as what we’ve covered so far are the facts. If you own a computer with an Intel chipset dating back as far as 2006, there is a computer inside your computer, running proprietary code, with ring -3 level access. The notion of “ring -3” certainly warrants more explanation as many are likely familiar with the four protection rings in Intel Architecture (AI). Intel defines these four rings as:

  • Level 0 – The operating system kernel
  • Level 1 and Level 2 – Device drivers
  • Level 3 – Applications

(Reference: (Figure 6-3. Protection Rings))

Negative rings represent conceptual levels of privilege and are used to illustrate deeper levels of access than defined by Intel protection rings 0-3. These theoretical privilege levels are defined as:

  • Ring -1 – The Hypervisor
  • Ring -2 – SMM (System Management Mode)). 
  • Ring -3 – Intel ME

Attackers running code and operating in Ring -3 pose, perhaps, some of the greatest threats to your systems.  Ring -3  level of access falls outside many other protections, allowing attackers to bypass restrictions and evade detection that may be present in higher-level rings.

Public Warnings and Disagreements

If there was ever a topic to get the open-source community fired up, it is Intel ME. The Libreboot project (creators of open-source BIOS/UEFI software) has this say:

“The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored.” (Ref:

The EFF also voiced concerns over Intel ME and its implications on privacy and security, writing in May 2017:

“EFF believes that Intel needs to provide a minimum level of transparency and user control of the Management Engines inside our computers, in order to prevent this cybersecurity disaster from recurring. Unless that happens, we are concerned that it may not be appropriate to use Intel CPUs in many kinds of critical infrastructure systems.” (Ref:

I believe these bold statements are a result of Intel using proprietary software and the discovery of vulnerabilities in Intel ME technology (which will dive into next). The fact remains, if you want a computer with an Intel chipset, you are getting Intel ME embedded. Before we get into the obvious questions such as “Can I remove Intel ME?” or “Can I disable ME?” Let’s have a look at some of the vulnerabilities discovered within Intel ME.

Intel ME Vulnerabilities

Some of the first security research to be published on Intel ME was published by Invisible Things Labs in a talk from Black Hat 2009 titled “Introducing Ring -3 Rootkits” by Alexander Tereshkin and Rafal Wojtczuk (Similar research, and many of the same slides, was included in a presentation titled “A Quest To The Core: Thoughts on present and future attacks on system core technologies” by Joanna Rutkowska, which also references Eclypsium cofounder Yuriy Bulygin’s Black Hat talk from 2008 titled “Chipset Based Detection And Removal Of Virtualization Malware  a.k.a. DeepWatch”. Invisible Things Labs researchers explored the use of a virtual CD-ROM in AMT in order to use DMA to access memory used by the host-OS. This research represents the first code execution flaw publicly disclosed for Intel ME.

In 2010 Vassilios Ververis published research in a paper titled “Security Evaluation of Intel’s Active Management Technology“ that documents several vulnerabilities in AMT including passwords transmitted in clear-text, HTTP Digest authentication susceptible to brute-force attacks, and a flaw in zero-touch provisioning that trusts any valid certificate allowing an attacker full control over AMT.

Further research was introduced at RECON 2014 in a presentation by Igor Skochinsky titled “Intel ME Secrets: Hidden code in your chipset and how to discover what exactly it does” (The recording is available in the Infocon archives). This research focused on gaining a deeper understanding of Intel ME and concluded with conclusions such as “I still have not managed to run my own rootkit on the ME”, but laid groundwork for future research, including the introduction of a plugin for IDA Pro. Also, “Intel ME: The Way of the Static Analysis” by Dmitry Sklyarov presented at Troopers in 2017 gave us further insights into Intel ME and AMT technologies. 

In 2017 security researchers discovered an authentication bypass flaw in Intel AMT’s web management interface dubbed “Silent Bob is Silent” leading to Intel security advisory SA-00075 (You can also watch the Black Hat USA 2017 presentation discussing this finding).  Also in 2017, the Microsoft Defender research team discovered the PLATINUM group’s usage of Intel AMT SOL (Serial-Over-Lan) as a communications channel.

Again in 2017 security researchers developed a working exploit for Intel ME and patches were made available from Intel in the SA-00086 security advisory. Two different presentations were given at Black Hat Europe in 2017, one detailing the Intel ME architecture and components titled “Intel ME: Flash File System Explained“ (Video recording). The other is titled “How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine” (Video recording). The latter describes a code execution vulnerability in Intel ME firmware, including technical details on how to get it past a non-executable stack. However, this exploit can only be used on systems where you can gain write access to the protected area on the SPI flash where the ME firmware is stored. This is possible if AMT is enabled on the system and either the attacker has the credentials or an exploit for a vulnerability that exists in the running AMT. Also, if the hardware manufacturer has not write-protected the ME region of the SPI flash (e.g. SPI Flash Descriptor permissions are set incorrectly), an attacker may have enough access to exploit the vulnerability without physical access to the system (of course, physical access to a system could be easy to pull off depending on the situation).

In 2018, vulnerabilities related to Intel ME manufacturing mode were discovered by security researchers and presented at the Hack-In-The-Box conference. This research details a method of altering the ME SPI flash region while the system is running, when manufacturing mode has been left open on a system, in order to be able to exploit SA-00086. This is significant because it allows an attacker to run code in Intel ME without requiring physical access to the system (if you are curious at this point about how to detect if your system is in manufacturing mode don’t worry as I will show you a few different methods to detect this condition in the article).

From 2018 to today there have been numerous vulnerabilities discovered in Intel ME and AMT technologies by both independent researchers and Intel’s internal security team. In fact, the Intel team presented at Blackhat 2019 in a talk titled “Behind the Scenes of Intel Security and Manageability Engine” (Video Recording) and it is here you can learn about some of the more recent architecture used in Intel ME. 

Discovering Intel ME Vulnerabilities 

Now that we understand a little more about Intel ME vulnerabilities, let’s use freely available tools to check our own systems for potential vulnerabilities. Intel has released a tool to check for SA-00075. You can download it from Intel’s Github repository and compile it on your system. I am using Ubuntu 20.04 and was able to compile it without any issues. While there are newer tools available from Intel that we will dive into in this article, I wanted to show the older one because it is still available online and I came across it quite often while researching Intel ME vulnerabilities. On my particular system the tool reported I was not vulnerable to SA-0075 (likely because my system runs a version of Intel ME that does not have AMT and/or has been updated since 2017):

$ git clone $ cd INTEL-SA-00075-Linux-Detection-And-Mitigation-Tools/ $ make $ sudo ./INTEL-SA-00075-Discovery-Tool -d /dev/mei0 INTEL-SA-00075-Discovery-Tool — Release 1.0 Copyright (C) 2003-2012, 2017 Intel Corporation. All rights reserved ——————Vulnerability Status——————– System is not Vulnerable, no further action needed. ———————————————————-

If you do have a system with AMT, enabled or not, the tool will produce different results:

While the above system was not vulnerable to SA-00075, the discovery tool has displayed useful information, including the status of AMT on your system and which version of AMT is running. If you want a second opinion you can use Matthew Garrett’s free tool available on his Github account called “mei-amt-check”:

$ git clone $ cd mei-amt-check/ $ make $ sudo ./mei-amt-check Error: Management Engine refused connection. This probably means you don’t have AMT

On my systems, AMT was not installed. Eclypsium’s product will produce a full report on the status of AMT, available in the “Intel Management Engine” component status:

The AMT Status field will contain different information depending on the state of AMT on the target system. These states may indicate that AMT is available on the system, but not enabled. The status field may also indicate the provisioning status, which could be one of the following:

  • Unprovisioned – An unconfigured state where credentials have not yet been established.
  • Being provisioned – AMT is in the process of being configured, credentials have been established, but no configuration has been set.
  • Provisioned – AMT has been configured on the system.

Once the research was published regarding vulnerabilities associated with ME manufacturing mode the Chipsec project added capabilities to detect this condition. The first step was to download and build Chipsec:

## Note: The instructions that follow were tested on Ubuntu 20.04.4 $ sudo apt install python3 python3-setuptools nasm build-essential linux-headers-$(uname -r) $ sudo update-alternatives –install /usr/bin/python python /usr/bin/python3 1 $ git clone $ cd chipsec $ python build_ext -i

If Intel ME is in manufacturing mode like it was on one particular system that I manage, Chipsec will produce the following results when using the “common.me_mfg_mode” module:

$ sudo python -m common.me_mfg_mode ################################################################ ## ## ## CHIPSEC: Platform Hardware Security Assessment Framework ## ## ## ################################################################ [CHIPSEC] Version 1.8.6 [CHIPSEC] Arguments: -m common.me_mfg_mode ****** Chipsec Linux Kernel module is licensed under GPL 2.0 [CHIPSEC] API mode: using CHIPSEC kernel module API [CHIPSEC] OS : Linux 5.15.0-41-generic #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022 x86_64 [CHIPSEC] Python : 3.8.10 (64-bit) [CHIPSEC] Helper : LinuxHelper (/home/paulda/chipsec/chipsec/helper/linux/chipsec.ko) [CHIPSEC] Platform: Desktop 8th Generation Core Processor (CoffeeLake S 8 Cores) [CHIPSEC] VID: 8086 [CHIPSEC] DID: 3E30 [CHIPSEC] RID: 0D [CHIPSEC] PCH : Intel Z390 (300 series) PCH [CHIPSEC] VID: 8086 [CHIPSEC] DID: A305 [CHIPSEC] RID: 10 [+] loaded chipsec.modules.common.me_mfg_mode [*] running loaded modules .. [*] Running module: chipsec.modules.common.me_mfg_mode [x][ ======================================================================= [x][ Module: ME Manufacturing Mode [x][ ======================================================================= [-] FAILED: ME is in Manufacturing Mode [CHIPSEC] *************************** SUMMARY *************************** [CHIPSEC] Time elapsed 0.001 [CHIPSEC] Modules total 1 [CHIPSEC] Modules failed to run 0: [CHIPSEC] Modules passed 0: [CHIPSEC] Modules information 0: [CHIPSEC] Modules failed 1: [-] FAILED: chipsec.modules.common.me_mfg_mode [CHIPSEC] Modules with warnings 0: [CHIPSEC] Modules not implemented 0: [CHIPSEC] Modules not applicable 0: [CHIPSEC] *****************************************************************

Note: In the above command example instructions are provided for installing the required dependencies to run Chipsec on Ubuntu 20.04.4. Other Linux distributions may have slightly different commands to install the dependencies (and set the default Python interpreter). 

Eclypsium also detects if Intel ME Manufacturing Mode is enabled. On one of my systems such a condition exists:

Yet another utility for collecting information about Intel ME comes from the Coreboot project and is called intelmetool. intelmetool will attempt to discover Intel ME and list the capabilities, including if manufacturing mode is enabled (or not). The instructions below show you how to download, compile and run intelmetool:

## Note: You make have to install the required dependencies: ## sudo apt install libpci-dev zlib1g-dev $ git clone –depth=1 $ cd coreboot/util/intelmetool $ make $ sudo ./intelmetool -m MEI found: [8086:a360] Cannon Lake PCH HECI Controller ME Status : 0x90000255 ME Status 2 : 0x6f10506 ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : YES ME: Manufacturing Mode : YES ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : M0 with UMA ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase ME: Power Management Event : Pseudo-global reset ME: Progress Phase State : (null) ME: Extend Register not valid ME: Firmware Version 12.0.1652.70 (code) 12.0.1652.70 (recovery) 12.0.1652.70 (fitc) ME Capability: Full Network manageability : OFF ME Capability: Regular Network manageability : OFF ME Capability: Manageability : OFF ME Capability: Small business technology : OFF ME Capability: Level III manageability : OFF ME Capability: IntelR Anti-Theft (AT) : OFF ME Capability: IntelR Capability Licensing Service (CLS) : ON ME Capability: IntelR Power Sharing Technology (MPC) : OFF ME Capability: ICC Over Clocking : OFF ME Capability: Protected Audio Video Path (PAVP) : ON ME Capability: IPV6 : OFF ME Capability: KVM Remote Control (KVM) : OFF ME Capability: Outbreak Containment Heuristic (OCH) : OFF ME Capability: Virtual LAN (VLAN) : ON ME Capability: TLS : OFF ME Capability: Wireless LAN (WLAN) : OFF

There is yet another tool that Intel provides called the CSME Version Detection Tool. This tool is freely available and provides similar capabilities as the previously mentioned tools, with one exception: it will notify you if the version of Intel ME on your system contains vulnerabilities:

$ wget $ mkdir intel_csme $ cd intel_csme/ $ tar zxvf ../CSME_Version_Detection_Tool_Linux.tar.gz $ sudo python3 ./intel_csme_version_detection_tool Intel(R) CSME Version Detection Tool Copyright(C) 2017-2022, Intel Corporation, All rights reserved. Application Version: Scan date: 2022-07-14 17:03:03 GMT *** Host Computer Information *** Name: gibson Manufacturer: Micro-Star International Co., Ltd. Model: Prestige 15 A10SC Processor Name: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz OS Version: Ubuntu 20.04.4 LTS (5.15.0-41-generic) *** Intel(R) ME Information *** Engine: Intel(R) Converged Security and Management Engine Version: *** Risk Assessment *** Based on the analysis performed by this tool: This system is vulnerable. Explanation: The detected version of the Intel(R) Converged Security and Management Engine firmware has a vulnerability listed in one or more of the public Security Advisories. Contact your system manufacturer for support and remediation of this system. For more information refer to the Intel(R) CSME Version Detection Tool User Guide or the related Intel Security Advisory list at:

One limitation of this tool is that while it tells you that you have vulnerabilities, you do not know how many, which vulnerabilities are present, or how to remediate them (other than going to your hardware manufacturer’s website and finding the update, which may or may not contain a list of known vulnerabilities in older versions of the update). Thankfully Eclypsium’s product was helpful in not just telling me about the version of Intel ME or AMT that is installed, but enumerating the known vulnerabilities as well:

When analyzing vulnerabilities related to Intel ME and/or AMT it is important to note that given the research cited above, chaining vulnerabilities can lead to successful attacks against your systems. For example, if the version of Intel ME is vulnerable to a local attack and you have AMT running with a remotely exploitable vulnerability, they can be combined to give remote attackers access to install malicious code in Intel ME firmware. 

Can I Remove Intel ME?

Before we go any further, I would like to caution readers to read through all the documentation before attempting Intel ME modifications. Furthermore, I do not recommend modifying Intel ME in any way, especially on production systems. The materials presented here are for educational purposes only and should be performed on test systems in a lab. 

The short answer is no. Intel ME components are required to properly boot a system and provide the functionality required to keep a system running. Since ME is firmware running on hardware within your system, you can modify Intel ME such that it has fewer features or instruct it to disable itself, in certain cases and when, or if, your hardware supports this process. This is made possible by previous research mentioned above and an open-source project called me_cleaner. Below are some important pieces of information, sometimes misunderstood, so to clarify:

  • In order to modify Intel ME you will most likely have to use a SPI programmer, a device that is attached directly to the SPI flash chip on your motherboard. Using the SPI protocol, the chip is powered up externally and the contents of the SPI flash are copied directly from the chip. You cannot access this region of the SPI flash through software as Intel ME resides on the SPI flash in a protected region. However, if there are missing security controls from your hardware, such as if the OEM has insecurely configured the SPI Flash Descriptor (a topic I will cover in the next part of this series), this could mean you are able to directly write to the SPI flash through the operating system (See also Screwed Drivers – Signed, Sealed, Delivered).
  • Another method of obtaining the Intel ME firmware for your system is through the hardware manufacturer’s updates. Since the hardware manufacturer knows the details of the specific hardware and software on your system, they typically will provide a firmware update for Intel ME to address both functional and security-related issues. There are documented methods for extracting the Intel ME firmware update from the software update packages
  • The Intel ME firmware is broken up into regions, and each region may contain a different, and individually signed, software module. For example, Intel’s AMT software is implemented as modules, and since they are individually signed, the software and the signature can be removed. However, this means we cannot, at least without further research and/or existing vulnerabilities, add modules to existing Intel ME firmware.
  • Depending on your hardware and the version of Intel ME running, you may be able to disable some functionality within Intel ME using the “HAP” (High Assurance Platform) bit on Intel ME (version 11 or greater, Skylake or newer) or the “AltMeDisable” bit, on systems running Intel ME less than version 11. In both cases, the bit acts as a kill switch for certain components of the Intel ME firmware. Both of these are undocumented features built into the ME firmware by Intel and were originally intended to allow certain government customers to disable most of the Intel ME functions.

What Are My Other Options For Remediation?

While you can attempt to disable, or greatly reduce the functionality of Intel ME on your system for many this may not be practical (myself included, at least on my primary systems). Once you’ve scanned your system for Intel ME vulnerabilities it is best to find your hardware manufacturer’s updates and follow the instructions carefully to update Intel ME. For example, one of my systems does have Intel ME updates available from the manufacturer, which come with the updated firmware and software to apply the updates. If you are running Windows, simply download the latest updates and tools then apply them accordingly. If you are running Linux you can use a Windows bootable thumb drive (I prefer Hiren’s Boot CD, a Windows PE bootable USB thumb drive image), load the new firmware and utilities, then update Intel ME. 


Intel ME, in some form, has been included with your Intel-based system and represents an attack surface that must be secured. A significant number of vulnerabilities and research has been published showcasing a wide variety of security-related issues with Intel ME. While there are various ways to disable and/or reduce the functionality of Intel ME, the best way to ensure your system is protected is to apply the latest firmware updates. You can use several different freely available tools to enumerate information about Intel ME on your system. Eclypsium customers are able to view detailed information about Intel ME (and AMT) firmware. Owners of Intel-based computers with Intel ME must prioritize and apply firmware updates to be more resilient against firmware-based threats.

Additional Resources

I discovered several articles covering various aspects of Intel ME that may not have been referenced above:

Special thanks to the Eclypsium research team, including Jesse Michael, Eclypsium co-founder Alex Bazhaniuk, and Mickey Shkatov for assisting me with this article.