Optimizing the rule Recon activity

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. 

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.

@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

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

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-SecOps-Reference-List/ta-p/738238

https://www.googlecloudcommunity.com/gc/Community-Blog/New-to-Google-SecOps-Regular-Expressions-and-Reference-Lists/ba-p/731989

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-for-CIDR/ba-p/733381

https://www.googlecloudcommunity.com/gc/Google-Security-Operations-Best/Getting-to-Know-Google-SecOps-CIDR-Reference-Lists/ta-p/745365/jump-to/first-unread-message

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

Hope this helps

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

Hi @NEIO,

Please see if the below rule logic works:

Kind Regards,

Ayman

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