As a penetration tester, I find the penetration testing activity to be exciting!  It’s exciting to be able to attack a target, legally mind you, with the intention of breaking in and stealing data or creating backdoors for persistent connections or any other sort of cool penetration testing activity. Before I go on though, I do want to point out that this article isn’t all encompassing relating to penetration testing or securing a network.

As a part of this, one of the possible challenges (but not always) is an experienced good guy adversary that has properly designed their company’s network. When I indicate “properly designed”, I’m specifically talking about segmentation or micro-segmentation of the network. Where the network is segmented based on the needs of the entity and could be segmented by IP subnet, or possibly by function, or even location. Segmented networks increase the work effort by bad actors to perform recon of the target environment because the bad actor either has to scan a large number of IP addresses at one time or configure for multiple scans. All of which can be very noisy on the network and attract attention to the bad actor. A segmented network also puts the attacker into the position of having to guess what IP subnets to scan.

However, and still talking about segmentation, in order to go from one network segment to another requires a router. Generally, companies that have routers in place will likely have some form of routing protocol to make that happen. As it is, there are numerous routing protocols that can be used in a dynamic manner. Not all of these routing protocols are secure though. One example is RIP (Router Information Protocol). RIP is one of the first routing protocols and, amazingly, is still in use because of how easy it is to set up. Unfortunately, almost all operating systems out there can act as a RIP listener and that can provide network subnet information to the bad actor without doing anything other than “listening”. Another example is OSPF (Open Shortest Path First). Much like RIP, OSPF can be “sniffed” using Wireshark which can help a bad actor diagram the network. Now the good thing from the network defense standpoint is all of this can be secured if the network engineer understands the routing protocol itself and the possible associated security measures to take.

You may be wondering why I specifically mention RIP and OSPF in the previous paragraph is because both are routing protocols that are vendor agnostic and easy to implement across networks with multiple types of network hardware. Most larger companies are hybrid in nature when it comes to network device infrastructure. However, there are other routing protocols that a bad actor should be aware of that can allow them to determine more about the network design. Specifically, I’m talking about running Wireshark to see if other routing protocols are in use, which can help determine device manufacturers. One example of this would be Cisco networks where proprietary routing protocols can be used. IGRP and EIGRP would be primary examples of Cisco proprietary routing protocols with IGRP being unsecure and routing limitations like RIP while EIGRP being upgraded to IGRP. Both require Cisco devices to work but because of that if either of those routing protocols are detected then the bad actor now knows that Cisco devices are used and can focus more energy on Cisco related attacks.

Also, most Cisco devices are configured to broadcast CDP (Cisco Discovery Protocol) which can release several bits of infrastructure information to bad actors. Examples would be device type, operating system, port density, and other relevant information a bad actor could use.

Before I move away from networks or routing, if a penetration tester is able to compromise a device and can determine if it is a multi-homed device then that only helps the penetration tester or bad actor. This has, more than once for me, exposed new IP subnets that were not part of the routable network. In most cases, actually in all cases from my experience, this hidden subnet leads to SCADA or PLC type devices.

One area of infrastructure security that I hardly, and very surprisingly, run across is the implementation of port security. If a company has wired connections to computers and those computers don’t move from one port to another then there really isn’t any reason to lock down switch ports to only that one device. This helps prevent a bad actor from simply unplugging a device and plugging in their own or unplugging a device and plugging in a hub to keep the legitimate computer in place but to also allow another computer. In network engineering language this is called “sticky MAC” and it’s easy to implement. The reason it sometimes is objected to, is because changing out an old computer with a new one will require more work and coordination with not only IT support but also network engineers. In one of my pentesting engagements, I ran across this but was also able to overcome “sticky MAC”, by masquerading the legitimate MAC (which in that case was an IP Phone).

Somewhat similar to port security is 802.1X, which can require a little more planning and coordination. 802.1X works by having the devices themselves communicate with an authentication server and, if the device is valid, it’s allowed on the network. It’s not impossible to implement but inexperienced network engineers or smaller companies with limited budgets or time may have difficulty implementing it.

Another area that can be easily exploited would be the DNS zone transfers. Being able to request a DNS zone transfer from improperly configured Active Directory servers (of DNS servers in general) can help a bad actor perform a tremendous amount of recon without scanning the network. By pulling information this way, the activity of performing ping sweeps doesn’t really have to happen. This is important for a bad actor because security technology may pick up a ping sweep. DNS zone transfers can expose IP subnets, computer names, and IP addresses associated with possible critical devices and with less noisy activity on the network. One of the areas I always enjoyed, to the dismay of whom I was attacking, was when I could do a DNS zone transfer and pick up interesting names like “Server1” or “Finance1” or “BadgingPC”.

One area that I routinely find unsecured, even in a secure network infrastructure environment, would be unsecured printers. I love to compromise printers as one of the first targets to see what is stored on the printer hard drives or if I can see what other network related information I can glean from the printers. It’s not unreasonable to find printers that actually have routing protocols configured and can disclose routing information to bad actors. It’s also not unreasonable to find printers that have poorly configured SNMP settings. Or to be blunt, SNMP configured with the default and if you are an auditor, implementer, or penetration tester, you know exactly what I mean by that.

So how could some of this be remediated? First, keep implementing segmentation of the network but do it thoughtfully. Network engineers will segment based on performance and some security engineers don’t have a network engineering background to understand the interrelation between performance and security. Segment the network based on IP subnet (for performance) but also by function to secure the network. Perform a network traffic analysis to determine which subnets need to talk to each other and put in controls to prevent other traffic. A great example of this would be the finance department. Finance personnel likely don’t need unrestricted access to the rest of the network but will need access to emails or possibly financial servers. Put restrictions in place where the finance people can’t get to unneeded areas of the network but can connect to email. Most communication is by email anyway or some cloud-based messaging program like Microsoft Teams or Slack. Finance people also need their own dedicated printers so put dedicated printers inside the “Finance Subnet” and prevent those printers from getting outside that Finance VLAN. Doing this will make it more difficult for a pentester/bad actor from going from one VLAN to another. Not impossible but more difficult.

Obviously, turn on port security, it’s one of the easiest things to do and most likely is already built into every switch that is sold. Not only does this help secure the network from bad actors but it also helps prevent users from installing switches or other devices without coordinating with network engineers first. As a consultant that helps companies get ready for audits, one of the tasks that I require my clients to do is create a network drawing. You would be amazed at the number of times I hear my clients complain about unapproved devices that they discover as a part of that exercise. 

Avoid proprietary routing protocols and focus on OSPF. But use the right version of OSPF and with the right configuration to do “secure routing” between different device manufacturers, and use encryption when possible. Disable CDP unless it’s needed. Get rid of multi-homed devices unless absolutely required. DNS servers can be configured to only do DNS zone transfers with identified servers rather than just any server that makes a request, and use encryption when possible. I’d even go so far as to suggest that the edge firewalls be configured to disallow DNS traffic except for approved internal DNS servers to prevent using DNS as a form of data exfiltration (think VPN but using DNS). For printers, secure them in every possible way, and unless the printer has a function involving Internet access, then implement firewall rules to prevent printers from being used as an exfiltration tool.

There’s actually quite a bit more I could write about relating to this, however, aspects of penetration testing change on a daily basis with the inclusion of new vulnerabilities disclosed by ethical hackers and the attempts to exploit them by bad actors. Having said that if you are an aspiring penetration tester then I strongly suggest you learn network engineering concepts, build out a test network, and then attack it. If you are a network engineer, or want to be one, then understand that network security and network performance must work hand in hand. Too much network security can give the impression that the network is slow and too much consideration to network performance can greatly increase risk in relation to network security.