Detecting reconnaissance activity in your network

By Bogdan Vennyk

One of the main services we provide at UnderDefense is 24×7 Monitoring with our Security Operation Center (SOC) and a critical part of great SOC is …, RIGHT! – its detection capabilities.

That is why we are continuously working on improving our Detections – tuning them for each customer as each network is unique, researching TTPs and reducing false positives. And today I would like to share our approach to detecting as simple activity as network reconnaissance.

Background

Reconnaissance definition: according to MITRE ATT&CK – Network Service Scanning is “Methods to acquire this information include port scans and vulnerability scans using tools that are brought onto a system. Adversaries may attempt to get a listing of services running on remote hosts, including those that may be vulnerable to remote software exploitation.”

Vulnerable service running on remote port is easy target which can be used for lateral movement for example notorious ETERNALBLUE vulnerabilityInformation collected at this step of the Killchain is crucial and defines what path adversaries will take to obtain Administrator privileges on Domain Controller.

When talking about network scanners there is always the one which comes first and it is NMAP. It has a variety of scanning techniques as well as a script engine which can be used to detect vulnerabilities

To get a better understanding of how network scanners are working, let’s run NMAP and collect network traffic with Wireshark. To check if a port is open NMAP tries to establish TCP handshake with sending SYN packet, if port is open it will receive SYN/ACK packet otherwise it will get RST/ACK packet. In the screenshot below NMAP was able to establish TCP handshake on port 80, while other ports were closed.

With this said we can come up with our initial detection – find an anomalous number of unique destination ports our host is trying to connect to for a specific time range, for example 5 minutes.

Network Reconnaissance detection using Zeek and Splunk

Zeek is a great open source network monitoring tool which supports a lot of the network protocols security analysts are interested in like HTTP, SMB, Kerberos etc. It is also part of Security Onion, a free and open source Linux distribution for threat hunting, enterprise security monitoring, and log management which can be installed as virtual appliance and used from the box. All of this makes Zeek a great source of network activity for your SIEM.

Because I am a Splunk guy I will proceed with it as a SIEM platform, but QRadar or ELK can be used as well. Also there is an Splunk add-on for Zeek which makes log ingest from Zeek a painless task.

We will use Basic scanning detection from Splunk Security Essentials as our initial port scanning detection, but with slight change – remove network scan part of this detection from where clause and change “more than 1000” to “more or equal than 1000” threshold, because by default NMAP will scan only top 1000 ports.

Search should looks like following:

source=”/nsm/bro/logs/current/conn.log”

| bin span=5m _time

| stats dc(dest_port) as num_dest_port, values(dest_ip) as dest_ip by _time, src_ip

| where num_dest_port >= 1000

And it gives following results:

NMAP scan was successfully detected, but there are couple things which should be taken into consideration:

  1. Threshold for unique destination ports is more or equal than 1000. From our observations, when adversaries get initial access, they hunt for specific ports like SMB or RDP, up to 10 ports at a time. 
  2. Other IPs were marked as scanned, beside the one scanned by NMAP.

To reduce false-positives rate and use as low as possible threshold let’s revisit Wireshark capture one more time. During port scanning NMAP is trying to establish TCP handshake on each port and if it is successful it means the port is open. Also remote service can return its banner, so in that case NMAP will get some data back, but the amount of data NMAP sends to the scanning port is always the same and it’s zero (besides TCP handshake itself). Unless we care about external connections they can be excluded to reduce false-positive rate.

Final detection for port scan:

source=”/nsm/bro/logs/current/conn.log” orig_bytes=0 dest_ip IN (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8)

| bin span=5m _time

| stats dc(dest_port) as num_dest_port, values(dest_port) as dest_port by _time, src_ip, dest_ip

| where num_dest_port >= 3

| fields – num_dest_port, num_dest_ip

Port scan detection results:

Summary

Network reconnaissance is the first step in the Killchain and usually the “first things first” of what adversaries are going to do when they established an initial foothold, which makes its detection crucial – it is better to detect them during this stage and not when detection “Upload to external server” with threshold of 1Gb was triggered.

Dig deeper into attack and try to understand how it works on low level, for example using wireshark for network attacks. It opens opportunities to reduce false-positive alert volume for your SOC analyst and get as small as possible threshold for your statistic based detections.

Next Readers

Forwarding MySQL log file in AWS to Splunk: monitoring connections

by UnderDefense | Feb 11, 2019 

Hidden aspects of mimikatz and infrastructure protection by Sysmon+Splunk

by UnderDefense | Nov 8, 2018

by UnderDefense | Sep 17, 2020

Do you have any questions?

Please leave your contact below and we’ll get back to you shortly.

Pin It on Pinterest

Share This