# 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: ``` index="t1110-003" "event.code"=4625 | sort _time | table _time, winlog.event_data.WorkstationName, inlog.event_data.SubjectUserName, winlog.event_data.IpAddress, winlog.event_data.TargetUserName, winlog.event_data.LogonType ``` 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: ``` index="t1110-003" "event.code"=4624 "winlog.event_data.WorkstationName"=kali | sort - _time | table _time, winlog.event_data.WorkstationName, winlog.event_data.IpAddress, winlog.event_data.TargetUserName, winlog.event_data.LogonType ```

The attacker successfully gained access to the following users: * **Administrator** * **harrashusky** * **turtledoverecall** * **infestedmerchant** * **interjectaerobics** * **squadronwar** ``` Q1- Who was the last logged-in user? Answer: Administrator ``` ``` Q2- What is the logon type of the failed logons? Answer: 3 ``` ``` Q4- How many users did the attacker succeed in getting their accounts? Answer: 6 ``` 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: 1. **SMB (Server Message Block)** - Used for sharing files, printers, and other network resources. NTLM is often used for authentication when accessing SMB shares. 2. **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

``` Q3- What is the protocol the attacker tried to bruteforce? Answer: RDP ``` 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.

``` Q5- According to Microsoft. What is the description of the "Sub Status" code for event id 4625? Answer: User logon with misspelled or bad password ``` 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: ``` index="t1110-003" event.code=4625 winlog.event_data.WorkstationName="kali" | sort _time | stats earliest(_time) as first_attempt latest(_time) as last_attempt count by winlog.event_data.WorkstationName | eval duration=tostring(last_attempt - first_attempt, "duration") | table first_attempt, last_attempt, duration, count ``` 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.

``` Q6- How long did the bruteforce last? MM:SS Answer: 05:48 ``` 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.

``` Q7- After How long did the attacker login to the machine again? MM:SS Answer: 11:12 ``` 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.

``` Q8- What is the name of the policy used to lock the account after a certain number of failed login attempts? Answer: Account Lockout ``` I hope you enjoyed :) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://h05am10.gitbook.io/h05am10/write-ups/cyberdefenders/threat-hunting/t1110-003.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.