How to Identify Network Vulnerabilities with NetworkRecon.ps1

Initially, I attempted to build a tool that would collect and analyze traffic presenting output similar to that produced by PowerUp.ps1 Invoke-AllChecks as seen below. PowerUp is used to provide very concise feedback indicating where an operating system’s configuration might allow privilege escalation. The intent for this script was to do the same for network protocol abuse.

In investigating the available options, I found that working with the facilities for packet capture and analysis using PowerShell (particularly Windows 7 and older operating systems) were not optimal for creating this output in all cases.

Fortunately, I was already familiar with Invoke-Inveigh written by Kevin Robertson and included in several other exploitation frameworks. After running into issues with the collect and analyze workflow, I adopted the packet sniffing capabilities observed in this and other tools as an alternative.

The script includes three functions; Invoke-NeighborAnalysis, Invoke-TraceCollect, and Invoke-LiveAnalysis. These functions provide different detective capabilities to identify CDP, DTP, VTP, LLDP, mDNS, NBNS, LLMNR, HSRP, OSPF, and VRRP protocols which may be used for information gathering or indicate vulnerability to attack. In addition, the script analyzes DHCP responses looking for options that indicate network boot is supported.

Invoke-NeighborCacheAnalysis:

Invoke-NeighborAnalysis attempts to detect the presence of the protocols listed above at layer 2 of the OSI model. This function uses the output from either “arp -a” or Get-NetNeighbor based on the supported PowerShell version. The output is analyzed looking for corresponding multicast layer 2 and layer 3 addresses indicating that a protocol is likely in use and visible from the end host. The packet sniffer uses a raw socket and doesn’t collect Ethernet frames. As a result, this is the only way that CDP, DTP, VTP, and LLDP can be detected at present. I did some research on collecting Ethernet frames using PowerShell but came up empty handed. Output from Invoke-NeighborCacheAnalysis can be seen below.

Invoke-TraceCollect

Invoke-TraceCollect does exactly what it sounds like. It simply records network traffic in a trace file for a user specified period (default is 5 minutes) so the user can move the traffic off and analyze it with another tool.  This function will output either a “.cap” file or a “.etl” file depending on the operating system features. Windows 8.1 and newer supports the Protocol Engineering Framework (PEF) PowerShell commandlets by default.  This framework allows one to directly save a network trace in packet capture format. Older versions of Windows support the Event Trace Log (ETL) format which records packets in an XML and binary format. ETL format can be converted to packet capture as well. However, Microsoft Message Analyzer (an additional Microsoft software package) is used to do so. The output from this function simply indicates which format is being used and where the trace file is being written. To run this function, you must have administrator permissions on the target computer.

Invoke-LiveAnalysis

Invoke-LiveAnalysis uses a raw IP socket to pick traffic up off of the wire and perform analysis. This method uses the layer 3 multicast addresses and well known ports to identify the presence of protocols of interest.  The user is notified when mDNS, NBNS, LLMNR, HSRP, OSPF, or VRRP packets are observed. Notifications include details parsed from observed traffic such as authentication method, passwords or hashes used, and hostnames for which queries are observed.  Output from several of the protocols above can be seen in the screen captures below.

The protocols listed above were selected due to the presence of attacks and tools available for each. Protocols and their related vulnerabilities are identified below.

• CDP and LLDP may expose information valuable to an attacker such as Layer 2 device names and firmware revisions.
• DTP and VTP may allow an attacker to access protected areas of the network through VLAN hopping attacks.
• mDNS, NBNS, and LLMNR may allow an attacker to send poisoned responses to multicast name resolution request. These attacks, executed by tools like Invoke-Inveigh and Responder, can result in credential compromise or direct exploitation by directing requesting hosts to an attacker controlled computer.
• HSRP and VRRP may allow an attacker to become a Man-in-the-Middle (MitM) by electing an attacking computer as the active router in a redundant configuration.
• OSPF may allow an attacker to become a MitM by manipulating the OSPF routing table.
• Discovery of DHCP boot options may allow an attacker to boot an authorized operating system or download and analyze the boot image for valid credentials.

The end goal for this tool is to include intelligence gathering and attack capabilities for all of the Layer 3 protocols identified above.  Further investigation into Layer 2 protocols will continue to determine whether Layer 2 attacks will be possible using the native PowerShell interface.

You can find the full script at https://bitbucket.org/Super68/networkrecon/ and an expanded explanation of each of the functions at https://www.sans.org/reading-room/whitepapers/access/identifying-vulnerable-network-protocols-powershell-37722 .

Please provide feedback and let us know how this tool works in practice!!