24H@CTF - I'm Blue da ba dee da ba di

Challenge Description

I’m Blue da ba dee da ba di was the “blue team” track of the 2022 edition of PolyHx’s 24H@CTF that tooks place on 2022-02-06.

We are placed in a scenario where we must investigate a malware event that occured on february 2nd using the ELK tool.

I never used this tool before, so I was prepared to take quite some time to browse the tool and find what I need to find.

Let’s get started

Flag #1 - Collection/Exfiltration (Query)

The first flag was in fact the SQL query used by the threat actor to get the data that’s been exfiltrated

First things first, let’s set our timeframe :

• Security > Overview > Top Right :
• Click “Update”

Now we can look at the security overview to see some alerts relative to our investigation : imblue5.png

Let’s take a look at the hosts

• Security > Explore > Hosts

We have 3 hosts listed :

• colelktor : 10.0.2.6
• criticaldb01 : 10.0.2.4
• DESKTOP-TJ2UCGM : 10.0.2.5

colelktor is, well.. the elk collector criticaldb is a posgresql server DESKTOP-TJ2UCGM is a Windows workstation

Let’s recap : we are looking for a SQL query that’s been used to get some data from, obviously, a database server. Let’s take a look at the processes on the workstation :

• Security > Explore > Hosts > DESKTOP-TJ2UCGM > Uncommon Processes

Going through the list of processes, there is one that got my attention :

legit_teams_updater.exe. Doesnt sound so legit to me.

Let’s inspect that process

• Click on the “event” tab, and set a filter on the top filter bar then click on refresh:

process.name : "legit_teams_updater.exe"

In the event tab, sort the events on the timestamp column and take a look a the events :

Our so called teams updater actually made connection with our precious criticaldb01, which is suspicious for a software update…

I tried to get more details from the event tab, but I haven’t been able to get any. I decided to create a timeline investigation

• Security > Investigate > Timeline > Create new timeline
• Add process filter like above

We now have a nice chronologic event list about what our process did

Since we’re looking for a SQL query, let’s try to narrow down our list by entering a new filter :

process.name : "legit_teams_updater.exe" and destination.ip : 10.0.2.4

We can’t find any queries yet but we can see that there was a connection to the database server using ssh.

It’s not clear at this point how the credentials for criticaldb01 were known, but we’ll see later.

Let’s see what happened on the server. We’ll focus our attention on the sshd process, which should be the first one on the process tree that we’re looking for. Set the filter to :

process.pid : 20373

and click “Analyze event” on the first one in the list

We have the whole process tree telling us a good story about what happened:

After looking around the tree a lot, I found the process #20439, lessecho, which is called by psql. Process info shows the query :

The query was : select * from credit_infos

Flag #2 - Collection/Exfiltration (User)

The flag #2 was the username that was used to do the query. We already have the answer in the lessecho process in the field user.name : that_db_guy

Flag #3 - Lateral Movement

For this one we had to find the ip and hostname of the machine that’s been used for lateral movement.

From our work on flag #1, we already know the answer : 10.0.2.4/criticaldb01

Flag #4 - Credential Access (Bonus)

The question for flag #4 was the name of the file containing the credentials for criticaldb01. To find this one, I tried to add some filters before the initial ssh connection, to pin point the file. I ended up with this filter :

process.name : "legit_teams_updater.exe" and destination.ip : 10.0.2.4 or (event.category : file and file.name : *pass*)

The filename was : mes_petits_mots_de_passe.txt.txt

Flag #5

For this one, we had to find the PID of the process that ran a port scan. We had a starting filter to start our research :

event.category : network and event.action : connection_attempted

Around 18:14:00, we can see multiple connection attempts on criticaldb01 :

Those connection attempts were done by our not so legit legit_teams_updater.exe.

The answer was : 1832

Flag #6 - Persistence

For flag #6, we had to find the registry key that was used to establish persistence.

Knowing how to autorun programs on startup using the registry, I know that the registry path must contains the word “Run”. Let’s try this filter :

event.category : registry and event.action : modification and registry.path : *Run* and user.name : Employee46

Bingo! :

The answer was : HKEY_USERS\S-1-5-21-2139450840-2415775787-1042386588-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\legit_teams_updater

Flag #7 - Initial Access/Execution

For the last flag, we had to find the malicious file that was originally downloaded by the user.

Again, I tried a couple filter to finish with this one :

event.category : file and event.action : creation and file.path : *Downloads*

The answer was : teams_update.zip

Conclusion

I had a lot of fun doing this track. Like I said, I neved used ELK before so it was a good thing to learn something new.

My guess on the events:

• User download malicious team updater and executes it
• Malicious updater download a Metasploit Payload
• Threat actor establish foothold and persistence
• Threat actor finds the credential file
• Threat actor move laterally to criticaldb01
• Threat actor do some enumeration on the server
• Threat actor find database and get sensitive data from it
• Threat actor exfiltrate the data with curl to a controlled endpoint

Since we could not save our timeline within the tool, I did my own to help me during the investigation: