Last updated at Fri, 29 Oct 2021 14:54:00 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.
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.
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:
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
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:
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
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.
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
- At the time of writing, only 10 antivirus solutions detected
- 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
- 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
- Communicates with
s4.cleancrack[.]tech(both of which resolve to
104.21.92[.]68at 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
Rapid7’s MDR interacted with
s4.cleancrack[.]tech and discovered what appears to be a login portal for the attacker to access stolen data.
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:
In another investigation, DNS logs showed a redirect chain that followed a similar pattern:
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.
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.
We suspect that the website hosted at
fastred[.]biz was responsible for the notification observed at
birchlerarroyo[.]com via the code in Figure 10.
Pivoting off of the string “Код RedPush” within the source code of
Rapid7’s MDR analyzed the websites hosted at each of
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 contained a similar
takiparkrb[.]siteand a varying rotator value
- 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.
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.
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.
Based on our analysis of timestamp evidence, the user was likely directed to each of
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-AppxPackagingOperational Windows Event logs contained suspicious entries confirming installation of the malware as a Windows application, as shown in Figures 15-19.
Rapid7’s MDR visited
chromesupdate[.]com in a controlled environment and discovered that it was hosting a convincing Chrome-update-themed webpage.
The website title, “Google Chrome - Download the Fast, Secure Browser from Google,” was consistent with those we observed of the redirect URLs
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.
Rapid7’s MDR obtained the MSIX file,
oelgfertgokejrgre.msix, hosted at
chromesupdate[.]com, and confirmed that it was a Windows application package.
Analysis of the contents extracted from
oelgfertgokejrgre.msix revealed the following notable characteristics and features:
- Two files,
JiLutime.dll, were contained within the
60bb67ebcffed2f406ac741b1083dc80) was a 32-bit Agile .NET obfuscator DLL signed by SecureTeam Software Ltd, likely to (de)obfuscate contents.
AppxManifest.xmlfile 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.
DeroKuilSza.build.appxrecipefile contained strings that referenced a project “DeroKuilSza,” which is likely associated with the malware author.
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.
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.
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.
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.
|Registry Value + Registry Data||HKCU\Environment.%windir% --> %LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe REM|