8 WAYS TO DETECT MALICIOUS FIREWALL TRAFFIC USING SIEM

Firewall logs are onboarded to most SIEMs early on as default log source. However, in most cases, not much value is gained from them. The number of logs received from firewalls is usually very high, and it is hard to tell the good from the bad. Read on and I will explain 8 ways to detect malicious behaviour, or configuration issues; using your firewall logs. I also wrote about DNS monitoring before which included some firewall logs, read that here.

If you have any issues implementing any of the below rules, contact me at https://blueteamblog.com/contact-me or https://twitter.com/blueteamblog.

FIREWALL DENIES VARIATIONS

First off, we can look at firewall denies. This can be useful for finding misconfigured devices or malicious communication attempts. Lets look at the different logic we can use.

EXCESSIVE DENIES FROM INTERNAL HOST TO MANY DESTINATIONS

In this first variation, we want to look at a single internal host failing to communicate to many devices within a short period of time.

  • Same Source IP
  • Traffic direction Local to Remote, Local to Local
  • Firewall or ACL Denies
  • 30+ Different Destination IP’s / within 5 minutes

You may need to tune out things such as asset scanners, vulnerability scanners and the like from this rule. You may also need to play around with the number of destinations and within amount of time as this will differ network to network.

EXCESSIVE DENIES FROM INTERNAL HOST TO MANY PORTS

During internal network scanning, an attacker may attempt to connect to a large number of ports from a single host; to see which ports are open. This will stand out amongst normal network traffic.

  • Same Source IP
  • Traffic direction Local to Remote, Local to Local
  • Firewall or ACL Denies
  • 10+ Different Destination Ports within 6 Hours.

EXCESSIVE DENIES FROM SINGLE INTERNAL HOST

This next rule is less particular and is just the idea of monitoring large numbers of internal / outbound firewall denies on a single host. This could highlight things such as network fingerprinting or a misconfigured device.

  • Same Source IP
  • Traffic direction Local to Remote, Local to Local
  • Firewall or ACL Denies
  • 3000 Denies / 30 Minutes

This rule is similar to above in the tuning principles. You may need to tune out things such as asset scanners, vulnerability scanners and the like from this rule. You may also need to play around with the number of denies and the time period.

EXCESSIVE DENIES FROM A SINGLE EXTERNAL SOURCE

I personally like splitting firewall denies into Internal and External. External denies inbound to the network are far more common and I personally like using external denies to help threat hunt, rather than a static SIEM rule. Create a search as follows :

  • Same Source IP
  • Traffic direction Remote to Local
  • Firewall or ACL Denies

Now sort the data by Source IP / count and look at the highest causes of firewall denies inbound to your network. Work through the highest offenders and look at any other traffic from these IPs, I bet you will find things happening on your network you didn’t know about before.

If you are too busy to perform this threat hunting, we can do something else.

Add any IPs which match the above rule to a reference set. Then create an alert if any of the IPs spotted causing large amount of alerts perform any activity which is NOT a firewall deny. This will detect things such as IP’s performing recon activities and highlight any activity they were successful in performing.

MALWARE / BOTNET BEACONING

A typical behaviour of a host infected with malware or being used as part of a botnet, is to beacon back to a command and control server. In most cases this will stand out from normal firewall traffic, so we can attempt to detect it. This is best done as a part of a threat hunting exercise, and can look something like this :

You will need to use AQL for this. If you are using a SIEM which is not QRadar, you can translate it using https://uncoder.io/

Detect beaconing which beacons every 24 hours

SELECT sourceip, destinationip, UNIQUECOUNT(DATEFORMAT(starttime,’HH’)) as ‘different hours’, COUNT(*) as ‘total flows’ FROM flows WHERE flowdirection = ‘L2R’ GROUP BY sourceip, destinationip HAVING “different hours” > 20 AND “total flows” < 25 LAST 24 hours

Detect beaconing which beacons every day or two

SELECT sourceip, destinationip, UNIQUECOUNT(DATEFORMAT(starttime,’dd’)) as ‘different days’, COUNT(*) as ‘total flows’ FROM flows WHERE flowdirection = ‘L2R’ GROUP BY sourceip, destinationip HAVING “different days” > 4 AND “total flows” < 14 LAST 7 days

Any activity detected by the two above rules should be investigated. The only false positive I have found from this rule are software downloads which may need tuned out.

INTERNAL ICMP SCANNING

blank

When attackers get inside a network they will sometimes attempt to fingerprint networks using ICMP. This bypasses many detection methods as most people usually only monitor TCP and UDP. We can look for this internal scanning which usually stands out from normal network traffic.

  • Traffic direction is Local to Local, Local to Remote
  • Protocol is IMCP
  • 100 events are seen with the Same Source IP and different Destination IP in 3 hours.

Tuning may need to be performed to exclude any legitimate devices which map the network.

MALICIOUS SMB CONNECTIONS

blank

SMB is commonly used by attackers to communicate outbound and exfiltrate data from networks.

  • Destination Ports 137 (UDP) , 138, 139 or 445 (TCP)
  • Same Source IP, Destination Port and Different Destination IP
  • 30 + Events / 5 Minutes

Thanks for reading the article and I hope you learned something today. If you have any Firewall rules I didn’t mention, please comment below. If you are having any issues making the rules I mentioned above, contact me or at https://twitter.com/blueteamblog and I will try to help.

Leave a Reply

Your email address will not be published. Required fields are marked *