Last updated at Fri, 29 Dec 2023 21:15:48 GMT

This post also includes contributions from Reese Lewis, Andrew Christian, and Seth Lazarus.

Rapid7's Managed Detection and Response (MDR) team leverages specialized toolsets, malware analysis, tradecraft, and collaboration with our colleagues on the Threat Intelligence and Detection Engineering (TIDE) team to detect and remediate threats.

Recently, we identified a malware campaign whose payload installs itself as a Windows application after delivery via a browser ad service and bypasses User Account Control (UAC) by abusing a Windows environment variable and a native scheduled task to ensure it persistently executes with elevated privileges. The malware is classified as a stealer, which intends to steal sensitive data from an infected asset (such as browser credentials and cryptocurrency), prevent browser updates, and allow for arbitrary command execution.

Detection

The MDR SOC first became aware of this malware campaign upon analysis of “UAC Bypass - Disk Cleanup Utility” and “Suspicious Process - TaskKill Multiple Times” alerts (authored by Rapid7's TIDE team) within Rapid7's InsightIDR platform.

As the “UAC Bypass - Disk Cleanup Utility” name implies, the alert identified a possible UAC bypass using the Disk Cleanup utility due to a vulnerability in some versions of Windows 10 that allows a native scheduled task to execute arbitrary code by modifying the content of an environment variable. Specifically, the alert detected a PowerShell command spawned by a suspicious executable named HoxLuSfo.exe. We determined that HoxLuSfo.exe was spawned by sihost.exe, a background process that launches and maintains the Windows action and notification centers.

Figure 1: PowerShell command identified by Rapid7's MDR on infected assets

We determined the purpose of the PowerShell command was, after sleeping, to attempt to perform a Disk Cleanup Utility UAC bypass. The command works because, on some Windows systems, it is possible for the Disk Cleanup Utility to run via the native scheduled task “SilentCleanup” that, when triggered, executes the following command with elevated privileges:

%windir%\system32\cleanmgr.exe /autoclean /d %systemdrive%

The PowerShell command exploited the use of the environment variable %windir% in the path specified in the “SilentCleanup” scheduled task by altering the value set for the environment variable %windir%. Specifically, the PowerShell command deleted the existing %windir% environment variable and replaced it with a new %windir% environment variable set to:

%LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe REM

The environment variable replacement therefore configured the scheduled task “SilentCleanup” to execute the following command whenever the task “SilentCleanup” was triggered:

%LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe REM\system32\cleanmgr.exe /autoclean /d %systemdrive%

The binary st.exe was a copied version of HoxLuSfo.exe from the file path C:\Program Files\WindowsApps\3b76099d-e6e0-4e86-bed1-100cc5fa699f_113.0.2.0_neutral__7afzw0tp1da5e\HoxLuSfo\.

The trailing “REM” at the end of the Registry entry commented out the rest of the native command for the “SilentCleanup” scheduled task, effectively configuring the task to execute:

%LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe

After making the changes to the %windir% environment variable, the PowerShell command ran the “SilentCleanup” scheduled task, thereby hijacking the “SilentCleanup” scheduled task to run st.exe with elevated privileges.

The alert for “Suspicious Process - TaskKill Multiple Times” later detected st.exe spawning multiple commands attempting to kill any process named Google*, MicrosoftEdge*, or setu*.

Analysis of HoxLuSfo.exe

Rapid7’s MDR could not remotely acquire the files HoxLuSfo.exe and st.exe from the infected assets because they were no longer present at the time of the investigation. However, we obtained a copy of the executable from VirusTotal based on its MD5 hash, 1cc0536ae396eba7fbde9f35dc2fc8e3.

Figure 2: Overview of HoxLuSfo.exe (originally named TorE.exe) within dnSpy and its partially obfuscated contents.

Rapid7’s MDR concluded that HoxLuSfo.exe had the following characteristics and behaviors:

  • 32-bit Microsoft Visual Studio .NET executable containing obfuscated code
  • Originally named TorE.exe
  • At the time of writing, only 10 antivirus solutions detected HoxLuSfo.exe as malicious
Figure 3: Low detection rate for HoxLuSfo.exe on VirusTotal
  • Fingerprints the infected asset
  • Drops and leverages a 32-bit Microsoft Visual Studio .NET DLL, JiLuT64.dll (MD5: 14ff402962ad21b78ae0b4c43cd1f194), which is an Agile .NET obfuscator signed by SecureTeam Software Ltd, likely to (de)obfuscate contents
  • Modifies the hosts file on the infected asset to prevent correct resolution of common browser update URLs to prevent browser updates
Figure 4: Modifications made to the hosts file on infected assets
  • Enumerates installed browsers and steals credentials from installed browsers
  • Kills processes named Google*, MicrosoftEdge*, setu*
  • Contains functionality to steal cryptocurrency
  • Contains functionality for the execution of arbitrary commands on the infected asset
Figure 5: Sample of the functionality within HoxLuSfo.exe to execute arbitrary commands
  • Communicates with s1.cleancrack[.]tech and s4.cleancrack[.]tech (both of which resolve to 172.67.187[.]162 and 104.21.92[.]68 at the time of analysis) via AES-encrypted messages with a key of e84ad660c4721ae0e84ad660c4721ae0. The encryption scheme employed appears to be reused code from here.
  • Has a PDB path of E:\msix\ChromeRceADMIN4CB\TorE\obj\Release\TorE.pdb.

Rapid7’s MDR interacted with s4.cleancrack[.]tech and discovered what appears to be a login portal for the attacker to access stolen data.

Figure 6: Login page hosted at hXXps://s4.cleancrack[.]tech/login

Source of infection

Rapid7’s MDR observed the execution of chrome.exe just prior to HoxLuSfo.exe spawning the PowerShell command we detected with our alert.

In one of our investigations, our analysis of the user’s Chrome browser history file showed redirects to suspicious domains before initial infection:
hXXps://getredd[.]biz/ →
hXXps://eu.postsupport[.]net →
hXXp://updateslives[.]com/

In another investigation, DNS logs showed a redirect chain that followed a similar pattern:
hXXps://getblackk[.]biz/ →
hXXps://eu.postsupport[.]net →
hXXp://updateslives[.]com/ →
hXXps://chromesupdate[.]com

In the first investigation, the user’s Chrome profile revealed that the site permission settings for a suspicious domain, birchlerarroyo[.]com, were altered just prior to the redirects. Specifically, the user granted permission to the site hosted at birchlerarroyo[.]com to send notifications to the user.

Figure 7: Notifications enabled for birchlerarroyo[.]com within the user's site settings of Chrome

Rapid7’s MDR visited the website hosted at birchlerarroyo[.]com and found that the website presented a browser notification requesting permission to show notifications to the user.

Figure 8: Website hosted at birchlerarroyo[.]com requesting permission to show notifications to the user

We suspect that the website hosted at birchlerarroyo[.]com was compromised, as its source code contained a reference to a suspicious JavaScript file hosted at fastred[.]biz:

Figure 9: Suspicious JavaScript file found within the source code of the website hosted at birchlerarroyo[.]com

We determined that the JavaScript file hosted at fastred[.]biz was responsible for the notification observed at birchlerarroyo[.]com via the code in Figure 10.

Figure 10: Partial contents of the JavaScript file hosted at fastred[.]biz

Pivoting off of the string “Код RedPush” within the source code of birchlerarroyo[.]com (see highlighted lines in Figure 9), as well as the workerName and applicationServerKey settings within the JavaScript file in Figure 10, Rapid7’s MDR discovered additional websites containing similar source code: ostoday[.]com and magnetline[.]ru.

Rapid7’s MDR analyzed the websites hosted at each of birchlerarroyo[.]com, ostoday[.]com, and magnetline[.]ru and found that each:

  • Displayed the same type of browser notification shown in Figure 8
  • Was built using WordPress and employed the same WordPress plugin, “WP Rocket”
  • Had source code that referred to similar Javascript files hosted at either fastred[.]biz or clickmatters[.]biz and the JavaScript files had the same applicationServerKey: BIbjCoVklTIiXYjv3Z5WS9oemREJPCOFVHwpAxQphYoA5FOTzG-xOq6GiK31R-NF--qzgT3_C2jurmRX_N6nY4g
Figure 11: Partial contents of the JavaScript file hosted at clickmatters[.]biz. The unicode in the “text” key decodes to “Нажмите \"Разрешить\", чтобы получать уведомления”, which translates to “Click \ "Allow \" to receive notifications”.
  • Had source code that contained a similar rbConfig parameter referencing takiparkrb[.]site and a varying rotator value
Figure 12: Example rbConfig parameter found in website source code
  • Had source code that contained references to either “Код RedPush” (translates to “Redpush code”), “Код РБ” (translates to “CodeRB”), or “Код нативного ПУШа RB” (translates to “Native PUSH code RB”)

Pivoting off of the similar strings of “CodeRB” and “Redpush” within source code led to other findings.

First, Rapid7’s MDR discovered an advertising business, RedPush (see redpush[.]biz). RedPush provides its customers with advertisement code to host on customers’ websites. The code produces pop-up notifications to allow for advertisements to be pushed to users browsing the customers’ websites. RedPush’s customers make a profit based on the number of advertisement clicks generated from their websites that contain RedPush’s code.

Figure 13: Summary of RedPush's ad delivery model via push notifications

Second, Rapid7’s MDR discovered a publication by Malwaretips describing a browser pop-up malware family known as Redpush. Upon visiting a website compromised with Redpush code, the code presents a browser notification requesting permission to send notifications to the user. After the user grants permission, the compromised site appears to gain the ability to push toast notifications, which could range from spam advertisements to notifications for malicious fake software updates. Similar publications by McAfee here and here describe that threat actors have recently been employing toast notifications that advertise fake software updates to trick users into installing malicious Windows applications.

Rapid7’s MDR could not reproduce a push of a malicious software after visiting the compromised website at birchlerarroyo[.]com, possibly for several reasons:

  • Notification-enabled sites may send notifications at varying frequencies, as explained here, and varying times of day.
  • Malicious packages are known to be selectively pushed to users based on geolocation, as explained here. (Note: Rapid7’s MDR interacted with the website using IP addresses having varying geolocations in North America and Europe.)
  • The malware was no longer being served at the time of investigation.

However, the malware delivery techniques described by Malwaretips and McAfee were likely employed to trick the users in our investigations into installing the malware while they were browsing the Internet. As explained in the “Forensic analysis” section, in one of our investigations, there was evidence of an initial toast notification, a fake update masquerade, and installation of a malicious Windows application. Additionally, the grandparent process of the PowerShell command we detected, sihost.exe, indicated to us that the malware may have leveraged the Windows Notification Center during the infection chain.

Forensic analysis

Analysis of the User’s Chrome profile and Microsoft-Windows-PushNotifications-Platform Windows Event Logs suggests that upon the user enabling notifications to be sent from the compromised site at birchlerarroyo[.]com, the user was presented with and cleared a toast notification. We could not determine what the contents of the toast notification were based on available evidence.

Figure 14: Windows Event Log for the user clearing a toast notification to proceed with the malware's infection chain

Based on our analysis of timestamp evidence, the user was likely directed to each of getredd[.]biz, postsupport[.]net, and updateslives[.]com after clicking the toast notification, and presented a fake update webpage.

Similar to the infection mechanism described by McAfee, the installation path of the malware on disk within C:\Program Files\WindowsApps\ suggests that the users were tricked into installing a malicious Windows application. The Microsoft-Windows-AppXDeploymentServerOperational and Microsoft-Windows-AppxPackagingOperational Windows Event logs contained suspicious entries confirming installation of the malware as a Windows application, as shown in Figures 15-19.

Figure 15: Windows Event Log displaying the reading of the contents of a suspicious application package “3b76099d-e6e0-4e86-bed1-100cc5fa699f_113.0.2.0_neutral__7afzw0tp1da5e”
Figure 16: Windows Event Log displaying the deployment of the application package and the passing of suspicious installation parameters to the application via App Installer, as explained here. (Note: Rapid7's MDR noticed the value of the ran parameter changed across separate and distinct interactions with the threat actor's infrastructure, suggesting the ran parameter may be employed for tracking purposes.)
Figure 17: Windows Event Log that appears to show the URI installation parameter being processed by the application via App Installer
Figure 18: Windows Event Log showing validation of the application package's digital signature. See here for more information about signatures for Windows application packages
Figure 19: Windows Event Log showing successful deployment of the application package

The events in Figures 15-19 illustrate that the malicious Windows application was distributed through the web with App Installer as a MSIX file, oelgfertgokejrgre.msix.

Analysis of oelgfertgokejrgre.msix

Rapid7’s MDR visited chromesupdate[.]com in a controlled environment and discovered that it was hosting a convincing Chrome-update-themed webpage.

Figure 20: Lure hosted at chromesupdate[.]com

The website title, “Google Chrome - Download the Fast, Secure Browser from Google,” was consistent with those we observed of the redirect URLs getredd[.]biz, postsupport[.]net, and updateslives[.]com. The users in our investigations likely arrived at the website in Figure 20 after clicking a malicious toast notification, and proceeded to click the “Install” link presented on the website to initiate the Windows application installation.

The “Install” link presented at the website led to a Windows application installer URL (similar to that seen in Figure 17), which is consistent with MSIX distribution via the web.

Figure 21: Portion of the source code of the webpage hosted at chromesupdate[.]com showing a Windows application installer URL for a malicious MSIX package

Rapid7’s MDR obtained the MSIX file, oelgfertgokejrgre.msix, hosted at chromesupdate[.]com, and confirmed that it was a Windows application package.

Figure 22: Extracted contents of oelgfertgokejrgre.msix

Analysis of the contents extracted from oelgfertgokejrgre.msix revealed the following notable characteristics and features:

  • Two files, HoxLuSfo.exe and JiLutime.dll, were contained within the HoxLuSfo subdirectory. JiLutime.dll (MD5: 60bb67ebcffed2f406ac741b1083dc80) was a 32-bit Agile .NET obfuscator DLL signed by SecureTeam Software Ltd, likely to (de)obfuscate contents.
  • The AppxManifest.xml file contained more references to the Windows application’s masquerade as a Google Chrome update, as well as details related to its package identity and signature.

Figure 24: Partial contents of AppxManifest.xml
  • The DeroKuilSza.build.appxrecipe file contained strings that referenced a project “DeroKuilSza,” which is likely associated with the malware author.
Figure 25: References to a “DeroKuilSza” project found within DeroKuilSza.build.appxrecipe

Our dynamic analysis of oelgfertgokejrgre.msix provided clarity around the malware’s installation process. Detonation of oelgfertgokejrgre.msix caused a Windows App Installer window to appear, which displayed information about a fake Google Chrome update.

Figure 26: Windows App Installer window showing a fake Google Chrome update installation prompt

The information displayed to the user in Figure 26 is spoofed to masquerade as a legitimate Google Chrome update. The information correlates to the AppxManifest.xml configuration shown in Figure 24.

Once we proceeded with the installation, the MSIX package registered a notification sender via App Installer and immediately presented a notification to launch the fake Google Chrome update.

Figure 27: Registration of App Installer as a notification sender and notification to launch the fake Google Chrome update

Since the malicious Windows application package installed by the MSIX file was not hosted on the Microsoft Store, a prompt is presented to enable installation of sideload applications, if not already enabled, to allow for installation of applications from unofficial sources.

Figure 28: Requirement for sideload apps mode to be enabled to proceed with installation

Figure 29: Menu presented to the user to enable sideload apps mode to complete the installation of the malware

The malware needs the enablement of “Sideload apps” to complete its installation.

Pulling off the mask

The malware we summarized in this blog post has several tricks up its sleeve. Its delivery mechanism via an ad service as a Windows application (which does not leave typical web-based download forensic artifacts behind), Windows application installation path, and UAC bypass technique by manipulation of an environment variable and native scheduled task can go undetected by various security solutions or even by a seasoned SOC analyst. Rapid7’s MDR customers can rest assured that, by leveraging our attacker behavior analytics detection methodology, our analysts will detect and respond to this infection chain before the malware can steal valuable data.

IOCs

Type Indicator
Domain Name updateslives[.]com
Domain Name getredd[.]biz
Domain Name postsupport[.]net
Domain Name eu.postsupport[.]net
Domain Name cleancrack[.]tech
Domain Name s1.cleancrack[.]tech
Domain Name s4.cleancrack[.]tech
Domain Name getblackk[.]biz
Domain Name chromesupdate[.]com
Domain Name fastred[.]biz
Domain Name clickmatters[.]biz
Domain Name takiparkrb[.]site
Directory C:\Program Files\WindowsApps\3b76099d-e6e0-4e86-bed1-100cc5fa699f_113.0.2.0_neutral__7afzw0tp1da5e\HoxLuSfo
Filepath C:\Program Files\WindowsApps\3b76099d-e6e0-4e86-bed1-100cc5fa699f_113.0.2.0_neutral__7afzw0tp1da5e\HoxLuSfo\HoxLuSfo.exe
Filename HoxLuSfo.exe
MD5 1cc0536ae396eba7fbde9f35dc2fc8e3
SHA1 b7ac2fd5108f69e90ad02a1c31f8b50ab4612aa6
SHA256 5dc8aa3c906a469e734540d1fea1549220c63505b5508e539e4a16b841902ed1
Filepath %USERPROFILE%\AppData\Local\Microsoft\OneDrive\setup\st.exe
Filename st.exe
Registry Value + Registry Data HKCU\Environment.%windir% --> %LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe REM
Filename oelgfertgokejrgre.msix
MD5 6860c43374ad280c3927b16af66e3593
SHA1 94658e04988b02c395402992f46f1e975f9440e1
SHA256 0a127dfa75ecdc85e88810809c94231949606d93d232f40dad9823d3ac09b767

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.