Suricata Cheat Sheet

** WILL FIX CODE HIGHLIGHtING LATER, grr so annoying**

Just some learnings.

Some Cheat sheets so I can organize my notes

To Run Suricata:

Reading a PCAP

sudo suricata -r PCAP

Sudo suricata -r <PCAP> -k none -l .

After running on a PCAP, search log

cat eve.json | jq -c 'select(.event_type="alert")'

cat eve.json | jq -c 'select(.event_type="tls")'

cat eve.json | jq -c  'select(.event_type="http")'

cat eve.json | jq -c  'select(.event_type="dns")'

For listing rules:

More /etc/suricata/rules/emerging-trojan/.rules

Ls -lah /etc/suricata/rules/

Config

enabled http-log, ssh, dns events within suricata.yaml

enable:

Load signatures from another file. Edit yaml

Change default-rule-path to /home/user

change rule-fles to customsig.rules

then save customsing.rules in folder

create rule and run in pcap:

sudo suricata -r /home/test/test.pcap -k none -l .

Main Log Formats:

Eve.json

jsn objects, timestamp, flow_id, event_type etc –> Use jq

Fast.log

logs alerts onle

Stats.log

self explanator

Logs stored:

root@test:/var/log/suricata#

Breaking down rules.

Summarizing: https://suricata.readthedocs.io/en/suricata-5.0.0/rules/intro.html

Main sections

Great help to break up the rule into 3 sections, as seen in the image above.

drop == ACTION: alert etc

tcp == PROTOCOL

any == port. [80,81] [80-101] !80

HOME_NET any –> EXTERNAL_NET any == direction of traffic

-> Will only match rule on first packet, no response.

Parts in BLUE:

These are high level key words:

eg: Flow Keywords

Flow matches on direction of the flow.
established to server: means on established connections for CLIENT TO SERVER

Flowbits

<action>:name of flowbit

flowbits: isset, name == generate alwer when rule mataches and condition is set in the flow

Reference == refer to where signature or information came from

MSG == text want to be displayed, no impact on Rule processing

SID ==  Signature ID (needs to be unique)

Rev == Just version number of SID

So breaking down this rule:

alert dns $HOME_NET any -> any any (msg:"Trojam DNS Query Observed" dns_query; content:"testlol.net"; isdataat:!1,relative; reference:url,threatintelprovider.com/trojanx; classtype:trojan-activity; sid:1; rev:1;)

This rule specifies to alert on DNS for any traffic from the internal network out. Specifically on the DNS protocol, any DNS queries for testlol.net. **The isdataat:!1 means it should match with nothing else after the last byte (being .net)** Then the classtype and reference, sid and rev are there

Open Live Writer

I am unable to post when I copy paste images into Open Live Writer Directly. But I can post images when I copy paste them into drive then drop and drag into Open Live Writer.

I use a screen shot tool that places the image into my clipboard and I simply paste into note taking tool. Unfortunately I am unable to do this for OLW.

It works, but annoying

Zeek - Access Nested Data Structures of ::INFO

More of a reminder for myself.
I am doing an IR course, I went through the Zeek Lab and experimented. I went to go back for review and realized I had created the scripts within the VPN. The VPN has reset and I have lost the scripts I made. - Do not do that again Haydn!


1 screenshot of my script was in my Google Doc (course notes), which saved me some time.

I wanted to write about an annoying thing I found when scripting. It is a difference in the new version against the course with a slightly older version. -  How to access the nested structure of the ::INFO script

The Zeek Documentation:

The Writing Scripts tutorial I found overwhelming and hard for me to see on a 1:1 basis what they were talking about.



Mostly this bit:

I was confused because the description of "TeamCymruMalwareHashRegistry::Match" is not in the code block they mention. See imagine below:

I have scripted in Python, written Bash scripts, but I was unable to understand what that section meant.
It was a bit frustrating

The issue I was having between Versions

The course was using an older version and was using RDP as an example. If you look at the RDP script for current Zeek(3.0) that the client machine variable is within RDP::INFO variable. However, in the older version, it is within the rdp_connect_request event (2.6).

It took me a while to figure it out. 

I did not know how to dig into the RDP::INFO variable, or any ::INFO part for any other of the base scripts.

So in the 2.6 version of Zeek, we can print a client machine from RDP connections this way:

@load base/protocols/rdp
event rdp_connect_request(c: connection, cookie:string)
{
    print cookie;
}

Whereas in the 3.0 Version, it would look like:

@load/base/protocols/rdp
event RDP::log_rdp(rec RDP::Info)
{
    print rec$cookie;
}

As you can see, it's quite different to access the event ::INFO for rdp. To find the name it is mentioned in the documentation under Events. See below screenshot 

An SSH script I wrote within http://try.bro.org/ is below. I chose to test with SSH because the website had an SSH PCAP to try.

Again if you look at the current SSH script documentation, you will see similar to the RDP:

The output of the script is:

The documentation from Zeek for writing scripts does explain using the $ sign to access nested data structures. Nor did it explain how to access ::INFO section. It explains nested data structures.  I just feel that it covers so much and takes a while to reach that. Hence this blog post to remind me how to access nested data structures.