How to Steal Windows Credentials with Mimikatz and Metasploit

Welcome back my fellow hackers! Today we’re going to be deviating from our antivirus evading escapades to discuss a tool that I’ve recently started using, Mimikatz. Mimikatz is a tool to automate many Windows hacking tactics. The capabilities of mimikatz stretch much further than a single article, so today we’re going to be focusing on a basic function of mimikatz, stealing Windows credentials straight from memory. Lucky for us, Rapid7 has included mimikatz into Metasploit, which makes it very easy to use.

In our exercise today, we’re going to be compromising a Windows 7 VM and using Mimikatz within Metasploit to steal the password of the user that’s logged into our VM. So, let’s get started!

Step 1: Generate Payload and Set up Handler

First things first, we need to generate a payload to execute on our victim machine. For this we’ll be using msfvenom to generate a meterpreter payload in the form of an EXE file. Once we’ve generated our payload, we can move it to /var/www/html on our Kali VM and use the command service apache2 start in order to start a web server to serve our payload to the victim (note: I’ll be generating the payload within the aforementioned directory):

Now that we’ve got our payload, we can move on to setting up our handler. The handler will catch the connection made by the payload on the victim machine. Once we catch the connection, we should be yielded a meterpreter. In order to set up the handler, we use multi/handler from within the msfconsole:

Note: The LHOST and LPORT values are the same between the payload we generated and our handler. LHOST should be the local IP address of your attacking machine, and LPORT should be the port to listen on/connect back to. These values must be the same between the payload and handler, or else we won’t be able to catch the connect back.

Step 2: Serve Payload and Gain Access

Now that we have our web server up and ready to serve our payload, and our handler listening for the reverse connection, we can move on to downloading and executing our payload on the victim machine:

Note: I’m using Internet Explorer for this act, as using a more modern browser (such as Google Chrome) will flag our payload as malware and refuse to download it. This is due to the fact our payload is an un-obfuscated EXE file of a well-known payload.

Once our payload is finished download, we need to right-click it and hit “Run as Administrator.” This step isn’t 100% necessary, but if we don’t then we’ll have to jump through the hoops of privilege escalation (which is beyond the scope of this article). Now that we’ve downloaded and executed our payload, we can return to our Kali machine and we should see that we have a brand new meterpreter, with which we can load mimikatz and steal that password!

Step 3: Load Mimikatz and Steal Credentials

So, we’ve got our meterpreter. But there’s a slight problem, mimikatz needs SYSTEM privileges in order to perform. But don’t fret! Since we ran our payload as Administrator, we should be able to use the getsystem meterpreter command to elevate our privileges to that of SYSTEM:

There we go! Now that we have SYSTEM privileges, we can load the mimikatz extension for our meterpreter:

Alright, we’ve loaded mimikatz successfully, so lets take a look at the help page:

Here we can see that we have many options when using mimikatz. Most of the options presented in the help page are various tactics for pulling passwords out of memory (Note: the mimikatz_command option can be used to access other capabilities of mimikatz, which I plan on getting to in a later article).

After some trial and error regarding which tactic to use, I discovered that in this particular case, the wdigest method will successfully retrieve the Windows credentials we’re after:

There we have it. We can see at the bottom of the above screenshot that the credentials mimikatz pulled are; Username: Defalt, Password: C0mplexP@ssw0rd!!@, which are the credentials I set before we began this exercise.

This is just the tip of the iceberg as far as mimikatz capabilities, but we’ll get to the rest in due time. Until then, happy hacking!

How to Steal Information with the Finger Command in Windows 10

A new security flaw has been found in Windows 10. This time it affects one of the basic commands of the Microsoft operating system. The affected one in this case is the Finger command, which can be exploited to download and steal files easily and quickly. The list of native Windows executables that can download or run malicious code continues to grow, and the Finger command has just been added to the list.

These are known as living-off-the-land binaries (LoLBins) and can help attackers bypass security controls without triggering a security alert on the system. Thus, as attackers use pre-installed tools to carry out their work, it makes it more difficult for defenders to detect attacks that are occurring on systems.

How the finger command works

The Finger command is a command that all Windows users have available. To start using it is as simple as:

1. We go to the Start Menu.
2. We write cmd to enter the command line.
3. We write Finger and hit enter.

Here is an example of the Finger command for Windows 10 in which it shows us the parameters offered by this executable.

As you can see, we will use -l to specify the user from whom we want to obtain information. We also have @host to specify a server on a remote system and get information from those users. In this sense, the Finger command found in Windows 10 is used to retrieve information about users on remote computers running the Finger service or daemon. What it does is show us information about the users of a specific remote computer that normally has a UNIX operating system, and is running the Finger service.

How can we exploit the Finger command to steal files

Security researcher John Page has found that the Finger TCP / IP command in Microsoft Windows 10 can also be used to:

1. Downloading files.
2. Be used as a makeshift command and control server that can be used to send commands and filter data.

According to the aforementioned researcher, by using commands we can mask Finger queries to download files and exfiltrate data. Thus, if we do it this way, Windows Defender will not detect any suspicious activity. The fault could be found in that port 79, which is the one used by the Finger protocol and which is frequently blocked within a company. However, an attacker with sufficient privileges can circumvent the restriction. We could do this using Windows NetSh Portproxy, which acts as a port forwarder for the TCP protocol.

Thanks to this way of working, it would allow us to overcome the firewall rules and communicate with the servers through unrestricted ports for HTTPS. So by doing it this way, the Portproxy queries are sent to the local machine IP and then forwarded to the specified host. It should also be noted that the Finger command to download files also has limitations. However, it is not something we cannot solve, since, if we encode the files with Base64 it will be enough for us to avoid detection.

Video of the Finger command in action and more

John Page, the researcher we talked about before, uses the hyp3rlinx nickname to make his publications. In a video you have demonstrated how you used the Finger command to download files. This security researcher has created proof of concept (PoC) scripts. In that sense, it published DarkFinger.py for the server and DarkFinger-Agent.bat on the client side to demonstrate that double function that allows us to perform finger.exe. If you want to consult those scripts you can do it from here .

Here’s the video from hyp3rlinx showing how the DarkFinger script completed the test without interruption on a Windows 10 PC, and furthermore that Windows Defender did not detect any suspicious activity.

In a Talos Intelligence report from last year, 13 LoLBins were listed that affected Windows, for example we have the famous powershell.exe or certutil.exe. Finally, it should be noted that the Finger command, as has been demonstrated, will become part of the list of LoLBins that we can use in windows.

We recommend that you read our tutorials on how to protect a Windows 10 system , and how to improve Windows Defender security , to protect your Windows as best as possible.

Beware! Hackers Can Steal Your Windows Password Remotely Using Chrome

A security researcher has discovered a serious vulnerability in the default configuration of the latest version of Google’s Chrome running on any version of Microsoft’s Windows operating system, including Windows 10, that could allow remote hackers to steal user’s login credentials.

Researcher Bosko Stankovic of DefenseCode has found that just by visiting a website containing a malicious SCF file could allow victims to unknowingly share their computer’s login credentials with hackers via Chrome and the SMB protocol.

This technique is not new and was exploited by the Stuxnet — a powerful malware that specially designed to destroy Iran’s nuclear program — that used the Windows shortcut LNK files to compromise systems.

What’s make this attack different from others is the fact that such SMB authentication related attacks have been first time demonstrated on Google Chrome publicly, after Internet Explorer (IE) and Edge.

Chrome + SCF + SMB = Stealing Windows Credentials

«Currently, the attacker just needs to entice the victim (using fully updated Google Chrome and Windows) to visit his website to be able to proceed and reuse victim’s authentication credentials,» Stankovic wrote in a blog post, describing the flaw.

As soon as the user opens the folder containing that downloaded file, immediately or later, this file automatically runs to retrieve an icon without the user having to click on it.

But instead of setting the location of an icon image, the malicious SCF file created by the attacker contain the location of a remote SMB server (controlled by the attacker).

So, as soon as the SCF file attempts to retrieve the icon image, it will trick into making an automatic authentication with the attacker’s controlled remote server over SMB protocol, handing over the victim’s username and hashed version of password, allowing the attacker to use your credentials to authenticate to your personal computer or network resource.

«Setting an icon location to a remote SMB server is a known attack vector that abuses the Windows automatic authentication feature when accessing services like remote file shares,» Stankovic said.

But following the Stuxnet attacks, Microsoft forced LNK files to load their icons only from local resources so they’d no longer be vulnerable to such attacks which make them load malicious code from outside servers.

However, SCF files were left alone.

Exploiting LM/NTLM Hash Authentication via SCF File

Image Source: SANS

But why would your Windows PC automatically hand over your credentials to the server?

If you are unaware, this is how authentication via the Server Message Block (SMB) protocol works in combination with the NTLM challenge/response authentication mechanism.

In short, LM/NTLM authentication works in 4 steps:

• Windows users (client) attempts to log into a server.
• The server responds with a challenge value, asking the user to encrypt the challenge value with his hash password and send it back.
• Windows handles the SCF request by sending the client’s username and hashed version of the password to the server.
• The server then captures that response and approves authentication, if the client’s hash password is correct.

Now, in the SCF attack scenario, elaborated by Stankovic, Windows will attempt to authenticate to the malicious SMB server automatically by providing the victim’s username and NTLMv2 password hashes (a personal computer or network resource) to the server, as described in above-mentioned step 3.

If the user is part of a corporate network, the network credentials assigned to the user by his company’s sysadmin will be sent to the attacker.

If the victim is a home user, the victim’s Windows username and password will be sent to the attacker.

[*] SMB Captured — 2017-05-15 13:10:44 +0200
NTLMv2 Response Captured from 173.203.29.182:62521 — 173.203.29.182
USER:Bosko DOMAIN:Master OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:98daf39c3a253bbe4a289e7a746d4b24
NT_CLIENT_CHALLENGE:01010000000000000e5f83e06fcdd201ccf26d91cd9e326e000000000200000000000
00000000000

«It is worth mentioning that SCF files will appear extensionless in Windows Explorer regardless of file and folder settings,» the researcher said. «Therefore, file named picture.jpg.scf will appear in Windows Explorer as picture.jpg. This adds to inconspicuous nature of attacks using SCF files.»

No Need to Decrypt Password *Sometimes*

Since a number of Microsoft services accept the password in its hashed form, the attacker can even use the encrypted password to login to your OneDrive, Outlook.com, Office 365, Office Online, Skype, Xbox Live and other Microsoft services, making the decryption unnecessary.

Such vulnerabilities, according to the researcher, could also pose a serious threat to large organizations as they enable attackers to impersonate one of their members, allowing attackers to immediately reuse gained privileges to further escalate access and gain access and control of their IT resources and perform attacks on other members.

How to Prevent Such SMB Authentication-related Attacks

Simply, block outbound SMB connections (TCP ports 139 and 445) from the local network to the WAN via firewalls, so that local computers can not query remote SMB servers.

Stankovic also advises users to consider disabling automatic downloads in Google Chrome by going to Settings → Show advanced settings → and then Check the «Ask where to save each file before downloading» option.

This change will allow you to manually approve each download attempt, which would significantly decrease the risk of credential theft attacks using SCF files.

Google is aware of the vulnerability and is said to be working on a patch, but no timeframe has been given as to when the patch will be made available to the users.