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.

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.

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.

Default tool operation

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:

VNCTCP/5900, TCP/5901, TCP/5902
RADIUSUDP/1812, UDP/1813
TACACS+TCP/49
SSHTCP/22
RDPTCP/3389
Cisco Smart InstallTCP/4786
WinRMTCP/5985
KerberosTCP/88, UDP/88
SMBTCP/445
HTTPTCP/80
HTTPSTCP/443
RPCTCP/135
SNMPUDP/161
RTSPTCP/554
IPMITCP/623, UDP/623
SIPTCP/5060, UDP/5060
FTPTCP/21
MySQLTCP/3306
MSSQLTCP/1433
PostgreSQLTCP/5432
Zebra RoutingTCP/2601
WinboxTCP/8291
Winbox APITCP/8728
Winbox API SSLTCP/8729
TelnetTCP/23
FINSTCP/9600, UDP/9600
CIPTCP/44818, UDP/2222
ModbusTCPTCP/502
S7CommTCP/102
LDAPTCP/389
SyslogUDP/514
TFTPUDP/69
NFSTCP/2049
STUNUDP/3478
NetBIOSTCP/137, TCP/138, TCP/139
OpenVPNTCP/1194, UDP/1194
ZabbixTCP/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.

ProtocolMulticast Address, Port, or EtherType
CDP01:00:0C:CC:CC:CC, SNAP: 0x2000
DTP01:00:0C:CC:CC:CC, SNAP: 0x2004
VTP01:00:0C:CC:CC:CC, SNAP: 0x2003
PVST01:00:0C:CC:CC:CC, SNAP: 0x010B
LLDP01:80:C2:00:00:0E
EDP00:E0:2B:00:00:00
ESRP00:E0:2B:00:00:02
MACSec0x88E5
ARP0x0806
802.1Q0x8100
802.1X0x888E
STP01:80:C2:00:00:00
OSPF224.0.0.5
EIGRP224.0.0.10
HSRP224.0.0.2, UDP/1985
HSRPv2224.0.0.102, UDP/1985
GLBP224.0.0.102, UDP/3222
VRRP224.0.0.18
LLMNRUDP/5355
NetBIOS (Name Service)UDP/137
mDNSUDP/5353
DHCPUDP/67, UDP/68
DHCPv6UDP/546, UDP/547
MNDPUDP/5678
SSDPUDP/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.

Subscribe to exploit.org

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe