o88                         ooooooo     ooooooo
 oooooooo8 oooo   oooo ooooooooo8 oo oooooo    oooooooo8 oooo  oo oooooo    ooooooo o88    888o o88    888o
888oooooo8   888   888 888oooooo8   888    888 888ooooooo  888   888   888 888     888   88888o      88888o
888           888 888  888          888                888 888   888   888 888       88o    o888 88o    o888
  88oooo888     888      88oooo888 o888o       88oooooo88 o888o o888o o888o  88ooo888  88ooo88     88ooo88
twitter | github | home
---

10/13/2024

---

Unpacking Snake Keylogger

I sometimes practice recreational malware analysis, in order to hone reverse engineering skills, learn about the little tricks and mistakes malware developers make, which in turn hones my own development skills and also because it simply is fun to do.

Usually, I just pick a random sample from malware bazaar and go for it, just as like this time:

71ce2bc7ce61c8b100d29f16914ec7cdf9ae3bd0dd1bc1d14a4b38f1fc606581

This malware is a packed Snake Keylogger, an Infostealer, Keylogger and Clipboard-Hijacker that first appeared in 2019 and is quite popular. During unpacking, we face some .NET obfuscation, process injection and more obfuscation to in the end uncover SnakeKeylogge rand get limited access to the threat actor DopeLord's Telegram Bot.

Snake Keylogger was analyzed many times, e.g. by FortiNet. Read a good analysis here: Deep Dive into a Fresh Variant of Snake Keylogger Malware | FortiGuard Labs (fortinet.com)

You can also skip to IOCs

Analysis

The initial sample is a file originally called Kqjvk.exe, masquerading as a PDF:

This is a .NET assembly and can as such be decompiled with dnSpy. An initial look shows a small obfuscated assembly:

The sample is a simple stager, that just loads a "pdf" file from a remote address, which contains the second stage:

The payload is then decrypted via AES with a hardcoded key...

and is finallly loaded into the current AppDomain:

Since the file is still available, we can download it and decrypt it, e.g. using powershell, implementing the same decryption logic:

function AESDecrypt {
        param (
            [byte[]]$cipherData
        )
    
        $key = [Convert]::FromBase64String("saMQI5lVAircxR0AQaVuKrXq2HpT3zRGKQ0x/GO5/Fs=")
        $iv = [Convert]::FromBase64String("twlpLSWX5l15d6cxWDiwFg")
    
        $aes = [System.Security.Cryptography.Aes]::Create()
        $aes.Key = $key
        $aes.IV = $iv
    
        $decryptor = $aes.CreateDecryptor($aes.Key, $aes.IV)
    
        $memoryStream = New-Object System.IO.MemoryStream
        $cryptoStream = New-Object System.Security.Cryptography.CryptoStream($memoryStream, $decryptor, [System.Security.Cryptography.CryptoStreamMode]::Write)
    
        $cryptoStream.Write($cipherData, 0, $cipherData.Length)
        $cryptoStream.Close()
    
        return $memoryStream.ToArray()
    }
    
    $cipherData = [System.IO.File]::ReadAllBytes(".\Ngggmyrptpi.pdf")
    $decryptedData = AESDecrypt -cipherData $cipherData
    [System.IO.File]::WriteAllBytes("decrypted.bin", $decryptedData)

The result is another .NET assembly, this time a DLL.

Second Stage

This second stage is also obfuscated:

Back in the first payload, the method fXu2FCc6q was called, which however is an empty method in the second stage disassembly - suggesting some dynamic unpacking going on. I reckoned it was best to go dynamic instead of static analysis now.

Running the sample in a sandboxed environment, while monitoring processes, shows that just before the malware exits, a new process RegAsm.exe is spawned:

This is the legitimate Microsoft executable & the process parent is explorer.exe, suggesting PPID spoofing was used, or there is another way to make it spawn as a child of explorer. Looking at network connections we see that this is definitely not the default RegAsm.exe execution, as it makes requests to both the telegram API as well as two different geoip-services:

The initial process can be seen creating a file mapping of RegAsm.exe, so there is likely some injection going on:

Examining the loaded assemblies in Process Hacker shows a weird assembly named Remington, which resolves its path to RegAsm.exe:

We can see a big unbacked RWX section examining RegAsm.exe in Process Hacker, containing an MZ header. This is the loaded assembly:

When we dump this to a file and use hasherezades pe_unmapper, we have unpacked the final payload, another .NET assembly:

Final payload: Snake Keylogger

The final payload scores 48 detections on Virus Total and is correctly identified as the Snake Keylogger malware family:

Besides the usual obfuscation, this payload also uses unicode for names, which makes the output less readable:

However de4dot can deobfuscate this for us:

Looking at the strings, we see many references to VIP Recovery, which is a string associated with the Snake Keylogger malware:

Snake Keylogger is a not very well written infostealer, that can e.g. hijack the clipboard, log keys or steal data from all kinds of browsers or other programs. The code is fairly readable after applying de4dot, so you can look for yourself (at your own risk) and examine it in a sandbox, if you want. I can send it to you, it's fun to look at, but there is nothing special (or download from VirusTotal).

Config

The malware sends data via the Telegram API, but can also be configured for FTP or SMTP exfiltration - in this specific config however, these values were not filled, besides for Telegram.

There are many IOCs which can be extracted from the binary, such as these URLs based on dynamic DNS providers:

While some strings are in plain text, many of the config variables are DES encrypted:

Again, we can implement this logic to decrypt with a powershell script:

function Decrypt-DES {
        param (
            [string]$encryptedText,
            [string]$keyString
        )
    
        try {
            # Create an MD5 hash of the key
            $md5 = [System.Security.Cryptography.MD5CryptoServiceProvider]::new()
            $keyBytes = [System.Text.Encoding]::ASCII.GetBytes($keyString)
            $hash = $md5.ComputeHash($keyBytes)
    
            # Use first 8 bytes as the DES key
            $desKey = $hash[0..7]
    
            # Setup DES decryption
            $des = [System.Security.Cryptography.DESCryptoServiceProvider]::new()
            $des.Key = $desKey
            $des.Mode = [System.Security.Cryptography.CipherMode]::ECB
    
            # Create decryptor
            $decryptor = $des.CreateDecryptor()
    
            # Decode the Base64 encrypted string
            $encryptedBytes = [Convert]::FromBase64String($encryptedText)
    
            # Decrypt the data
            $decryptedBytes = $decryptor.TransformFinalBlock($encryptedBytes, 0, $encryptedBytes.Length)
    
            # Convert the decrypted bytes back to string
            $decryptedText = [System.Text.Encoding]::ASCII.GetString($decryptedBytes)
    
            return $decryptedText
        } catch {
            Write-Error "Decryption failed: $_"
            return $null
        }
    }
    
    $result = Decrypt-DES -encryptedText "<ENCRYPTED_B64>" -keyString "<KEY_MATERIAL_B64>"
    if ($result) {
        Write-Output "Decrypted result: $result"
    } else {
        Write-Output "Decryption failed."
    }

While some config variables use the same key, there are also some strings that use unique keys, and some which are in plain text.

Looking through the different config variables, most interesting was the telegram bot token 7371892501:AAE6c_q-yLsVj82ZZEmMuRlQtTm95MBjCz0. With this token, it is possible to access the Telegram API to either spam the threat actor or try to get some more info, such as the username of the Bot via the /getMe endpoint:

So we are dealing with the user DopeLord here lol.

Using the decrypted chat ID, we can see the bot name Newman Kinty. Not sure what this references, it could reference the API software newman or something else entirely.

Access to messages, to e.g. find victims of the malware, is however not possible from this token, as well as getting info on DopeLord himself, as his user ID is not known or enumeratable. We could only spam him some messages or fake credentials.

IOCs

Usernames

Telegram IDs

URLs

Hashes (SHA256)

---

back to top 
helloskiddie.club <3