Deep dive into Tofsee spambot(Win32:Tofsee-J) malware dropper-2

In this part we will do the static analysis of dropper of tofsee .Tofsee is a spambot categorie of malware used to send spam messages, click fraud to different smtp mail server.

5 min read
Deep dive into Tofsee spambot(Win32:Tofsee-J)  malware dropper-2

In previous part we have run the Tofsee spambot sample(read here) and look at its behaviour. Now lets start reversing the sample.

Static analysis

I stated the sample in ollydbg. The entry point sets to .text section and doesn't look obstructed in any way. First interesting call I noticed is RegOpenKeyExA which is used to access the registry key HKEYCURRENTUSER\Software\Microsoft\Windows\CurrentVersion\Run.

The malware is only try to access the key HKCU not HKLM, that means will only affect the user that has logged in at that time.

Next it queries if MSCONFIG key value is set on registry location accessed earlier or not through RegQueryValueExA.

We can guess that it will later try to add the MSCONFIG key in registry. In the background I have also started Process monitor which give logs for are these changes.

Next it creates a file in a weird place named ".\pipe\stdinout". I think this location refer to its own pe file in disk. And it try to verify if the file is accessible or not. It later try to get the file size using GetFileSize function.

Screenshot_win7-clone_2018-06-30_21-51-31. You can verified the \.pipe\stdinout file is actually its own pe file using the Process Monitor.

After few instructions ReadFile is used to read the first 64 byte of the pe file which mostly contain pe header.


Then the ReadFile operation repeat in loop to copy all sections header of pe file.


Next the program allocate a heap memory of 0xe600 bytes and copy all the data it receive through ReadFile in that allocated memory. The data copied look like contain the complete header information.

Next program try to read USERPROFILE environment variable value using GetEnvironmentVariable.


The USERPROFILE variable stores the location of your User's data directory. Example, in my case the location is "C:\User\hackbox" where hackbox is my username.
The program then runs a subroutine that generate a random string and creates a file with that name in location return by USERPROFILE system varible.

The file name in my case is btwlmyqp.exe.

Next the program check for Free disk space in C:\ drive through GetDiskFreeSpaceA and then load ntdll.dll through LoadLibrary funtion.

Then it copy the original pe file data that it has stored earlier through ReadFile to the newly created pe file. You can also guess that it is checking for disk space mentioned above just to confirm that there is enough space left in C:// drive to create a new executable.


Now again it opens the HKCU\Software\Microsoft\Windows\CurrentVersion\Run
registry key and set the MSCONFIG registry value to path of newly created executable.



It is adding these registry key for persistence purpose, so that at next reboot the process run automatically at startup. It has choosed that particular location HKCU..CurrentVersion\Run because that location is used to store registry key for process that system want to run on startup. There are other such location also which you can check using Autoruns tool from sysinternals. You can confirm the key is created in Registry editor also.


Now the process has spawn a new process from the pe file it has created using CreateProcessScreenshot_win7-clone_2018-07-01_16-41-16

The process created in suspended mode hence will not visible in process explorer until the parent process get terminated. After starting the process the program is checking if it is debugged or not and exit the program if it is debugged. Hence to view the remaining work I have to change the flow at particular location 0x00407B77.
After changing the flow I have seen GetTickCount call which generally used for anti-debugging purposes. But here it is used just to check the system time.

Next the program has done something interesting, it first retrieve the location of user's temp folder and then create a .bat file of four character string.


File with .bat extension is used as windows script file run some sequence of windows shell command. The program stores some text given below to the bat file using WriteFile.

The script consist of commands sequence running in loop to delete the original pe file (unpack.exe in my case) and then ping the host system.
Next, it get executed with ShellExecuteA.


After that the program terminate itself. The script runs in background and will delete the pe file once the program stops. It is been running in loop so that it will wait until the process get closed to delete the pe file as it can't do that when the process is in memory. You can see the ping running in system using process explorer.


Once restarting the system you can check svchost process spawn from explorer.exe due to the registry change done by the dropper.

The dropper was simple to analyze since it doesn't contain any obstruction techniques and its working is similar to most other dropper.

Summary of Analysis

The dropper once started create a new executable at user's home folder and put a registry key with name MSCONFIG at location HKEYCURRENTUSER\Software\Microsoft\Windows\CurrentVersion\Run. Then it starts a new process from the executable it create. Once the new process has started it delete itself by running a bat file which contains instruction to delete the pe file.

Possible Files created by dropper
????.bat (four characteres)

Thats it for this part, in future we will reverse the module which is the process the dropper has created.