responder

Microsoft Zero-Day with No Patch!

Overview
CVE-2022-30190, known as Follina, was released by Microsoft on Monday, May 30th, 2022. The vulnerability resides within the Microsoft Support Diagnostics Tool (MSDT), which may allow an attacker to run arbitrary code with the privileges of the calling application. Microsoft Office applications use MSDT to troubleshoot and collect diagnostic information when something goes wrong.

This vulnerability was discovered by the independent cybersecurity researchers at nao_sec after they noticed a strange word document posted to VirusTotal. Using the Remote Template feature in Microsoft Word, an HTML file was pulled from a remote web server. It then made use of the “ms-msdt://” URI scheme to run a malicious payload. Experts are now saying this vulnerability is being exploited by attackers in the wild. Some security researchers have demonstrated execution of the malicious code merely by previewing the document in Windows File Explorer or Outlook.

Exploit
The video below demonstrates how easily this vulnerability can be exploited. Exploit code is now publicly available, making this process trivial. We will outline the steps taken in this video below:

An attacker downloads exploit code from GitHub.
This exploit code is then utilized to create the malicious Word document and stand up a web server to serve up the HTML file. In the video below, this Word document is called “sploit.docx.”
Once the user opens the Word document, you see the MSDT tool also fire off. MSDT is also commonly referred to as “Program Compatibility Troubleshooter.”
The producer of this video then shows you that both a cmd.exe process and powershell.exe process have been launched on the system. At this point, the document can be closed, but the malicious process is still running.
The demo then shows a Cobalt Strike window. Cobalt Strike is a command-and-control framework used for maintaining persistent access on compromised systems. You can see in the video that a “beacon” has been launched on the system. A beacon is an agent on the system that allows an attacker to maintain persistent access and run arbitrary code.
At this point the producer of this video runs “whoami” on the system itself to show you which user account launched the Word document. They then flip back to Cobalt Strike and run “whoami” from the interactive beacon. This displays the same user account. Persistent remote code execution achieved.

What To Do?
At this point in time, Microsoft has not released an official fix for this vulnerability. They are recommending that the MSDT URL protocol be disabled in order to protect systems from this vulnerability. That guidance can be found here. nGuard offers a bevy of services that can help prevent and identify these types of attacks. Both Social Engineering simulations and Social Engineering Awareness Training can assist your organizations employees in identifying these types of attacks. Internal Penetration Testing can boost the overall security posture of your internal network. If a machine on your network does become compromised, you have assurance that the adversary won’t make it very far. Lastly, Managed Event Collection & Correlation gives you 24×7 monitoring from advanced log analysis tools and nGuard professionals who are trained to detect suspicious activity.

How nGuard Pwned Your Network Video Series | Part 3 of 3

In this 3-part series we are demonstrating how nGuard most commonly gains an initial foothold on internal networks, then takes that initial access and pivots through the network to obtain full command and control over systems. If you missed parts I or II, check them out here and here.

In this third part, we are going to round out our initial compromise, show you how we can obtain full command and control over a host, and show you the results of our password cracking attempts. For this part we are going to be using PowerShell Empire. The original tool was deprecated, but later was revived and now is maintained on GitHub. The framework has multiple modules and listed on the GitHub they say, “Empire 4 is a post-exploitation framework that includes pure-PowerShell Windows agents, Python 3.x Linux/OS X agents, and C# agents. It is the merger of the previous PowerShell Empire and Python EmPyre projects. The framework offers cryptologically-secure communications and flexible architecture. On the PowerShell side, Empire implements the ability to run PowerShell agents without needing powershell.exe, rapidly deployable post-exploitation modules ranging from key loggers to Mimikatz, and adaptable communications to evade network detection, all wrapped up in a usability-focused framework.”

To set this attack up and eventually have persistent command and control of a host, which will be called agents, we need to configure the server and the client. In separate terminals we will run these commands:

powershell-empire server
powershell-empire client

Once those are started, we can now set up a listener. In this attack we will need to configure the client to use an http listener. To do this we will configure the Bind IP and host to use our local IP and choose a port to run on.

After the listener is executed, we will see our sever reflect the results:

The next thing we will want to configure is our stager, which will output the encoded PowerShell command we want to execute on our compromised host. To do this we use the http listener and input the command generate.

Now that we have our encoded PowerShell, we want to go back to our Responder and ntlmrelayx tools. We will leave Responder running in the same configuration used in Part II and only have to change our ntlmrelayx command. This time we will add the -c option to have the PowerShell command run on the host, rather than dumping the SAM hashes.

Once our connection using the ntlmrelayx tool is created and our PowerShell command executes we will receive a connection back to our local machine from a compromised host in the form of an agent.

Now that we have an agent, there are many modules and commands we can run to further exploit the compromised host. In the video demonstration below you will see examples of commands like whoami for basic information about the host and mimikatz to look for more hashed and cleartext credentials on the host.

In part I we talked about loading the hashes in our password cracker and when reviewing we can see the password hash for two users were cracked in 4 minutes and 26 seconds!

Although we were able to crack the password in a relatively short time, environments with complex password requirements may take a significant amount of time to crack or will not during the time you have on an engagement. Since this task may be time consuming or unsuccessful it is much easier and quicker to utilize the hashes and not have to rely on discovering cleartext credentials.

Check out the video below to see all these steps live in action:

IIf you have any questions about this attack or want to see if nGuard can perform attacks like this on your internal network during one of our internal penetration testing assessments please reach out to an Account Executive.

How nGuard Pwned Your Network Video Series | Part 2 of 3

In this second part, we are going to take the hashes we have intercepted from part I and build upon it. We are going to relay the hashes to other hosts on the network and see what permissions and access we have. This attack is different than another common attack called pass-the-hash (PTH). Since the hashes we have captured with our Responder tool are Net-NTLM hashes, we cannot perform the PTH attack. Instead, we relay them to discover local NTLM hashes, which we can perform the PTH attack with.

In this attack we are going to use CrackMapExec and Impacket’s ntlmrelayx Python module. CrackMapExec is a post-exploitation tool that is used in assessing Active Directory environments. This is a tool with many features, but we will only be showing the feature of generating a list with hosts that have Server Message Block (SMB) Singing disabled/not required. To do this we run the command:

crackmapexec smb <IP Range to scan> –gen-relay-list <outputFileName.txt>

This command specifies the name of the tool, the protocol we want to scan for (SMB), command to generate a list, and the name of the file where we want to output the hosts with SMB signing disabled. In the screenshot below you can see we discover two hosts with SMB singing as false (disabled).

The Impacket module ntlmrelayx.py allows us to take the Net-NTLM hashes we captured in Responder and perform SMB relay attacks on the hosts discovered with SMB signing disabled utilizing CrackMapExec. The default behavior of this module is to dump the local Security Account Manager (SAM) file which contains local NTLM hashes. These are hashes we can now perform the PTH with. The two screenshots below demonstrate how this attack is carried out.

As we obtain these hashes throughout these attacks, we will always upload them into our password cracking machine and attempt to discover the cleartext password. As demonstrated in these videos so far, there are many things we can do with hashes, but working with the cleartext is always easier.

Here is a video demonstrating this in action:

In part 3 we will take the access we have gained, use that to setup full command and control over a specific host, and view the results of the hashes being uploaded into our password cracker. If you have any questions about this attack or want to see if nGuard can perform attacks like this on your internal network during one of our internal penetration testing assessments please reach out to an Account Executive.

How nGuard Pwned Your Network Video Series | Part 1 of 3

This is a 3-part series on how nGuard most commonly gains an initial foothold on your internal network, then takes that initial access and pivots through the network to obtain full command and control over systems. These are attacks that are present in over 90% of the networks we conduct internal penetration testing on. This will show you how quickly nGuard or an attacker can take an initial foothold and create persistent access. Some of the systems shown throughout this series will be Windows 7 machines but make no mistake, these are attacks that work in modern day Windows 10 environments.The first video will utilize a tool called Responder. This is a LLMNR (Link-Local Multicast Name Resolution), NBT-NS (NetBIOS Name Service) and MDNS (multicast DNS) poisoner. It will answer to specific NBT-NS queries based on their name suffix. By default, the tool will only answer to File Server Service request, which is for SMB. By responding to these broadcasts, nGuard can impersonate the host being requested and intercept future requests that may contain sensitive information. Through these requests, an attacker will receive the user’s hashed credentials, which can then be taken offline for cracking or used in other attacks.

The image below shows exactly how this works:

Here is the output to the terminal with a user’s hashed credentials:

The video below shows how this first step unfolds:

Stay tuned for part 2 where we will take these hashed credentials and relay them to other machines/systems which will discover other hosts we can gain access to on the network. If you have any questions about this attack or want to see if nGuard can perform attacks like this on your internal network during one of our internal penetration testing assessments please reach out to an Account Executive.