T1110-003
Scenario
Adversaries may use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials. Password spraying uses one password (e.g. 'Password01'), or a small list of commonly used passwords, that may match the complexity policy of the domain. Logins are attempted with that password against many different accounts on a network to avoid account lockouts that would normally occur when brute forcing a single account with many passwords.
Typically, management services over commonly used ports are used when password spraying. Commonly targeted services include the following:
SSH (22/TCP)
Telnet (23/TCP)
FTP (21/TCP)
NetBIOS / SMB / Samba (139/TCP & 445/TCP)
LDAP (389/TCP)
Kerberos (88/TCP)
RDP / Terminal Services (3389/TCP)
HTTP/HTTP Management Services (80/TCP & 443/TCP)
MSSQL (1433/TCP)
Oracle (1521/TCP)
MySQL (3306/TCP)
VNC (5900/TCP)
In addition to management services, adversaries may "target single sign-on (SSO) and cloud-based applications utilizing federated authentication protocols," as well as externally facing email applications, such as Office 365
In default environments, LDAP and Kerberos connection attempts are less likely to trigger events over SMB, which creates Windows "logon failure" event ID 4625.
Incident Walkthrough
Before conducting any investigation, we need to gather information about the environment.
I collected details about the hosts, sources, and source types we have.
We can notice that we have:
One host called Windows
One source type: t1110.003
One source: logs.ndjson
.ndjson stands for Newline-Delimited JSON, a format where each line in the file is a separate JSON object. This format is efficient for streaming JSON data and is commonly used in logging and data interchange scenarios.
Based on the scenario provided, we know there's a brute-force alert. I used the following query to retrieve the failed login attempts:
Breakdown:
_time: To see the timestamp of the failed logins.
winlog.event_data.WorkstationName: If a workstation is involved in brute force from the internal network.
winlog.event_data.SubjectUserName: To track brute force attempts for local user accounts.
winlog.event_data.IpAddress: Helps identify network brute force attempts from external or internal sources.
winlog.event_data.TargetUserName: The account the attacker is targeting.
winlog.event_data.LogonType: To determine the logon type (e.g., RDP, console login, etc.)
At first, we saw normal failed login attempts, but we noticed something suspicious: a remote machine within the internal network is attempting to brute-force using Kali Linux from Logon Type 3 (network) in small amount of time, which raised concerns.
Upon investigating more login attempts, we observed that the attacker is brute-forcing passwords for multiple users.
We know the attacker tried to brute-force users, but did he gain access? Which account? When?
I used the following query to check if the attacker successfully accessed any account:
The attacker successfully gained access to the following users:
Administrator
harrashusky
turtledoverecall
infestedmerchant
interjectaerobics
squadronwar
To remotely access the machine, the NTLM authentication seen in the log is commonly used in scenarios where users are attempting to access network resources, often via protocols like:
SMB (Server Message Block) - Used for sharing files, printers, and other network resources. NTLM is often used for authentication when accessing SMB shares.
RDP (Remote Desktop Protocol) - Allows remote access to a desktop over the network, and can also use NTLM for authentication, though Kerberos is more common in domain environments.
To determine which service the attacker used, based on the source type, we can begin by checking the logs generated by those services.
For RDP, Event ID 1149 is generated for successful logons. If the attacker used RDP, the number of 1149 events should match the successful login events (4624) from the attacker's machine
To determine the type of brute-forcing the attacker is performing, we can check the sub-status of the failed login events. We noticed the sub-status 0xC000006A. According to Microsoft, this status code means "User logon with misspelled or bad password", indicating that the account names were correct but the passwords were incorrect.
It's essential to determine when the attacker started the brute-force attack to assess how difficult the password was to guess.
We can do this by using the following query:
Explanation:
*earliest(time): Captures the first failed login attempt during the brute force.
latest(time): Captures the last failed login attempt.
duration: Calculates the difference between the first and last attempt in human-readable format.
count: Provides the total number of failed login attempts for context.
table: Displays the result with the first and last attempt timestamps, the duration, and the count of attempts.
To determine how long the attacker was logged into the machine, we need to check the timestamp of the last brute-force attempt and the timestamp of the first successful login. By calculating the difference between these two timestamps, we can assess the duration of the attacker’s session.
We can implement the account lockout policy to help prevent brute-force attacks on the accounts. This policy temporarily locks an account after a specified number of failed login attempts, making it more difficult for attackers to guess passwords.
I hope you enjoyed :)
Last updated
