Infostealer infection through fake Windows Update Error Fix

Analysis White Hat todayJune 12, 2024 122

Background
share close

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 website: https://pchelprwizard.com/0x80070643/index.html

01_infostealer

 

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:

download 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:

02_infostealer

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

03_infostealer

 

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

04_infostealer

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:

05_infostealer

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

06_infostealer

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.

07_infostealer

The binary’s certificate seems to be valid:

08_infostealer

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

09_infostealer

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.

10_infostealer

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.

11_infostealer

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:

12_infostealer

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:

13_infostealer

14_infostealer

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:

15_infostealer

And a popup window informs us about installation error:

16_infostealer

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

17_infostealer

 

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:

18_infostealer

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’

19_infostealer

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

20_infostealer

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.

21_infostealer

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

22_infostealer

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

23_infostealer

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

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

24_infostealer

Lastly, we checked the network communication during the infection.

Powershell.exe downloaded components from one site:

25_infostealer

  • 21.72.53 on port 443 – behind Cloudflare Inc.

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

26_infostealer

  • 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.

27_infostealer

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

 

 

 

Written by: White Hat

Tagged as: , , .

Rate it
Previous post

Similar posts