Recently, we released a blog post detailing how you can solve the Unit 42 Wireshark quiz for January 2023 using SELKS instead of Wireshark. SELKS does include a suite of threat hunting tools that can use Suricata alert data for exactly that purpose, but this week we want to demonstrate how you can use SELKS to solve the quiz without alerts – using only protocol data and Kibana dashboards. If you didn’t already know, Suricata can actually produce network protocol, file transaction, and flow events regardless of whether an alert has been generated or not. We are going to be using that data to solve the Unit 42 Wireshark quiz for January 2023 today. 

Ace the Wireshark Quiz with these Kibana Dashboard Tips

The Unit 42 Wireshark quiz for January 2023 challenges cybersecurity professionals to test their knowledge on different topics related to this subject. With the help of the predefined  Kibana dashboards in SELKS, you can gain valuable insights into the quiz and improve your performance.

You can use Kibana dashboards in SELKS to complete the Unit 42 quiz by following the instructions in this blog article. SELKS comes preloaded with over 28 dashboards and 400+ visualizations that help security practitioners navigate through any data that Suricata produces: alerts, network protocol logs, flow logs, file transaction logs, extracted files, and pcap.

Those dashboards can be used as part of SELKS or be imported to any existing Elasticsearch installation. 

It is worth mentioning that even though we could completely answer the quiz questions just by looking at the alert in the Scirius CE Hunting interface – as we did in our last post about the Unit 42 quiz – we can also find the same and even more valuable information by exploring Kibana’s interactive dashboards. In particular, we will be focused on the SN-Hunt-1 and SN-SMTP dashboards.

In our previous blog post, we have solely used the Stamus Scirius CE Suricata dedicated hunting interface and the generated alert, in order to solve the Quiz.

However, there is an alternative approach to finding the correct answers to the Quiz questions with the help of SN-Hunt-1 Kibana dashboard in SELKS.

Solving the Unit 42 Wireshark quiz with the Kibana SN-Hunt-1 dashboard in SELKS

To access the Kibana dashboards in SELKS, you can follow these steps:

1. 1. Open a web browser and enter the IP address of your SELKS installation in the address bar: https://your_selks_IP_here/ or https://localhost/
2.  
3. 2. This will bring up the SELKS login page. Enter your username and password to log in.
4.  
5. 3. Once you are logged in, you should see the SELKS landing page. From there, click on the app switcher icon in the top right corner and click on the "Kibana" icon.
6.  
7. 4. This will take you to the Kibana homepage, where you can access the various pre-configured dashboards, including the SN-Hunt-1 dashboard.
8.  
9. 5. Click on the menu icon in the top left corner of the page. From there, you can navigate to Analytics -> Dashboard. This will give you a list with all available dashboards, including the SN-Hunt-1 dashboard.
10.  
11. 6. To open it and start exploring the network security data and visualizations, you simply need to click on it from the list.

NOTE: Since the original timestamp of the pcap is preserved when reading the pcap, we have to set the time span in Kibana in the right upper corner to “1 year ago” in order to be able to populate the dashboard with the generated data.

Once the dashboard has been populated, we can start answering the questions from the quiz. The SN-Hunt-1 dashboard holds the answers to all questions and a lot more information.

The first question from the quiz is :When did the malicious traffic start in UTC? 

The answer to it is located in the SN-ALL-EventsList table. Since it represents all events/alerts, we can easily figure out that the time when the malicious traffic started is: Jan 5, 2023 @ 22:51:00.081

NOTE: Depending on your timezone, Kibana will adjust the timestamp of the events/alerts. In order to see them in UTC, you need to set Kibana’s timezone to UTC. To do this, you need to:

1. 1. Login to Kibana and navigate to the "Kibana" -> “Advanced Settings” tab.
2. 2. Click on the "Advanced Settings" option in the left-hand menu.
3. 3. Scroll down to the "Timezone for date formatting" setting and select Etc/UTC from the dropdown menu.
4. 4. Click on “Save changes”.

Now let’s move on to the next question, which is: What is the victim’s IP address?

And its answer is pretty obvious if we look at the SN-ALERT-EventsList or SN-ALL-EventsList tables (and check the alert there).  

And the alert target IP is in fact the victim’s IP address, which is 192.168.1.27. 

When Suricata generates an alert, it usually contains information about the source and destination IP addresses of the network traffic that triggered the alert. The source IP address refers to the IP address of the device that originated the network traffic that triggered the alert. The destination IP address, on the other hand, refers to the IP address of the device that received the network traffic.

For example, if Suricata generates an alert for suspicious network traffic between two devices on a network, the alert will include the source and destination IP addresses of those devices. The source IP address may belong to a device that is known to be compromised or is exhibiting suspicious behavior, while the destination IP address may belong to a critical server or other important network resource.

Within these alerts, the source IP and destination IP refer to the IP addresses of the devices involved in the network traffic that triggered the alert, while the target IP refers to the IP address of the device that was targeted by the network traffic.

The source IP address is the IP address of the device that initiated the network traffic. The destination IP address is the IP address of the device that received the network traffic. These IP addresses are typically included in the alert message generated by Suricata to provide information about the network traffic that triggered the alert.

The target IP address, on the other hand, refers to the IP address of the device that was the intended recipient of the network traffic. In some cases, the target IP may be the same as the destination IP, but in other cases, the network traffic may have been directed at a different device, and the target IP would reflect that.

We can also find the victim’s IP address on the SN-FILE-EventsList table.

The content of the table indicates that on Jan 5, 2023 @ 22:51:00.081, a data file with a SHA256 hash of 90d977ca0a3331d78005912d2b191d26e33fa2c6ef17602d6173164ba83fd85e was transferred over HTTP from the source IP address of 45.56.99.101 (port 80 clear text) to the destination IP address of 192.168.1.27 (port 51952). The file is named "/sav/Ztvfo.png" and has a size of 664,576 bytes. So we confirm again that the answer to our second question is that the victim’s IP address is: 192.168.1.27

The third question from the quiz is: What is the victim’s MAC address? 

The Mac address can be found on any related event, processed by Suricata. For example, we can have a look at the SN-Anomaly-EventsList. As mentioned above, the SN-Flow-EventsList table represents a list of network anomaly events captured by Suricata. If we expand either of the events, we can easily figure out the answer to the third question, and we find that the victim’s MAC address is: bc:ea:fa:22:74:fb. 

Additionally, with the help of an online tool – like the Ip Check Tool for example – we can easily find what is the hardware type of the victim. In this case, it was a Hewlett Packard device. In order to figure out this, you just need to make a search on the destination MAC address, which is listed in the event:

Now let’s find out the answer to the remaining questions from the quiz:

• What is the victim’s Windows host name? 

• What is the victim’s Windows user account name?

• How much RAM does the victim’s host have?

• What type of CPU is used by the victim’s host?

• What is the public IP address of the victim’s host?
• What type of account login data was stolen by the malware?

In this case, we can find the relevant information with just a glance at the payload_printable section of the alert. In Suricata, the payload_printable section contains the printable content of the packet payload that triggered the alert. The payload is the part of the network packet that contains the actual data being transmitted, such as the content of an email or a web page. 

The payload printable section also shows the printable characters in the payload, which can be useful in identifying the type of traffic that triggered the alert.

In order to see the payload, we can use the SN-Alert-EventList table from the SN-Hunt-1 dashboard. We have to expand the alert and either check the Table view or the JSON view. I used the JSON view, as it provides a better view on the payload. It basically holds the answers to all of the remaining questions from the Quiz:

• The victim’s Windows host name is “DESKTOP-WIN11PC”

• The victim’s Windows user account name is “windows11user”

• The victim’s host has 32165.83 or 32GB of RAM 

• The victim’s CPU is Intel(R) Core(TM) i5-13600K 

• The public IP address of the victim’s host is 173.66.46.112

• The type of account login data that was stolen is email and web accounts and credentials for those

The “Payload printable" section shows the actual data payload of a captured network packet in a human-readable format. The data payload is the part of the network packet that carries the actual information being transmitted, such as the contents of an email, a website request, or a file transfer. In this section, the data payload is presented in a format that allows analysts to read the actual content of the packet, rather than the various headers and metadata that are also included in the packet.

In the screenshot, the payload data is shown in a hexadecimal format on the left-hand side, with the corresponding ASCII representation on the right-hand side. The ASCII representation shows the actual characters that are being transmitted, allowing analysts to read the contents of the packet. The hexadecimal representation is useful for understanding the underlying binary representation of the data.

By analyzing the payload data, security analysts can gain insights into the content of the network traffic, and identify any potential security threats or anomalies. For example, they may look for patterns or keywords that indicate malware, data exfiltration, or other suspicious activity. The payload data can also be used to reconstruct the actual files or messages being transmitted, which can be useful for forensic analysis or incident response.

In this specific case, the payload_printable appears to be an SMTP (Simple Mail Transfer Protocol) conversation between a mail server and a client. It contains the following information:

• The client sends an EHLO command identifying itself as DESKTOP-WIN11PC.
• The client authenticates with the server using the login authentication method, providing base64-encoded username and password.
• The client initiates a mail transaction, specifying the sender's address as marketing[@]transgear[.]in and the recipient's address as zaritkt[@]arhitektondizajn[.]com.
• The client sends the email content, including MIME version, date, subject, content type, transfer encoding, and email body.
• The email body contains various pieces of information such as the time, user name, computer name, OS full name, CPU, RAM, IP address, and a list of URLs, usernames, passwords, and applications.
• The client ends the email by sending a dot followed by the QUIT command.

The email content appears to contain sensitive information such as login credentials and URLs of various websites, indicating a possible attempt at phishing or hacking.

The SELKS Kibana dashboards have other really useful visualizations that can help us find out even more about the flow of the attack. Some of them are the SN-ALL-EventsList table, the SN-HTTP-EventsList table on SN-Hunt-1 dashboard, as well as the SN-HTTP dashboard. The SN-ALL-EventsList table displays a list of events that can help us determine how the attack evolved over time. 

First, we have the DNS request from the client’s IP address 192.168.1.27 towards the gateway 192.168.1.1 for the savory[.]com[.]bd server. 

In between the DNS and the next HTTP event, we have a Fileinfo event, which gives us some interesting information. We can see that  “magic” is set to “data” and could indicate that it was not an actual “image/png” file but rather something else.

Next, we have an HTTP event with a GET request to savory[.]com[.]bd/sav/Ztvfo[.]png. The response from the server had a status code of 200, and included an image of type "image/png". The server was identified as LiteSpeed, and the connection was kept alive. The content length of the response was 664576 bytes.

The geoip field indicates that the source IP address is located in Cedar Knolls, New Jersey, USA. The event also includes other metadata, such as the flow ID, packet source (wire/pcap), path, and community ID.

The HTTP event also shows us that the protocol used for the file transfer was HTTP/1.1. HTTP/1.1 is a request/response protocol, which means that clients (such as web browsers) send requests to servers, and servers respond with the requested data. The data is sent in plaintext, which means that it can be intercepted and read by anyone who has access to the network traffic. In addition to the HTTP information, there is also geolocation data about the source IP address and information about the network packet flow (such as the Ethernet source and destination MAC addresses and the network protocol used).

Next, we can see a new DNS request towards api[.]ipify[.]org. This DNS event log shows that a query for  "api.ipify.org" was made from the victim’s source IP address of 192.168.1.27 via the UDP protocol. 

ipify.org is a free, public IP address API service. It provides a simple, easy-to-use API that is used to programmatically fetch the public IP address of the device or network that the API request is made from. In our case, this information is really important, because usually, if an internal device is trying to find out its public IP address - often enough that is exactly what malware needs to know, in order to understand where the device is and communicate with the correct CnC server.

The next event is a TLS event that shows us that a connection was established between the source IP address of 192.168.1.27 (victim’s address) and the destination IP address of 64.185.227.156 over TCP port 443. The TLS connection was established to the same domain api[.]ipify[.]org. The event contains various information about the TLS connection, such as the TLS version used (TLS 1.2), the certificate's subject and issuer, the certificate's validity dates, and the JA3 and JA3S fingerprints of the TLS client. 

Afterwards, we can see another DNS request for mail[.]transgear[.]in, which at first glance appears to be a public mail service. However, it could be pretty unusual for an internal client that already has presumably a corporate setup, to use non corporate mail services. That’s why it could be worth checking this case, as this can reveal to us policy violation/bypass that could lead to some malicious activity.

Thus, just by clicking on the suspicious URL as on the screenshot below , listed on our SN-ALL-EventsList table, we will be redirected towards abuse.ch, where we can easily figure out that in fact, it is a Malware URL.

A check on the URL in Virustotal would only confirm this observation - the DNS request from the victim’s IP address was done towards a malicious URL. Furthermore, if we go on the Details tab, we can see the Offender’s IP address that was also detected by Suricata.

This flow of events leads to the actual SMTP traffic that triggered the alert later on. 

Monitoring SMTP Traffic with SN-SMTP Kibana Dashboard in SELKS

Another really helpful dashboard, which could offer some of the answers to the quiz, is the SN-SMTP dashboard. The SN-SMTP-SmtpOverTime visualization shows the trend of SMTP traffic over time. This visualization plots the volume of SMTP traffic (in terms of the number of messages) against time, usually in hourly or daily intervals, depending on the selected time range.

The SN-SMTP-SmtpOverTime chart can be useful in identifying trends and patterns in SMTP traffic on the network. For example, a substantial surge in SMTP traffic at a specific time of day or day of the week could indicate a spam campaign or other malicious behavior, as clear text SMTP is unusual. Conversely, if there is a sudden decrease in SMTP traffic, it could be a sign of a network outage or other technical issue.

In our case, it shows that there were 2 SMTP events, which triggered in January 2023. 

The SN-SMTP-AttachmentsExtension chart on the SN-SMTP dashboard shows a breakdown of email attachments by file type. This visualization helps to identify the most common types of attachments that are being sent via email on the network. The chart displays the frequency of each attachment file type over a period of time. The file types can range from common ones such as PDFs, Word documents, and Excel files to more obscure file types.

This visualization is helpful in identifying potential security threats on the network. With it we can monitor for office doc/pdfs and executable transfers, preventing and auditing completed data exfiltration or potential exfiltration attempts. By monitoring the SN-SMTP-AttachmentsExtension visualization regularly, network administrators can quickly identify any anomalies and take action to prevent any potential security incidents.

Overall, the SN-SMTP-AttachmentsExtension visualization provides administrators with valuable insights into the type of email attachments being sent on the network, which can help to improve security and performance.

The SN-SMTP-Top20SrcIP table on the SN-SMTP dashboard in SELKS represents the top 20 source IP addresses that have sent the most SMTP traffic during the selected time period. This table provides a visualization of the SMTP traffic sources that are sending the most messages on your network. By identifying these sources, you can better understand your network's SMTP traffic patterns to identify, audit and investigate any suspicious activity.

The table includes Source IP and Count columns. The Source IP column lists the IP addresses of the top 20 sources of SMTP traffic, while the Count column represents that the given source IP has sent a total of 2 SMTP sessions during the selected time period.

The SN-SMTP-Top20DestIP table, on the other hand, represents the opposite. It shows the top 20 destination IP addresses that have sent the most SMTP traffic and the count of SMTP sessions from the given destination IP towards the source IP. 

The SN-SMTP-Top20DestPort and SN-SMTP-Top20SrcPort tables on the SN-SMTP dashboard represent the top 20 destination and source ports respectively - for SMTP traffic.

The tables show the destination/source port number and the number of SMTP connections that were made to that port.

In our specific case, the SN-SMTP-Top20DestPort table shows that the destination port number 587 was used for only one SMTP connection. Port 587 is a commonly used port for SMTP submission, which is the process of authenticating and sending email messages from a client to a server. The SN-SMTP-Top20SrcPort shows that there was one SMTP connection made from the source port 51958 TCP port. This means that a client on the network initiated one email transmission using this port number as the source port.

Another two really useful visualizations on the SN-SMTP dashboard are the SN-SMTP-Top20rcpt_to and SN-SMTP-Top20mail_from visualizations on the SN-SMTP dashboard. They provide insight into the top 20 recipients and senders of SMTP traffic on the network.

The SN-SMTP-Top20rcpt_to visualization displays a bar chart showing the top 20 recipients of SMTP traffic, based on the number of emails received. This can provide information on which users or email addresses are receiving the most emails, which may be useful in identifying potential targets for phishing attacks or other types of email-based attacks.

The SN-SMTP-Top20mail_from visualization, on the other hand, shows a bar chart of the top 20 senders of SMTP traffic, based on the number of emails sent. This can provide information on which users or email addresses are sending the most emails, which may be useful in identifying potential sources of spam or other unwanted email traffic.

Both of these visualizations can be used to identify patterns or anomalies in SMTP traffic on the network, which may be indicative of malicious activity or other security issues. For example, a sudden increase in the number of emails sent to a particular recipient or from a particular sender may be a sign of a compromised account or a spam campaign.

The visualizations also provide for reverse ordering which is an easy way to identify least/low senders - which can also highlight suspicious activity depending on which part of the network it comes from.

Thanks to the SELKS SN-SMTP Kibana dashboard and these two visualizations, on the SN-SMTP-Top20rcpt_to, we can easily see that an email has been sent to zaritkt[@]arhitektondizajn[.]com (the victim) from marketing[@]transgear[.]in (the offender).

The SN-SMTP Kibana dashboard in SELKS provides visualizations for even more SMTP-related data produced by Suricata. For example:

• SN-SMTP-Top20MailApplications: This visualization shows the top 20 mail applications that are sending emails to the monitored system. The data is based on the SMTP header information, which contains details about the client application used to send the email.
• SN-SMTP-Top20MailOrganizations: This visualization shows the top 20 organizations that are sending emails to the monitored system. The data is based on the SMTP header information, which contains details about the sender's organization.
• SN-SMTP-Top20MailSendingIPs: This visualization shows the top 20 IP addresses that are sending emails to the monitored system. The data is based on the SMTP header information, which contains details about the sender's IP address.

These visualizations can help IT and Network administrators identify and audit the sources/destinations of SMTP traffic to their system and potentially detect any security violations which can be a result of malicious or suspicious activity.

The SN-SMTP-EventsList section on the SN-SMTP Kibana dashboard in SELKS represents a list of events related to the SMTP protocol. The section provides a table that displays various SMTP-related events such as SMTP connections, disconnections, SMTP commands, responses, and errors.

Each row in the table represents a single SMTP-related event, and its content (in table and json formats)  provides information about the event, such as the timestamp, source IP address, destination IP address, SMTP command or response, and the corresponding message. The table also allows filtering, sorting, and grouping of events based on various criteria.

The SN-SMTP-EventsList section is a useful tool for network administrators and security analysts to monitor SMTP traffic on their network, detect potential security threats, and troubleshoot any SMTP-related issues. By analyzing the information provided in this section, network administrators can identify and investigate suspicious SMTP activity and take appropriate actions to mitigate any potential security risks.

This event log from the first related event shows an SMTP-related communication between a source IP address of 192.168.1.27 and a destination IP address of 204.11.58.28. The source port was 51958, and the destination port was 587, which is commonly used for SMTP submission. The log also provides additional information such as the Ethernet source and destination MAC addresses, geoip location data, and SMTP-specific details such as the HELO/EHLO domain name used in the SMTP conversation.

The event occurred on Jan 6, 2023, at 00:53:09.870 and was logged in the logstash-smtp-2023.01.05 index. The log was generated from the eve.json file located in /var/log/suricata/ directory on the host machine named 2023-01-Unit42-Wireshark-quiz.pcap. 

The log contains a tag "_geoip_lookup_failure" which suggests that the GeoIP lookup failed for the destination IP address. Overall, this event log provides information about a SMTP communication between two IP addresses, and it may be useful for network monitoring and troubleshooting purposes.

This second related event on the SN-SMTP-EventsList section, gives even more information. Some of it is: 

• geoip: The geographic location of the destination IP address in the SMTP event 
• @version: The version of the event.
• src_ip: The source IP address of the SMTP event.
• flow_id: Suricata native  ID of any and all events from the same flow. Allows for easy correlation of alerts to protocol logs and flows. In this case it is SMTP events of the flow.
• smtp.helo: The hostname that was provided by the client in the HELO/EHLO command.
• smtp.rcpt_to: The recipient email address(es) in the SMTP event.
• smtp.mail_from: The sender email address in the SMTP event.
• tags: Additional tags for the event, here the "_geoip_lookup_failure" tag.
• dest_ip: The destination IP address of the SMTP event.
• event_type: The type of the event, here "smtp".
• email.status: The status of the email, here "PARSE_DONE".
• email.from: The sender email address of the email.
• email.date: The date when the email was sent.
• email.to: The recipient email address(es) of the email.
• email.subject: The subject of the email.
• dest_port: The destination port used for the SMTP event.
• ether.dest_mac: The MAC address of the destination host in the SMTP event.
• ether.src_mac: The MAC address of the source host in the SMTP event.
• timestamp: The timestamp of the event in UTC
• pcap_cnt: The number of packets captured for the event.
• community_id: The community ID calculated for the event.
• type: The type of event, here "SELKS".
• pkt_src: The source of the packet capture, here "wire/pcap".
• proto: The protocol used for the event, here "TCP".
• src_port: The source port used for any event.
• @timestamp: The timestamp of the event in Month Day, Year @ Hour:Minute:Second.Millisecond format.
• host: The name of the host where the event occurred.

In fact, most of the answers to the Quiz are easy to see on this SMTP related event: 

Solving the Wireshark quiz with SELKS Kibana Dashboards

Utilizing SELKS Kibana dashboards is an easy way to unleash the power of the data that Suricata produces in order to successfully complete the Unit 42 Wireshark Quiz and for analyzing network traffic in general. The dashboards provide a user-friendly interface that enables network analysts to quickly identify potential threats and anomalous behavior in network traffic. Additionally, the dashboards offer valuable insights into network performance and can aid in troubleshooting network issues. By leveraging the capabilities of SELKS Kibana dashboards, network analysts can streamline their analysis process and more effectively protect their organization's network from potential security threats.

To learn more about SELKS, visit the page on the Stamus Networks website here.