Defbox Vulnerable SSH Write-up

Mikhail Aksenov

An SSH-setup with a password-based authentication. Common ssh passwords will be brute-forced in a matter of hours if exposed. Detect SSH password bruteforce

Lab descriptions tells us that SSH will be brute forced. Info about SSH and how it can be bruteforced can be found here:

https://en.wikipedia.org/wiki/SSH
https://www.geeksforgeeks.org/how-to-use-hydra-to-brute-force-ssh-connections/

Defbox asks us to find highlights when lab is deployed. What are the highlights for this lab?

SSH Config file location
User that was bruteforced

Let's try to guess the ssh config file location. What if we use the answer from google?

It works!

To find out the bruteforced user account we have to start the bruteforce. I will take a look at logs before I trigger the attack:

We need the discover tab in elastic. To better understand what are the logs collected I look into data views in elastic. The dataviews contain logs from auditbeat and filebeat

I'm looking at filebeat and auditbeat data views. If you don't know what these are I suggest you first take a look into these links:

Auditbeat collects data from the operating system. We can use it to see network connections, authentication attempts and various syscalls.

Filebeat is parsing files. Files may contain even more useful information than auditbeat because it is being collected on a higher level. It can be illustrated pretty well with our SSH case:

Most of auditbeat docs don't even contain the message field

Filebeat message is always presented and more informative

Now I start the attack

There is only one attack in the SSH Bruteforce lab

After 5 minutes events appear in the timeline. Red dots mean attackers actions and blue dots mean certain MITRE ATTACK phase

More info on MITRE ATTACK can be found here - https://www.blackberry.com/us/en/solutions/endpoint-security/mitre-attack/mitre-attack-vs-cyber-kill-chain

The SSH Bruteforce attack has 4 attack events. We do provide points based on when you detected the attack. 1300 points if detected after Initial Access. 300 points if after Impact

Let's find the attack in the logs now. I know 2 ways of doing that

Auditbeat authentication logs:

We see spikes after 15.33. Look at the left upper corner - event.category is the filter we use to filter out authentication attempts

Second option is filebeat /var/log/auth.log

Filebeat authentication logs also have spikes after 15.33 , but filter is different

We can now identify the bruteforced account to enter the highlight:

The last step is to create a rule. Defbox asks us to set up elastic so that elastic will send a post request to the URL specified in the Information section of the lab page:

To create a rule you have to go to the Security->Manage->Rules. First you have to create a query to identify bruteforce. One of the queries can be that one - log.file.path: "/var/log/auth.log" and message : "*Failed password*". In the gif above I create a rule that trigger alert if the query has more than 100 matching documents . I also create a webhook integration to send POST request from elastic to defbox

To see if rule has worked I go back to defbox and look into timeline. Yellow dot should appear:

Now I finished this lab. I showed how to get the bare minimum which is 300 points. To gain more points you have to do something to get the rule fire earlier. I suggest you do it on your own.

Defbox can recreate lab. If you click the recreate button the lab will be recreated, but elastic won't. It means that all the rules you created in the elastic will stay. The only thing you should remember is that POST URL is new every time you recreate the lab. So for the old rules to work you have to change the POST URL in your webhook integration

I hope this guide was helpful to you and you will try your best at other defbox labs : )

Defbox Vulnerable SSH Write-up

Report Page