Brutus HTB Sherlock Challenge

Mar 23, 2025    #wtmp   #linux   #utmp   #sherlock   #auth.log   #defensive   #forensics  

Brutus Hack The Box Sherlock Challenge Writeup:

Challenge Information:

Challenge Files:

Introduction

In this writeup, we’ll investigate a security incident on a Confluence server that was compromised through its SSH service. We’ll analyze two critical log files - auth.log and wtmp - to reconstruct the attack timeline and understand the attacker’s actions.

What You’ll Learn

Investigation Overview

Our analysis will follow this structured approach:

  1. Examining wtmp records to identify suspicious logins
  2. Analyzing auth.log entries to confirm the breach
  3. Reconstructing the attacker’s actions post-compromise
  4. Drawing conclusions and security lessons

Analysis:

wtmp analysis:

We are provided a wtmp file but what is a wtmp file & what is it used for?

What Is A wtmp File?

If we check the man pages using

wtmp man

We get the following paragraph

The wtmp file records all logins and logouts. Its format is exactly like utmp except that a null username indicates a logout on the associated terminal. Furthermore, the terminal name ~ with username shutdown or reboot indicates a system shutdown or reboot and the pair of terminal names |/} logs the old/new system time when date(1) changes it. wtmp is maintained by login(1), init(1), and some versions of getty(8) (e.g., mingetty(8) or agetty(8)). None of these programs creates the file, so if it is removed, record-keeping is turned off.

wtmp file type:

The wtmp is a binary file which means if we try to cat it out it will not work, see below.

It is possible to open it in a text editor but there is a lot of noise due to it being a binary.

Luckily thought there is an easy way to get information from this file and filter out all the noise.

wtmp strings Analysis:

As we are dealing with binary data the easiest way to get information is to run strings on the file. However if we just ring strings as is it will give us a lot of output & duplicate entries, luckily though we can refine our search further by piping the output into sort so that it will sort all lines alphabetically bringing duplicates together & then once the duplicates are together we can further refine the results by removing using uniq so we are left with just the unique strings.

martin in content-org/Walkthroughs/HTB/Sherlocks/Brutus  🍣 main 📝 ×204🛤️  ×5 10GiB/31GiB | 0B/34GiB on ☁️  (eu-west-2) with /usr/bin/zsh
🕙 17:18:58 zsh ❯ strings files/wtmp | sort | uniq -i
203.101.190.9
6.2.0-1017-aws
6.2.0-1018-aws
65.2.161.68
pts/0
pts/1
reboot
runlevel
shutdown
ts/0root
ts/0ubuntu
ts/1cyberjunkie
ts/1root
tty1
tty1LOGIN
ttyS0
tyS0
tyS0LOGIN

We have some interesting things here, so let’s analyze further.

Analysis out of output:

System event entries:
Kernel version entries:

Summary of wtmp file findings.

We can now see that the wtmp file is showing a history of:

auth.log analysis:

We are also provided an auth.log file, but what is the auth.log file for?

What is auth.log?

If we check for documentation for the auth.log file, we find that it’s not described in man pages in the same way as wtmp, as it’s primarily a syslog facility rather than a specific file format. The auth.log file is typically located at /var/log/auth.log on Debian-based systems like Ubuntu, while on Red Hat-based systems, authentication messages are logged to /var/log/secure.

When investigating a breach, we as security professionals typically examine auth.log for:

This file is automatically maintained by the system’s syslog daemon, so there’s no need to create it manually. However, log rotation policies might archive older logs, so we may need to check both the current file and any archived versions during a forensic investigation.

auth.log file type:

This one is pretty self explanatory as it’s a .log file, but we can run the file command on the file to explain what this is. We can see it’s ascii text so we can open this in a standard text editor like, emacs, vim, nano, etc.

auth.log Analysis:

If we run head -n 20 auth.log to view the first 20 lines of the file we can see a number of things. (I will break this down into chunks for ease)

Summary of findings so far:

I think it’s important to point out we have only looked at 20 lines of this 385 line file and we have already uncovered the below findings.

Discovering evidence of a brute-force attack in auth.log:

As this file is 385 lines, we can speed up this investigation process by filtering out any information we deem legitimate.

🕙 12:19:11 zsh ❯ wc -l auth.log
385 auth.log

🕙 12:32:28 zsh ❯ cat auth.log | grep -v "user confluence" | wc -l
287

As you can see if we remove all lines that have the word “confluence” in them we can reduce the log by 98 lines.

Lets save this filtered file with no confluence entries to a new file for ease.

🕙 12:32:33 zsh ❯ cat auth.log | grep -v "user confluence" >> auth_noConfluence.log

Lets look at this filtered information now:

head -n 20 auth_noConfluence.log

Now that we have a source IP we can further refine our filtering, we also know from earlier that the word “accepted” is used when an ssh connection is established via password authentication, so lets filter for that.

cat auth_noConfluence.log | grep -Ie "65.2.161.68" | grep -ie "accepted" | wc -l
3

Now we can see we are down to 3 results. Let’s check these.

Establishing Initial Breach Time of 6:31:40:

Investigating the successful root login at 6:31:40

If we filter for that specific time we get a larger view of what was happening at the time.

As we can see all of this happened at the same time 06:31:40. At the top is the successful authorization login to the root account from the ip 65.2.161.68 however we can see further brute force attempts for the user names server_adm & svc_account this is most likely due to having concurrent threads running when attacking and the successful login not stopping the process.

Findings:

Establishing Time Of Malicious User & Group Creation 06:32:44:

As we saw there was a subsequent successful root login at 06:32:44 which we should also investigate.

As this is, what I believe to be a manual login, I am going to filter the results to show an additional 10 lines of information

cat auth_noConfluence.log | grep "06:32:44" -A 11

+Important Note+:

Enumerating further action take by cyberjunkie

Now we know that the hacker has made a user account called cyberjunkie we can filter for all lines matching that.

Attack Timeline:

To tie everthing together here is an overview of the key points of the attack.

Time (UTC) Event Details
06:31:31 Brute Force Begins Multiple failed login attempts from
65.2.161.68 using username “admin”
06:31:40 Initial Breach Successful root login via SSH from
65.2.161.68 (Session 34)
06:32:44 Secondary Access Second root login from same IP
06:34:18 Persistence Setup Creation of “cyberjunkie” group
06:34:18-19 User Creation “cyberjunkie” user created and
added to sudo group
Post-06:34 Post-Exploitation - Reading /etc/shadow
- Downloading linper.sh persistence tool

Key Findings From This Investigation:

  1. Attack Pattern Analysis:

    • Initial compromise through SSH brute force
    • Quick transition to persistence (< 3 minutes)
    • Use of automated tools for maintaining access
    • Classic privilege escalation through root access

  2. System Vulnerabilities Identified:

    • Root SSH access enabled
    • Password authentication allowed
    • No brute force protection
    • Weak access controls

Further Technical Information:

This is some additional information for users who want it, I find it helpful to add this information to provide further context and paint a larger picture.

PAM (Pluggable Authentication Modules):

Root SSH Access Risks:

Root SSH access is particularly dangerous because of the following:

  1. It bypasses the principle of least privilege
  2. No audit trail of privilege escalation (sudo usage)
  3. Single point of failure - if root password is compromised, the whole system is compromised.
  4. No individual accountability when multiple admins have access (each user should have their own key)

linper.sh tool:

The attacker downloaded linper.sh, a Linux persistence toolkit that can do the following.

This tool’s presence indicates the attacker’s intent to maintain long-term access, which means further analysis has to be taken, this is not a case of removing access, changing passwords etc.

Security Recommendations:

So we know what the attacker did, but how do we now prevent attacks & attack paths like the one above?

SSH Hardening:

First of all, we should disallow the use of root login, especially with passwords. We can modify the /etc/ssh/sshd_config file to do so.

# Key SSH configuration changes (/etc/ssh/sshd_config):
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
LoginGraceTime 60

Access Control Best Practices:

  1. User Management:

    • Require individual accounts for all users, again users should NOT be using the sudo account.
    • Implement strong password policies, use a password manager to store these (they should so complex that even if you wanted to remember them you couldn’t.)
    • Regular audit of user accounts and permissions.

  2. Sudo Configuration:

    • Configure granular sudo permissions, if a user/system account does need sudo permissions to run a binary grant them that specific permission only.
    • Enable sudo logging
    • Require password for sudo access.
       # /etc/sudoers.d/logging
   Defaults log_output
   Defaults!/usr/bin/sudoreplay !log_output
   Defaults!/sbin/reboot !log_output

  3. System Monitoring:

    • Configure remote logging
    • Use SIEM solutions for log analysis, this way there should be notifications in events like this.

Log Monitoring Setup

Lessons Learned:

Technical Lessons:

+Remember+: Security is a continuous process, not a one-time setup. Regular reviews and updates of security measures are essential for maintaining system integrity, you often can’t just “set and forget”, defenders need to be right 100% of the time, attackers only need to be right once to get a foothold.

What did I learn?

  1. That by correlating the wtmp & auth.log files we gain a greater understanding of attacks and sudo uses.
  2. How dangerous, root login with weak passwords & no rate limiting can be.

What mistakes did I make?

  1. None this time, but I’m sure I will make plenty of silly mistakes in the future.

Sign off:

Remember, folks as always: with great power comes great responsibility. Use this knowledge wisely, and always stay on the right side of the law!

Until next time, hack the planet!

– Bloodstiller

– Get in touch bloodstiller at bloodstiller dot com

Resources for Further Learning: