Another Macro Script Technique in Executing Malware

Recently I came across with a macro malware that uses a technique quite new to me. If macro is enabled, macro script does the following:

1. Save the Doc file as RTF file, 300.rtf and 301.rtf
2. Open the 300.rtf file with an embedded PE file
3. Then execute the PE file

Lets start analyzing the file and see how it successfully used the above trick.

Upon inspecting the file in Hiew we could see that there is an embedded PE file. But by simply opening the file in Word doesn't mean that the PE file will run in the system, but with the use of macro script that is possible.

Existing macro script in files. These macro scripts are password protected.

Extracted Macro script

By inspecting 300.rtf we could notice that there is an embedded object. 

Using the following instructions macro file were able to open 300.rtf, embedded PE file will be extracted to TEMP folder. Thus, macro script were able to successfully execute the file.

Set sttKaka = CreateObject("Word.Application")

sttKaka.Visible = False

Set docWord = sttKaka.Documents.Open(TCA)

This technique is only feasible using Microsoft Word 2010 and Microsoft Word 2013, with Microsoft 2007 and below it will encounter Privacy Warning. 

It is highly adviseable to disable macro to avoid this type of malware from compromising your system.

Read More

New Crypto 3.0 sample

August 11, 2015, one of our systems managed to get a new sample belonging to the family of Cryptowall 3 (Crowti).

Using ThreatSecure Networks' behavioral determination, we were able to confirm the "maliciousness" of this sample as it exhibited the following notable behaviors

"Runs an exe in the system folder"
"Creates a hidden file"
"Known malicious behavior, Crowti related"
"Opens Windows configuration files"
"Searches for credentials"
"Executes non-standard memory operations"
"Creates a registry entry to start itself at each boot"
"Disables or removes Windows services"
"Checks for kernel debugger"

Cryptowall is a known ransomware that encrypts files on a targeted PC. It urges the victim to pay in exchange for decrypting the "hostaged" files.

Fig 1. HELP_DECRYPT.PNG

One of the most noticeable features of this sample, is it's icon, which is technically nothing (See Fig 2)

Fig 2. Notice the "invisible" icon?

The sample also beacons out to known malicious IP addresses, attempting to download and POST data gathered from the victims PC.

ip-addr.es

myexternalip.com/raw

curlmyip.com

glamazona.com

fortecegypt.com

Read More

Uncovering a new MFC downloader

Last July 23, 2015, ThreatTrack's new product, ThreatSecure Network (TSN), uncovered a new sample that was not detected by any major antivirus vendors. Using TSN's unique behavioral determination engine, we were able to tag that a particular sample going through one of our appliances was possibly malicious.

Our engine determined that it performed anomalous behaviors some of which are
   Nonstandard memory operations
   Creates suspended or unsuccessful process
   Sleeps for a long period of time
   Beacons out to remote locations
 
Sample md5: 759c8c5b2b8cf9cd4dcbc1beee1cf3b7

Looking at its internals, the sample is compiled using c++ MFC. Possibly in an attempt to make it harder for analysts to reverse engineer what it does. Delving more deeply and using tools that are on my disposal, I was able to find the function that the MFC calls that performs a malicious behavior.
Initially, trying to find the malicious code is a bit tricky. The sample itself was compiled using MFC.
I could also use IDA and debug it side by side with Olly, but I'm kinda lazy so I just downloaded the .lib files that would allow me to resolve the API names from the ordinals.
Tracing through the calls, I found an interesting API on the MFC42.dll memory space that accepted 5 arguments (Fig 1)

Fig 1

The interesting part here is that this points to an API that would eventually call a function inside the sample we're debugging. Tracing a bit more and we landed on a curious set of codes that does some sort of copying.

 Fig 2

Fig 2 illustrates the snippet of code that copies part of the malware onto the stack and jumps to it. This in itself is malicious, as starting from Windows XP SP2, Microsoft has implemented a technology that prevents data from executing on certain memory locations (DEP).

So what the engine told me about "NonStandardMemory operations" was true. What about the rest?

To make it easier for me, I dumped the parts of code that it copied on the stack, inserted it to a "container" file and launched IDA :) This way, even though it has several levels of encryption, I'll be able to follow the jumps and calls, and tag it while I debug it in Olly. 

Fig 3

Fig 3 Shows that multiple functions that writes code into the  memory process of a suspended thread and after some time, resumes it. This in turns executes another "copy" of it in memory.

Now, this sample contains 2 more executables inside its body which are encrypted. These are the ones responsible for connecting to a remote location, in turn downloading and executing another executable in memory. Doing more research yielded the family connected to this downloader sample was also seen trying for the following remote URLs

89.136.39.204/loader/arisx06.exe (seen inside the sample)

89.136.39.204/arisx06.exe

89.136.39.204/loader/b0be001.exe

89.136.39.204/loader/cclub11.exe

89.136.39.204/cclub02.exe

89.136.39.204/arisx06.exe

89.136.39.204/sdhfjkl.exe

89.136.39.204/pod2/xiitoui.exe

89.136.39.204/pod1/priyo03.exe

89.136.39.204/loader/cclub11.exe

89.136.39.204/mobile7.exe

89.136.39.204/loader/jera001.exe

89.136.39.204/pod1/priyo03.exe

89.136.39.204/loader/cclub11.exe

77.122.146.34/pod2/gavrill.exe

77.122.146.34/gavrill.exe

77.122.146.34/rain003.exe

77.122.146.34/pod1/mobile7.exe

77.122.146.34/suba002.exe

77.122.146.34/loader/cclub02.exe

Read More

[BE CAUTIOUS] Dragon Ball Z: Resurrection of F MALWARE and SCAM

Be wary of downloading movies in torrent sites.  Executables can also be executed with a file size as huge as a gigabyte.  

A recent Dragon Ball Z movie from Japan was released entitled Dragon Ball Z: Resurrection 'F'  has been making rounds as of this writing.  References at: http://en.wikipedia.org/wiki/Dragon_Ball_Z:_Resurrection_%27F%27

Searching torrents for this movie shows a small number of seeds.

Let's check the top seeded torrent's Trackers.

Domains points to a .coppersurfer.tk, demonii.com, and tfile.me.

Here's the interesting part.

Notice the .exe file name extension instead of .avi or .mkv or the like.

All 6 torrents shown from the top points to downloading a .exe file.  Could be a malware.  The downloaded executable has an md5 of e62607261e5138d76497e3ccc092e20b.  It is an NSIS compiled SFX.

But while downloading it, here's another one but rather a scam.  Googling for this movie's torrent would usually end up with something like this page.

Following the piratetorrents.net link directs to this page.

Downloading the torrent and leeching it shows these files to be downloaded.

The movie is RAR compressed and is password protected.  Along with the whole package is a README.txt that contains.

Going to the link where the password is redirects to this site.

A very obvious scam.  Didn't bother continuing to all that scam process.

Read More

Unpacking MFC Compiled CryptoWall Malware

Unpacking MFC Compiled CryptoWall Malware

Introduction

First and foremost, this article does not intend to analyze what CryptoWall malwares are (since many malware researchers did that already) but instead this analysis is focused on unpacking MFC compiled cryptowall.

You can also download this MFC tutorial by Externalist on this site https://tuts4you.com/download.php?view.2509 for additional references.

I used IDA Pro and Ollydbg hand in hand when debugging to get a better overview of the malware when unpacking.

What is MFC?

MFC or Microsoft Foundation Class is a collection of classes most commonly used in object oriented programming. Think of MFC as a wrapper for windows API that are written in C++.

So, why MFC?

Since MFC are wrapped windows API, the commonly known windows API to us malware researchers are now hidden inside a MFC library making static analysis on malwares such as cryptowall quite difficult.

Here is what the imports of a MFC compiled file looks like:

Imports of MFC42.DLL

Woah!! No string names at all? Only ordinals? Don't fret, we can still continue to analyze this file.

If you have IDA Pro installed, it will automatically load the corresponding library for you making the import names for MFC42.dll visible.

Let's begin..

First, lets take a look at the WINMAIN of our sample (9DB8BE981E9CDFCB583030E0057345AB)

Following the MFC call instruction leads us to a dead-end. So what now?

Based from experience, I know that packed malwares will attempt to reconstruct it's import API from kernel32.dll at some point. So from there, lets load it in OllyDbg and put a breakpoint in LoadLibraryA. Press F9 (run) a couple of times until a familiar "kernel32.dll" string with an address within the scope of our file is visible in stack.

Press Alt+F9 to return to user code, then trace from there and let's look for a decryption routine.

I found the decryption routine at 

.text:00401370 push esi ;
.text:00401371 mov esi, ecx
.text:00401373 call READ_TO_MEM ;
.text:00401378 push 54638
.text:0040137D mov ecx, esi
.text:0040137F call DECRYPT_FUNC

where it will first read a portion of itself to higher memory (Function@00401373) then proceed to decrypt a size of 0x434Ah.

Take note of the memory location because execution will be transferred from there.

In this case, the memory location is 00980228 and lets call this UNPACKED01 Function.

Typical to packers is that they will always attempt to rebuild their Import Address Table by preparing the windows API strings to be used together with using LoadLibrary and GetProcAddress combo.

In this example, the packer prepares its strings directly in stack as a way of obfuscation making it not readily visible to the naked eye of the researcher.

debug029:0098047F mov byte ptr [ebp-20h], 'k'
debug029:00980483 mov byte ptr [ebp-1Fh], 'e'
debug029:00980487 mov byte ptr [ebp-1Eh], 'r'
debug029:0098048B mov byte ptr [ebp-1Dh], 'n'
debug029:0098048F mov byte ptr [ebp-1Ch], 'e'
debug029:00980493 mov byte ptr [ebp-1Bh], 'l'
debug029:00980497 mov byte ptr [ebp-1Ah], '3'
debug029:0098049B mov byte ptr [ebp-19h], '2'
debug029:0098049F mov byte ptr [ebp-18h], '.'
debug029:009804A3 mov byte ptr [ebp-17h], 'd'
debug029:009804A7 mov byte ptr [ebp-16h], 'l'
debug029:009804AB mov byte ptr [ebp-15h], 'l'
debug029:009804AF mov [ebp-14h], bl
debug029:009804B2 mov byte ptr [ebp-0A0h], 'G'
debug029:009804B9 mov byte ptr [ebp-9Fh], 'e'
debug029:009804C0 mov byte ptr [ebp-9Eh], 't'
debug029:009804C7 mov byte ptr [ebp-9Dh], 'M'
debug029:009804CE mov byte ptr [ebp-9Ch], 'o'
debug029:009804D5 mov byte ptr [ebp-9Bh], 'd'
debug029:009804DC mov byte ptr [ebp-9Ah], 'u'
debug029:009804E3 mov byte ptr [ebp-99h], 'l'
debug029:009804EA mov byte ptr [ebp-98h], 'e'
debug029:009804F1 mov byte ptr [ebp-97h], 'F'
debug029:009804F8 mov byte ptr [ebp-96h], 'i'
debug029:009804FF mov byte ptr [ebp-95h], 'l'
debug029:00980506 mov byte ptr [ebp-94h], 'e'
debug029:0098050D mov byte ptr [ebp-93h], 'N'
debug029:00980514 mov byte ptr [ebp-92h], 'a'
debug029:0098051B mov byte ptr [ebp-91h], 'm'
debug029:00980522 mov byte ptr [ebp-90h], 'e'
debug029:00980529 mov byte ptr [ebp-8Fh], 'W'
debug029:00980530 mov [ebp-8Eh], bl 

List of strings used is listed below.

• kernel32.dll
• GetModuleFileNameW
• CreateFileA
• VirtualAlloc
• GetFileSize
• ReadFile
• CloseHandle
• myapp.exe
• GetSystemDirectoryA
• explorer.exe

It then traverses the values of LoadLibraryA and GetProcAddress in kernel32.dll. An interesting note here is that you will never see a string "LoadLibraryA" or "GetProcAddress" assembled in stack or somewhere in memory. This is because, the packer used its own hashing algorithm where the string hashes of LoadLibraryA, GetProcAddress and kernel32.dll are already precomputed.

debug029:00980263 nop
debug029:00980264 push 0D5786h ; hash of "LoadLibraryA"
debug029:00980269 push 0D4E88h ; hash of "kernel32.dll"
debug029:0098026E call UNHASHER
debug029:00980273 mov [ebp-4], eax ; EAX = kernel32.dll:kernel32_LoadLibraryA
debug029:00980276 push 348BFAh ; hash of "GetProcAddress"
debug029:0098027B push 0D4E88h ; hash of "kernel32.dll"
debug029:00980280 call UNHASHER
debug029:00980285 mov [ebp-8], eax ; EAX = kernel32.dll:kernel32_GetProcAddress

It will then check the existence of the file "%systemdrive%:\myapp.exe" (C:\myapp.exe) or "%windir%\explorer.exe.\" (C:\Windows\explorer.exe.\). If either exists, the malware will go into an infinite loop and system infection will be bypassed. Also, you may see a 100% CPU utilization by the malware process. Malware code authors may have used this function in order to not get their own system infected when writing/testing codes.

This function may have been copied over from a known malware family called "Soraya" in which the malware terminates and discontinue system infection when the file C:\myapp.exe exists. But in this case instead of terminating, it goes into an infinite loop.

It will then allocate another memory location using VirtualAlloc, copies itself yet again to the allocated memory, and then looks for a dword marker in order to know which offset it will start decrypting.

The dword marker is known to be 0xA2658111 in this sample.

009809AA C685 34FFFFFF A2 MOV BYTE PTR SS:[EBP-CC],0A2
009809B1 C685 35FFFFFF 65 MOV BYTE PTR SS:[EBP-CB],65
009809B8 C685 36FFFFFF 81 MOV BYTE PTR SS:[EBP-CA],81
009809BF C685 37FFFFFF 11 MOV BYTE PTR SS:[EBP-C9],11

Once found, it will decrypt 0x3AACh bytes starting at +0x14h from the marker offset. The decrypted code will then be copied once more to a newly allocated memory space. Execution will also be transfered afterwards to the decrypted code.

From here, we have successfully unpacked the first layer of cryptowall.

But wait, there's more...

If you think, that we are done, then you are mistaken my friend. There is one more layer to unpack in order to get to the real Cryptowall code.

So let's get started :)

Here is a preview of what the next set of codes looks like:

CRYPTO_UNPACK2 Function has 8 options total depending on what is pushed in stack before it is called.

These options are:

• 0 = Exit process
• 1 = Unpacked compressed data to allocated memory 
• 4 = Verify priviliges and create mutex "UACMut"
• 5 = Check for existence of sbiedll.dll module (Sandboxie) in running processes 
• 6 = Check for existence of VBoxService.exe and vmtoolsd.exe in running processes
• 7 = Run unpacked cryptowall in memory.
• 8 = Copy itself as system.pif to %ALLUSERSPROFILE%\Start Menu\Programs\Startup and in %USERPROFILE%\Application Data with hidden and system attributes, create REGRUN entries, and can also disable firewall service
• 9 = Traverses registry to get default web browser application, also verifies iexplorer.exe if it is 32-bit, 64-bit version is skipped.

Note that there is no option 2 and 3.

To summarize it, the typical execution sequence for this malware is the following:

Push 1 - Call CRYPTO_UNPACK2
|- Push 6 - Call CRYPTO_UNPACK2
   |- Push 5 - Call CRYPTO_UNPACK2
      |- Push 4 - Call CRYPTO_UNPACK2
         |- Push 8 - Call CRYPTO_UNPACK2
             |- Push 7 - Call CRYPTO_UNPACK2 (Spawn unpacked cryptowall as process)
Push 0 - Call CRYPTO_UNPACK2 (Exit Process)

At start of CRYPTO_UNPACK2 Function, it will reconstruct its strings and needed windows API with the same method as done previously. 

For reference, here is the list of strings that will be populated in stack.

• kernel32.dll
• shell32.dll
• advapi32.dll
• GetProcAddress CreateProcessA
• CreateProcessW
• CreateToolhelp32Snapshot
• Process32First
• Process32Next
• Module32First
• Module32Next
• CloseHandle
• GetCurrentProcess
• GlobalAlloc
• OpenProcessToken
• GetTokenInformation
• AllocateAndInitializeSid
• EqualSid
• LookupAccountSid
• OpenMutexA
• CreateMutexA
• CreateFileA
• CreateFileW
• GetFileSize
• ReadFile
• GetSystemDirectoryA
• GetSystemDirectoryW
• SetFileAttributesW
• SHGetSpecialFolderPathW
• RegOpenKeyExA
• RegOpenKeyExW
• RegSetValueExA
• RegSetValueExW
• RegQueryValueExA
• RegQueryValueExW
• RegCloseKey
• CreateDirectoryW
• ExitProcess
• Sleep
• GetFileTime
• SetFileTime
• CopyFileW
• VirtualAlloc
• GetTickCount
• IsWow64Process
• OpenProcess
• DuplicateHandle
• NtUnmapViewOfSection
• VirtualAllocEx
• WriteProcessMemory
• GetThreadContext
• SetThreadContext
• ResumeThread
• VirtualProtectEx
• TerminateProcess
• NTReadVirtualMemory

Looking back at the execution sequence posted above, Push 1 - Call CRYPTO_UNPACK2 will decrypt more of its encrypted data not surprisingly with the same procedure done on the first layer.

It will check (again) for a dword marker in its encrypted data in order to get the offset where to start the decryption routine. This time the dword marker is 0x34E812AEh.

debug031:013C2795 _looForMarker: ;
debug031:013C2795 cmp byte ptr [ecx+edi], 34h ; Compare Two Operands
debug031:013C2799 jnz short _notMarker ; Jump if Not Zero (ZF=0)
debug031:013C279B cmp byte ptr [ecx+edi+1], 0E8h ; Compare Two Operands
debug031:013C27A0 jnz short _notMarker ; Jump if Not Zero (ZF=0)
debug031:013C27A2 cmp byte ptr [ecx+edi+2], 12h ; Compare Two Operands
debug031:013C27A7 jnz short _notMarker ; Jump if Not Zero (ZF=0)
debug031:013C27A9 cmp byte ptr [ecx+edi+3], 0AEh ; Compare Two Operands
debug031:013C27AE jnz short _notMarker ; Jump if Not Zero (ZF=0)
debug031:013C27B0 cmp [ebp+arg_0], ebx ; Compare Two Operands
debug031:013C27B3 jnz short loc_13C27BD ; Jump if Not Zero (ZF=0)
debug031:013C27B5 lea edx, [ecx+4] ;
debug031:013C27BB jmp short _notMarker ; 

When the marker is found, it will call its decryption routine to decrpyt another chunk of data.
Voilà!! Its another MZ-PE file (why am I not surprised?). This new win32 file is actually the REAL Cryptowall malware. You can dump this in olly if you want to have a local copy of it.

It will then check if it is being run under a specific environment (sandboxie, vboxservice and vmware) and when found true will force exit its execution. (Push 6 - Call CRYPTO_UNPACK2, Push 5 - Call CRYPTO_UNPACK2)

It will then verify if its running with administrative privileges and create a mutex name "UACMut" when successful. (Push 4 - Call CRYPTO_UNPACK2)

Next, it will create a copy of itself located in %ALLUSERSPROFILE%\Start Menu\Programs\Startup\system.pif and %USERPROFILE%\Application Data with hidden and system attributes. It will also create regrun entries pointing to its copy to ensure automatic execution at windows startup.

Firewall service may also be disabled from using the command line "net stop Mpssvc" (Push 8 - Call CRYPTO_UNPACK2)

The newly unpacked MZ-PE file (unpacked cryptowall) will then be executed in memory by spawning a suspended process of itself but replacing all of its contents to that of the newly unpacked cryptowall using WriteProcessMemory API before finally calling ResumeThread. (Push 7 - Call CRYPTO_UNPACK2)

This is where unpacking ends and the real cryptowall malware starts. You can continue analysis of the unpacked cryptowall malware if you want, but my job here is done :)

Christopher D. Del Fierro

Read More

Upatre: .ENC File Extension

Cybercriminals uses different techniques to pass through different kinds of network intrusion defenses the users have in their system to avoid malwares. This time criminals have found a new way to deceive users and be able steal important information by encrypting the file and making it unexecutable with a file extension of either “.ENC” or “.EXE”. These files are known to be downloaded by Upatre malwares.

Upatre malwares sizes are ranging from 5KB-10KB only. This malware size is noticeably small compared to other malwares since its main role is to just download “.enc”  or “.exe” files, decompress it then executes it. In order to evade malware detection, downloaded files magic bytes are ZZP and without the downloader the downloaded files are completely un-executable.

Sample of downloaded file

The Downloader

cef76fa7b4b30f76c7b6d2eefa30d944

It will first check if the malware is running with its desired filename from %TEMP% folder. If not it will create a copy of itself with its desired filename then execute it using ShellExecuteW.

Check if the existing filename is budha.exe

Create and Execute budha.exe

It will connect to the following sites to download another malware which is the encrypted one (“.enc” or “.exe” files).

• dcmsservices.com/images/stories/slides/pdf.enc
• electriciansdublinireland.com/wp-content/uploads/2014/01/pdf.enc
• freebiegalore.com/facelift/pdf.exe
• freebiesvaults.info/freebies/nucleus/images/pdf.exe

This file is also the one responsible in decrypting and decompressing the downloaded file. In the above memory dump at offset 60, the first four bytes are the decryption keys using XOR operand. But before decrypting the downloaded files it will first check if the magic bytes of the downloaded file are ZZP\0. Decrypted files are in a compressed form and are needed to decompress using RTLDecompressBuffer

Magic Bytes checking

Decryption and Decompression routine

Copy of decrypted file

Note: ZZP/0 is not included in bytes to be decrypt.

If the above check fails, it will skip the decryption part and proceed on checking the MZ header. It will create a copy of decompressed or a valid win32 PE downloaded file in %TEMP% folder and then execute it.

MZ header checking and creating a copy of downloaded file

The Downloaded File

The downloaded file contains encrypted file in resource section.

Encrypted resource

Decrypted resource

It parses resource section through the FindResource, LoadResource and LockResource APIs instead of LoadBitmap so that it can copy its data to another application.

This malware is simply the loader of the encrypted Win32 file in Resource section. It uses process hollowing technique to load the said file but instead of loading legitimate process, it creates another process of the downloaded file in a suspended state.

Then the malware will unmap the original code from memory in the host process using ZwUnmapViewOfSection API, and use VirtualAllocEx to allocate memory for the new code.

The malware will write its new code into the hollow host process using WriteProcessMemory. The data to be written into the hollow host process is from resource section of the downloaded file (0x40555A). Then the malware will simply resume the suspended process using ResumeThread.

The hallowed process contains an encrypted chunk of code where in these codes are responsible for calling the functions in creating a copy of itself.

It will create a folder in %APPDATA% with a random folder name, first character is always in capital letters. This folder contains a copy of this malware also with a random filename.

Code snippet in generating random folder and malware name

Sample folder and malware name

Then this malware will execute the created copy of itself using CreateProcessW.

It will enumerate all of the running processes and check the SID length of each process. In this case if the SID length is 0x1c the malware will create thread that run into the virtual address space of this process through CreateRemoteThread.

Read More