In this article, we review in further detail the authentication and privileged user account activities and techniques that are used to detect various anomalies.
Authentication and privileged user account activities
Here, we need to keep in mind that while traversing the network, the Cyber attacker never tries to identify and exploit the vulnerabilities in every system to get shell access. Instead, they make use of legitimate credentials to log in to these systems. They use various techniques and tools to extract or dump the credentials for privileged accounts. Detecting the suspicious authentication activities early in the attack life cycle is very important to stop the lateral movement of the targeted attacks. We can keep track of the unauthorized activities being done with the use of privileged user accounts (domain or local administrator accounts). The Cyber attacker tends to target domain accounts rather than local privileged users accounts, since because they have access to the entire network to perform privileged activities. The Cyber attacker gains access to these accounts by using one of the following techniques:
Vulnerabilities in the domain controller or active directory; Password hashes from the local system.
So, how do we identify if an adversary has gained access to or trying to connect with any of the systems in the network? Here, again the windows security event logs become of use, as they keep track of all the authentication related activities. In the case of the active directory infrastructure, you may need to configure the audit policy at domain controller level. Following are some of the important Event IDs we can monitor:
4624: An account was successfully logged on; 4625: An account failed to log on; 4627: Group membership information; 4648: A logon was attempted using explicit credentials; 4672: Special privileges assigned to new logon.
Additional Event IDs across various windows versions
529: Unknown username or password 530: Logon Failure – Account logon time restriction violation 531: Account currently disabled 532: User account has expired 533: User not allowed to logon to the computer 534: User has not been granted the requested logon type 535: The account’s password has expired 536: The NetLogon component is not active 537: The logon attempt failed for other reasons 539: Account lockout 4768: Kerberos Authentication 4776: Kerberos Service Ticket 1102: The audit log was cleared
This is in not a comprehensive list, but rather these are the critical events which you can include in your monitoring and analysis. We will be focusing on some of the vital Event IDs listed above, for the authentication activities used in lateral movement detection analysis. Some of these events are disabled by default in windows systems, so we must enable these events from the audit policy as illustrated in below screenshot:
Logon types
Before going to the Event IDs, we need to review the logon types which are encountered in every Event ID that is generated against authentication activity. This is a handy piece of information as it tells you HOW the user logged on or is trying to logon to the system. The table below is taken from ultimatewindowssecurity.com.
Event ID 4624: An account was successfully logged on
The Windows log Event ID 4624 occurs when there is a successful logon to the system with one of the login types previously described. Windows keeps track of each successful logon activity against this Event ID regardless of the account type, location or logon type. The illustration below shows the information that is logged under this Event ID:
The Subject section in this event does not provide any significant information so that it can be ignored. Some of the important fields that help us to analyze the authentication activities are described below: Logon type: This field provides information about how the user has logged into the system, which is very useful while identifying anomalies. In the above illustration, we can see that the logon type is 2, this means that user has logged on to the system locally. Security ID: This is the SID of the account that has logged on to the system. Account Name: This is the account name in which the user has logged on to the system, and as we can see in the above screenshot, the account name is “Suresh Khutale“. Account Domain: This is the domain name to which the account belongs to, for domain systems it would be the corresponding domain name. Logon GUID: The GUID helps correlate the authentication on the computer with the corresponding authentication events on the domain controller. Workstation Name: This is the workstation name where the user is logged on. Source Network Address: This is the IP address of the system from which the user has logged on to the target system. If the logon was initiated locally, sometimes the IP address will be 127.0.0.1 instead of the actual IP address. By looking at the fields in the screenshot up above we can then develop the scenarios and fine tune the rule set to monitor the suspicious activities. It is important to:
Look for instances where multiple users are logged onto an end-user workstation simultaneously within a relatively short period of time; Where the same user account is logged onto more than one host; Where a network login references a non-domain account on the target system.
It is important to keep track of the total number of administrative attempts and to analyze these activities to look for any deviations such as:
The total number of attempts; The accounts involved in the attempts or the computers on which they occur.
As we had discussed earlier about the logon types which provide significant piece of information, we can track down any anomalies with help of these events and detect lateral movement across the network.
Event ID 4625: An account failed to log on
Windows keeps track of the account log on failed activities under Event ID 4625. It provides useful information about each failed logon attempt happening on the system. The following illustration displays the important fields in the Event ID 4625:
Some of the fields in the above screenshot are common to that of Event ID 4624. The Failure information section provides significant information about the account logon failure event. The table below shows the description of the failure status, and is derived from the following source: ultimatewindowssecurity.com We can now look for the consecutive failed login failed attempts Event IDs 4625 followed by the successful logon onto the system Event ID 4624. This will give an insight of any malicious activity happening on the remote system.
4627: Group membership information
This is the new Event ID introduced by Microsoft in the latest versions of the windows systems. It documents the group membership of all the nested groups where the user belongs. This Event ID is disabled in windows by default. Thus, we must enable the “Audit Group policy” and the “Audit Logon” features in the windows audit policy. The illustration below shows the information documented under this Event ID:
We can see that except for the Group Membership section, all the other fields are common to the other security events previously described. The account name is the one with which the user has logged onto recently corresponding to Event ID 4624. Group Membership: This section documents all the groups to which the user belonged to at the time of logon, specifically the following:
The Local and Domain groups to which the user belongs; The Users with special rights; All the groups and the Nested group membership.
Here, the account name “Suresh Khutale” has been used to logon to the system, is a member of various groups such as “Administrators” highlighted in the above screenshot. As we know that when the Cyber attacker launches credential artifact attacks, they often end up using privileged accounts to logon. By correlating Event ID 4627 with Event ID 4624, we might see some interesting facts such as the logon to the normal system with a privileged account. With the help of Event ID 4627, we can now fine tune our rule set and visualize on suspicious activities. For example, if the logged-on account belongs to one of the privileged groups such as Domain_Administators or Administrators, this would raise serious concern.
4648: A logon was attempted using explicit credentials
This is a very useful event for tracking several privileged activities by providing a separate set of credentials explicitly. Windows logs this Event ID whenever the user tries to run the program locally by using alternate credentials. A classic example of Event ID 4648 is when the user maps a shared drive of the remote server by specifying somebody else’s credentials. To demonstrate this, I have created a local user “test” with administrators group privileges. I will start a program called Chrome.exe to run as a different user. This is demonstrated in the screenshot below:
Upon the successful logon of the above credentials, windows will log the Event ID 4648. The screenshot below shows the information that is logged under Event ID 4648 for the above explicit logon activity.
As we can see in the above screenshot, the account named “test” is being used to login explicitly. The process name DpHostW.exe is the file that is associated with HP ProtectTools Security Manager. Also, by looking at the Event ID 4638 we can gather more information, such as the of the individual whom has initiated this activity. Whenever Event ID 4648 is logged, it will be followed with the Event ID 4624 and 4627. The screenshot below shows the details that are logged for these events against 4648 event ID for user “test.”
We will now look for the exact process which was started with the explicit credentials. It was Chrome.exe. We will see Event ID 4688 followed by Event ID 4648, as demonstrated in the screenshot below:
We will now briefly review some of the common tools that the Cyber attacker makes use of. They very often move these tools to an administrative share such as (ADMIN$, IPC$, C$). To view them, we can use event ID 5145. PsExec.exe: This was developed by Sysinternals. It has the ability perform administrative activities such as upload, execute and interact with an executable on a remote host. This program can be used from command line scripts, and antivirus software will not flag it. The Cyber attacker uses this program specifically to avoid detection. We can also look for instances of PsExec.exe execution by probing the event logs and stack the audit logs against Event ID 5145. PowerShell.exe: This is Microsoft’s object-oriented scripting program; all the latest versions of windows have this. It is a very powerful tool, and the Cyber attacker often uses it to capture in-memory credentials, modify configurations, and move laterally from one system to the next. By looking at Event ID 4688 (Discussed in Part I), one can identify spawned process security logs and analyze the legitimacy of the PowerShell call. PowerShell Auditing is another way to detect malicious PowerShell activities (Read more here). WMI and WinRM: The Windows Management Instrumentation is also a built-in program in windows. It is a spawned process of the WMI, and it can be used to:
Start remote processes; Query system information; Store persistent malware that does not touch the disk in a traditional sense.
The Cyber attacker makes use of WinRM to enumerate system intelligence to identify targets to hit. At Jobs: Similar to the WMI, At jobs are used to schedule and start a process on a remote system with local administrative rights. The Cyber attacker uses this program to remotely execute scripts, launch tools, delete tools that have been executed, etc. via the task scheduler. This also comes with the TaskScheduler/Operational event logs feature that can be used to detect suspicious At jobs remotely. Remote Desktop (RDP): The Remote Desktop is used to connect to a remote system without interrupting a user’s session. RDP connections can easily be detected by the Cyber attacker. Common password hash dumping tools: Below are some of the well-known tools and scripts that are used by the Cyber attacker to dump the password hash, authorization tokens, etc.:
Mimikatz (steal password hash/pass the hash method) Mimikatz (steal ticket/pass the ticket method) Windows Credentials Editor (WCE) PWDump7 PWDumpX Quarks PwDump
Conclusion
The detection of lateral movement is as important as thwarting a security breach. As we discussed, the Cyber attacker frequently moves laterally with the help of legitimate administrative tools available in Windows based systems. The Cyber attacker could use lateral movement for many purposes, including the following:
Remote execution of tools; Pivoting to additional systems; Access to specific information or files; Access to additional credentials.
These kinds of threats can be mitigated by focusing proactively by making use of the security auditing capabilities in windows systems.
Sources
Threathunting Hunting lateral movement Lateral movement Detecting lateral movement through event logs Lateral movement – Trendmicro Research – JPcert Top 20 lateral movement tactics Lateral movement detection Lateral Movement – Mitre Advanced persistent threat APT Ransomware analysis How to secure your system from risks that malware pose RAT remote access Privileged access station Security log Investigating powershell command and script logging
