top of page
Writer's pictureHarisuthan

Advance port scan detection using ChatGPT



Adversaries/Attackers keeps on spending lots of time at information gathering, it's basically starts with an port or and network scan, which includes various advances techniques, we are gonna create some baseline detection rule for multiple advances port scan techniques like : Vanilla, Strobe, Fragmented Packets, UDP, Sweep, FTP Bounce, Stealth using Chat GPT

We have generated three different detection rules for different SIEM tools like [SPLUNK. ELK, LogRhythm].


Vanilla Port scan:

On of the most commonly used port scan techniques the major outcome of vanilla port scan results are all available open ports available at the targeted network

It generally uses three way handshake techniques [TCP] on the targeted system to determining the open ports,

It sends a synchronize (SYN) flag. When it receives a SYN-ACK response, or an acknowledgment of connection, it responds with an ACK flag.


The above techniques can be resulted with accurate result but it's been easily detectable too


Vanilla scan working:


SPLUNK Detection Rule:

index=your_index sourcetype=your_sourcetype (tcp_flags=syn OR udp) | stats count by src_ip, dst_ip, dst_port | where count>10 AND dst_port!=80 | rename src_ip as"Source IP", dst_ip as"Destination IP", dst_port as"Destination Port" | table Source IP, Destination IP, Destination Port, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [message] =~ "connection attempt" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["vanilla_scan"]
                timeout => 300
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] > 20"
                }
            }
        }
    }
}

LogRhythm Detection Rule:

  1. Open the LogRhythm Advanced Search feature

  2. In the "Event Type" field, select the "NetMon" event type

  3. In the "Message" field, enter the keyword "connection attempt"

  4. In the "Time Range" field, set the time range to the last 5 minutes

  5. In the "Aggregation" field, group the results by "Source IP Address"

  6. In the "Filter" field, add a filter to only show results where the "Source IP Address" count is greater than 20

Strobe Port scan:

It's a bit similar to vanilla port scan. It also basically uses TCP protocol, it will generate and send an TCP SYN packet to a target host on a specific port, it will wait for the response if the host responded with a SYN-ACK packet, then the port is considered open. If the host responds with a RST packet, then the port is considered closed.


It's generally used for large scale or infrastructure scan and it has been embedded with many vulnerability scanners too.


Strobe scan working:


SPLUNK Detection Rule:

index=your_index sourcetype=your_sourcetype (tcp_flags=syn OR udp)
| stats count by src_ip, dst_ip, dst_port
| where count > 20 AND dst_port != 80
| eval time_window=relative_time(now(), "-5s")
| search count > 20 AND _time > time_window
| rename src_ip as "Source IP", dst_ip as "Destination IP", dst_port as "Destination Port"
| table Source IP, Destination IP, Destination Port, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [message] =~ "connection attempt" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["strobe_scan"]
                timeout => 5
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] > 20"
                }
            }
        }
    }
}

LogRhythm Detection Rule:

  1. Create a new SmartResponse rule in the LogRhythm Console

  2. In the "Event Filter" section, set the filter to only match events from the NetMon module that contain the "connection_attempt" event type.

  3. In the "Threshold" section, set the threshold to trigger when the number of matching events from a single IP address exceeds a certain value within a certain time frame (for example, 20 events in 5 seconds)

  4. In the "Actions" section, you can choose to alert, block, or quarantine the IP address that triggered the rule.

Fragmented Packets:

A bit of unique port scan techniques, its mostly used in case of firewall and IDS evasion techniques.


In a fragmented packet scan, the scanner sends multiple smaller chunks of packets to the target host, each with its own IP header and fragment offset field.

These packets are designed to reassemble into a complete packet when they reach the target host, but they may be blocked or dropped by intermediate devices if they are not configured to handle fragmentation properly.


It typically waits for the response if a successful response received it will considered as a open port.


Fragmented Packets based port scan working:



SPLUNK Detection Rule:

index=your_index sourcetype=your_sourcetype fragment=*
| stats count by src_ip
| where count > 20
| rename src_ip as "Source IP"
| table Source IP, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [message] =~ "fragmented packet" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["fragmented_packet_scan"]
                timeout => 300
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] > 20"
                }
            }
        }
    }
}

LogRhythm Detection Rule:

  1. Create a new SmartResponse rule in the LogRhythm Console

  2. In the "Event Filter" section, set the filter to only match events from the NetMon module that contain the "fragmented packet" event type.

  3. In the "Threshold" section, set the threshold to trigger when the number of matching events from a single IP address exceeds a certain value within a certain time frame (for example, 20 events in 5 minutes)

  4. In the "Actions" section, you can choose to alert, block, or quarantine the IP address that triggered the rule.


UDP port scan

UDP and new way of determining open & closed ports, it typically send an User Datagram packets[UDP] to an range of ports on the targeted host,


It uses ICMP services to determine its availability, if the host responds with a "Destination Unreachable" message, indicating that the port is open and accepting UDP packets. If a port is closed, the target host will typically not respond, indicating that the port is closed or filtered


Mostly at every organization ICMP request has been configured to block or ignore by firewalls and intrusion detection systems.


So it will be more difficult to detect open ports using a UDP scan.

UDP Port Scan Working:


SPLUNK Detection Rule:

# Search for events that have a high number of UDP connection attempts within a short period of time
index=your_index sourcetype=your_sourcetype protocol=udp
| stats count by src_ip, dst_ip, dst_port
| where count > 20
| eval time_window=relative_time(now(), "-5s")
| search count > 20 AND _time > time_window
| rename src_ip as "Source IP", dst_ip as "Destination IP", dst_port as "Destination Port"
| table Source IP, Destination IP, Destination Port, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [protocol] == "udp" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["udp_scan"]
                timeout => 5
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] > 20"
                }
            }
        }
    }
}

LogRhythm Detection Rule:

  1. Create a new SmartResponse rule in the LogRhythm Console

  2. In the "Event Filter" section, set the filter to only match events from the NetMon module that contain the "UDP" protocol

  3. In the "Threshold" section, set the threshold to trigger when the number of matching events from a single IP address exceeds a certain value within a certain time frame (for example, 20 events in 5 minutes)

  4. In the "Actions" section, you can choose to alert, block, or quarantine the IP address that triggered the rule.

Sweep port scan:

Its combinations of TCP and UDP scan the scanner typically sends a huge packet to a range of consecutive ports, starting from a low port number and increasing to a high port number.


It will wait for the response from the target host for each port.

If a port is open, the target host will typically respond with a SYN-ACK packet for TCP, or an ICMP "Destination Unreachable" message for UDP, indicating that the port is open and accepting connections.


If a port is closed, the target host will typically respond with a RST packet for TCP, or no response for UDP, indicating that the port is closed or filtered.


Sweeps scan been easily detected by firewalls or intrusion detection systems.

Sweep port scan working:


SPLUNK Detection Rule:

# Search for events that have a high number of connection attempts to a range of ports within a short period of time
index=your_index sourcetype=your_sourcetype (tcp_flags=syn OR udp)
| stats count by src_ip, dst_port
| where count > 20
| eval time_window=relative_time(now(), "-5s")
| search count > 20 AND _time > time_window
| rename src_ip as "Source IP", dst_port as "Destination Port"
| table Source IP, Destination Port, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [tcp_flags] == "syn" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["sweep_scan"]
                timeout => 5
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] > 20"
                }
            }
        }
    }
}

LogRhythm Detection Rule:

  1. Create a new SmartResponse rule in the LogRhythm Console

  2. In the "Event Filter" section, set the filter to only match events from the NetMon module that contain the "SYN" flag

  3. In the "Threshold" section, set the threshold to trigger when the number of matching events from a single IP address exceeds a certain value within a certain time frame (for example, 20 events in 5 minutes)

  4. In the "Actions" section, you can choose to alert, block, or quarantine the IP address that triggered the rule.


FTP Bounce:

It's an unique type of port scan technique where the scanner takes advantage of a feature of FTP known as "FTP bounce" or "FTP proxy" which allows an attacker to use a vulnerable FTP server as a proxy to scan another host.


This specific techniques generally targets and publicly accessible FTP server to act as a intermediate for request and response from the scanners,


When the scan gets initiated the request will be send to an publicly accessible FTP server and the FTP server sends a PORT command to the targeted server, which includes the IP address and port number of the target host.


If the FTP server receives a positive response indicating that the port is open. If the port is closed, the FTP server will receive a connection refused error, and the scanner will receive a negative response indicating that the port is closed.


It's been acting as an Stealth scan because the attacker system does not involved directly in the scan the request are forwarded to an vulnerable FTP server and then it’s been forwarded to the targeted host.


FTP Bounce working:


SPLUNK Detection Rule:

# Search for events that have a high number of FTP PORT commands within a short period of time
index=your_index sourcetype=your_sourcetype ftp_command=PORT
| stats count by src_ip, dst_ip
| where count > 20
| eval time_window=relative_time(now(), "-5s")
| search count > 20 AND _time > time_window
| rename src_ip as "Source IP", dst_ip as "Destination IP"
| table Source IP, Destination IP, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [ftp_command] == "PORT" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["ftp_bounce_scan"]
                timeout => 5
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] > 20"
                }
            }
        }
    }
}

LogRhythm Detection Rule: Create a new SmartResponse rule in the LogRhythm Console

  1. In the "Event Filter" section, set the filter to only match events that contain the "PORT" FTP command

  2. In the "Threshold" section, set the threshold to trigger when the number of matching events from a single IP address exceeds a certain value within a certain time frame (for example, 20 events in 5 minutes)

  3. In the "Actions" section, you can choose to alert, block, or quarantine the IP address that triggered the rule.


Stealth port scan:

An port scan evasion technique used by the attacks to evade firewall and IDP, it's basically uses an old school techniques of TCP scan,


An crafted TCP request has been send to an targeted host, which also termed as half-open scan or a SYN scan


The scanner sends a TCP SYN packet to a target host on a specific port, but does not wait for a response. If the port is open, the target host will respond with a SYN-ACK packet, indicating that the port is open and accepting connections. If the port is closed, the target host will respond with a RST packet, indicating that the port is closed. The scanner can then infer the status of the port based on the absence or presence of the SYN-ACK or RST packet.


This technique can be easily evaded from firewall and IDS detection, but it can be easily detected by advance/next gen firewall and IDS.


Stealth port scan working:


SPLUNK Detection Rule:

# Search for events that have a low number of connection attempts to a range of ports within a long period of time
index=your_index sourcetype=your_sourcetype (tcp_flags=syn OR udp)
| stats count by src_ip, dst_port
| where count < 5
| eval time_window=relative_time(now(), "-60m")
| search count < 5 AND _time > time_window
| rename src_ip as "Source IP", dst_port as "Destination Port"
| table Source IP, Destination Port, count

ELK Detection Rule:

filter {
    if [event_type] == "NetMon" {
        if [tcp_flags] == "syn" {
            aggregate {
                task_id => "%{src_ip}"
                code => "map['src_ip'] = event.get('src_ip')"
                map_action => "create"
                add_tag => ["stealth_scan"]
                timeout => 3600
            }
            if !map['src_ip'].nil? {
                aggregate {
                    task_id => "%{src_ip}"
                    code => "event.cancel() if map['src_ip']['count'] < 5"
                }
            }
        }
    }
}

LogRhythm Detection Rule::

  1. Create a new SmartResponse rule in the LogRhythm Console

  2. In the "Event Filter" section, set the filter to only match events that contain the "SYN" TCP flag

  3. In the "Threshold" section, set the threshold to trigger when the number of matching events from a single IP address is below a certain value within a certain time frame (for example, 5 events in 1 hour)

  4. In the "Actions" section, you can choose to alert, block, or quarantine the IP address that triggered the rule.


Note: CHATGPT helps us only creating some baseline rule, it required lots of hardening and finetuning process


Reference:

461 views0 comments

Recent Posts

See All

Comments


bottom of page