Optimizing the rule Recon activity

[NEIO]

Hi Team,

I require assistance with fine-tuning the rule: ["recon activity detected from internal host"] to minimize false positives and optimize its performance. Your support in this matter would be greatly appreciated.

PFA.

rule recon_activity_detected_from_internal_host

{

  meta:

     subject = "recon activity detected from internal host"

     description = "This rule is to identify instances where a local host initiates port scan against single internal IP over at least 50 different port or port sweep against more than 99 internal IP address over same port. Port scanning activities within the internal network may indicates that adversary attempting to identify vulnerable services on target systems after gaining an initial foothold on the network."

     tactic = "Discovery"

     technique = "Network Service Scanning"

     subtechnique = ""

     tool = ""

     datasource = "Network Traffic"

     category = ""

     product = ""

     logsource = "Firewall, Netflow, Network Security Monitor(NSM), EDR, Windows Events"

     actor = ""

     malware = ""

     vulnerability = ""

     custom = ""

     confidence = "Medium"

     severity = "Low"

     falsePositives = "This could be benign in case of network scan from authorized internal scanners. Whitelisting the internal scanner IP is to only identify suspicious activity."

     externalSubject = "0"

     externalMITRE = "0"

     version = "7"

  events:

        $e.metadata.event_type = "NETWORK_CONNECTION"

        not(net.ip_in_range_cidr($e.target.ip, "224.0.0.0/4")) //Excluding multicast IP address from the target.IP

        $e.principal.ip != $e.target.ip

        $e.target.port > 0

        all $e.principal.ip != $e.target.ip

        $e.principal.ip = $principal_ip

        $e.target.ip = $target_ip

        $e.target.port = $target_port  

    match:

        $principal_ip over 50m

    condition:

       (#target_port > 10 and #target_ip=1) or (#target_ip >=20 and #target_port=1)

}

[jstoner · Accepted solution]

For community members to provide additional guidance, some additional specifics may be required to help understand the kind of challenges you are trying to overcome. This tuning is likely to be specific to your organization to minimize what you define as false positives.

Since you are looking for internal to internal, i'd probably start by making sure that I've defined the internal ranges of my network and start by having something like below as it pertains to both principal and target. 

        (net.ip_in_range_cidr($e.principal.ip, "10.0.0.0/8") or net.ip_in_range_cidr($e.principal.ip, "172.16.0.0/12") or net.ip_in_range_cidr($e.principal.ip, "192.168.0.0/16"))

For simplicity it may also be wise to separate the ping sweep from the port scan. Also the thresholds in the conditions do not align to the description.

Are there specific IPs that are more interesting than others to focus the sweep on, ie stuff below 1024? specific ports that indicate ldap, http/s, sql, etc activity?

Additional context is important to factor into this and perhaps adjusting the match window from 50 minutes downward or the conditions upward might be something else to consider.

[NEIO · Accepted solution]

Hi @jstoner ,

Instead of defining single IP's from multiple subnets, can we create a group and define in the rule.

PFA the range of IP's we have blocked.

Thanks,

Neha.h

[jstoner · Accepted solution]

We've already mentioned a few different techniques in this thread, so I apologize if I repeat a few things.

The net function mentioned originally allows you to focus your rule on specific netblocks of interest.

Rather than building a huge OR statement for a bunch of random IP addresses, you could use a reference list for those singular IP addresses. This applies to search and rules. Here is a link to a video and another blog on building and using a reference list: https://www.googlecloudcommunity.com/gc/Google-Security-Operations-Best/Getting-to-Know-Google-SecOp...

https://www.googlecloudcommunity.com/gc/Community-Blog/New-to-Google-SecOps-Regular-Expressions-and-...

Another technique you might decide to use is to roll up specific netblocks in different CIDR lengths and just put them in some sort of exclusion or watchlist.

This could be done with the net function as well or could be done in conjunction with CIDR reference lists.

Blog and video examples can be found here: https://www.googlecloudcommunity.com/gc/Community-Blog/New-to-Google-SecOps-Fall-is-the-perfect-time...

https://www.googlecloudcommunity.com/gc/Google-Security-Operations-Best/Getting-to-Know-Google-SecOp...

Docs on Reference Lists: https://cloud.google.com/chronicle/docs/reference/reference-lists

Hope this helps

[jstoner · Accepted solution]

For community members to provide additional guidance, some additional specifics may be required to help understand the kind of challenges you are trying to overcome. This tuning is likely to be specific to your organization to minimize what you define as false positives.

Since you are looking for internal to internal, i'd probably start by making sure that I've defined the internal ranges of my network and start by having something like below as it pertains to both principal and target. 

        (net.ip_in_range_cidr($e.principal.ip, "10.0.0.0/8") or net.ip_in_range_cidr($e.principal.ip, "172.16.0.0/12") or net.ip_in_range_cidr($e.principal.ip, "192.168.0.0/16"))

For simplicity it may also be wise to separate the ping sweep from the port scan. Also the thresholds in the conditions do not align to the description.

Are there specific IPs that are more interesting than others to focus the sweep on, ie stuff below 1024? specific ports that indicate ldap, http/s, sql, etc activity?

Additional context is important to factor into this and perhaps adjusting the match window from 50 minutes downward or the conditions upward might be something else to consider.

[NEIO]

@jstoner ,

Yes i agree that the threshold in the condition does not align with description , because i tried to change the values in the condition to maybe possible to decrease the false positives. Like for example : We have alert triggering from multiple IP's and all belong to different subnets. (104.152.52.229, 108.181.57.185 etc)

Thanks,

Neha.H

[NEIO · Accepted solution]

Hi @jstoner ,

Instead of defining single IP's from multiple subnets, can we create a group and define in the rule.

PFA the range of IP's we have blocked.

Thanks,

Neha.h

[jstoner · Accepted solution]

We've already mentioned a few different techniques in this thread, so I apologize if I repeat a few things.

The net function mentioned originally allows you to focus your rule on specific netblocks of interest.

Rather than building a huge OR statement for a bunch of random IP addresses, you could use a reference list for those singular IP addresses. This applies to search and rules. Here is a link to a video and another blog on building and using a reference list: https://www.googlecloudcommunity.com/gc/Google-Security-Operations-Best/Getting-to-Know-Google-SecOp...

https://www.googlecloudcommunity.com/gc/Community-Blog/New-to-Google-SecOps-Regular-Expressions-and-...

Another technique you might decide to use is to roll up specific netblocks in different CIDR lengths and just put them in some sort of exclusion or watchlist.

This could be done with the net function as well or could be done in conjunction with CIDR reference lists.

Blog and video examples can be found here: https://www.googlecloudcommunity.com/gc/Community-Blog/New-to-Google-SecOps-Fall-is-the-perfect-time...

https://www.googlecloudcommunity.com/gc/Google-Security-Operations-Best/Getting-to-Know-Google-SecOp...

Docs on Reference Lists: https://cloud.google.com/chronicle/docs/reference/reference-lists

Hope this helps

[NEIO]

Hi @jstoner ,

Need your help here, while i am executing the below rule i am encountering one error. Could you please help me fix it.

Pasting the rule below:

rule recon_activity_detected_from_internal_host
{
meta:
subject = "recon activity detected from internal host"
description = "Identifies a port sweep or host port scan attempt from an internal IP address on the network. A port scan or sweep can be used to identify vulnerable services on target systems in the internal network once an adversary gets an initial foothold on the system."
tactic = "Discovery"
technique = "Network Service Scanning"
tool = ""
datasource = "Network Traffic"
category = ""
product = ""
logsource = "Firewall, Netflow, Network Security Monitor(NSM), EDR, Windows Events"
actor = ""
malware = ""
vulnerability = ""
custom = ""
confidence = "Medium"
severity = "Low"
falsePositives = "This could be benign in case of network scan from authorized internal scanners. Whitelisting the internal sca+C2nner IP is to only identify suspicious activity."
externalSubject = "0"
externalMITRE = "0"
version = "6"

events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.principal.ip in cidr %private_network_IP_ranges
$e.target.ip in cidr %private_network_IP_ranges
not(net.ip_in_range_cidr($e.target.ip, "224.0.0.0/4")) //Excluding multicast IP address from the target.IP
$e.principal.ip = $principal_ip
$e.target.ip = $target_ip
not $e.principal.ip in %vulnerability_scanners
not $e.principal.ip in %DHCP_servers
not $e.principal.ip in %WSUS_servers
$e.target.port = $target_port
match:
$principal_ip over 30m

condition:
($e.target.port >50 and $e.target.ip=1) or ($e.target.ip >=100 and $e.target.port=1)
}

Error screenshot as below :

Thanks,

Neha.H

[AymanC · Accepted solution]

Hi @NEIO,

Please see if the below rule logic works:

rule recon_activity_detected_from_internal_host
{
meta:
subject = "recon activity detected from internal host"
description = "Identifies a port sweep or host port scan attempt from an internal IP address on the network. A port scan or sweep can be used to identify vulnerable services on target systems in the internal network once an adversary gets an initial foothold on the system."
tactic = "Discovery"
technique = "Network Service Scanning"
tool = ""
datasource = "Network Traffic"
category = ""
product = ""
logsource = "Firewall, Netflow, Network Security Monitor(NSM), EDR, Windows Events"
actor = ""
malware = ""
vulnerability = ""
custom = ""
confidence = "Medium"
severity = "Low"
falsePositives = "This could be benign in case of network scan from authorized internal scanners. Whitelisting the internal sca+C2nner IP is to only identify suspicious activity."
externalSubject = "0"
externalMITRE = "0"
version = "6"

events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.principal.ip in cidr %private_network_IP_ranges
$e.target.ip in cidr %private_network_IP_ranges
not(net.ip_in_range_cidr($e.target.ip, "224.0.0.0/4")) //Excluding multicast IP address from the target.IP
$e.principal.ip = $principal_ip
$e.target.ip = $target_ip
not $e.principal.ip in %vulnerability_scanners
not $e.principal.ip in %DHCP_servers
not $e.principal.ip in %WSUS_servers
$e.target.port = $target_port

match:
$principal_ip over 30m

outcome:

$TargetPortCount = count($target_port)
$TargetIPCount = count($target_ip)

condition:

$e and ($TargetPortCount > 50 and $TargetIPCount = 1 or $TargetPortCount = 1 and $TargetIPCount >= 100)

}

Kind Regards,

Ayman

[NEIO]

Hi @AymanC ,

Yes, its working after the removal of the below groups.
not $e.principal.ip in %vulnerability_scanners
not $e.principal.ip in %DHCP_servers
not $e.principal.ip in %WSUS_servers
$e.principal.ip in cidr %private_network_IP_ranges
$e.target.ip in cidr %private_network_IP_ranges

We will observe this and let you know. With the addition of the above groups its not working.

Thanks,

Neha.H

[NEIO]

@AymanC  and @jstoner ,

Can you please help me finetune the below rule as well.

rule possible_outbreak_excessive_connections

{

    meta:

     subject = "possible outbreak excessive connections"

     description = "Identifies a local host performing port sweep or scan against external network. Possibly this could be local host infection and it is acting as bot to scan external network as per instructions from command-and-control server."

     tactic = "Command and Control"

     technique = "Application Layer Protocol"

     tool = ""

     datasource = "Network Traffic"

     category = ""

     product = ""

     logsource = "EDR, Netflow, NGFW, Windows Events, Firewall"

     actor = ""

     malware = ""

     vulnerability = ""

     custom = "SIEM use cases"

     confidence = "Medium"

     severity = "Medium"

     falsePositives = "None"

     externalSubject = "0"

     externalMITRE = "0"

  events:

        $e.metadata.event_type = "NETWORK_CONNECTION"      //All netwrok traffic events from all type of devices will be normalized to the event type: NETWORK_CONNECTION

        $e.metadata.product_name != "AWS VPC Flow"         //Its temporary exclusion as it is causing a lot of falsePositives

        //Capturing variables for event correlation

        $e.principal.ip = $principal_ip

        $e.target.ip = $target_ip

        $e.target.port = $target_port

        //Exclusions

        $e.target.port !=443 and $e.target.port !=80  //Excluding standard web access ports as it triggers signal on regular web browsing

 match:

        $principal_ip over 1h

 condition:

        (#target_port >= 25 and #target_ip=1) or (#target_ip>=25 and #target_port=1)

}