Infostealer infection through fake Windows Update Error Fix

Let us share with you a thorough investigation conducted by two of our excellent IT security analysts, Judit Erős and Sándor Fekete. This is an infostealer infection effecting through a fake Windows update error fix with a premade script.

The starting point is a Windows Update error (0x80070643) hitting the community worldwide concerning the installation of the package KB5034441.

The official explanation from Microsoft was:

“Devices attempting to install the January 2024 Windows Recovery Environment update ( KB5034441) might display an error related to the size of the Recovery Environment’s partition. The Windows Recovery Environment (WinRE) is used to repair or recover from issues affecting Windows.”

The fix, in a nutshell, is to expand the size of the Windows Recovery partition. This is not a daily exercise for most of us, so an attacker identified a demand in the ‘market’ and created a malicious script. This script is hosted on a website that provides a one-click solution, but it requires administrative rights. It’s a simple, yet unfortunate process: download the script, run it as an admin, and you’re done.

Fortunately, an IT security expert detected the malicious activity and reported it to us for further analysis. After doing a quick Google search about the problem, you land on the following, since removed website:

The author explains what to do and how to manually fix the error. However, at the bottom of the page, you are provided with the magic solution, a blue button:

Clicking on it results in a powershell script in your download folder named as: Fix_ad-Code.ps1

Once we open the script in a text editor, we encounter the first layer of slightly obfuscated code:

After decoding the Base64 strings, it starts to become clear what is happening:

However, it is still a bit unclear, so we continue the deobfuscation to reach Layer 2:

Let’s break down the functionality step by step:

• Generate a random name for a directory under the user’s TEMP directory (between 8-15 characters long from the given charset).
• Generate a random name for the payload and give it the .zip extension.
• Set a User-Agent string.
• Set the Download URL of the fake update package.
• If download is successful, it sends a status code 2.
• Unzip the payload zip, search for the .exe file inside, and start a process with it.
• If this action is successful a status code of 3 is posted.
• Finally, the code exits.

From this, we can infer that the main functionalities are to download the payload and post the status check’s result.

To investigate the downloader part, we used the necessary lines from the script just to download the zip payload:

Without executing anything we can have a closer look on the full content of the zipped payload:

We assumed that not ‘everything is as it appears’, so we ran quick checks on file types searching for anomalies. The most suspicious files were chalcocite.accdb and brunch.deb. We delved into the .exe file (WinNc.exe), which is initiated by the script. At first glance, it is a 64-bit PE compiled on March 15, 2024, with a substantial resource.

The binary’s certificate seems to be valid:

We shifted our focus to the other binaries in the folder and detected that the signature of unrar64.dll is not valid.

https://www.virustotal.com/gui/file/45470517054714f8fd967b7723102a5040a5ffdf56cd461c5af92bb94024d29e/detection

We compared the suspicious file with unrar64.dll in the original WinNc software’s folder of the same version (10.7.0.0), and we found a few functions that exist in our file but not in the legitimate sample.

These are mostly not library functions, which means we can easily identify the attackers’ custom code for static analysis if we choose to follow that path in the investigation. However, based on an educated guess, we believe that unrar64.dll is only the second stage, so our goal is to reach the third stage. That’s why we opted for dynamic analysis. The results vary slightly depending on network access. Initially, we ran it without internet access to gain preliminary insights into the process flow.

In more detail, the sample first copies all relevant files from its folder to the user’s Appdata\Roaming\Qbhost folder. Then it starts itself from the new location, spawns a cmd process, and initiates regsvr32.exe to download further components. However, this is likely the point where it detects the lack of internet access.

A strange environment variable is created for that cmd.exe child process:

The file is the first element dropped on disk by the first stage infection.

In the meantime, unrar64.dll is reading 2 encrypted files from its folder, brunch.deb and chalcocite.accdb:

We repeated the process, this time with network access, hoping to catch the next payload.

Let’s focus on the differences! Firstly, our process tree is now complete with the third stage, which was downloaded through regsvr32.exe:

And a popup window informs us about installation error:

A quick check on the path shows empty dll files in the mentioned folder:

These masters of the LOL (Living Off the Land) techniques represent the typical repertoire of infostealers. For example, nss3.dll belongs to the Network Security Services of Mozilla Firefox and is often used by attackers’ tools to extract passwords from Mozilla profiles.

You can read about the subject in the excellent article of cyberSecAsia.org:

https://www.linkedin.com/pulse/detecting-undetected-risk-your-info-cybersecasia-org

Finally, our third stage Stealer (we can call it on his name now) is written on disk:

As we aren’t expecting any major surprises from this point forward, we’ll just collect some static details about DAEBKKKEHD.exe.

The good news is that Defender recognizes and quarantines the file. The screenshot is from an earlier run and the name is randomized, but this file is indeed our ‘stealer friend’

In the HKCU Registry hive there is evidence of the execution:

The binary is a 32-bit PE file, does not have valid signature (surprise-surprise!) and pretend to be iTop Easy Desktop Uinstall Confirm application.

sample contains 88 functions which are not present in the original:

Unfortunately, only a few AV products know our guy according to Virustotal, tagged as Penguish:

https://www.virustotal.com/gui/file/3e985b9112a5b9ff5f3d4a8b20db2519aff35d19ec71d541a6927b8618e3000a

But the legit IEDConfirm.exe is confirmed even more clean as Unwanted Software:

Lastly, we checked the network communication during the infection.

Powershell.exe downloaded components from one site:

• 21.72.53 on port 443 – behind Cloudflare Inc.

Our regsvr32.exe communicated with 4 IP addresses – but only 3 is interesting.

• 21.43.75 on port 443 – behind Cloudflare Inc.
• 154.167.99 on port 443 – Telegram Messenger INC (!!)
• 69.102.132 on port 5432 – VPS of Hetzner Online GmbH

So, we identified our C2 server listening on port 5432 and YES, attackers can use Telegram as a Bot Client Proxy.

To sum things up, we can tell: not all that glitters is gold and not all that is too easy is safe!

If you would like to read more analyses conducted by our expert colleagues, check out these previous posts of ours:

MedusaLocker ransomware – Part 2 – White Hat IT Security

Analysing a latent malware infection on a recently MDE-onboarded machine (Part 1) – White Hat IT Security

Analysing a latent malware infection on a recently MDE-onboarded machine (Part 2) – White Hat IT Security