How It Works

The sequence begins with threat actors creating a fake site on a web hosting service, which remains undetected by the hosting service itself. When a user searches for relevant information and clicks on a link from the search results, they unknowingly access the malicious site.

Interestingly, if the user directly enters the URL instead of clicking on the link, it bypasses this interaction, potentially to avoid analysis by security researchers – a topic further explored in the next section.

Evasion techniques

Threat actors employ checks on these malicious sites designed to evade detection by researchers. Upon loading, they verify the referral URL. If it originates from search engines like Google, Bing, DuckDuckGo, Yahoo, or AOL, the site proceeds to the next page. If the user accesses the website directly, indicating potential analysis, the site avoids redirection.

The following screenshot showcases an obfuscated script which checks and redirects users accordingly. 

Figure 2: The obfuscated code responsible for checking and redirecting users to evade detection.

This obfuscation method employs string concatenation and mathematical manipulation to hide the code’s logic. It combines strings or arrays to create expressions and manipulates values through mathematical operations to make the code more difficult to understand.

The screenshot below shows the decoded JavaScript code that’s hidden in the heavily obfuscated code mentioned above.

Figure 3: The decoded JavaScript code hidden in the heavily obfuscated code.

Payload delivery

Consider a scenario where a user searches for a cracked version of software on a search engine. One of these malicious websites may prominently feature in search results, where the user proceeds to select one. Once the above-mentioned script confirms that the user landed on the page through a search engine, it displays a fake MediaFire page hosted on Weebly.com that appears legitimate. However, instead of cracked software, the user may inadvertently download malware, thus initiating the malicious payload delivery.

As an example, the figure below shows a comparison of a fraudulent and legitimate MediaFire page. Both pages are similar; however, examining the URL provides clear indications that one of them is fraudulent because it does not use the MediaFire domain.

Figure 4: A comparison of a fake and legitimate MediaFire page.

The payload file downloaded from the fake MediaFire page has a two-level zipped structure. 

Upon extracting the first ZIP archive, the victim will find another ZIP archive inside. This secondary ZIP archive is password-protected and the password is located in an image inside the first ZIP archive. This represents the second technique employed by attackers to evade detection.

The screenshot below depicts the two-level zipped structure.

Figure 5: The files after extracting two ZIP archives.

Upon executing the extracted setup.exe file, the installation process initiates. This setup file will install the genuine GNU Privacy Guard, an OpenPGP cryptographic software suite widely utilized to enhance the security of email communications. During the installation process, we have observed that alongside setting up the genuine GNU Privacy Guard (GPG), a malicious DLL is also dropped into the same directory. This DLL utilizes DLL sideloading techniques to execute malicious activities under the guise of legitimate processes.

The screenshot below shows the malicious DLL within the directory.

Figure 6: A screenshot of the malicious DLL libgcrypt-20.dll loaded using DLL sideloading.

Subsequently, this malicious DLL begins executing its activities. To evade detection, it triggers the execution of explorer.exe and utilizes process hollowing techniques.

Below, we outline the steps involved in the process.

The attacker exploits an undocumented API, CreateProcessInternalA, to initiate a suspended explorer.exe process, then utilizes NtQueryInformationProcess to acquire its base address. After replacing legitimate content with the malicious payload via NtUnmapViewOfSection, VirtualAllocEx allocates memory within the target process. WriteProcessMemory copies the payload, and ResumeThread resumes execution, completing the injection process.

Furthermore, explorer.exe will initiate the execution of the PowerShell executable, passing along a malicious command-line argument, -windowstyle hidden, to the PowerShell console. The screenshot below shows the decoded version of this command-line argument. This command-line instructs PowerShell to download a heavily obfuscated script from a specified URL. Subsequently, it replaces certain special characters with alphabetical characters. The resulting string is decoded using the FromBase64String method. The decoded Base64 string undergoes XOR operations with the values 167 and 18.

The screenshot below shows the malicious command-line argument.

Figure 7: The malicious command-line argument.

The screenshot below depicts a section of the Base64-encoded file retrieved from the URL provided. This special character replacement prior to decoding is specifically designed to evade detection by antivirus software, enhancing the malware’s ability to bypass security measures effectively.

Figure 8: The malicious file Base64-encoded file with special character replacement.

This file exhibits multilayered obfuscation. After undergoing the initial level of deobfuscation, certain parts of the script remain obfuscated. Additionally, there are segments of code included within the script responsible for deobfuscating these encoded portions.

The screenshot below shows the second level of deobfuscation.

Figure 9: The second level of deobfuscation.

The obfuscated script primarily consists of JavaScript files related to a malicious browser extension. Upon execution, PowerShell will drop multiple files into the directory at C:Users{username}AppDataLocalDefault and create a browser shortcut on the user’s Desktop. The target path for this shortcut will point to the malicious browser extensions located at "C:Program FilesGoogleChromeApplicationchrome.exe" --load-extension="C:UserstestAppDataLocalDefault".

The --load-extension is a command-line option used with certain web browsers. It allows users to load extensions into the browser during startup.

The screenshot below shows the files associated with the browser extensions.

Figure 10: Files related to the browser extensions.

The screenshot below shows the manifest.json file associated with this malicious extension. The file includes:

• The list of permissions required by the browser extension. 
• Numerous JavaScript files, all of which are heavily obfuscated. 
• Attempts to disguise itself as a Google Drive extension.

Figure 11: The manifest.json related to the extension.