Shell Shocked: The Oyster Backdoor Update
In early September 2024, a limited set of observations emerged, suggesting a potential update to the Oyster backdoor (Broomstick), now referred to as CleanUpLoader, as dubbed by @RussianPanda9xx. These observations are primarily centred around a specific signing company responsible for issuing certificates linked to the deployed malware variants. By analysing the tactics, techniques, and procedures (TTPs) associated with CleanUpLoader and comparing them with the newly deployed executables, I was able to identify key patterns and draw meaningful conclusions.
Figure 1: Depicts the malicious signed executables, including their icons and the associated signer name.
My observations indicate that these executables were distributed through malvertising via sponsored advertisements in various search engines, consistent with previous Oyster Backdoor campaigns. The compromised websites impersonated legitimate software download platforms for popular applications like Teams, Edge, or Chrome, but instead delivered the malicious variants referenced above.
Figure 2: An example of a malicious sponsored advertisement on Google Search.
Credits - MalwareBytes.
Figure 3: An example of a malicious Teams website.
Credits - Rapid7.
I proceeded to collect all the malicious binaries to analyze the changes introduced since the previous version of the Oyster Backdoor. I was surprised to find minor updates even within the small subset of applications I analysed.
Figure 4: Depicts malicious executables I analysed that are associated with the same signer.
To begin, I verified that all the executables listed above were signed by the same signer.
Figure 5: Depicts all the executables being analysed are signed by the same signer.
Beginning with Chrome.exe, we observe that all strings in the .data section are in plaintext, and IP addresses are presented in a hex-encoded format. This pattern of the IP address encoding is consistent across all versions of the malware.
Figure 6: Depicts the C2 IP addresses, DLL names, imported functions, as well as the PowerShell and system reconnaissance commands observed in the Chrome.exe binary.
Upon closer examination, it becomes apparent that the strings appear unusual due to a special decoding scheme employed by this binary. Specifically, if a hex byte in the .data section is 0x20 or any value greater than or equal to 0x60, the decoder subtracts 0x20 from it. Conversely, if the byte is less than 0x60, it adds 0x20 to it.
Using this, we can decode the C2 IP addresses above, which yields the below result.
Figure 7: Depicts the decoded C2 IP addresses observed in the Chrome.exe binary.
Moving on to the Teams1.exe sample, the XOR key 0x04 is very evident from the repeating pattern in the .data section.
Figure 8: Depicts the repeating 0x04 pattern observed in the Teams1.exe binary.
By performing the XOR operation with the previously mentioned key and cleaning up the data structures, the following data is revealed.
Figure 9: Depicts the C2 IP addresses, DLL names, imported functions, as well as the PowerShell and system reconnaissance commands observed in the Teams1.exe binary.
In the Edge.exe binary, the XOR encryption pattern is similar. The repeating pattern indicates that the XOR key used is 0x95 in the .data section.
Figure 10: Depicts the repeating 0x95 pattern observed in the Edge.exe binary.
By applying a similar XOR operation and cleanup to the Edge.exe binary with the correct XOR key, as done with the Teams1.exe binary, we can retrieve the encrypted strings, as shown below.
Figure 11: Depicts the C2 IP addresses, DLL names, imported functions, as well as the PowerShell and system reconnaissance commands observed in the Edge.exe binary.
The Teams3.exe binary exhibits similarities to the Edge.exe and Teams1.exe binaries, including the use of a fixed XOR key for extracting plaintext strings. The repeated pattern observed in the Teams3.exe binary is shown below.
Figure 12: Depicts the repeating 0x81 pattern observed in the Teams3.exe binary.
By applying a similar XOR operation and cleanup to the Teams3.exe binary with the correct XOR key, as done with the Teams1.exe and Edge.exe binaries, we can retrieve the encrypted strings, as shown below.
Figure 13: Depicts the C2 IP addresses, DLL names, imported functions, as well as the PowerShell and system reconnaissance commands observed in the Teams3.exe binary.
The Teams2.exe binary operates differently by embedding a legitimate copy of Teams within its resources, along with an additional resource containing the backdoor, as illustrated below.
Figure 14: Displays the .rsrc section of the Teams2.exe binary, which contains two resources—one being the legitimate Teams binary and the other a backdoor binary.
We can verify the legitimacy of the Microsoft Teams copy by inspecting its digital signature, which is signed by Microsoft. In contrast, the second binary is unsigned, with the product name "technical" and a copyright attribution to the "technical Team" as shown below.
Figure 15: Displays the Microsoft-signed Teams binary on the left and the unsigned backdoor binary details on the right.
On inspecting the backdoor binary in further detail, we observe that this binary exhibits similarities to the Edge.exe, Teams3.exe and Teams1.exe binaries, including the use of a fixed XOR key for extracting plaintext strings. The repeated pattern observed in the backdoor binary is shown below.
Figure 16: Depicts the repeating 0x7F pattern observed in the backdoor binary.
By applying a similar XOR operation and cleanup to the backdoor binary with the correct XOR key, as done with the Teams1.exe, Teams3.exe and Edge.exe binaries, we can retrieve the encrypted strings, as shown below.
Figure 17: Depicts the C2 IP addresses, DLL names, imported functions, as well as the system reconnaissance commands observed in the backdoor binary.
A key observation is that this backdoor binary lacks the PowerShell command found in the previously analysed binaries. The reason for this omission will be discussed shortly.
Now that we have extracted the IOCs, let's examine the execution of this binary and analyse how the TTPs align with the Oyster Backdoor (CleanUploader/Broomstick). In the case of all binaries, except Teams2.exe, upon execution, they connect to a malicious domain to download the legitimate installer for the targeted application (Teams, Edge, Chrome, etc.) and install it to avoid raising suspicion, similar to CleanUpLoader. After successful installation, the binaries establish communication with their C2 server over port 443.
In previous instances of CleanUpLoader, the CleanUpXX.dll binary was embedded within the .rsrc section. However, in this case, it is downloaded from the C2 server and executed via hard-coded rundll32.exe commands found across all binaries, invoking the export function "rundll" within the downloaded DLL file.
The key difference with the Teams2.exe binary is that, since it already pre-packages the legitimate Teams installer, it does not connect to any malicious domain to download it. Instead, it extracts the installer from the .rsrc section, drops it onto the disk, and executes it to install the application. Once the installation is complete, the backdoor binary, also present in the .rsrc section, reaches out to the C2 server and follows the same procedures as the other binaries.
Additional Reading
Malvertising Campaign Leads to Execution of Oyster Backdoor | Rapid7 Blog
Rhysida using Oyster Backdoor to deliver ransomware - ThreatDown by Malwarebytes
A Simple Approach to Discovering Oyster Backdoor Infrastructure | Hunt.io
IOCs
The indicators mentioned here are based on the analysis conducted by me and do not include any externally referenced indicators.