With the sudden surge in popularity for Zoom meetings, an increase interest has been seen by white/grey/black hats to identify potential vulnerabilities and weaknesses.
One of the recent popular security weaknesses identified is around the way a UNC path sent over Zoom chat gets interpreted as a hyperlink. If a member of the Zoom session clicks on the displayed link, this could lead to multiple risks.
If we also consider the scenarios involving zoom bombing, where an attacker can join a public session (which is the case for most Zoom sessions by default), either by obtaining the invitation link or by guessing personal meeting room names without having to be logged in, scenarios where an attacker manages to convince users to click on carefully crafted links become more probable.
Scenario 1: Interception of NTLM Password Hashes
The user receives a clickable link in the chat window. This could lead to an IP address or domain controlled by the attacker. The example shows a private IP address, but it could have been a public IP as well.
When the user clicks on the hyperlink, Windows will try to connect to the mentioned destination over SMB, sending the user’s username and NTLM password hash in the process.
As seen is the below screenshot, as the attacker has control over the destination host, he is able to capture the user's NTLM password hash.
The attacker can then use the NTLM hash value to crack the user’s password, as seen below.
Scenario 2: Remote execution of local files
The same technique can be used to execute a local file on the victim’s machine.
In the below screenshot, the user clicks on the hyperlink, which execute the calculator. In a real scenario, something malicious could have been executed.
Scenario 3: Remote execution of a remote file/script
An attacker can use the same technique to remotely execute a malware hosted on his machine. Instead of pointing to a local executable, the link could point to an executable on a machine controlled by the attacker. This machine could be on the internet and doesn’t have to be on the same network. In the below example, the attacker is hosting a file named “YGH.exe” on his SMB server.
In this scenario, the victim would get a warning message, but it’s safe to assume that some users would click on “Run”, and the YGH.exe file would get executed without any additional actions needed from the user's end.
In this example, the malware only shows a popup message. In a real attack, an actual malware could have been executed.
Detection of these behaviors
It's possible to easily identify these behaviors with the right visibility into network traffic and endpoint data. The below are ways to identify such instances using RSA NetWitness Network and RSA NetWitness Endpoint.
RSA NetWitness Network
Filter on direction = ‘outbound’ && service = 139 to look for outbound SMB session leaking to the internet. Do not base your filter on the TCP destination port, as the attacker doesn’t have to use the standard SMB port. Leveraging “service”, which identifies the service based on the content of the network payload instead of the advertised port numbers, allows to account for these scenarios.
Monitor where the traffic is going to and if this is expected or not (typically, no SMB traffic should go out)
Identify any potentially risky files that might have been downloaded over SMB. In this case we can identify that an executable (ygh.exe) has been downloaded. We could then check if this file has been executed and what it did using RSA NetWitness Endpoint.
RSA NetWitness Endpoint
By looking at the process analysis details for the zoom.exe process, we can easily identify any executable that has been launched by zoom, in this case, YGH.exe. In a real scenario where the malware would have taken some actions, those actions, commands, ... would have been shown in this view as well.
We can also easily filter on files that have been executed from a remote path. Filters can be created to excludes expected trusted paths based on the organization’s naming convention. In this case, it shows the remote domain used by the attacker.
Some additional recommendations
Follow standard best practices, and don’t click on any link without verifying its authenticity
Block SMB traffic from going out to the Internet
This should be the norm in any environment
With the increase in people working from home where corporate firewall policies might not be enforced, this can be done on the local Windows Firewall