Blog Post

Trying to keep up with regular posts, I found another malicious sample on VirusBay recently that I was quite interested in analyzing, mainly because it was 14.3 Megabytes large. Unless it was written in Python and compiled, I had no idea what it could be – so let’s find out!

– As this malware randomized the name of files and folders, whenever I reset the virtual  machine there were different names – because of this there will be some varying names  in this post, hopefully it isn’t too difficult to follow.

TL;DR

This particular sample is split into two sections – first, it checks to see if it is running as svchost.exe in the SysWOW64 folder and if it has escalated privileges, and if so it continues on with the program flow.

If it does not, this sample creates a randomly named folder in the SysWOW64 directory, using a CMD command. It then creates a copy of itself in the TEMP folder, also randomly named. Those two randomly generated names are then utilized throughout the program. A service is created using the name of the folder in SysWOW64 and is named “wifi support” – this is the persistence method. The program then executes WUSA which runs with SYSTEM privileges, allowing the program to perform Token Impersonation and execute svchost.exe with SYSTEM rights. A firewall command is issued that allows all connections in and out of that program. Once svchost.exe has been executed, the program exits, and svchost continues the execution of the program.

The malicious payload of this sample is to spam emails containing extremely dodgy links.

Hash of Sample (MD5): 12df46dfb67afd5ba56c76c3e3e4cc38

After running strings on the sample, I found some clues that hinted to the fact that the  malware used the Simple Mail Transfer Protocol (SMTP) somehow – perhaps for sending logs to a hardcoded email address? Maybe this was a keylogger, however I saw no strings containing GetAsyncKeyState or any Windows Hooking API, so I decided to investigate further. I also noticed “AUTH LOGIN” in the file of strings, which, according to Wikipedia, is a method of logging into a SMTP server with Base64 encoded credentials – so if we log the session with Wireshark we might be able to capture any used SMTP credentials by the malware.  I also noticed “ESMTP” in the file, which stands for Extended SMTP – as the name states it is an extension of SMTP, meaning there is improved security and authentication compared to regular SMTP.

I opened up the sample in PEStudio, revealing that 37/67 Anti-Virus programs detected this sample as malware – but somehow MalwareBytes thought it was clean? I checked the imported libraries, and what a surprise, ws2_32.dll was one of the seven. For those who are unaware, ws2_32.dll contains the Windows Socket API which allows the program to create network connections, so this is usually a massive clue that the sample uses network connections, and that you should look out for any inbound or outbound connections. LoadLibrary and GetProcAddress were also discovered as imported functions by PEStudio, so the malware could be dynamically importing API calls at runtime. I decided it was about time to execute this file and get an idea of how it functions.

Upon executing this sample, several things occurred. First, a Windows Update Standalone Installer popped up and then a few seconds later, disappeared. I then noticed a popup in the bottom right of the screen, noting that the service “xgxeetvm” had been installed, and that it was just “wifi support“. Hmm, funnily enough I don’t think it is. Perhaps it was a persistence method? I checked this fraudulent service and it stated that it started automatically, rather than executing on boot up. The file also deleted itself from the Desktop, meaning it must have spawned a process to resume execution of the file whilst deleting the original sample. At the same time, a suspicious, escalated svchost.exe spawned – running in “C:\Windows\SysWOW64\“. This must be the process carrying on the execution!

Sure enough, looking at the network tab in Process Hacker, I noticed plenty of connections out to multiple websites, on port 25 and port 420. Port 25 is SMTP, but I had no clue what used Port 420. Upon further inspection, most of the services running on port 420 had to do with malware. Whilst I was examining the execution of this sample, I also had Wireshark running in the background and managed to capture hundreds of SMTP packets that were sent out or received by the malware. Going through the plaintext emails, I deduced that this was all spam being sent out. I attempted to search for any packets containing “AUTH LOGIN“, but sadly nothing came up. It was time to put this in x32dbg (definitely my favorite debugger) and figure out exactly what this malware does, and how it does it, because the basic idea I had was not going to cut it.

I first wanted to figure out what function executed WUSA and spawned svchost, as well as installing the “legitimate” service. After stepping over several function calls in the main thread, I noticed “qocopkio.exe” was stored in the EAX register, before the function call at 00409DD2. Utilizing an extremely professional method in order to find the function that executed WUSA (AKA stepping over function calls until the Windows Installer window popped up, and then resetting the virtual machine snapshot) I was able to determine that the function call at 00409DD2 was the start of what seemed to be the escalation part of the malware.

This function also seemed responsible for creating a random folder name in SysWOW64, as well as appending the randomized .EXE filename to the path to the TEMP directory.

While I was debugging this particular function, I noticed a loop that seemed to form a CMD command, containing “%s” in multiple places. If you are not aware, in programming languages “%s” is usually a placeholder for a variable. For example, if you have a variable that is randomly generated during runtime, you would use “%s” in a print statement (for example), as you cannot know the string that is randomly generated whilst developing the code. This could mean that the code is filled in with randomly generated variables – such as the name of an executable.

 cmd /C mkdir %s\r\ncmd /C move /Y \"%s\" %s\r\nsc create %s binPath= \"%s%s /d\\\"%s\\\"\" type= own start= auto DisplayName= \"wifi support\"\r\nsc description %s \"wifi internet conection\"\r\nsc start %s\r\n"

From the looks of it, this command creates a folder in a directory, moves a file to another location, creates a service, and then executes that service. It is beginning to seem like this sample uses CMD commands to root itself into the system, before continuing execution with svchost. Further down there are functions that append svchost.exe to “C:\Windows\SysWOW64\“, until we get to another function that forms a CMD command – this time a firewall command:

 netsh advfirewall firewall add rule name=\"Host-process for services of Windows\" dir=in action=allow program=\"%s\" enable=yes>nul\r\n

Again we see the “%s”, so hopefully the program fills those blanks in for us soon. This command basically adds a rule to the firewall that allows inbound and outbound connections to and from the specified program, so that they are not blocked. As we go on, the program calls “GetUserName” and “LookupAccountName“, which could be how the program detects the current privileges.

The program then uses the same loop that was used to form the commands, in order to form the registry key: SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. After returning from that function, it opens it using RegOpenKeyEx, and attempts to query two values using RegQueryValueEx; “ConsentPromptBehaviourAdmin” and “PromptOnSecureDesktop“. The keys are then closed using RegCloseKey.

After querying the registry values, the program then begins to import functions, using LoadLibrary and GetProcAddress, from NTDLL.dll. A list of functions to import are stored in the memory of the program, so it was not hard to find them all:

• RtlExpandEnvironmentStrings_U
• ZwOpenProcessToken
• RtlSetLastWin32Error                         
• ZwDuplicateToken
• NtTerminateProcess                           
• RtlAllocateAndInitializeSid
• RtlFreeSid                                             
• ZwFilterToken
• RtlInitUnicodeString                           
• RtlLengthSid
• NtSetInformationThread                   
• NtQueryInformationToken 
• ZwSetInformationToken
• RtlNtStatusToDosError
• ZwClose

Once these new functions are imported successfully, the malware calls “GetCurrentProcess” and “ZwOpenProcessToken“. “NtQueryInformationToken” is called and then the Token is closed with “ZwClose“. This could be the method that this sample uses to determine whether or not it is running as svchost with SYSTEM rights, or just a regular executable.

WUSA is executed using the “ShellExecuteEx“. The program then opens a handle to a process token and then duplicates it, multiple times. This could be a case of Token Impersonation, as this program executes svchost.exe with SYSTEM rights – this could be the MS16-032 exploit, which allowed privilege escalation through the use of Token Impersonation.

Further on I managed to locate the function that filled in the blanks of the make directory command, revealing:

 cmd /C mkdir C:\\Windows\\SysWOW64\\xgxeetvm\\

At least we now know that the “%s” was in fact a placeholder, so we should be able to find the rest of the command in the executable. A function call later, I noticed two interesting things. The first thing I noticed was another command being filled in, and three strings; “uac“, “is” and “useless”,  being passed to the function “CreateProcessWithLogon“. The second part of the command is this:

cmd /C move /Y \"C:\\Users\\RE\\AppData\\Local\\Temp\\qocopkio.exe\" C:\\Windows\\SysWOW64\\xgxeetvm\\

Even more interesting, is the fact that this is also passed to the CreateProcessWithLogon function. As you can see on the MSDN page, “CreateProcessWithLogon” is being called with the username “uac“, the domain “is“, and the password as “useless“. The command is passed as the Command Line argument.

Once the file has moved, the program fills in the third, and final, part of the command string, giving us:

\r\nsc create xgxeetvm binPath= \"C:\\Windows\\SysWOW64\\xgxeetvm\\qocopkio.exe /d\\\"C:\\Users\\RE\\Desktop\\Sample_5af72dbf575129196e3b7af6.false\\\"\" type= own start= auto DisplayName= \"wifi support\"\r\nsc description xgxeetvm \"wifi internet conection\"\r\nsc start xgxeetvm\r\nnetsh advfirewall firewall add rule name=\"Host-process for services of Windows\" dir=in action=allow program=\"C:\\Windows\\SysWOW64\\svchost.exe\" enable=yes>nul\r\n

This command is also executed by “CreateProcessWithLogon“, however it is split up and run in a specific order:

• First, the service is created and the display name is set
• Then the description of the service is set
• After the description is set, the service is started
  • This executes svchost.exe, which continues on the execution of the program
• Finally, the firewall rule is set that allows all connections to and from svchost.exe.

After the program finishes executing this final command, the main sample closes all handles and checks to see if it is running as svchost or not, and then proceeds to exit the process, leaving the spawned svchost.exe process to resume the execution.

So now we have managed to narrow down how svchost is executed and how it remains persistent on a system, but what happens with svchost once it is executed? I will be exploring that in part 2 of this analysis, as it is seeming to be quite long. Hopefully you learnt something from this, and if there is anything I can improve on, feel free to let me know.

You can download the executable from here.

IOCs

Sample 12df46dfb67afd5ba56c76c3e3e4cc38 – Executable