CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

NAC doesn’t like your penetration testing device? IPv6 to the rescue!

Sometimes when I conduct a network penetration test it's just too easy to get to the "crown jewels". And sometimes I just hit the wall from the very start and have no idea how to proceed. It happened to me during my last test, when the client chose to decline the option to whitelist my penetration testing device on their Network Access Control (NAC) system.

Below I explain how when my IPv4 connections were blocked by the NAC system, I used IPv6 to compromise a number of hosts and some sensitive data during a recent test.


The pentesting device was located in the internal client network and I was connecting to it remotely over an SSH connection. And, as it turned out later, that was the only connection allowed for this device. So it was far from easy to test anything in that scenario. Since the client preferred an entirely black-box approach, it seemed the list of results might be empty. But where there's a will, there's a way…

At the beginning of the test I had started a port scan to find any active hosts with open ports. That was unsuccessful but I noticed something weird in those scans. They finished very fast, but too fast. A little investigation and I understood that there was some kind of active defense system in the network that was resetting all my connections that were going to active hosts. So at least I knew that I was not alone in the network and that I would need to find another way to access other machines.

I launched a sniffer and after a while of looking at the flowing traffic, I came up with an idea: If all my IPv4 connections are getting blocked, then why not try to use the IPv6!

So just a little refresher for those who are not familiar with this protocol:

  • IPv6 is the latest version of the Internet communications protocol intended to replace IPv4, as IPv4 can only address about 4 billion unique IPs, and the 21st century Internet needs much more than that. IPv6 expands the number of available addresses to an almost limitless amount: 340 trillion trillion trillion addresses!
  • Unlike the IPv4 address space, it is not easy to scan IPv6 addresses in order to discover active systems (due to wider address space). But just as with IPv4, you can ping the broadcast address (in IPv6, this is FF02::1) and all the systems on the local network should respond to this.
  • IPv6 sometimes can be overlooked by the network engineers who are setting up the firewall/NAC rules. And because many firewall products might not block IPv6 traffic by default, we can use this gap for our penetration test.
  • You can find more detailed information about IPv6 on Wikipedia or the IPv6 RFC.

A little bit of Googling and I find out that Nmap and Metasploit already have some nice modules to discover IPv6 addresses in the local network. The Metasploit module "ipv6_multicast_ping" worked fine for me and I was able to discover other IPV6 enabled hosts in the same subnet:



The next step was to find running services on the discovered hosts. Nmap has been offering basic IPv6 support (like connect port scans, basic host discovery and version detection) since 2002. So we can scan the IPv6 address with this command:

nmap -6 -sV <IPv6_address>

(You don't need to add the interface name e.g. "%eth0" at the end of the IPv6 address anymore if you are using one of the latest versions of nmap)



Wow, this phpMyAdmin on port 80 looks promising, but can we access this service running on IPv6 host with a normal web browser?

Yes we can! Many modern browsers support the IPv6 protocol by default. But in my scenario, when I was accessing this host over an SSH tunnel with port forwarding enabled, my Firefox browser couldn't load the website. With a little help from a more experienced pen tester, I ran "socat" to proxy IPv4 to IPv6 traffic. A sample socat command you can use to bind a remote 80 TCP port on the IPv6 host to your local 8080 TCP port:

socat TCP-LISTEN:8080,reuseaddr,fork TCP6:[IPv6_address%eth0]:80

Then we can easily load the website using our localhost address:



Bingo! It seems that someone forgot to set up a password for the root user on the phpMyAdmin web page. From here we can create a simple web shell and gain access to the operating system command shell in a few minutes:



And we have a remote code execution!


At the beginning of the test, I was thinking that there was no hope and that I would end up without any serious finding that I could include in the report. Knowing that there was a NAC system in the network was only adding to my frustration. I didn't believe that there was a way to bypass it, because after all it was a product made by a leading company in the IT security field. But in the end, with a little help from the IPv6 protocol, I was able to pwn some hosts and get access to the sensitive data.

So remember, when you are running a test and everything goes slowly and with little success, you just never give up, there's always a way.

Latest SpiderLabs Blogs

EDR – The Multi-Tool of Security Defenses

This is Part 8 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

The Invisible Battleground: Essentials of EASM

Know your enemy – inside and out. External Attack Surface Management tools are an effective way to understand externally facing threats and help plan cyber defenses accordingly. Let’s discuss what...

Read More

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More