Stockholm Syndrome: Accurate network testing
Caution is important when pentesting networks, it is important to perform the security analysis in a way that does not disrupt the customer's infrastructure. In this article, I will discuss the aspects that need to be considered for a safe security analysis.

Caution is important when pentesting networks, it is important to perform the security analysis in a way that does not disrupt the customer's infrastructure. In this article, I will discuss the aspects that need to be considered for a safe security analysis.
Caster - Stockholm Syndrome
Genre: Offensive
Label: exploit.org
Release Date: 29 July 2024
Performed by: Caster
Written by: Magama Bazarov
Cover Man: Magama Bazarov (Sony ILCE-7M3, f/5.6, 1/3 sec)
Intro
Pentesting the internal infrastructure always carries some risks. Even a single scan can have a serious negative impact on a network. It is important to handle traffic intelligently, especially when conducting man-in-the-middle (MITM) attacks. Consider the potential presence of switch-level security systems that can interfere with the scanning process.
This article is intended to raise pentester awareness when working with network infrastructure during penetration testing.
Disclaimer
This article is for informational purposes and is intended for security specialists conducting testing under an agreed contract. The author and exploit.org are not responsible for any damage caused by the use of the information provided.
Disruption of systems, hacking into other people's computer networks will be prosecuted. Be careful and do not try your luck.
Active Recon
Active Recon involves interacting with target systems to gather information. This method may be more visible than passive reconnaissance, but it provides richer information for subsequent testing phases.
ARP
ARP (Address Resolution Protocol) is a protocol used to determine the MAC addresses of devices based on their IP addresses. ARP queries are widely used for active reconnaissance in LANs, but their use carries certain risks:
- High visibility: ARP queries generate significant traffic that can be easily detected by network monitoring tools;
- Possibility of blocking: Some network devices and security systems may block or restrict ARP requests, which can prevent information collection. Speaking of which, Storm-Control is capable of this, which can simply block a port due to excessive traffic;
- Network overload: Mass ARP requests can cause network congestion and affect network performance
To deal with ARP, you can use netdiscover. This is a passive and active LAN scanning tool that is especially useful for detecting live hosts.
You can use passive mode: this mode allows you to listen for ARP traffic on the network without sending your own requests. This is the least visible way of collecting information:
caster@kali:~$ sudo apt-get install netdiscover
caster@kali:~$ sudo netdiscover -i eth0 -p
It is the -p
argument that indicates the passive mode of operation of netdiscover
As for the active mode, you can scan the address range you want by selecting for example the /24
mask.
caster@kali:~$ sudo netdiscover -i eth0 -r 192.168.100.0/24
This will reduce traffic and probability of detection, because if you run netdiscover without specifying a particular subnet range, the tool will start scanning all subnets in a row.

You can also use the -c
parameter, it indicates the number of ARP requests to be sent for each IP address. For example, 15 requests for each IP address:
caster@kali:~$ sudo netdiscover -i eth0 -r 192.168.100.0/24 -c 15
This can be useful in networks with a high probability of packet loss
However, before using the -c
parameter, evaluate the network status. If the network is stable and packet loss is low, you may not need to send so many requests.
NetBIOS
NetBIOS (Network Basic Input/Output System) is a network protocol that allows applications on different computers on a local area network to communicate with each other. It provides a wealth of information about the network, including computer names, IP addresses, services, and shared resources. However, using NetBIOS for active reconnaissance carries certain risks:
- High visibility: NetBIOS requests can be easily detected by network monitoring tools. Notable requests can raise suspicion and lead to blocking or other security measures.
- Blocking Capability: Modern security systems can block or restrict NetBIOS traffic, making it more difficult to gather information, again, Storm Control can interfere
To reduce noise, you can conduct NetBIOS exactly on the address range using the -r
argument
caster@kali:~$ sudo nbtscan -r 192.168.100.0/24
NetBIOS scanning is just as noisy as ARP scanning. Same clinical picture.
Passive Recon
A method of gathering information about the infrastructure, but the attacker does not generate noise in the air. The main technique here is traffic analysis. I believe that traffic analysis is an underestimated thing and it is possible to extract quite valuable information about the infrastructure from the air without scanning.
Traffic Sniffing
With the Above tool, you can analyze traffic to find network security issues. As of version 2.6, it supports 27 protocols, including dynamic routing protocols, gateway redundancy, neighbor discovery protocols, and more. The tool does not make any noise over the air and can find potential attack vectors for network equipment. The startup is very simple, just give two arguments to the input, the interface name and the number of seconds to listen to the air:
caster@kali:~$ sudo apt install above
caster@kali:~$ sudo above --interface eth0 --timer 300
Above is available from the Kali Linux repositories, installs in one click

This is how valuable information can be extracted from the air, for example, an attacker knowing the presence of dynamic routing domain or redundancy protocols can develop a network attack vector.
Fingerprinting
Fingerprinting can be especially useful if the attacker is conducting a MITM attack. p0f allows host identification, the attacker can find out which OS the target hosts are running. This is a very useful technique to complement a MITM attack.
caster@kali:~$ sudo apt install p0f
caster@kali:~$ sudo p0f -i eth0 -o p0f.log
Credentials Sniffing
The net-creds and PCredz utilities are useful tools for easy collection of data on the air. They are usually used to extract passwords, NTLM hashes, SNMP community strings and other interesting things from traffic:
caster@kali:~$ sudo python2 net-creds -i eth0
caster@kali:~$ sudo python3 ./Pcredz -i eth0
This is roughly how you can do passive reconnaissance based on traffic analysis. An underrated thing in pentest that can bail you out.
Scanning
Network devices and applications may have varying degrees of load sensitivity. Avoid high-intensity scanning, which can cause disruptions or attract attention
Why it is undesirable to use high speed
If the scanning speed is too fast, there is an increased risk that the target hosts simply do not have time to respond. Buffering at the network hardware level can also be a problem. At high scan rates, these buffers can fill up quickly, causing new packets to be dropped if the buffer is full. Also, at moderate scanning speeds, the risk of hardware overload is greatly reduced, which helps keep both your network and the hosts being scanned stable.
Rates
When pentesting network infrastructure, scanning speed is a critical parameter. Optimal scanning speed allows you to effectively identify vulnerabilities while minimizing the risk of network congestion and missing active hosts.
For /8 masked networks, a scan rate of 4500-5000 packets per second (pps) is optimal. This is the sweet spot between scanning speed and quality, minimizing the risk of overloading equipment and reducing the chance of missing active hosts:
caster@kali:~$ sudo masscan -pT:22,445,3389 --rate 4700 10.0.0.0/8
For networks with mask /16 it is recommended to reduce the scanning speed to 2600-2800 pps. This avoids unnecessary load on the network and equipment, while ensuring a sufficiently high rate of detection of active hosts:
caster@kali:~$ sudo masscan -pT:22,445,3389 --rate 2700 172.16.0.0/16
For networks with a /24 mask, a scan rate in the range of 700-1000 pps is sufficient. Given that the /24 mask provides only 254 host addresses, a high scan rate is not required:
caster@kali:~$ sudo masscan -pT:22,445,3389 --rate 800 192.168.0.0/24
It is important to keep in mind that the optimal scanning speed parameters should be selected individually, based on the peculiarities of a particular network infrastructure. In some cases, even at 1000 pps, the network may exhibit unstable behavior. It is important to communicate with the customer and take their opinion into account, as the network equipment in the infrastructure may not have sufficient capacity to handle high scanning speeds.
Hosts Randomizing
The use of the --randomize-hosts
flag in masscan is important to reduce the probability of scan detection and reduce the load on the network at certain times. If scans are sequential across IP addresses, IDSs can easily detect the pattern and recognize the scan. Randomizing the hosts makes the pattern less obvious and makes detection more difficult. But it does not exempt it from guaranteed detection
caster@kali:~$ sudo masscan -pT:22,445,3389 --rate 4000 10.0.0.0/8 --randomize-hosts
TCP MSS
It can sometimes happen that some hosts will not be able to respond to you if a TCP segment is missing a TCP MSS header. This can affect the number of hosts detected. It is very important for an attacker to find as many live hosts in the infrastructure as possible.
Masscan used to not have a TCP MSS header setting when scanning into a TCP segment, but IVRE made a fork of masscan and added TCP MSS add-on features to set itself to this fork:
caster@kali:~$ sudo apt install git make gcc
caster@kali:~$ mkdir tools
caster@kali:~$ cd tools
caster@kali:~/tools$ git clone https://github.com/ivre/masscan
caster@kali:~/tools$ cd masscan
caster@kali:~/tools/masscan$ make
caster@kali:~/tools/masscan$ sudo make install
Then after installation masscan will be available on the system, the --tcp-mss
argument is required to add the TCP MSS header:
caster@kali:~$ sudo masscan -pT:22 192.168.1.0/24 --rate 700 --tcp-mss

Now the generated TCP segments will contain the TCP MSS header, its value is 1460.
Services Table
This is a list of TCP and UDP ports of network services that a pentester might be interested in when performing an infrastructure scan:
VNC | TCP/5900, TCP/5901, TCP/5902 |
RADIUS | UDP/1812, UDP/1813 |
TACACS+ | TCP/49 |
SSH | TCP/22 |
RDP | TCP/3389 |
Cisco Smart Install | TCP/4786 |
WinRM | TCP/5985 |
Kerberos | TCP/88, UDP/88 |
SMB | TCP/445 |
HTTP | TCP/80 |
HTTPS | TCP/443 |
RPC | TCP/135 |
SNMP | UDP/161 |
RTSP | TCP/554 |
IPMI | TCP/623, UDP/623 |
SIP | TCP/5060, UDP/5060 |
FTP | TCP/21 |
MySQL | TCP/3306 |
MSSQL | TCP/1433 |
PostgreSQL | TCP/5432 |
Zebra Routing | TCP/2601 |
Winbox | TCP/8291 |
Winbox API | TCP/8728 |
Winbox API SSL | TCP/8729 |
Telnet | TCP/23 |
FINS | TCP/9600, UDP/9600 |
CIP | TCP/44818, UDP/2222 |
ModbusTCP | TCP/502 |
S7Comm | TCP/102 |
LDAP | TCP/389 |
Syslog | UDP/514 |
TFTP | UDP/69 |
NFS | TCP/2049 |
STUN | UDP/3478 |
NetBIOS | TCP/137, TCP/138, TCP/139 |
OpenVPN | TCP/1194, UDP/1194 |
Zabbix | TCP/10050, TCP/10051 |
Sniffing Table
This is a table of network protocols worth looking for on the air when listening for traffic. These include neighbor discovery protocols, routing protocols, gateway redundancy protocols, VLANs, name resolution protocols, etc.
Protocol | Multicast Address, Port, or EtherType |
---|---|
CDP | 01:00:0C:CC:CC:CC, SNAP: 0x2000 |
DTP | 01:00:0C:CC:CC:CC, SNAP: 0x2004 |
VTP | 01:00:0C:CC:CC:CC, SNAP: 0x2003 |
PVST | 01:00:0C:CC:CC:CC, SNAP: 0x010B |
LLDP | 01:80:C2:00:00:0E |
EDP | 00:E0:2B:00:00:00 |
ESRP | 00:E0:2B:00:00:02 |
MACSec | 0x88E5 |
ARP | 0x0806 |
802.1Q | 0x8100 |
802.1X | 0x888E |
STP | 01:80:C2:00:00:00 |
OSPF | 224.0.0.5 |
EIGRP | 224.0.0.10 |
HSRP | 224.0.0.2, UDP/1985 |
HSRPv2 | 224.0.0.102, UDP/1985 |
GLBP | 224.0.0.102, UDP/3222 |
VRRP | 224.0.0.18 |
LLMNR | UDP/5355 |
NetBIOS (Name Service) | UDP/137 |
mDNS | UDP/5353 |
DHCP | UDP/67, UDP/68 |
DHCPv6 | UDP/546, UDP/547 |
MNDP | UDP/5678 |
SSDP | UDP/1900 |
Kernel Tuning
When conducting MITM attacks, your host must be prepared to handle large amounts of traffic. You can customize the Linux kernel a bit to handle such traffic optimally.
mitm_tuning.sh
#!/bin/bash
sudo sysctl -w fs.file-max=100000
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.core.netdev_max_backlog=65536
sudo sysctl -w net.ipv4.tcp_fin_timeout=15
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.tcp_tw_recycle=1
sudo sysctl -w net.ipv4.tcp_max_tw_buckets=65536
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216
sudo sysctl -w net.core.rmem_default=8388608
sudo sysctl -w net.core.wmem_default=8388608
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
fs.file-max=100000
- sets the maximum number of file descriptors that can be opened simultaneously. Increasing the value helps to avoid problems with descriptor shortage when handling a large number of connections This will be useful when a host is handling many connections at the same time, it needs many file descriptors for each connection. Increasing this value allows you to keep more connections open without a descriptor overflow error;
net.core.somaxconn=65535
- sets the maximum number of connections that can wait to be processed in the connection queue. This is useful for high load applications such as servers that accept many incoming connections, increasing this value helps prevent new connections from being dropped due to an overflowing queue;
net.core.netdev_max_backlog=65536
- defines the maximum queue size for network devices handling incoming traffic. Increasing this parameter allows network interfaces to process packets arriving at high rates more efficiently, preventing packet loss;
net.ipv4.tcp_fin_timeout=15
- sets the time, in seconds, that a connection waits to complete after sending a packet (FIN). Reducing the wait time frees resources faster, which is useful in high load environments, with a value of 15 seconds being a compromise between freeing resources and avoiding port reuse problems;
net.ipv4.tcp_tw_reuse=1
- allows sockets to be reused in the TIME-WAIT state for new connections. Reuse of sockets avoids port shortage under high load because ports in TIME-WAIT state can be reused;
net.ipv4.tcp_tw_recycle=1
- activates the accelerated socket reuse mode in the TIME-WAIT state. Enabling this option allows the kernel to release and reuse sockets faster, improving overall performance under high load conditions;
net.ipv4.tcp_max_tw_buckets=65536
- sets the maximum number of sockets in the TIME-WAIT state that can be queued. Increasing this value prevents sockets in the TIME-WAIT state from being dropped, which can happen if they arrive too quickly;
net.core.rmem_max=16777216
and net.core.wmem_max=16777216
- these parameters set the maximum buffer sizes for incoming (rmem_max)
and outgoing (wmem_max)
packets. Increasing these values allows network interfaces to handle larger amounts of data, which is especially important when dealing with high-speed traffic;
net.core.rmem_default=8388608
and net.core.wmem_default=8388608
- These parameters set default values for the buffer sizes of incoming (wmem_default) and outgoing (wmem_default) packets. These values define the initial buffer sizes for new sockets, providing sufficient capacity to handle traffic;
net.ipv4.tcp_max_syn_backlog=4096
- increases the maximum number of incoming SYN requests that can wait for acknowledgment. Increasing this value allows the host to handle a larger number of incoming connection requests, which is especially important under high load conditions.
TCP Window Scaling
The TCP Window Scaling parameter controls the scaling of the TCP window. Increasing the TCP window size can improve data transfer performance in a high latency or high load network. In TCP, each side sets the size of the window. The appropriate number of bytes can be sent without acknowledgment. Window Scaling provides the ability to increase this window size, which is especially useful when dealing with high-speed networks.
caster@kali:~$ sudo sysctl -w net.ipv4.tcp_window_scaling=1
MITM
One of the most impactful network attacks, in which the attacker gets in the middle between the gateway and legitimate hosts with the further goal of capturing sensitive data. MITM has been discussed in many training materials, but the reality is that MITM attacks carry a certain amount of risk. In this chapter of the article, I will discuss some important aspects that will help you conduct MITM more safely.
Routing Permission
The main rule of MITM is to allow traffic routing on your end. Otherwise, when attacking, legitimate traffic will bump into your host and will not go any further, which is DoS, i.e. a visible sign of an attack:
caster@kali:~$ sudo sysctl -w net.ipv4.ip_forward=1
Potential Storm Control
If the attacker's port has Storm Control with unicast, multicast, broadcast traffic control, a hardware alarm may be triggered because the attacker's port will start handling much more traffic than expected by the configured threshold when MITM occurs.
Offset TTL
A TTL offset in the mangle table will help hide the attacker's IP address from the packet trace. MITM attacks create a redundant hop, and if traced from a legitimate machine, the attacker's IP address will appear in the trace itself
caster@kali:~$ sudo iptables -t mangle -A PREROUTING -i eth0 -J TTL --ttl-inc 1
Hardware capabilities
Check the capacity of your hardware, it should be ready to handle traffic from several dozen legitimate hosts. This also applies to your network interface. If you plan to spoof hosts with a gigabit interface and you have a 100mb/s connection, network speeds will suffer and collapse.
Here are the recommended hardware settings:
- CPU: minimum of 4 cores. High clock speeds and multi-threading will also help handle large amounts of traffic;
- RAM: minimum of 8 GB;
- Fast Ethernet interface or use a high-speed Thunderbolt 3 or Thunderbolt 4 interface.
You also can't rule out the fact that you're likely to be stymied by the capabilities of the switch port you're connected to. If it's a 1Gbps link, you can't go any higher than that. Be sure to keep an eye on network behavior.
Selecting subnet masks for ARP spoofing
When doing ARP spoofing, keep an eye on the subnet mask you are going to work with. If you use a mask that is too large, your hardware may not be able to handle the load and DoS will occur
Restore ARP table after an attack
The tool you are ARP Spoofing with should generate reverse is-at frames that restore the state of the ARP tables of the hosts before the attack. This is a very important point. The host or service may not request ARP, they will think that you are still their gateway. And this is DoS. This is a very important point to consider. By the way, Ettercap and Arpspoof do a great job of this, and when finished, they generate the necessary is-at frames and restore the ARP table structure of the hosts.
NAT Issues
If you use NAT with MITM, you will need the nf_conntrack kernel module for SIP, FTP, H.323 protocols to work correctly, as these protocols do not work well with NAT
caster@kali:~$ sudo modprobe nf_conntrack
SIET Danger
Smart Install (SMI) is a feature of Cisco switches that simplifies the process of installing and configuring network devices. It allows centralized configuration management of switches, which significantly speeds up the process of their deployment and configuration. SMI exploitation is carried out with the help of SIET, but it is against a Cisco 2960-X switch that it is very dangerous, as the 2960-X hangs up intentionally for some reason while the exploit is running.
If you find a TCP/4786 port on your network that is used by Cisco switches, check with your customer to see if the 2960-X is there. This may help you avoid a situation where you could disrupt the device.
Outro
In this article, I have discussed several important aspects when conducting penetration testing of network infrastructure. Each stage of the pentest should be carefully planned, including the selection of tools and techniques, as well as an assessment of the potential impact on the network. Pentest is not only a test for the strength of the network, it is also a competent action of the performer in order not to disrupt the normal operation of the network, there must be a balance in everything.