Exploiting the Intel AMT Vulnerability with Burp Suite

On a somewhat recent engagement I discovered a number of open ports that I was not immediately familiar with. When this happens, I’ve found that it (almost) always pays to explore further… We can see that this range of ports is open on a number of hosts on this particular subnet. Additionally, as it turned out, there were many other hosts on other subnets also listening within this port range as well.


A more in-depth, nmap service scan provides us with more additional information about the service.

capture 2

A quick google search leads us to: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr

Based on the httpd version number, all indications point to this host being vulnerable to CVE-2017-5689. Another nmap scan can validate this for us:


Now that we know our host is actually vulnerable the next step is figuring out how to exploit it. If you notice above, we can see that it says “…can be exploited by performing digest authentication and *sending a blank response*…”

Armed with this information, we can fire up Burp Suite and attempt to exploit the vulnerability. However, first, we need to hit the login page on our host:

capture 4

With Burp Suite now open AND “intercept” turned on (see below), we can input “admin” into the username field and click “ok”. We should see a response in the RAW data (see below)

capture 5

Next, we need to modify the “response” data and eliminate everything so that it’s blank:

capture 6

When we click the “Forward” button in Burp Suite (see bottom right of below screen shot), it should send our blank response back to the host and we should now be logged in – as seen here:

capture 7

Note: every time you switch between menu items within the AMT management console, you will need to blank out the digest response and “forward” the blank response back to the host – otherwise, you will be unable to navigate throughout the console. As a result, you’ll need to keep Burp Suite running side by site or easily accessible in the background.


Anonymizing Recon Using Tor & Proxychains

Whenever we send a packet to our intended target, that packet contains information about network (like our public IP address) – which can ultimately then be traced back to us.  In the interest of remaining anonymous, our goal here is to perform recon on a public network (using something like NMAP) with the least risk of our work being traced back to us.

To achieve this, we need two tools: Tor and proxychains.  ProxyChains allows us to pipe TCP connections through a proxy, or a chain of multiple proxies, effectively masquerading our public IP address.

We can download our tools using the commands below:

apt-get install tor
apt-get install proxychains
apt-get install nmap (if you don’t already have it)

Before we get started, we want to make sure we don’t accidentally disclose our public IP to our victim by running the following command. Replace the below IP address with your target victim.

sudo iptables -A OUTPUT –dest -j DROP

Once we do that, we can see what happens when we try to send packets to that IP address.

Prior to using Tor and ProxyChains, we should (always) determine/check what our public IP address is:


Next we need to get the Tor service running. We can run the following commands:

service tor start
service tor status


With Tor running, we can now use ProxyChains to mask our public IP address by running the following command:

proxychains curl ipecho.net/plain


We are now ready to do some NMAP scanning on our victim. This can be done using the following command:

proxychains nmap -Pn -sV -sT -v -p 80,443


Since we have access to the victim box, let’see what a tcpdump looks like while the NMAP scan is in progress:


If we curl using ProxyChains, we can also see that Apache logs (on the victim box) also show as coming from our new IP address on the Tor network: