A Red Team Operation Leveraging a zero-day vulnerability in Zoom
ManoMano’s employees — Manas & Manos — play a key role in the protection of the organization and constitute our first barrier. At ManoMano, our utmost paradigm is human first and in this context, we prefer investing time into training them. We regularly perform red team operations and security traps to prepare our Manas & Manos to real attacks, e.g. USB keys attacks, phishing attacks, etc. Red team operations are becoming popular amongst industries in which the red team plays the role of evil characters that attempt to look for breaches in the company to e.g. exfiltrating confidential data, ciphering files, asking for a ransom, etc. while the blue team — usually known as the SOC (Security Operations Center) — is here to protect the company. Those operations require a lot of creativity and a Do-it-yourself approach that combined together add a real value to ManoMano while bringing some fun as well ! Before each operation, we always ask ourselves the following questions. Will they recognize the attack? How will they react ? Will they contact the security team ?
In this article, we will share with you a real attack carried out by the security team. All the steps of the preparation with a special emphasize on a Zoom zero-day vulnerability will be described. The results of the attack will be of course kept confidential but the operation was a success.
In all the red team operations, preparation is a paramount step for an operation to be successful. During the preparation, we define an objective, a target (what/who we want to target), an attack vector (how do we want to reach the victim), and an attack scenario. Although the red team operations are carried out by the security team itself, we are trying to adopt a black-box approach, i.e., as if we were real attackers with no prior knowledge about the company and their employees.
Red Team Operation Phases
During this red team operation, we targeted the managers at the C-level and below. The objective defined by the CISO (Chief Information Security Officer) and accredited by a member of the C-level — in our case the CTO itself — consisted in trapping the managers and accessing to their computers remotely without being blocked by the security controls including the Antivirus itself. Only the CTO was kept up to date about the operation but also of any problems that might have arisen. Once the objective and the target were defined, we were able to move on to the attack vector.
Due to the COVID-19, we shifted from physical meetings to virtual meetings using Zoom and so do attacks related to web conference tools as highlighted by Zoom itself. Because of this trend, we decided it was a suitable moment to trap ManoMano employees with attacks related to Zoom. Well, if attackers do succeed, why should not we leverage the famous Zoom web conference tool to launch our attack. Instead of spending time on finding a vulnerability on the victim’s browser, it was easier to leverage the human weakness using social engineering and we did so with a whaling attack by spoofing the CISO identity and asking the employees to update their Zoom software urgently.
Our attack scenario is as follows: (1) the security team sends phishing emails to the ManoMano managers asking them to update their Zoom urgently, (2) the managers click on the malicious link that points to the spoofed Zoom website, (3) the managers download, uncompress the Zoom ZIP archive, and click on the legitimate Zoom installer, (4) the reverse shell included in the Zoom ZIP connects to the security team’s server without being stopped by the Next-Gen Antivirus, and (5) the security team gains control over the managers’ laptops. In the next sections, we will describe how we built up the spoofed website, the Zoom ZIP including the reverse shell, and the server to communicate with the infected laptops. The whole attack scenario is summarized in Figure 1.
Preparation — website
First of all, we needed to mimic the Zoom web page. To this end, we launched the HTTrack tool that copies a real website locally. As you can notice in Figure 2, the website looks quite legitimate although it is spoofed. To avoid any suspicions, we registered a domain with a valid SSL certificate to look even more real; however, we updated the Zoom links to make them point to our Zoom binaries and bumped the Zoom versions up as well (version 5.1.3 instead of 5.1.2 when the attack was launched).
Preparation — Zoom
The Zoom ZIP file contains two binaries — “Install.exe” signed by Zoom and “Zoom.msi” . We wanted to keep an original version of Zoom to not raise any suspicions, so when the manager clicks on the installer, a genuine version of Zoom will be installed plus our reverse shell. To this end, we extracted from “Install.exe” and “Zoom.msi” from a genuine Zoom installer, but we modified the latter file to embed our reverse shell. Zoom.msi, as shown in Figure 3, is a 7-zip archive that contains a list of DLLs, executables, etc. During the analysis of this archive, one specific file drew our attention: “ZoomInstall.xml”. What is the purpose of the file ?
As depicted in Figure 4, the XML file contains instructions parsed by Installer.exe to set up Zoom on the system, i.e., the registries to create, the binaries to copy, the DLLs to extract, the processes to kill, the shortcuts and directories to make, etc. For instance, in the excerpt of the Figure 4, the libraries “reslib.dll” and “XmppDll.dll” are copied to a destination folder. But before carrying on, we needed to check the properties of Zoom.msi, in particular whether or not the archive was signed.
When looking at the properties of both binaries, we noticed that Installer.exe is signed by a valid Zoom signature and thus cannot be updated while Zoom.msi is not signed at all (see Figure 5). Seeing this window wide open, the possibility to embed our reverse shell and create an entry in the Windows registry to launch our reverse shell while using the genuine Installer.exe of Zoom were not discarded.
We first tried to include our own reverse shell in an executable, but without any success. We investigated this issue and to this end we reversed Installer.exe by means of the Ghidra disassembler. We deduced that the installer (1) initializes the system by creating a destination directory, (2) uncompresses Zoom.msi (7-zip archive) in the temporary folder “zoom_install_dir”, (3) parses the configuration file “ZoomInstall.xml”, and (4) copies the files from “zoom_install_dir” to the “bin” directory. However, during the last step, Zoom performs a couple of checks before copying the files. For all the files contents that start with the string “MZ” (i.e. executable file) and have the IMAGE_NT_HEADER’s signature set to 0x4550 (i.e. PE signature), Zoom checks their content’s signature by means of the “WinVerifyTrust” function of the Wintrust.lib library. In a nutshell, Zoom only checks the signature of executables and libraries, but what about script files, e.g. bat or PowerShell? Well, there is no check and this constitutes a major vulnerability as we are able to ship our own reverse shell using a legitimate Zoom installer. This modus operandi allowed us to bypass many antivirus engines including next-generation antivirus that base their detection upon user’s behavior. This vulnerability was reported to Zoom on December 22nd, 2020 and is supposedly fixed in Zoom version 5.5.4.
Now that we were able to embed our reverse shell in the Zoom.msi, we needed a way to launch this reverse shell automatically. By default, Windows does not allow us to run PowerShell script (Zoom.ps1) from the Windows hive “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” when Windows boots up. Instead, we used a trampoline Zoom.bat that calls our PowerShell script (Zoom.ps1). Both Zoom.ps1 and Zoom.bat were embedded in Zoom.msi as shown in Figure 6. One more detail to fix, Windows by default prohibits the execution of remote Windows PowerShells that are not signed. This detail was solved by setting the Windows hive “Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy” to the “Unrestricted” mode by creating a registry operation (regop) in the “ZoomInstall.xml” file.
Later, we implemented a simple reverse shell in PowerShell to evade AntiVirus detections. However, Windows defends itself against malicious PowerShell scripts and we needed a way to bypass it. By default, Windows raises an exception when the “System.Net.Sockets.TCPClient” class followed by a domain or IP address is detected. It is worth mentioning that this class is used to initiate a TCP connection with a server and is used very often by malware. This was bypassed using the open source obfuscater “PowerShell-Obfuscator”. You can notice the difference between an unobfuscated reverse shell depicted in Figure 7 and the corresponding obfuscated version displayed in Figure 8.
We also created some scripts to disinfect the computers. To this end, a tracker was embedded into all the Zoom installers to keep track of all the infected computers.
Preparation — server
Before launching the campaign, we needed to set up a server on which the reverse shells will connect. To this end, we deployed a metasploit server that allowed us to easily communicate with the infected computers and to bootstrap even faster the whole infrastructure Docker containers were deployed temporarily during the campaign (see Figure 9).
And finally, we were done with the preparation. On the D-Day, the mails were sent out to the ManoMano managers…
Conclusions
This Red Team operation required us a month of preparation to make sure that everything ran smoothly during the D-Day. After each operation, a debriefing is organized with all the ManoMano stakeholders. This kind of operation is a right way to monitor the employees’s behaviors in case of a security incident in terms of detection, reaction, communication, etc. ManoMano’s employees are now better trained and prepared for the next trap ;-)
Vulnerability disclosure
2020/12/22 - Vendor contacted via HackerOne with the vulnerability details.
2020/12/22 - HackerOne received the vulnerability details
2020/12/23 - HackerOne is starting the triage
2021/02/03 - HackerOne is done with the triage
2021/02/12 - Vendor has confirmed the vulnerability.
2021/03/02 - Vendor supposedly fixed the vulnerability in version 5.5.4
