Suspicious Self Extracting CAB and Trojan.Bunitu
Asalamualikum and welcome
So here we are, this time with an artifact which is not an MS office document or a pdf but a self extracting and executing CAB file.
The file hashes are:
Performing a string analysis on the sample shows some interesting strings like: Reboot, wininit.ini, runprogram, postrunprogram, decryptfile,
Analyzing the sample's header and resources, we find that the file is a or at least impersonating as an MS CAB SFX. These files are like normal binary PE files but they are supposed to run and extract the compressed files.
Other header analysis reveals that the sample was compiled and linked on (Hex: 41107BC1) 4/8/2004.
Exeinfo confirms that the file is a CAB installer and it was created using MS IExpress
Process Explorer - Process Tree. We can see the sample (sample.exe) is spawning child processes and we can see that B.exe is created but it seems to crash resulting in Werfault.exe to execute which is the windows error reporting proces. The problem is that as soon as the child process crashes, the process tree is terminated and all created files are deleted.
So here we are, this time with an artifact which is not an MS office document or a pdf but a self extracting and executing CAB file.
The file hashes are:
MD5: 81d76c004e9ac9917dc449c19185a9fd
SHA1: 1c4f6703600a4251c074c7088760066b07f5dbf8
From the byte histogram we could see that the sample is not packed due to uneven byte distribution:
Performing a string analysis on the sample shows some interesting strings like: Reboot, wininit.ini, runprogram, postrunprogram, decryptfile,
Some
more interesting strings: RunOnce registry (maybe for persistence mechanism). But since it is a CAB file it is possible that the runonce registry is used by the wextract_cleanup for
cleaning up temporary files created by the self-extracting executable on
reboot. This is typical of CAB installers for windows updates.
Some other interesting strings are highlighted:
Analyzing the sample's header and resources, we find that the file is a or at least impersonating as an MS CAB SFX. These files are like normal binary PE files but they are supposed to run and extract the compressed files.
Some related strings shows the nature of the "original file"
Other header analysis reveals that the sample was compiled and linked on (Hex: 41107BC1) 4/8/2004.
More interestingly we can see some resources from the resource editor and the RUNPROGRAM RCData shows "B.exe"
The CABINET RCData item shows the header of the CAB file. They are identified by the first 4 bytes "MSCF".
The PeStudio malicious indicators indicates that the file starts a child process. Most probably it is B.exe which is mentioned in the RUNPROGRAM resource item:
We also see B.exe spawning winlogon process which in turns spawns the Windows Desktop Manager (dwm.exe) process:
Process Activity summary shows no network activity (except for werfault.exe for obvious reasons). However we can see some file and registry related events:
One of the artifacts which were not deleted and was able to give some pointers about the nature of the file B.exe was the "Report.wer" (crash report compiled by the kernel). Getting hold of this file was easy as we could see the location of the file from the File Summary. According to the wer report, B.exe Appname is "SSH Telnet Rlogin client". We were able to extract other information from the wer report like the libraries loaded by B.exe at the time of crash.
The registry entry RunOnce\extractcleanup0 is basically calling advpack.dll.DelNodeRunDll32 and passing the temp folder path (where B.exe is created) as a parameter. I believe this registry entry is responsible for removing the temp folder. I could not find much official material on DelNodeRunDll32 and the stuff I was able to google out, was mostly related to malware activity:
B.exe tries to write a file CSIDL_ in the local folder:
Tries to open a suspicious myapp.exe from C drive but cannot find it. Maybe this myapp.exe is to be dropped by B.exe? But since B.exe crashes there is no myapp.exe.
The sample gets a file handle on itself and then look for several resources some which are present and some are not. It then loads the resources
The sample also checks the OS version
It allocates memory in the heap for the resource to be written on to:
The sample also compares the value from several resources with embedded strings:
Resource item RUNPROGRAM, is loaded and written in the process heap to be accessed later
Here we see the sample making KERNERL32 API call to find the temp directory path address and then creating the folder "IXP000.TMP". Which we have seen earlier where B.exe will be dropped:
The sample can be seen creating another TMP file in the temp folder:
The file can be seen in the temp folder:
The sample also checks for free disk space and get volume information for the current drive
Next we see the sample loading the CABINET resource. This is the item out of which the sample extracts B.exe and put it form of a file in the temp folder
The function call to 01006AA4 is passing pointers to several other functions as parameters and I believe these are responsible for decryption of the CABINET resource for putting together B.exe:
We can see a global allocation called. Could not guess why it used this instead of the LocalAlloc.
Combination of custom XOR and REP MOVS assembly instruction is seen during the process of decryption and writing to memory allocated in the heap:
We can see the CreateFile API call to create the B.exe file
An logically next step is to write to the created file the blocks of memory from the heap (you can see the MZ header being formulated)
The handle 0000000C is the file B.exe
Same process is repeated for another file B.ex_, which seems to be noise. However we can see the two files created in the temp folder:
Next we see the resource item RUNPROGRAM being loaded:
The sample for some reason checks whether RUNPROGRAM resource item contains .inf or .bat file.
Next the sample adds the registry key wextract_cleanup0 under RunOnce
And then it creates another similar registry key under RunOnce
I believe the second key is used to perform the cleanup (deletion of the temp folder and all files inside it). The first key remains in the registry.
Next we see the process B.exe being created:
But unfortunately B.exe crashes and triggers the cleanup. However I was able to salvage the two files B.exe and B.ex_ for further analysis.
Some other resource items are loaded for finishing up like POSTRUNPROGRAM and FINISHMSG:
However that is insignificant and no impact further:
The process exits gracefully:
The two salvaged artifacts:
I decided to check out the hash of B.exe on VirusTotal and found it to be a very recent malware! which was compiled in September 2015 and was also first submitted to VirusTotal in late September:
The original file name of the malicious sample was putty.exe. So it is impersonating putty. Remember we saw earlier from the windows WER (crash report) the Appname, which said it was an SSH, Telnet RSH Program. So somehow it seems to be a modified (trimmed) form of putty with most of the functionality dropped. OR it could be a new file impersonating putty but performing some malicious activity:
So from VirusTotal results I noted that Malwarebytes identifies the sample as Trojan.Bunitu
We can see that the functionality of this malware is use infected endpoints as proxy for remote clients.
The usual IIV for this infection is drop through EPs like Angler or Neutrino. So malvertising leads to EK landing page where the exploitation happens and most probably the initial CAB SFX file is dropped, which when executes and leads to subsequent stage of the attack:
Performing preliminary static analysis on the file shows that the file is not packed and was compiled on Sep 21 2015:
PEStudio shows following indications of maliciousness:
There are two custom resource items in the resource header of the malware:
Strangely we see some libraries (notably odbc32.dll which is usually used for db connectivity and running SQL queries). However we cannot see any library which could be used for setting up socket connections like ws2_32.dll. Nor can we see any library typically used for C2 communications like WinInet or URLMon,
We see some basic anti-debugging symbols highlighted as indicators of maliciousness:
And weirdly we see a lot of SQL related symbols:
I though of performing a string analysis of the original putty.exe and the malware B.exe and found some similarities, which confirms that the original putty.exe has been modified:
The following strings from the malicious binary also do not make sense. It almost seems as if it is making noise to show that is a library management system? Fines, books, authors, reader, borrower...and related SQL queries:
I guess the only way to know to be sure is to first see why the malware crashes, fix the offsets and then perform a dynamic code analysis to see what is it hiding under covers.
Check back soon for that. Thank you for your attention.
Process Activity summary shows no network activity (except for werfault.exe for obvious reasons). However we can see some file and registry related events:
From the File summary we can see the files which were created (and later deleted on crash). We see B.exe and B.ex_ as artifacts of interest, which we somehow need to salvage for further analysis:
One of the artifacts which were not deleted and was able to give some pointers about the nature of the file B.exe was the "Report.wer" (crash report compiled by the kernel). Getting hold of this file was easy as we could see the location of the file from the File Summary. According to the wer report, B.exe Appname is "SSH Telnet Rlogin client". We were able to extract other information from the wer report like the libraries loaded by B.exe at the time of crash.
As we guessed correctly that the runonce entry is not for any
persistence but normal mechanism for self extracting cab files to do cleanup on
reboot. This is most probably the registry entry which is responsible for removal of the B.exe artifact.
The registry entry RunOnce\extractcleanup0 is basically calling advpack.dll.DelNodeRunDll32 and passing the temp folder path (where B.exe is created) as a parameter. I believe this registry entry is responsible for removing the temp folder. I could not find much official material on DelNodeRunDll32 and the stuff I was able to google out, was mostly related to malware activity:
B.exe tries to write a file CSIDL_ in the local folder:
Tries to open a suspicious myapp.exe from C drive but cannot find it. Maybe this myapp.exe is to be dropped by B.exe? But since B.exe crashes there is no myapp.exe.
I decided to do some dynamic code analysis in order to identify the point of extraction of B.exe and save it from deletion.
Firstly we see that a certain binary is compared with hard
coded binary value "xBBx40". It is validating whether this binary
pattern exist or not. The reason is unknown.
The sample gets a file handle on itself and then look for several resources some which are present and some are not. It then loads the resources
The sample also checks the OS version
Same thing for resource items "LICENSE",
"FILESIZES" and writing contents in the process heap
Resource item RUNPROGRAM, is loaded and written in the process heap to be accessed later
Here we see the sample making KERNERL32 API call to find the temp directory path address and then creating the folder "IXP000.TMP". Which we have seen earlier where B.exe will be dropped:
The sample can be seen creating another TMP file in the temp folder:
The file can be seen in the temp folder:
The sample also checks for free disk space and get volume information for the current drive
We can see the sample is getting the address of the procedure ADVAPI32.DecryptFileA
Next we see the sample loading the CABINET resource. This is the item out of which the sample extracts B.exe and put it form of a file in the temp folder
We can see a global allocation called. Could not guess why it used this instead of the LocalAlloc.
Combination of custom XOR and REP MOVS assembly instruction is seen during the process of decryption and writing to memory allocated in the heap:
We can see the CreateFile API call to create the B.exe file
An logically next step is to write to the created file the blocks of memory from the heap (you can see the MZ header being formulated)
The handle 0000000C is the file B.exe
Same process is repeated for another file B.ex_, which seems to be noise. However we can see the two files created in the temp folder:
Next we see the resource item RUNPROGRAM being loaded:
The sample for some reason checks whether RUNPROGRAM resource item contains .inf or .bat file.
Next the sample adds the registry key wextract_cleanup0 under RunOnce
And then it creates another similar registry key under RunOnce
I believe the second key is used to perform the cleanup (deletion of the temp folder and all files inside it). The first key remains in the registry.
Next we see the process B.exe being created:
But unfortunately B.exe crashes and triggers the cleanup. However I was able to salvage the two files B.exe and B.ex_ for further analysis.
Some other resource items are loaded for finishing up like POSTRUNPROGRAM and FINISHMSG:
However that is insignificant and no impact further:
The process exits gracefully:
The two salvaged artifacts:
I decided to check out the hash of B.exe on VirusTotal and found it to be a very recent malware! which was compiled in September 2015 and was also first submitted to VirusTotal in late September:
The original file name of the malicious sample was putty.exe. So it is impersonating putty. Remember we saw earlier from the windows WER (crash report) the Appname, which said it was an SSH, Telnet RSH Program. So somehow it seems to be a modified (trimmed) form of putty with most of the functionality dropped. OR it could be a new file impersonating putty but performing some malicious activity:
So from VirusTotal results I noted that Malwarebytes identifies the sample as Trojan.Bunitu
The usual IIV for this infection is drop through EPs like Angler or Neutrino. So malvertising leads to EK landing page where the exploitation happens and most probably the initial CAB SFX file is dropped, which when executes and leads to subsequent stage of the attack:
Performing preliminary static analysis on the file shows that the file is not packed and was compiled on Sep 21 2015:
PEStudio shows following indications of maliciousness:
Strangely we see some libraries (notably odbc32.dll which is usually used for db connectivity and running SQL queries). However we cannot see any library which could be used for setting up socket connections like ws2_32.dll. Nor can we see any library typically used for C2 communications like WinInet or URLMon,
We see some basic anti-debugging symbols highlighted as indicators of maliciousness:
And weirdly we see a lot of SQL related symbols:
Using BinText to observe the embedded strings, results in
various interesting strings, a lot of them related to SQL queries"
I though of performing a string analysis of the original putty.exe and the malware B.exe and found some similarities, which confirms that the original putty.exe has been modified:
The following strings from the malicious binary also do not make sense. It almost seems as if it is making noise to show that is a library management system? Fines, books, authors, reader, borrower...and related SQL queries:
I guess the only way to know to be sure is to first see why the malware crashes, fix the offsets and then perform a dynamic code analysis to see what is it hiding under covers.
Check back soon for that. Thank you for your attention.
Comments
Post a Comment