While performing a routine internal penetration test, I began the assessment by running Responder in analyze mode just to get an idea of what was being sent over broadcast. Much to my surprise, I found that shortly after running it, a hash was captured by Responder’s SMB listener.

This hash belonged to an account named “panagent,” which I assumed to mean PAN (Palo Alto Networks) agent. I threw the hash into Hashcat and shortly thereafter I was able to recover the plaintext password. Using CrackMapExec, I sprayed these credentials against internal systems within the local network and found that they had administrator access on multiple hosts within the environment.

After gaining admin access on these systems, I performed what is known as the “credential shuffle” until I compromised the credentials for an account within the “Domain Admins” group. So, what happened?

I began researching this issue, and the earliest write-up I could find was one by Rapid7 titled: R7-2014-16: Palo Alto Networks User-ID Credential Exposure. The root cause appears to be a feature called “User-ID” that Palo Alto uses to map network traffic with specific users. After this discovery, it prompted Palo Alto to release an advisory on the security impacts of misconfiguring User-ID.

To see how User-ID functions, I set up a Palo Alto firewall myself to see how this would be configured, and read the documentation provided by Palo Alto on how to set up User-ID.

One of the first things that needs to be done before setting up User-ID is establishing zones. The documentation warns the reader to only enable User-ID on trusted zones. It also informs you that probing by User-ID could reveal the service account name, domain name, and encrypted password hash.

To use this feature, you must also configure a user/service account with it. Palo Alto documentation advises you use the minimum permissions required; however, what the minimum requirements are is not quite clear. It can be assumed that local administrator rights are not required.

When setting up User-ID you must specify the network ranges that User-ID should communicate with, otherwise it will default to all servers.

To define this, you can set a zone by going to the Network tab, clicking on Zones, and modifying the Include list and Exclude list as well as checking the “Enable User Identification” box.

The last step is by far the most dangerous, and Palo Alto now recommends that you do not enable it. While the warning in the documentation advises you not to enable it on “high-security networks,” this could be better interpreted as a warning not to enable it on a network where security is of any concern at all.

Client probing is performed with WMI and/or NetBIOS. NetBIOS is a multicast name resolution protocol that is particularly dangerous on any network, and it is always advised to have it disabled enterprise wide. The risks become even more apparent when reading Palo Alto’s documentation on client probing.

What this means is that with any unknown system on the network identified by the firewall, it will immediately try to connect to the device, and then repeat every 20 minutes by default. If a rogue attacking system is in your network, this feature will send the domain, username, and the encrypted password hash to that rogue device every 20 minutes. This is highly undesirable. To disable this feature or to ensure it is not enabled, navigate to the Device tab, and click User Identification. From there click the gear icon, navigate to the Client Probing tab, and uncheck “Enable Probing.”

I hope this helps those who use Palo Alto firewalls have a better understanding of the risks associated with User-ID and the particularly dangerous Client Probing option within it.