Effectively Using Zeek (Bro)
\nNOTE: Bro is now Zeek!
\nLAB 6
\nScenario
\nThe organization you work for is considering deploying Zeek (now known as Bro) to enhance its traffic inspection capabilities. Your IT Security manager tasked you with thoroughly analyzing zeek's capabilities. He also provided you with PCAP files containing malicious traffic, so that you can experiment with writing zeek detection scripts and signatures.
\nA test instance of zeek has already been set up and is waiting for you!
\nLearning Objectives
\nThe learning objective of this lab is to not only get familiar with the detection capabilities of zeek but also to learn effective zeek scripting.
\nSpecifically, you will learn how to use zeek's capabilities in order to:
\n- \n
- \n
Have better visibility over a network
\n \n - \n
Respond to incidents timely and effectively
\n \n - \n
Proactively hunt for threats
\n \n
Introduction To Zeek
\nZeek's creators describe it as an open-source traffic analyzer. It is typically used to inspect all traffic on a link (in depth) for signs of malicious or suspicious activity. That being said, Zeek can also be used for network troubleshooting and various measurements within a network. By deploying Zeek, blue teams can immediately access a variety of log files that contain all kinds of network activity, at a high level. More specifically, those logs contain not only detailed records of every connection on the wire but also application-layer transcripts (for example - DNS requests and the respective replies, whole HTTP sessions, etc.). Zeek does a lot more than just keeping track of the aforementioned. It is also shipped with a whole range of analysis and detection capabilities/functions.
\nWhat is important to know is that Zeek exposes an extremely capable scripting language to its users (to develop Zeek scripts, the equivalent of Suricata rules). This key feature makes Zeek a fully customizable and extensible platform, based on which blue team members can create their own analysis and detection logic/posture.
\nIf we combine that fact that Zeek runs on commodity hardware with its capable scripting language, we can easily conclude that we are not dealing with yet another signature-based IDS. Zeek is a platform that could also facilitate semantic misuse detection, anomaly detection, and behavioral analysis.
\nThe most important Zeek features and capabilities are:
\n- \n
- \n
Comprehensive logging of network activity
\n \n - \n
Analysis of application-layer protocols (regardless of the port, covering protocols like HTTP, DNS, FTP, SMTP, SSH, SSL, etc.)
\n \n - \n
Ability to look into file content exchanged over application-layer protocols
\n \n - \n
IPv6 support
\n \n - \n
Tunnel detection and analysis
\n \n - \n
Ability to perform sanity checks during protocol analysis
\n \n - \n
IDS-like pattern matching
\n \n - \n
Scripting Language
\n- \n
- \n
Facilitates the expression of arbitrary analysis tasks
\n \n - \n
Event-based programming model
\n \n - \n
Domain-aware
\n \n - \n
Can facilitate tracking and managing network state over time
\n \n
\n - \n
- \n
Interfacing
\n- \n
- \n
Outputs to well-structured ASCII logs, by default
\n \n - \n
Alternative backends for ElasticSearch and DataSeries
\n \n - \n
External input can be integrated into analyses, in real-time
\n \n - \n
External C library for exchanging Bro events with external programs
\n \n - \n
Ability to trigger arbitrary external processes from within the scripting language
\n \n
\n - \n
Zeek operation modes:
\n- \n
- \n
Fully passive traffic analysis
\n \n - \n
libpcap interface for capturing packets
\n \n - \n
Real-time and offline (for example, PCAP-based) analysis
\n \n - \n
Cluster-support for large-scale deployments
\n \n
Zeek architecture and events:
\n![\"https://docs.zeek.org/en/stable/_images/architecture.png\"](\"https://assets.ine.com/cybersecurity-lab-images/d67706a9-d983-44d3-b1e2-6bef49c6cc33/image3.png\")
Zeek consists of two main components, the event engine (or core) and the script interpreter.
\n- \n
- \n
The event engine \"transforms\" an incoming packet stream into a series of high-level events. In Zeek language, these events lay any network activity out in policy-neutral terms; this means that they inform us of what has been spotted, but not if it requires attention or how/why it got there in the first place. For example, all spotted HTTP requests will be \"transformed\" into http_request events. These events carry every request detail/component, but they don't include any level of interpretation, e.g., of whether a port corresponds to a known port used by malware.
\n \n - \n
Such interpretation is offered through Zeek's second main component, the script interpreter. Under the hood, the script interpreter executes a set of event handlers written in Zeek's scripting language (Zeek scripts); this is actually how a site's security policy is expressed when Zeek is used. By security policy we mean, for example, the actions to occur immediately after detection.
\n \n
Events generated by Zeek core are placed into an ordered \"event queue\" to be handled in a first-come-first-serve order.
\n| Event Name | \nEvent Description | \n
|---|---|
| rdp_begin_encryption | \nGenerated when an RDP session becomes encrypted | \n
| rdp_client_core_data | \nGenerated for MCS client request | \n
| rdp_connect_request | \nGenerated for X.224 client requests | \n
| rdp_gcc_server_create_response | \nGenerated for MCS server responses | \n
| rdp_negotiation_failure | \nGenerated for RDP Negotiation Failure messages | \n
| rdp_negotiation_response | \nGenerated for RDP Negotiation Response messages | \n
| rdp_server_certificate | \nGenerated for a server certificate section | \n
| rdp_server_security | \nGenerated for MCS server responses | \n
For a more comprehensive list, refer to the following resource: https://docs.zeek.org/en/stable/scripts/base/bif/
\nZeek logs:
\nWhen we use Zeek for offline analysis of a PCAP file though, Zeek logs will be stored in the current directory.
\nSome known Zeek logs are:
\nconn.log: IP, TCP, UDP, and ICMP connection details
\ndns.log: DNS query/response details
\nhttp.log: HTTP request/reply details
\nftp.log: FTP request/reply details
\nsmtp.log: SMTP transactions, e.g., sender and receiver
\nIf we take, for example, the http.log Bro log, it includes numerous useful information such as:
\n- \n
- \n
host: HTTP domain/IP
\n \n - \n
uri: HTTP URI
\n \n - \n
referrer: HTTP request referrer
\n \n - \n
user_agent: Client user agent
\n \n - \n
status_code: HTTP status code
\n \n
Note that in its default setup, Zeek will gzip compress log files every passing hour. The old logs will be moved into a directory with a YYYY-MM-DD format. In the case of dealing with compressed logs, you can use alternative tools such as gzcat to print logs or zgrep to search in them.
\nFor zeek examples, use cases and the basics of writing Bro scripts, refer to the following link: https://docs.zeek.org/en/stable/examples/index.html
\nFor a quick start guide, refer to the following link: https://docs.zeek.org/en/stable/quickstart/index.html
\nSpend time studying the resources above before proceeding to the lab's tasks.
\nRecommended tools
\n- \n
- Zeek (Already installed on the lab setup) \n
Tasks
\nTask 1: Write a zeek script to alert you on any RDP connection initiated by a user different than \"admin\"
\nConsider the RDP-004.pcap file stored in the /root/Desktop/PCAPs directory.Write a Zeek script that will extract the username(s) that initiated the RDP connection attempts and alert you in case a username is different than \"admin\".
\nHints: Locate and analyze the rdp_connect_request event.
\nResources:
\n- \n
- \n
https://docs.zeek.org/en/stable/scripts/base/bif/plugins/Bro_RDP.events.bif.bro.html
\n \n - \n
https://docs.zeek.org/en/stable/examples/scripting/index.html
\n \n - \n
https://docs.zeek.org/en/stable/frameworks/notice.html?highlight=notice
\n \n
Task 2: Analyze the provided incident_1.pcap PCAP file leveraging Zeek native functionality and identify any suspicious or abnormal activity
\nAnalyze the incident_1.pcap PCAP file (stored in the ~/Desktop/PCAPs directory) leveraging Zeek native functionality. Try to identify any abnormalities by going through all created Zeek logs.
\nHint: Malware can leverage unencrypted SSL components for their nefarious purposes.
\nTask 3: Analyze the provided incident_2.pcap PCAP file leveraging Zeek native functionality and identify any suspicious or abnormal activity
\nAnalyze the incident_2.pcap PCAP file (stored in the ~/Desktop/PCAPs directory) leveraging Zeek native functionality. Try to identify any abnormalities by going through all created Zeek logs. Note that the incident_2.pcap PCAP file was captured inside a sandbox.
\nHint: Malware are known to oftentimes abuse the flexible infrastructure of the Domain Name System (DNS); specifically, numerous new domain names are being produced by malware authors, and each one of them can play the role of the botmaster, should the occasion requires so. For more information, refer to the following link: https://blogs.akamai.com/2017/05/spotlight-on-malware-dga-communication-technique.html
\nTask 4: Analyze the provided incident_3.pcap PCAP file leveraging Zeek native functionality and identify any suspicious or abnormal activity
\nAnalyze the incident_3.pcap PCAP file (stored in the ~/Desktop/PCAPs directory) leveraging Zeek native functionality. Try to identify any abnormalities by going through all created Zeek logs.
\nHint: Malware doesn't always keep a single TCP session alive during their operation. As a matter of fact, the new age of RATs prefers beaconing at regular intervals, rather than keeping a single TCP session alive. Beaconing can help evade certain methods of detection that are based on spotting long-running connections.
\nTask 5: The incident_4.pcap PCAP file contains traffic of a RAT that kept a single TCP session alive during its operation. Develop a Zeek script to detect such long-running connections.
\nYou knew from the beginning that the incident_4.pcap PCAP file (stored in the ~/Desktop/PCAPs directory) is related to a known RAT that prefers keeping a single TCP session alive during its operation. Develop a Zeek script to detect such long-running connections.
\nTask 6: The ZeroAccess.pcap PCAP file contains malicious traffic that derives from the notorious ZeroAccess rootkit. Leverage Zeek's signature framework to create a signature for this rootkit.
\nAccording to Zeek docs regarding its Signature Framework, \"Zeek relies primarily on its extensive scripting language for defining and analyzing detection policies. Additionally, however, Zeek also provides an independent signature language for doing low-level, Snort-style pattern matching\".
\nBased on the following analysis, create a Zeek signature to detect ZeroAccess on the wire. http://malforsec.blogspot.com/2013/02/zeroaccess-analysis-part-i-network.html
", "published_date": "2020-10-20T15:32:25Z", "solutions": "# SOLUTIONS\n\nBelow, you can find solutions for every task of this lab. Remember though, that you can follow your own strategy (which may be different from the one explained in the following lab.\n\n## Task 1: Write a zeek script to alert you on any RDP connection initiated by a user different than \"admin\"\n\n#\n\nLet's first set zeek's path as environment variable so that we can access it globally. We can do so with the help of following command -\n\n```\nexport PATH=/opt/zeek/bin/:$PATH\n```\n\n***NOTE: If you are closing this lab, you need to run the above mentioned command again in order to set the zeek's path.***\n\nNow, let's introduce a script file to handle the *rdp_connect_request* event, according to the requirements of Task 1\n\n```\ncd ~/Desktop\nmkdir zeek\ncd zeek\nnano test.zeek\n```\n\nInside nano (in 'test.zeek'), type the below code-\n\n```\n@load base/protocols/rdp\nevent rdp_connect_request(c: connection, cookie:string)\n{\n\tprint cookie;\n}\n```\n\nIn the first line, we simply imported all of the base functionality already implemented in Zeek, regarding RDP analysis. Then, we defined the event handler, instructing it to only print the cookie of the request. What is important to remember, is that the event declaration should be identical to the one shown in the Zeek *rdp_connect_request*.\n\nNow, let's execute Zeek and specify the *RDP-004.pcap* PCAP file as well as the script we just created.\n\n```\nzeek -b -r ~/Desktop/PCAPs/RDP-004.pcap test.zeek\n```\n\nThe -b flag is used so as to **not** automatically load all scripts under *base* (which is the default behavior).\n\nThe -r flag is used to execute Zeek for offline analysis of a provided traffic capture file.\n\nPlacing a Zeek script at the end of the command will load the specified Zeek script.\n\nYou should see something similar to the following.\n\n\n\nWhat if we wanted some more information from the connection request, such as the source address and the start time (in Unix time), all printed in one line?\n\nWe could do so, by extending our Zeek script (*nano test.zeek* again), as follows.\n\n```\n@load base/protocols/rdp\nevent rdp_connect_request(c:connection, cookie:string)\n{\n local start_time = strftime(\"%Y-%m-%d %H:%M:%S\", c$start_time );\n print fmt(\"New RDP Requst from: %s at %s by user %s\", c$id$orig_h, start_time , cookie);\n}\n```\n\nNow, let's execute Zeek and specify the *RDP-004.pcap* PCAP file as well as the extended script we just created.\n\n```\nzeek -b -r ~/Desktop/PCAPs/RDP-004.pcap test.zeek\n```\n\nYou should see something similar to the following.\n\n\n\nTo make our Zeek script fulfill the requirements of Task 1 (alert us on any RDP connection initiated by a user different than \"admin\"), we have to implement two additional things.\n\n1. Instead of just printing the log into standard output, we would like the Zeek output to be logged into a file for better and more effective monitoring; this is where Zeek's \"*notice*\" framework comes into play. The \"*notice*\" framework is used when we want Zeek to alert us on suspicious or malicious activity. When writing a Zeek script, we can raise such an alert by simply calling the NOTICE function.\n\n2. We should also introduce functionality that compares the observed username in the RDP connection to the username \"admin\" and alerts us in case of a mismatch.\n\nBoth the above can be easily implemented, as follows (below is the final version of our Zeek script).\n\n- Write (Copy-Paste) the below mentioned script into your *test.zeek* file.\n\n```\n@load base/protocols/rdp\n@load base/frameworks/notice\nexport { redef enum Notice::Type += {Suspicious_RDP}; }\nevent rdp_connect_request(c: connection, cookie:string){\n\tif (cookie != \"admin\"){\n\t\tlocal start_time = strftime(\"%Y-%m-%d %H:%M:%S\", c$start_time );\n\t\tlocal message = fmt(\"New RDP Request from: %s at %s by user %s\", c$id$orig_h, start_time , cookie);\n\t\tNOTICE([$note= Suspicious_RDP, $msg=message]);\n\t}\n}\n```\n\nFinally, let's execute Zeek and specify the *RDP-004.pcap* PCAP file as well as the final version of our script.\n\n```\nzeek -b -r ~/Desktop/PCAPs/RDP-004.pcap test.zeek\n```\n\nYou should see nothing in the standard output, but you will find a new Zeek log named **notice.log** in the current directory.\n\n\n\n**notice.log** contains the alert messages we specified in the final version of our Zeek script.\n\n- Run the following command -\n```\ncat notice.log\n```\n\n\n\n\n## Task 2: Analyze the provided PCAP file leveraging Bro native functionality and identify any suspicious or abnormal activity\n\nFirst, delete any previously generated logs in the current directory.\n\nRun -\n```\ncd ..\nrm -r zeek\nmkdir zeek\ncd zeek\n```\n\nLet's start our analysis, by executing Zeek as follows.\n\n```\nzeek -C -r /root/Desktop/PCAPs/incident_1.pcap local\n```\n\n-C is used to ignore invalid TCP checksums.\n\nYou should see nothing important in the standard output, but various Zeek logs being created, as follows.\n\nNow run ``` ls -l ```\n\n\n\nLet's take a look at **weird.log**. weird.log contains unusual/exceptional activity that can indicate malformed connections, traffic that doesn't conform to a particular protocol or even a malicious actor trying to evade or confuse a sensor.\n\n```\ncat weird.log\n```\n\nYou should see something similar to the below.\n\n\n\nNothing conclusive. Let's move on.\n\nLet's now inspect the contents of **notice.log**, as follows.\n\n```\ncat notice.log\n```\nYou should see something similar to the below.\n\n\n\nFirst of all, notice that even though we see port 4433 (TCP), Zeek was still able to identify that what it sees is SSL traffic. **Disregard 127.0.0.1, the PCAP is from a run using local loopback.**\n\nWhat you should also notice, are those \"self signed certificate\" messages. Unfortunately, self-signed certificates are quite common, even nowadays. So, nothing suspicious yet. Those \"default\" values on the SSL certificates (marked in yellow) are interesting!\n\nWe should not forget that malicious actors are known for both using self-signed SSL certificates and being lazy, so, let's take a closer look.\n\nSSL certificates are quite valuable when it comes to responding to SSL-powered malware; this is because they are transmitted unencrypted. Unfortunately, Zeek doesn't extract every observed SSL certificate, by default. Let's configure it, so that it does, as follows.\n\n```\nnano /opt/zeek/share/zeek/site/local.zeek\n```\n\nInside nano, append the following at the end of the **local.zeek** file.\n(Already present in the lab setup, just verify it is there or not.)\n\n```\n@load protocols/ssl/extract-certs-pem\nredef SSL::extract_certs_pem = ALL_HOSTS;\n```\n\nThis will extract all observed SSL certificates and store them inside a big **certs-remote.pem** file.\n\nIf you run zeek once again, you will notice this big **certs-remote.pem** file, in the current directory.\n\nRun -\n\n```\nzeek -C -r /root/Desktop/PCAPs/incident_1.pcap local\nls\n```\n\n\n\nNow, let's move that **certs-remote.pem** file in a temp directory and split it into all the separate .pem files that constructed it. This can be done as follows.\n\n```\nmkdir temp\nmv certs-remote.pem temp\ncd temp\nawk ' split_after == 1 {close(n\".pem\"); n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} { print > n\".pem\"}'SOLUTIONS
\nBelow, you can find solutions for every task of this lab. Remember though, that you can follow your own strategy (which may be different from the one explained in the following lab.
\nTask 1: Write a zeek script to alert you on any RDP connection initiated by a user different than \"admin\"
\n\nLet's first set zeek's path as environment variable so that we can access it globally. We can do so with the help of following command -
\nexport PATH=/opt/zeek/bin/:$PATHNOTE: If you are closing this lab, you need to run the above mentioned command again in order to set the zeek's path.
\nNow, let's introduce a script file to handle the rdp_connect_request event, according to the requirements of Task 1
\ncd ~/Desktop\nmkdir zeek\ncd zeek\nnano test.zeekInside nano (in 'test.zeek'), type the below code-
\n@load base/protocols/rdp\nevent rdp_connect_request(c: connection, cookie:string)\n{\n print cookie;\n}In the first line, we simply imported all of the base functionality already implemented in Zeek, regarding RDP analysis. Then, we defined the event handler, instructing it to only print the cookie of the request. What is important to remember, is that the event declaration should be identical to the one shown in the Zeek rdp_connect_request.
\nNow, let's execute Zeek and specify the RDP-004.pcap PCAP file as well as the script we just created.
\nzeek -b -r ~/Desktop/PCAPs/RDP-004.pcap test.zeekThe -b flag is used so as to not automatically load all scripts under base (which is the default behavior).
\nThe -r flag is used to execute Zeek for offline analysis of a provided traffic capture file.
\nPlacing a Zeek script at the end of the command will load the specified Zeek script.
\nYou should see something similar to the following.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image1.png\")
What if we wanted some more information from the connection request, such as the source address and the start time (in Unix time), all printed in one line?
\nWe could do so, by extending our Zeek script (nano test.zeek again), as follows.
\n@load base/protocols/rdp\nevent rdp_connect_request(c:connection, cookie:string)\n{\n local start_time = strftime(\"%Y-%m-%d %H:%M:%S\", c$start_time );\n print fmt(\"New RDP Requst from: %s at %s by user %s\", c$id$orig_h, start_time , cookie);\n}Now, let's execute Zeek and specify the RDP-004.pcap PCAP file as well as the extended script we just created.
\nzeek -b -r ~/Desktop/PCAPs/RDP-004.pcap test.zeekYou should see something similar to the following.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image2.png\")
To make our Zeek script fulfill the requirements of Task 1 (alert us on any RDP connection initiated by a user different than \"admin\"), we have to implement two additional things.
\n- \n
- \n
Instead of just printing the log into standard output, we would like the Zeek output to be logged into a file for better and more effective monitoring; this is where Zeek's \"notice\" framework comes into play. The \"notice\" framework is used when we want Zeek to alert us on suspicious or malicious activity. When writing a Zeek script, we can raise such an alert by simply calling the NOTICE function.
\n \n - \n
We should also introduce functionality that compares the observed username in the RDP connection to the username \"admin\" and alerts us in case of a mismatch.
\n \n
Both the above can be easily implemented, as follows (below is the final version of our Zeek script).
\n- \n
- Write (Copy-Paste) the below mentioned script into your test.zeek file. \n
@load base/protocols/rdp\n@load base/frameworks/notice\nexport { redef enum Notice::Type += {Suspicious_RDP}; }\nevent rdp_connect_request(c: connection, cookie:string){\n if (cookie != \"admin\"){\n local start_time = strftime(\"%Y-%m-%d %H:%M:%S\", c$start_time );\n local message = fmt(\"New RDP Request from: %s at %s by user %s\", c$id$orig_h, start_time , cookie);\n NOTICE([$note= Suspicious_RDP, $msg=message]);\n }\n}Finally, let's execute Zeek and specify the RDP-004.pcap PCAP file as well as the final version of our script.
\nzeek -b -r ~/Desktop/PCAPs/RDP-004.pcap test.zeekYou should see nothing in the standard output, but you will find a new Zeek log named notice.log in the current directory.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image3.png\")
notice.log contains the alert messages we specified in the final version of our Zeek script.
\n- \n
- Run the following command -\n
cat notice.log\n
![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image4.png\")
Task 2: Analyze the provided PCAP file leveraging Bro native functionality and identify any suspicious or abnormal activity
\nFirst, delete any previously generated logs in the current directory.
\nRun -\n
cd ..\nrm -r zeek\nmkdir zeek\ncd zeekLet's start our analysis, by executing Zeek as follows.
\nzeek -C -r /root/Desktop/PCAPs/incident_1.pcap local-C is used to ignore invalid TCP checksums.
\nYou should see nothing important in the standard output, but various Zeek logs being created, as follows.
\nNow run ls -l
![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image5.png\")
Let's take a look at weird.log. weird.log contains unusual/exceptional activity that can indicate malformed connections, traffic that doesn't conform to a particular protocol or even a malicious actor trying to evade or confuse a sensor.
\ncat weird.logYou should see something similar to the below.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image6.png\")
Nothing conclusive. Let's move on.
\nLet's now inspect the contents of notice.log, as follows.
\ncat notice.log![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image7.png\")
First of all, notice that even though we see port 4433 (TCP), Zeek was still able to identify that what it sees is SSL traffic. Disregard 127.0.0.1, the PCAP is from a run using local loopback.
\nWhat you should also notice, are those \"self signed certificate\" messages. Unfortunately, self-signed certificates are quite common, even nowadays. So, nothing suspicious yet. Those \"default\" values on the SSL certificates (marked in yellow) are interesting!
\nWe should not forget that malicious actors are known for both using self-signed SSL certificates and being lazy, so, let's take a closer look.
\nSSL certificates are quite valuable when it comes to responding to SSL-powered malware; this is because they are transmitted unencrypted. Unfortunately, Zeek doesn't extract every observed SSL certificate, by default. Let's configure it, so that it does, as follows.
\nnano /opt/zeek/share/zeek/site/local.zeekInside nano, append the following at the end of the local.zeek file.\n(Already present in the lab setup, just verify it is there or not.)
\n@load protocols/ssl/extract-certs-pem\nredef SSL::extract_certs_pem = ALL_HOSTS;This will extract all observed SSL certificates and store them inside a big certs-remote.pem file.
\nIf you run zeek once again, you will notice this big certs-remote.pem file, in the current directory.
\nRun -
\nzeek -C -r /root/Desktop/PCAPs/incident_1.pcap local\nls![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image8.png\")
Now, let's move that certs-remote.pem file in a temp directory and split it into all the separate .pem files that constructed it. This can be done as follows.
\nmkdir temp\nmv certs-remote.pem temp\ncd temp\nawk ' split_after == 1 {close(n\".pem\"); n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} { print > n\".pem\"}' <certs-remote.pemRun-\n
ls![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image9.png\")
Let's continue, by inspecting 1.pem, we can do so through the openssl binary, as follows.
\nopenssl x509 -in 1.pem -text -nooutYou should see the below.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image10.png\")
![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image11.png\")
If you go further down the certificate, you will notice an overly large X509v3 Subject Key Identifier section.
Such an overly large X509v3 Subject Key Identifier and subsequently such an overly large .pem file is not common. Additionally, the whole section seems like hex values (including NULL ones) and that 4D5A part, in the beginning, looks scary because it is the equivalent of the MZ in ASCII and MZ is known to be a magic value to identify a Portable Executable file format.
\nLet's make sure, by executing the following.
\necho \"copy-paste the whole X509v3 Subject Key Identifier section here\" | sed 's/://g'Then, take the stripped output and execute the following.
\necho \"copy-paste the stripped X509v3 Subject Key Identifier section here\" | xxd -r -pYou should see the following.
\n![\"\"](\"https://assets.ine.com/cybersecurity-lab-images/d67706a9-d983-44d3-b1e2-6bef49c6cc33/image17.png\")
The above means that a binary was stealthily being transferred, masked as an X509v3 Subject Key Identifier.
\nPCAP was taken from: https://github.com/fideliscyber/x509/
\nFor more on the attacking technique being used, check out the following link: https://www.fidelissecurity.com/threatgeek/threat-intelligence/x509-vulnerabilities>
\nTask 3: Analyze the provided incident_2.pcap PCAP file leveraging Zeek native functionality and identify any suspicious or abnormal activity
\nFirst, delete any previously generated logs in the current directory.
\nRun -\n
cd ../..\nrm -r zeek\nmkdir zeek\ncd zeekNow, let's start our analysis, by executing Zeek as follows.
\nzeek -C -r /root/Desktop/PCAPs/incident_2.pcap localFor a summary of the connections in incident_2.pcap you can refer to Zeek's conn.log, as follows.
\ncat conn.logYou should see something similar to the below.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image12.png\")
For a more straightforward representation, we can execute the following.
\ncat conn.log | zeek-cut id.orig_h id.orig_p id.resp_h id.resp_p proto conn_state![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image13.png\")
Remember that traffic was captured inside a sandbox; this is why you see some inconsistent connection attempts on port 80. Some of them got rejected (REJ), some of them had no reply (S0), and others left the connection half-open (SH).
\nPort 80 means that HTTP traffic occurred. Let's take a closer look by inspecting Zeek's http.log, as follows.
\ncat http.log | zeek-cut id.orig_h id.orig_p id.resp_h id.resp_p host uri referrerYou should see the below.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image14.png\")
The host field looks quite abnormal.
\nIf we take a look at zeek's dns.log, the same story continues.
\ncat dns.log | zeek-cut query![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image15.png\")
Let's now analyze the requested domains. First, let's get rid of the TLDs, as follows.
\ncat dns.log | zeek-cut query | cut -d . -f1 > stripped_domainsfor i in `cat stripped_domains`; do echo \"${#i}\"; done![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image16.png\")
The stripped domains seems to be random strings of character between some range.
\nWe are most probably dealing with a DGA-equipped malware.
\nPCAP was taken from: http://blog.opensecurityresearch.com
\nTask 4: Analyze the provided incident_3.pcap PCAP file leveraging Zeek native functionality and identify any suspicious or abnormal activity
\nFirst, delete any previously generated logs in the current directory.
\nRun -\n
cd ..\nrm -r zeek\nmkdir zeek\ncd zeekNow, let's start our analysis, by executing Bro as follows.
\nzeek -C -r /root/Desktop/PCAPs/incident_3.pcap localFor a summary of the connections in incident_3.pcap you can refer to Zeek's conn.log, as follows.
\ncat conn.logYou should see the below.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image17.png\")
We notice that Zeek identified SSL on port 80; this is quite strange.
\nLet's take a look at Zeek's ssl.log as well.
\ncat ssl.logYou should see the following.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image18.png\")
Of course, we notice the presence of self-signed SSL certificates, but this is just the tip of the iceberg. If we carefully look at the timestamps of both conn.log and ssl.log, we notice that communication with the remote server occurs every 5 seconds. We are most probably dealing with a beaconing malware.
\nTask 5: The incident_4.pcap PCAP file contains traffic of a RAT that kept a single TCP session alive during its operation. Develop a Zeek script to detect such long-running connections.
\nFirst, delete any previously generated logs in the current directory.
\nRun -\n
cd ..\nrm -r zeek\nmkdir zeek\ncd zeekNow, let's start our analysis, by executing Zeek as follows.
\nzeek -C -r /root/Desktop/PCAPs/incident_4.pcap localFor a summary of the connections in incident_4.pcap you can refer to Zeek's conn.log, as follows.
\ncat conn.logYou should see the below.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image19.png\")
Further down Zeek's conn.log, we can see that there are some long-running connections with a remote machine. Find out which, as an exercise.
\nA viable Zeek script to detect such long-running connections can be found below. Create it through nano and save it in current directory as detect-long-connections.zeek.
\n@load base/protocols/conn\n@load base/utils/time\n# This is probably not so great to reach into the Conn namespace..\nmodule Conn;\nexport {\nfunction set_conn_log_data_hack(c: connection)\n {\n Conn::set_conn(c, T);\n }\n}\n# Now onto the actual code for this script\\...\nmodule LongConnection;\nexport {\n redef enum Log::ID += { LOG };\n ## Aliasing vector of interval values as\n ## \"Durations\"\n type Durations: vector of interval;\n ##The default duration that you are locally\n ##considering a connection to be \"long\".\n const default_durations = Durations(10min, 30min, 1hr, 12hr, 24hrs, 3days) &redef;\n ## These are special cases for particular hosts or subnets\n ## that you may want to watch for longer or shorter\n ## durations than the default.\n const special_cases: table[subnet] of Durations = {} &redef;\n}\nredef record connection += {\n ##Offset of the currently watched connection duration by the long-connections script.\n long_conn_offset: count &default=0;\n};\nevent zeek_init() &priority=5\n {\n Log::create_stream(LOG, [$columns=Conn::Info, $path=\"conn_long\"]);\n }\nfunction get_durations(c: connection): Durations\n {\n local check_it: Durations;\n if ( c$id$orig_h in special_cases )\n check_it = special_cases[c$id$orig_h];\n else if ( c$id$resp_h in special_cases )\n check_it = special_cases[c$id$resp_h];\n else\n check_it = default_durations;\n return check_it;\n}\nfunction long_callback(c: connection, cnt: count): interval\n {\n local check_it = get_durations(c);\n if ( c$long_conn_offset < |check_it| && c$duration >= check_it[c$long_conn_offset] )\n {\n Conn::set_conn_log_data_hack(c);\n Log::write(LongConnection::LOG, c$conn);\n local message = fmt(\"%s -> %s:%s remained alive for longer than %s\",\n c$id$orig_h, c$id$resp_h, c$id$resp_p, duration_to_mins_secs(c$duration));\n ++c$long_conn_offset;\n }\n # Keep watching if there are potentially more thresholds.\n if ( c$long_conn_offset < |check_it| )\n return check_it[c$long_conn_offset];\n else\n return -1sec;\n }\nevent connection_established(c: connection)\n {\n local check = get_durations(c);\n if ( |check| > 0 )\n {\n ConnPolling::watch(c, long_callback, 1, check[0]);\n }\n}Let's test the script above, as follows.
\nzeek -C -b -r ~/Desktop/PCAPs/incident_4.pcap detect-long-connections.zeekYou should now be able to see a new log conn_long.log created in the current directory, with the below contents.
\n![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image20.png\")
Indeed, those were the longest-running connections inside conn.log. It is way better to have a Zeek script automating this procedure for us, don't you think?
\nTask 6: The ZeroAccess.pcap PCAP file contains malicious traffic that derives from the notorious ZeroAccess rootkit. Leverage Zeek's signature framework to create a signature for this rootkit.
\nBy studying the ZeroAccess analysis, we come across the following part.
\n![\"\"](\"https://assets.ine.com/cybersecurity-lab-images/d67706a9-d983-44d3-b1e2-6bef49c6cc33/image27.png\")
First, delete any previously generated logs in the current directory.
\nRun -\n
cd ..\nrm -r zeek\nmkdir zeek\ncd zeekNow, we could easily make a Zeek signature based on this fingerprint, as follows.
\nnano zeroaccess.sigInside nano, type the following.
\nsignature zeroaccess {\n ip-proto == udp\n payload /....\\x28\\x94\\x8d\\xab.*/\n event \"zeroaccess\"\n}nano zeroaccess.zeekInside nano, type the following.
\n@load base/frameworks/notice\n@load base/frameworks/signatures/main\n@load base/utils/addrs\n@load base/utils/directions-and-hosts\n@load-sigs ./zeroaccess.sig\nredef Signatures::ignored_ids += /zeroaccess/;\nmodule ZeroAccess;\nexport {\n redef enum Notice::Type += {\n ##Raised when a host doing Bitcoin mining is found.\n ZeroAccess_Client,\n ##Raised when a host is serving work to Bitcoin miners.\n ZeroAccess_Server\n };\n ##Type of ZeroAccessHost which, on discovery, should raise a notice.\n const notice_zeroaccess_hosts = LOCAL_HOSTS &redef;\n const notice_zeroaccess_hosts = LOCAL_HOSTS &redef;\n const zeroaccess_timeout = 60 mins &redef;\n global zeroaccess_tracker: set[addr];\n}\nevent signature_match(state: signature_state, msg: string, data: string)\n &priority=-5\n{\n if ( /zeroaccess/ !in state$sig_id ) return;\n if ( state$conn$id$orig_h !in zeroaccess_tracker )\n {\n add zeroaccess_tracker[state$conn$id$orig_h];\n NOTICE([$note=ZeroAccess::ZeroAccess_Client,\n $msg=fmt(\"Probably ZeroAccess P2P Client Access: \"),\n $sub=data,\n $conn=state$conn,\n $identifier=fmt(\"%s%s\", state$conn$id$orig_h,\nstate$conn$id$resp_h)]);\n }\n }Let's now put the Zeek signature and the accompanying Zeek script to the test, as follows.
\nzeek -C -b -r ~/Desktop/PCAPs/ZeroAccess.pcap zeroaccess.zeekYou should now be able to find a notice.log file in the current directory, having the following content.
\nRun -\n
cat notice.log![\"\"](\"https://assets.ine.com/content/threat-hunting-professional/effectively_using_zeek/image21.png\")
Credits to Liam Randall (Critical Stack) for the Zeek script.
\n