Tag Archives: forensics

Decrypting QBot/QakBot Registry

Recently, we have host machine that been infected with QBot/QakBot. Upon investigation, we found that it added a registry with some random name.

Based on Googling, I found this article – Decrypting Qakbot’s Encrypted Registry Keys which explain in details the encryption routine and how to decode the encrypted registry.

But I wondered.. How to decode the registry when we have only the artifacts e.g. NTUSER.dat, SOFTWARE registry hive collected.

Key Generation

Initially, system information is gathered by Qakbot from the infected host, including:
1. Computer Name (using GetComputerNameW)
2. Volume Serial Number (using GetVolumeInformationW)
3. User Account Name (using LookUpAccountSidW)

Let’s take, for example, our infected machine’s information:
Computer name: DESKTOP-4NQG47A (converted to UPPERCASE)
Volume Serial: 2797280851 (converted from the hexadecimal serial number A6BB1E53)
User Account Name: SECRET ACCOUNT (converted to UPPERCASE)

This information is then concatenated to form a password:
DESKTOP-4NQG47A2797280851SECRET ACCOUNT

The password is then hashed using a modified CRC32_shift4 algorithm.

Getting Ready

Typically, during case investigation, we usually have Computer Name and User Account Name info. But we missing the Volume Serial Number. To get that, run Powershell cmd below to get that serial number on infected host:

PS C:\ > Get-WmiObject Win32_volume | Format-table Name, @{Label = "SerialNumber"; Expression = {"{0:X}" -f $_.SerialNumber}}  -auto
Name                                        SerialNumber
----                                        ------------
C:\                                          CE6EB0A8

Next, convert the serial number from hex to decimal at https://www.rapidtables.com/convert/number/hex-to-decimal.html

CE6EB0A8 –> 3463360680

Now, we have the details of infected host:

W7VM39DKGH
3463360680 (from hex CE6EB0A8)
MAX_MAXIMUS

Next, we going to use this script below to decrypt the registry:
https://github.com/drole/qakbot-registry-decrypt

* Please note that this script needs to be run using Python 3+ and on Windows OS as it uses winreg library.
* Please setup this on your VM as we require to load/add the encrypted registry file to local machine.


Download the script and ensure required library and modules are installed in your VM.

Next, export the encrypted registry. In this example, I’m extracting the encrypted registry from NTUSER.dat:

To export it, open the NTUSER.dat file using Registry Explorer. Then, go to the encrypted registry path; in this case, its on SOFTWARE\Microsoft\Cjxgyfyefv. Then, right click on the key Cjxgyfyefv, select Export –> Key –> To .reg format. Choose your file name and location to save.

Copy the exported reg file to your VM. After that, double click the saved/exported .reg file to load/add it on your VM:

Click Yes to load/add the registry.

Check whether the registry is loaded or not via regedit:

Next, we going to decrypt the registry.

Before running the script, we need to do some modification. Comment the line 52 until 63:

Then, add the following: computer_name, volume_serial_number with the converted hexa number and user_account_name of the infected machine. Refer screenshot above.

After that, run the Python script to decrypt the registry:

python qakbot-registry-decrypt.py -r HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cjxgyfyefv

Remember to include also path to the encrypted registry key; in this case its HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cjxgyfyefv

As you can see, we able to decode the registry and read the content. We see the possible C2 IP; 85.86.242.245, the .dll name, location and the time of execution.

Check in VT for the C2 IP – https://www.virustotal.com/gui/ip-address/85.86.242.245/detection

Seems like the IP is also noted as QBot/QakBot related IP from various sources.

That’s all from me. Hope you enjoy reading the article. 🙂

Windows Credentials Manager – Looking for cached Zip Passwords

Intro

When you open a password protected zip archive using Windows Explorer (“Extract All…”); in Windows 8.x/10, the password is automatically cached in the Credentials Manager for the life of the logon session.

Let’s say you discover a host been infected with a malware that coming from a zip file that are password-protected. We can possibly try to extract cached/stored credential from Windows Credential Manager and see if it stores password for password-protected file that we’re looking for.

Steps

To view if the host contains password for file that we needed, run this cmd below (require Admin privileges):

cmdkey /list

It will show list of stored credential that are available. If your target file is not listed, probably the credential has gone (the host has been rebooted) or the file been extracted using 3rd party apps (WinRAR, 7Zip).

To recover the password, we’ll need to use this Powershell script – https://github.com/zetlen/clortho/blob/master/CredMan.ps1

Download & save the script into target machine. Then, run the script as below:

.\CredMan.ps1 -GetCred -Target "target_credential"

e.g.:

.\CredMan.ps1 -GetCred -Target 'Microsoft_Windows_Shell_ZipFolder:filename=C:\Users\Administrator\Downloads\GeoIP.zip'

As you can see, we able to retrieve the “GeoIP.zip” password (pass: testtest).

Break-In Analyzer – Quickly analyze auth.log, secure, utmp & wtmp logs for possible SSH break-in attempts

Recently, I encountered incident where several hosts been infected by < █████████ >. So, to investigate this incident, we received bunch of logs to be analyze; mostly Linux related logs.

I’ve been thinking.. What if the host has been successfully brute-forced? How can we identify it?

In Linux, there are several logs that we can refer that contains authentication logs for both successful or failed logins, and authentication processes. Location & names of the logs varies; depending on system type. For Debian/Ubuntu, the logs located at /var/log/auth.log. For Redhat/CentOS, the logs located at /var/log/secure.

There are 2 more logs that we can refer;
/var/log/utmp: current login state by user.
/var/log/wtmp: record of each user login/logout.

So, what if we write a script to quickly go thru those mentioned logs & identify the culprits? Probably we can find out if our host has been successfully brute-forced.

Introducing.. Break-In AnalyzerA script that analyze the log files /var/log/auth.log (for Debian based systems), /var/log/secure (for RHEL based systems), utmp/wtmp for possible SSH break-in attempts. – https://github.com/zam89/Break-In-Analyzer

Here are some screenshot of the script in action:

Analyzing auth.log
Analyzing secure logs
Dumping & Analyzing wtmp files

The output result will be written into text file; stored into folder named output. Inside the folder will contains file named:
auth_output.log
secure_output.log
utmp_output.log
wtmp_output.log

So, you must been wondering; how can I validate these IPs? whether they are harmless or not? Well, to do that, we can use AbuseIPDB to quickly see each of IP reputation; either they’re clean or has been reported due to malicious activity.

In this example, I’m using AbuseIPDB Bulk Checker from – https://github.com/AdmiralSYN-ACKbar/bulkcheck. This tool can perform bulk checking of IPs towards AbuseIPDB website. *Just a side notes: it require API key from AbuseIPDb. You can get it for free by registering on the website. Its limited to 1000 request/IPs per day.

So, I’m checking 203 IPs that we got from Break-In Analyzer script output (after removing duplicated using Excels) on AbuseIPDB if there is any records for those IPs. After the check completed, the result shows something like this:

AbuseIPDB Bulk Checker result

If you filter out by abuseConfidenceScore (removing score 0), you’ll see there are 3 IPs that having kinda high confidence score. The higher the score, the more chances the IP marked as malicious – meaning that the IP has been reported multiple times related to malicious activities.

Next, we cross check with our Break-In Analyzer outputs to see where did these IPs located on the logs. Or you can cross check directly with your logs. To do that, run command as below:

$ grep --perl-regexp "110.93.200.118" --color=always --only-matching --recursive * | sort | uniq --count | sort --numeric --reverse

This command is basically searching where the IP “110.93.200.118” located/contains inside the log. If you run the command, you’ll see output as below:

Now we know that the IP “110.93.200.118” is contains inside wtmp dump log:
– node2/output/wtmpdump_output.txt
– node1/output/wtmpdump_output.txt

and also inside tools output:
– node2/output/output_node2.txt
– node1/output/output_node1.txt

If we go search inside the wtmp dump log for that IP “110.93.200.118“, we found that the IP has been accessing the system since Feb 2016… hmm.. 🤦

cat node2/output/wtmpdump_output.txt | grep 110.93.200.118 --color=always

This may indicate that the attacker has been leveraging the host for very long time.

Next step is probably to search what the IP or the account “portaladmin-ts” is doing inside the host.

Generate Memory Dump from .vmss file using vmss2core

Previously, I’ve encountered a problem where I’m unable to copy the .vmem file for further analysis.

So, the next alternative way that we can do is to use .vmss file & convert it into .vmem file. .vmss is a Virtual machine suspend file.

To start convert it, first you need to download vmss2core tool here – https://flings.vmware.com/vmss2core

Next, open your cmd and enter cmd as below:

F:\Tools> .\vmss2core-sb-8456865.exe -W 'F:\INC\<REDACTED>\<REDACTED>.vmss'
vmss2core version 8456865 Copyright (C) 1998-2017 VMware, Inc. All rights reserved.
region[0]: start=0 end=c0000000.
region[1]: start=100000000 end=240000000.
Cannot translate linear address 0.
... 10 MBs written.
... 20 MBs written.
<snip>
... 8180 MBs written.
... 8190 MBs written.
Finished writing core.

After it finished, it will create a file named memory.vmem.

There you have it. So you can start doing your memory analysis using volatility if you want.

For example, here we’ll be using volatility in order to find out the profile for which .vmem is created.

$ python vol.py -f memory.dmp imageinfo
Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64_24000, Win2008R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_24000, Win7SP1x64_23418
                     AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)
                     AS Layer2 : VirtualBoxCoreDumpElf64 (Unnamed AS)
                     AS Layer3 : FileAddressSpace (/home/memory.dmp)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf800028530a0L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff80002854d00L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2019-12-23 17:42:50 UTC+0000
     Image local date and time : 2019-12-23 11:42:50 -0600