Splunk Corelight CTF Walkthrough - Part 1

EDIT: You can find the second part here

Today I’m here with a walkthrough of the threathunting CTF offered by Splunk on its BOTS site. You can register for free and although it has a limit to play it of 3 hours, you can replay it as many times as you like.

If you are familiar with the BOTS CTFs published by Splunk in previous years, you be familiar with the format, if not, is very easy, you have a series of questions and you have to find the answer on the logs using Splunk. This one can be played completely online, you just login to the Splunk instance provided.

The level of the CTF if you are experienced in other editions of BOTS or in threathunting, I’d say is low/very low; if you are completely new to Splunk or a beginner, then is a very good first contact with Splunk and threathunting.

SPOILER ALERT: I INCLUDE ALL THE ANSWERS TO THE CTF, BUT HIDDEN, SO YOU HAVE TO CLICK TO SEE IT, IN CASE YOU WANT TO PLAY ALONG

Once you login, you see the 3 CTFs available on BOTS Splunk.

I’ll go through the questions one by one, numbered in the same way as in the scenarios. Click on Play Now on the Corelight one, then open in a second tab the Splunk server in the resources section - you have the credentials there as well.

Once you login, go to the Apps menu on the top and click on the Search & Reporting App.

And now, let’s play!

Scenario 1 Corelight Zeek and Suricata CTF

Important: use for this scenario the index “corelight”

101. How many total Suricata alerts were generated in this index?

     First find all sourcetypes ordered by count:

        `| metadata index="corelight" type=sourcetypes | sort - totalCount`
     

     We see 2 related to Suricata, and one with all the alert fields: corelight_suricata_corelight

     Search for that sourcetype:

        `index="corelight" sourcetype="corelight_suricata_corelight"`
     

     And we get the number of events.

     

	47

102. Most of the alerts are being generated by a single source host. What is its IP address?

     We count by field src:

       index="corelight" sourcetype="corelight_suricata_corelight" | stats count by src
     

	10.0.0.31

103. What’s the name of the malware family identified by these alerts?

     Looking at the events at field alert.signature, there is one that is obvious:

     index="corelight" sourcetype="corelight_suricata_corelight" "alert.signature"="ET MALWARE Win32/Trickbot Data Exfiltration"
     

		trickbot

104. Let’s take a closer look at the “ET MALWARE Win32/Trickbot Data Exfiltration” alerts. You’ll notice that three of the alerts share a single UID, meaning they all occurred on a single TCP stream. What is that UID?

     We count by uid field:

        index="corelight" sourcetype="corelight_suricata_corelight" "alert.signature"="ET MALWARE Win32/Trickbot Data Exfiltration" | stats count by uid
     

     And there is one with 3 events.

	CAoNRI62m9CRqS0R2

105. What is the IP address of the malicious server involved in the alerts for this stream?

     We use the UID from previous question to filter our search:

        index="corelight" sourcetype="corelight_suricata_corelight" "alert.signature"="ET MALWARE Win32/Trickbot Data Exfiltration" uid=CAoNRI62m9CRqS0R2 | table src, dest
     

     And the destination IP is the malicious server, as this is an alert about exfiltration activity.

	103.16.104.83

106. What layer 7 protocol is the traffic in the previous question flowing over that generates the alerts?

     In previous search, looking at fields like app and dest_port (443), the answer is clear.

	http

107. Taking the UID mentioned in the previous question and searching for it across the index, we see that a corelight_notice log was also generated. What is the number of the MITRE ATT&CK TTP referenced in the notice?

     We just follow the instructions in the question:

        index="corelight" uid=CAoNRI62m9CRqS0R2 sourcetype=corelight_notice
     

     Get a single event. In the field msg:

        msg: Potential C2 traffic - Trickbot Malware https://attack.mitre.org/software/S0266/. This detection is based on attributes within the http connection, further details can be found in http.log and conn.log - the relevant log lines will share the same uid as this notice. (Algorithm 1)
     

     

	S0266

108. What User-Agent string was sent as part of the Trickbot HTTP requests?

     We continue filtering by the UID we have and look at sourcetype corelight_http

        index="corelight" uid=CAoNRI62m9CRqS0R2 sourcetype=corelight_http
     

     Look at field ** http_user_agent**.

	Ghost

109. What is a process name that is repeated within the POST body of these HTTP requests?

     Just have to look at the contents of the field post_body in previous search. I was confused at first about what the question is asking for. It means which process appears several times within the body.

	svchost.exe

110. Let’s look at what happened after the malware was dropped. Looking at Suricata alerts following the Trickbot alert, a popular scanning tool appears to have been used for reconnaissance. What is the name of that tool?

     We set the time for 5 minutes after the events with the trickbot signature:

     Then show values for signatures after that:

        index="corelight" sourcetype="corelight_suricata_corelight" | stats values(alert.signature)
     

     And we see the answer in one of the signatures.

	nessus

111. One of the alerts generated by our infected host could result in command execution on a wireless access point. Looking at the response from the remote system, however, it’s pretty clear that the attack failed. How many bytes did the target send back to the attacker on this connection?

     First let’s find the alert mentioned using the previous search:

        index="corelight" sourcetype="corelight_suricata_corelight" | stats values(alert.signature)
     

     

     We see a signature ETPRO Exploit Possible Asus WRT LAN Backdoor Command Execution Search the event:

        index="corelight" sourcetype="corelight_suricata_corelight" "ETPRO Exploit Possible Asus WRT LAN Backdoor Command Execution"
     

     We get the UID from the event C1k4ed3UCQLkshoMZh and search in the sourcetype corelight_conn

        index="corelight" C1k4ed3UCQLkshoMZh sourcetype=corelight_conn
     

     We get 1 event, and in the field resp_ip_bytes we have the answer.

	0

112. Looking at the layer 7 services used by the infected host after the Trickbot alerts above, we see an SSH connection made to an internal host. What is the IP address of that host?

     We know the IP from previous searches: 10.0.0.31. We know it’s ssh, so we can focus on sourcetype corelight_ssh:

        index="corelight" src=10.0.0.31 sourcetype=corelight_ssh
     

     We get 23 events, with several internal IP as destination, but there is a field auth_success, filter by that:

        index="corelight" src=10.0.0.31 sourcetype=corelight_ssh auth_success=true | table dest
     

     

	10.0.0.72

113. What is the PCR (producer/consumer ratio) of that SSH session?

     What is PCR:

     		( SrcApplicationBytes - DstApplicationBytes )
        PCR = 	---------------------------------------------
          		( SrcApplicationBytes + DstApplicationBytes )
     

     We get the connection UID CLn5mqsd7SVfTn10g, and check the sourcetype corelight_conn:

        index="corelight" CLn5mqsd7SVfTn10g sourcetype=corelight_conn
     

     Helpfully, there is a pcr field in this sourcetype ** pcr: -0.9959339475461754**

	-0.99593

114. Examining the inferences section of the SSH log associated with that session, one code indicates a behavior that explains the PCR we just observed. Which code is it?

     If we go back to the event in sourcetype corelight_ssh, there is a field called InferenceName. There are 3 different inferences, the one probably causing the PCR is the Large File Download.

     

     The field inferences has the codes

	LFD

115. The owner of the infected workstation had no credentials to log into 10.0.0.72 over SSH. However, there was another connection between those hosts over HTTP. What attack type was sent over that connection?

     We search connections between those 2 hosts and relate to HTTP:

        index="corelight" src=10.0.0.31 dest=10.0.0.72 sourcetype=corelight_http
     

     We look at the values of the field uri for hints:

        index="corelight" src=10.0.0.31 dest=10.0.0.72 sourcetype=corelight_http | stats values(uri)
     

     And we see what it looks like SQLi attacks:

        /mutillidae/index.php?page=user-info.php&username=admin'+or+1=1+#&password=adfadf&user-info-php-submit-button=View+Account+Details
     

	SQL Injection

116. What parameter of the index.php script did the infected system attempt to use for SQL injection?

     Looking at the URI field of previous question, we see the parameter after the &:

        page=user-info.php&username=admin
     

	username

117. What was the HTTP status code from the targeted server?

     From the previous event, field status_code

	200

118. Did this SQL injection attack generate any Suricata alerts? (Yes/No)

     Select a time range of -+ 5 seconds around the SQL injection, and look for Suricata alerts.

	NO

119. Returning to SSH connections made by our infected host, we see a second one being made to a country the organization has no business relationship with. What country is that connection going to?

     We reuse the search from question 112:

        index="corelight" src=10.0.0.31 sourcetype=corelight_ssh auth_success=true
     

     There is a field remote_location.country_code with the 2 letter code for the country.

	Thailand

120. Judging by the PCR (producer/consumer ratio) of this connection, data was definitely exfiltrated to this external system. What is the SSH host key of that system?

     The answer is also in the same event, in a field called host_key

	1c:6e:58:a2:57:98:33:f4:53:e8:63:46:df:a2:31:ef

121. How many payload bytes were sent over that connection?

     We search for the UID of the connection: CPxHxI3uiHLgH2I196:

        index="corelight" CPxHxI3uiHLgH2I196 sourcetype=corelight_conn
     

     We get one event, and the question asks for bytes sent, so the field bytes_out should have the answer.

	128105745

122. The challenge author’s favorite SSL certificate organization name - a default out of many certificate generation tools - is present in this index, highlighted by a Suricata alert. What is that organization name?

     We start by looking at all Suricata alerts and filter signature:

        index="corelight" sourcetype="corelight_suricata_corelight"  | stats values(alert.signature)
     

     We see a couple of them related to TLS and certificates:

        ET POLICY OpenSSL Demo CA - Internet Widgits Pty (O)
        ET POLICY Signed TLS Certificate with md5WithRSAEncryption
     

     From the question I assume it’s the first alert “ET POLICY OpenSSL Demo CA - Internet Widgits Pty (O)”, we take the UID CxAsok2xLkCyAoxiy6 and look at sourcetype corelight_ssl:

        index="corelight" CxAsok2xLkCyAoxiy6 sourcetype=corelight_ssl
     

     There is a field ssl_issuer with all the details.

     

	Internet Widgits Pty Ltd

First Scenario finished

And this was the last question for the first scenario; to no make this too long will leave the second scenario walkthrough for a new post. I hope you found this useful and see you soon!

EDIT: You can find the second part here

See also

• Splunk Corelight CTF Walkthrough - Part 2