0x7ORVS

0x7ORVS

Computer science student interested in malware analysis and reverse engineering

QuasarRAT Analysis pt2

5 minute read

QuasarRAT Analysis pt2

Ok in the previous part, I analyzed the dropper that drop 3 binaries [RunAsDate.exe, svchost.exe, System.exe ] and start the first one and put the rest on the RUN registry. So, now we can assume that the second and third binaries will do continuously malicious activities for the first one I performed analysis for it and I found that it doesn’t perform mal activities just normal application.

So, I’ll start this part with System.exe because, from CAPA output in the previous part, it performs a lot of suspicious activities.

So, let’s dig into it.

Basic Analysis

After running FLOSS to extract the strings from this binary, I got some interesting strings:

- Anti-Analysis:
IsXP
DetectSandboxie
IsSmallDisk
DetectDebugger
Anti_Analysis
RunAntiAnalysis
Antivirus
VIRTUAL
vmware
VirtualBox
SbieDll.dll
Select * from AntivirusProduct

-----------------------------------------------------------

- Encryption:
Sha256
Aes256
aes256
UTF8Encoding
FromBase64String
ToBase64String
SslStream
DecodeFromStream
CryptoStream
GZipStream
SymmetricAlgorithm
AsymmetricAlgorithm
HashAlgorithm
MD5CryptoServiceProvider
RSACryptoServiceProvider
AesCryptoServiceProvider

-----------------------------------------------------------

- Mutex:
CloseMutex
CreateMutex

After running Procmon and Wireshark to monitor host/network activities, I didn’t find anything suspicious unless some failed TCP requests on the Wireshark, so, let’s perform advanced analysis to know what is happing.

Advanced Analysis:

After loading this binary into dnSpy and goto Main, the binary will sleep for 3 seconds and then call InitializeSettings function.

Inside this function, we will find that the malware will set up all things needed for malicious activities.

It used AES256 and Base64 to encrypt its configuration and in VerifyHash function it will use SHA256 algorithm to make sure that this information is not modified.

So, I start debugging this function to get this information in decrypted form.

Key: "Izdqx6qm1HwSWNSLt0xbwxRibN1U7Ove"
ports: "6606,7707,8808"
Hosts: "protectgoogle.ddns.net"
Version: "0.5.7B"
Install: "true"
MTX: "AsyncMutex_6SI8OkPnk"
Pastebin: "null"
Anti: "false"
BDOS: "false"
Group: "ninjagram"
Hwid: "CB51B195AEA0AED882EA"

After setting up all configurations and checking the integrity, the malware will try to create a mutex with a decrypted name to make sure that one version of it is running at a time.

Then it will check for Anti field in settings also to see if it will run RunAntiAnalysis or not and in our case, it won’t run it because this field is false.

Inside RunAntiAnalysis the malware will check for this information:

  • Manufacturer
  • Debugger
  • Sandbox
  • Disk size
  • windows version if it’s XP (All this information I got in strings above)


  • In manufacturer checking, the malware will check if anyone of these terms [VIRTUAL, vmware, VirtualBox] exists on the manufacturer name.

  • In debugger checking, the malware will check for isDebuggerPresent for this process

  • In sandbox checking, the malware will search if SbieDll.dll (which is associated with sandboxes) exists between modules in this process.

  • In disk checking, the malware will get the size of the system directory disk and compare it with a number.

  • In the last check, the malware will check if the OS name is XP or not.

After completing RunAntiAnalysis, the malware will check for the install field and this field is true in our case, so, it will call Install function.

Inside this function, the malware will check if it’s running under administrator and if true it will create a scheduled task with the highest privilege using schtasks.

and if not running under administrator, it will put itself again into RUN registry key for the current user (The dropper in the first part did this task).

Then, it will create a .bat file with the same information that we found in .bat file in the first part.

After the end of this function, the malware will check for two conditions (BDOS is true, running under administrator) to call Client.Helper.ProcessCritical.Set() function.

In the Set function, the malware will call EnterDebugMode which puts a Process component in state to interact with operating system processes that run in a special mode by enabling the native property SeDebugPrivilege on the current thread. And then call RtlSetProcessIsCritical and this is used to set a process to a system critical status. This function is used by malware to prevent the process from being terminated. You can read about them in MDSN and MalApi

After all this stuff, we will find the part that related to the network connection

If the malware lost the connection with the C2 server it will first call Reconnect function, and if we look at this function, it will dispose of everything on this connection.

Then, it will call InitializeClient which will initialize the TCP client and set up the host and ports and also check if the host is valid or not and get the IP address from this host using Dns.GetHostAddresses to connect with it using this Client

If the malware successfully connected to the server, the connection between them will be encrypted using SSL

And finally, that’s the end of the code.

I think we get the full methodology of this malware and know how it works from the dropping phase to connecting with the C2 server, but there is one binary remaining svchost.exe, I think it doesn’t do any additional things but I’ll try to investigate it and if I found something suspicious I’ll publish 3rd part for this malware.

IOCs:

Mutex: AsyncMutex_6SI8OkPnk

C2:
- protectgoogle.ddns.net:6606
- protectgoogle.ddns.net:7707
- protectgoogle.ddns.net:8808

Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run