Previously, we compiled a number of useful JQ command routines for fast malware PCAP network analysis using Suricata. In this post, we decided to use some new PCAPs to share additional command routines that you might find useful.
As before, I often find myself stumbling upon interesting social media posts by other malware researchers. These posts frequently include a PCAP file as an artifact from a malware binary that was detonated in a controlled environment such as a sandbox.
In many cases, I don’t have much extra time, so one of the first questions I need to quickly answer is, “Is this interesting?”. When I come across these files I want to know what they look like from a high level, so I can find out if the research is relevant to me.
There are of a few caveats of course – the PCAP itself or the recording of the network trace might not be long or complete – but in many cases it is good enough to provide ideas for hunting formulas, which I have found to be essential. By devising a quick way to review these PCAPs, which I will share today, I can break up my daily routine while also inviting the possibility to discover something novel.
What tools are needed?
The tools we will use in this exercise are:
- A sample malware PCAP from SANS
- Suricata
- Cyberchef
- Proofpoint (PFPT) Suricata ruleset
- JQ
SANS - The SANS Institute is a trusted resource for cybersecurity training, certifications and research.
Suricata - is a “high performance, open source network analysis and threat detection software used by most private and public organizations, and embedded by major vendors to protect their assets”. It is an open source tool.
Cyberchef - known as “The Cyber Swiss Army Knife” is an open-source web app for encryption, encoding, compression and data analysis.
ET Pro - “Proofpoint ET Pro is a timely and accurate rule set for detecting and blocking advanced threats using your existing network security appliances, such as next generation firewalls (NGFW) and network intrusion detection/prevention systems (IDS/IPS).” There is also a free version.
JQ - “JQ is a lightweight and flexible command-line JSON processor”. It is readily available and packaged on many OSs.
One of the many powerful features of Suricata is that it can create protocol and transaction logs even in the absence of alerts. These logs include flow, anomaly, alert, protocol, and file transaction logs, plus file extraction and packet capture (PCAP).
Here is a full list and details of what those logs and transactions look like.
The sample PCAP
Let’s have a look at an example. Today we are exploring some fields in SMB and KRB5 as part of a QBot activity. The file can be found at the link below. Please note: This PCAP file can contain still active or live malware artifacts like binary and/or executables or configs and domains, so please handle with care.
During any regular day researchers working for vendors, in academia, or for other organizations publish new findings and reports of malware and behaviors on social media and blogs. Usually, a fast initial analysis (non-detailed) can reveal behaviors and help assess if this specific malware is using a novel network technique of communication or not.
There are many relevant examples that become available daily. I’ve found that reading these isolated samples with the Suricata “-r” option and then reviewing the output has been a very fast way to get a top-level picture of what’s going on. Let’s walk through this process with the above malware example.
Reviewing the PCAP with Suricata
First, we need to conduct a quick initial north-south network analysis with Suricata.
Note: This setup assumes Suricata 7 is installed on the system.
Here is the command, and you can copy and paste the actual text below:
sudo suricata -S "rules/*.rules" -l logs/ -k none -r 2023-02-27-Qakbot-infection-traffic.pcap ; \
echo "Suricata event types:" ; jq -r .event_type logs/eve.json | sort | uniq -c |sort -rn ; \ echo "Alerts:" ; grep '"event_type":"alert"' logs/eve.json | jq .alert.signature | sort -rn | uniq -c | sort -rn ; \
echo "TLS SNIs:" ; jq 'select(.event_type=="tls")' logs/eve.json | jq .tls.sni | sort -rn | uniq -c | sort -rn ; \
echo "TLS Versions:"; jq 'select(.event_type=="tls")' logs/eve.json | jq .tls.version | sort -rn | uniq -c | sort -rn; \
echo "HTTP Hostnames:" ; jq 'select(.event_type=="http")' logs/eve.json | jq .http.hostname | sort -rn | uniq -c | sort -rn ; \
echo "DNS Queries:" ; jq 'select(.event_type=="dns" )' logs/eve.json | jq .dns.rrname | sort -rn | uniq -c | sort -rn ; \
echo "Filetransfer protocols:" ; jq 'select(.event_type=="fileinfo" )' logs/eve.json | jq .app_proto | sort -rn | uniq -c | sort -rn ; \
echo "Filenames:" ; jq 'select(.event_type=="fileinfo")' logs/eve.json | jq .fileinfo.filename | sort -rn | uniq -c | sort -rn ; \
echo "File magic:" ; jq 'select(.event_type=="fileinfo")' logs/eve.json | jq .fileinfo.magic | sort -rn | uniq -c | sort -rn ; \
echo "Kerberos snames:" ; jq 'select(.event_type=="smb" and .smb.command=="SMB2_COMMAND_SESSION_SETUP" and .smb.status=="STATUS_SUCCESS" )' logs/eve.json | jq .smb.kerberos.snames[1] | uniq -c | sort -rn ; \
echo "Kerberos realm:" ; jq 'select(.event_type=="smb" and .smb.command=="SMB2_COMMAND_SESSION_SETUP" and .smb.status=="STATUS_SUCCESS" )' logs/eve.json | jq .smb.kerberos.realm | uniq -c | sort -rn ; \
echo "SMB hostnames:" ; jq 'select(.event_type=="smb" and .smb.command=="SMB1_COMMAND_SESSION_SETUP_ANDX" and .smb.status=="STATUS_SUCCESS" and .smb.ntlmssp )' logs/eve.json | jq .smb.ntlmssp.host | uniq -c | sort -rn ; \
echo "SMB ntlmssp version:" ; jq 'select(.event_type=="smb" and .smb.command=="SMB1_COMMAND_SESSION_SETUP_ANDX" and .smb.status=="STATUS_SUCCESS" and .smb.ntlmssp )' logs/eve.json | jq .smb.ntlmssp.version | uniq -c | sort -rn ; \
echo "SMB native_lm:" ; jq 'select(.event_type=="smb" and .smb.command=="SMB1_COMMAND_SESSION_SETUP_ANDX" and .smb.status=="STATUS_SUCCESS" and .smb.ntlmssp )' logs/eve.json | jq .smb.response.native_lm | uniq -c | sort -rn ;
This is the output. Below you will find a breakdown of the findings with explanations. We will skip over the ones already covered in the previous blogs.
Let’s cover the basics. Below is a list of different unique event fields that could give us a hunting idea during an initial review.
These different unique event fields could give us some hunting ideas during our initial review. These unique protocol and other log event types were all produced by Suricata after reading the PCAP. Any of these Suricata event types can be expanded and reviewed in full detail, however we have them summed up here for the purpose of brevity and for the sake of getting a “bird’s eye” view.
Suricata event types:
650 flow records - “event_type”:”flow”
378 dns protocol logs - “event_type”:”dns”
182 tls protocol logs - “event_type”:”tls”
137 SMB protocol logs - “event_type”:”smb”
122 DCERPC protocol logs - “event_type”:”dcerpc”
67 alerts - “event_type”:”alert”
7 file transactions - “event_type”:”fileinfo”
5 anomaly logs - “event_type”:”anomaly”
3 HTTP protocol logs - “event_type”:”http”
1 stats entry log - “event_type”:”stats”
These are the generated alerts. These alerts also use the Stamus Networks Open Lateral Movement Ruleset in addition to ETOpen and ETPRO:
Alerts:
19 "SN MS-DRSUAPI service - IDL_DRSUnbind"
19 "SN MS-DRSUAPI service - IDL_DRSCrackNames"
19 "SN MS-DRSUAPI service - IDL_DRSBind"
2 "ETPRO MALWARE Possible Qbot SSL Cert"
2 "ET MALWARE Observed Qbot Style SSL Certificate"
1 "SN MS-NRPC service - NetrLogonGetDomainInfo"
1 "ETPRO MALWARE Qbot Style Payload Response - Encrypted Zip M2"
1 "ET POLICY PE EXE or DLL Windows file download HTTP"
1 "ET INFO Windows Powershell User-Agent Usage"
1 "ET INFO EXE IsDebuggerPresent (Used in Malware Anti-Debugging)"
1 "ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response"
We also see the Kerberos full sname:
Kerberos snames:
10 "WIN-PL5VGYU6KMT.rydeordie.audio"
Here we see the Kerberos Realm. This field is displayed from the “event_type:smb” or “event_type:krb5” protocol log produced by Suricata:
Kerberos realm:
10 "RYDEORDIE.AUDIO"
We can also see some SMB hostnames too. This field is displayed from the “event_type:smb” protocol log produced by Suricata:
SMB hostnames:
5 "WYN10-RIDEORDIE"
By viewing the “event_type:smb” protocol log produced by Suricata, we can tell the exact Windows 10 build:
SMB ntlmssp version:
5 "10.0 build 19041 rev 15"
We can also tell there is Windows 2022 Standard edition involved. This field is displayed from the “event_type:smb” protocol log produced by Suricata:
SMB native_lm:
5 "Windows Server 2022 Standard 6.3"
Based on what we are seeing, it would be interesting to look at examples of SMB logs displaying KRB5 realms and snames of the host as well as MAC (ether) addresses. This is natively produced by Suricata and can be produced using the following command:
jq 'select(.event_type=="smb" and .smb.command=="SMB2_COMMAND_SESSION_SETUP" and .smb.status=="STATUS_SUCCESS" )' logs/eve.json
That command produces this output:
{
"timestamp": "2023-02-28T04:26:24.706159+0100",
"flow_id": 205737340120838,
"pcap_cnt": 12112,
"event_type": "smb",
"src_ip": "172.16.0.143",
"src_port": 52718,
"dest_ip": "172.16.0.10",
"dest_port": 445,
"proto": "TCP",
"pkt_src": "wire/pcap",
"ether": {
"src_mac": "12:5b:36:af:c9:48",
"dest_mac": "00:e1:93:8b:9a:95"
},
"smb": {
"id": 3,
"dialect": "3.11",
"command": "SMB2_COMMAND_SESSION_SETUP",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 30786459795565,
"tree_id": 0,
"kerberos": {
"realm": "RYDEORDIE.AUDIO",
"snames": [
"cifs",
"WIN-PL5VGYU6KMT.rydeordie.audio"
]
}
}
}
Suricata can gather and natively generate a ton of interesting information for investigation from SMB protocol logs, including hostnames and native OS advertised during the exchange. We can also see the MAC (ether) addresses of the communicating hosts.
NTLM Over Server Message Block (SMB)
That can be done with this command:
jq 'select(.event_type=="smb" and .smb.command=="SMB1_COMMAND_SESSION_SETUP_ANDX" and .smb.status=="STATUS_SUCCESS" and .smb.ntlmssp )' logs/eve.json
Which will produce an SMB log output like this one:
{
"timestamp": "2023-02-28T02:27:39.977811+0100",
"flow_id": 1092941659242825,
"pcap_cnt": 3531,
"event_type": "smb",
"src_ip": "172.16.0.143",
"src_port": 52496,
"dest_ip": "172.16.0.10",
"dest_port": 139,
"proto": "TCP",
"pkt_src": "wire/pcap",
"ether": {
"src_mac": "12:5b:36:af:c9:48",
"dest_mac": "00:e1:93:8b:9a:95"
},
"smb": {
"id": 3,
"dialect": "NT LM 0.12",
"command": "SMB1_COMMAND_SESSION_SETUP_ANDX",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 2048,
"tree_id": 65535,
"ntlmssp": {
"domain": "",
"user": "",
"host": "WYN10-RIDEORDIE",
"version": "10.0 build 19041 rev 15"
},
"request": {
"native_os": "",
"native_lm": ""
},
"response": {
"native_os": "Windows Server 2022 Standard 20348",
"native_lm": "Windows Server 2022 Standard 6.3"
}
}
}
This is a very basic, although very useful, quick analysis of a PCAP trace from a live malware sandbox detonation to give us an idea of what is happening in this example. Keep in mind that the PCAPs shown here have a short timespan, so the idea is to see and explore the details in that specific timeframe of the malware process. However, this gives us plenty of information and ideas for structured and unstructured hunting recipes or queries, which in turn can be automated. For example, we could hunt for clear text SMTP, FTP transactions, obfuscated executables in images, the SMB/KRB5 user and hostnames that are present during malware proliferation and investigation, and other similar results.
The commands showcased above and from the previous blog post can also be put in a script to give us a quick overview of the major pieces of information that are essential for a fast initial review of specific malware: communication points, usernames, hostnames, email, TLS certificates, OS levels, file magic/names, and file transactions and flows.
The logs reviewed are standard JSON. There is also, naturally, a possibility to review full and summarized details of the logs in any graphic interfaces as Grafana (free dashboards for Suricata), Kibana (free dashboards for Suricata ), Splunk (free Stamus app for Suricata) and others. The purpose of these blog posts however is to do these reviews fast and easy on the command line to get an initial view (in less than 1 minute) of the network communication.
Conclusion
Some people might still consider Suricata a “legacy” intrusion detection system (IDS), but at Stamus Networks, we don’t see it that way. It is not only a highly capable IDS but also an impressive tool for gathering NSM data. And Suricata is, in fact, a powerful foundation on which to build a full-featured network detection and response (NDR) system.
Many Suricata users remain unaware of how they can use and optimize Suricata beyond the basic alerts and signatures. For more JQ tips and tricks you could also review this video recording of a webinar by Open Information Security Foundation (OISF). Additionally, further reading on this topic can be found in our free book, “Suricata for Analysts.”” the world’s first practical guide to threat detection and hunting using Suricata.
Make sure to subscribe to the Stamus Networks blog, because we will be continuing this series with two more follow-ups detailing how to perform east-west SMB and KRB5 analysis using the same method. You can also receive updates by following us on Twitter, LinkedIn, and Facebook, or by joining our Discord.
