English
EspañolStatic analysis of the Dalixy worm
Abstract
In this blog entry is documented the analysis performed to a variant of the Dalixy malware family, also known as LdPinch, Dalia or Trodal. Dalixy is a malicious program with characteristics of both a worm (sending itself through email) and a bot (communication through an IRC chat).
Static Analysis
The first step was to check the strings using BinText. Some of the strings found have as its objective to make the user believe that the software is legitimate, as can be seen on the file’s properties, where the following data was found:
- - Description: Windows Stack Processor
- - Copyright: Microsoft(R) Windows(R) Operating System
- - Comments: Этовесьмаважныйфаилнесмейегоудалить! (A posible translation of this Russian phrase could be “This is a very important file do not dare to erase it!”)
- - Company: Microsoft Corporation
- - Company Contact: support@microsoft.com
- - Original File Name: winlogon.exe
- - Versioning Added By: Windows
- - Язык (Language): Russian
Subsequently, the Exeinfo PE was used to find if the sample was packed, in this case the packer was yoda’s Crypter, which is a free software to compress and cipher executables, although it is known by malware writers to evade antivirus engines.
Some characteristics of yoda’s Crypter are the following:
- The executable has one or more sections called “yC”.
- It may have a block of instructions similar to this:
PUSHAD CALL xxxxxx
POP EBP
SUB EBP, xxxx
MOV ECX, xxxx [There may be other lines of code here]
LEA EDI, xxxx
As shown on the imahe below, extracted from the sample.
- The OEP (Original Entry Point), or the entry point of the executable without packer, is a PUSH instruction with some hex value o MOV, as we will see further down.
1) Process to remove yoda’s Crypter
To unpack, the first step is to open the executable with OllyDbg and to press F8 until you reach the instruction after PUSHAD (that sends the content of the general purpose registries to the stack in this order: EAX, ECX, EDX, EBX, EBP, ESP, ESI, EDI), which is a call to a subroutine. The CALL instruction saves the address of the next instruction on the stack (0042F066) and then jumps to the address indicated on the label (call <label>), which in this case is 0042F066. When this subroutine ends, the program continues its execution on the address stored on the stack, which is 0042F066.
On the registers area we click with the right mouse button the value stored in ESP (Extended Stack Pointer that contains the address of the last value stored in the stack) and select “Follow in Dump”. This allows us to see the content of the memory on the address stored in the register.
In this case, what’s important is not the content of the memory, what we need is to put a breakpoint of type “Hardware, on Access” to stop de execution of the program when it tries to read or write on that address.
With the mouse, we select the first four bytes (4 bytes = 2 WORDS = 1 DWORD) on the area of the dumped memory to place the breakpoint. This can be done by clicking with the right button of the mouse on the selection and choosing the option “Breakpoint”, after that “Hardware, on Access” y finally “Dword”.
We press F9 and the execution stops due to an INT 3 interruption, which is usually used by debuggers to establish breakpoints.
The execution of the program should be continued until it stops because of a memory read access violation, such as the one shown below:
We press the keys Shift+F9once and Olly stops the execution at a hardware breakpoint.
At this point, we scroll down step by step with F7 or F8 until we reach the unconditional jump (JMP) and then we press F9 twice until Olly indicates a write violation.
We press Shift + F9 again and Olly stops at what seems to be a section without relevant instructions, right click on any section of the disassembled code and we select “Analyze This!” to distinguish code data. We press key F9 again and on the jump instruction we press F7 or F8 once.
The “MOV EAX, 0” instruction where Olly stops is the original entry point of this Dalixy sample without the yoda’s Crypter packer. A memory dump must be done on this instruction.
Note: This procedure is specific for this Dalixy sample and might not work with other versions of the packer or with other malicious samples, even if they are from the same malware family.
Next, we open the ImpREC tool and select the active process of the malware. On the OEP field we write the last four digits of the address where Olly stopped and click on “IAT AutoSearch”.
ImpREC detects an address of the import address table; to validate this, we click “Get imports”. We now get to see that all the functions found are valid, which means that we can repair the IAT using the dump generated with Olly. We click “Fix Dump” and select the file that contains the memory dump.
As the log indicates, the repair was done successfully.
2) Registry keys
Using IDA Pro’s free version, we found the strings “99BCryptIV”, “Miranda ICQ DB” and “password”, related to the instant messaging application ICQ, developed by the Mirabilis enterprise. In another code block, a call to the function RegCreateKeyA to create or open a registry subkey that includes the path “SOFTWARE\Mirabilis\ICQ\NewOwners”.
Subsequently two subkeys more are created or opened:
- One for “SOFTWARE\Miranda”, also for instant messaging.
- And another with the name “Software\Far\Plugins\FTP\Hosts”.
It also adds the value “winlogon” to the registry key “Software\Microsoft\Windows\CurrentVersion\Run”
The library that contains the functions related to the management or registry keys is ADVAPI32.dll that the sample calls with the function “LoadLibraryA”.
3) File System
The sample attempts to download three files (dfp.exe, pspv.exe and winnt2.dll) from the URL “http://www.posizionaxxxxxx.com/tools/win...”.
It then creates, or opens, the files “windows.ini”, “windows3.ini” and “win.ini”. And deletes “windows2.ini”.
It searches for a username and a password on the section indicated on AppName on the configuration file (.ini), its path is located in szPath.
It also searches the system for the following files:
- - fethard_keyfile
- - userpref.ini
- - ipass.ini
- - wcx_ftp.ini: That contains the configuration for a FTP client.
- - edialer.ini
- - ws_ftp.ini
- - pal.ini
- - pal95.ini
4) Network Activity
Code blocks related to an IRC channel were also found. First, the inet_addr is used, taking as parameter the string with the IP irc01.megaxxxxxxxx.com, with the standard notation of decimal numbers and points, and returns an adequate number to be used as an IP address. By default, the execution of the program goes on the direction of the green arrow, which in this case is a connectfunction, that requests a connection to a remote host. Otherwise, the gethostbyname is used, to obtain information about irc01.megaxxxxxxxx.comand to try to resolve the name of the host through a DNS server. Otherwise, it waits 6249 milliseconds, which is equivalent to 6.249 seconds, and calls the function inet_ntoa, that receives an address and returns a pointer to a string that must be expressed as an IP.
After trying to connect to irc01.megaxxxxxxxx.com, which is an IRC (Internet Relay Chat) server, with the user “research” (the real name is “dalia asm bot 0.2”) and has as the server “freexxxx.org”, it joins the channel l“#general”. Where it waits until it receives a command and then closes the socket.
The sample is also able to send private messages to the “#general” channel with the command PRIVMESG.
Additionally, it tries to convert the string with the IP address 65.174.xxx.166 into an adequate binary representation and compares the obtained value with 0FFFFFFFFh, which in decimal is 4294967295, equivalent to the broadcast address 255.255.255.255.
The result of this comparison is going to be the same on each execution due to both values being constants; therefore the sample is always going to try to connect to the IP 65.174.xxx.166 and not to the domain “thecpaxxxx.us”. This is an obfuscation method called “garbage code insertion” that consists of adding instructions that do not have any effect or purpose to complicate the analysis of the sample.
After connecting to the IP address mentioned above, it makes the following HTTP request:
GET /images/proxy3.php?i= HTTP/1.1
Host: thecpaxxxx.us
As can be observed, the sample tries to download the file proxy3.php from the domain “thecpaxxxx.us”, possibly using the IP 65.174.xxx.166 as a proxy, unfortunately we could not validate this due to it not being active at the time of analysis. However, there are reports that mention this IP has been used for malicious activities:
http://www.projecthoneypot.org/ip_65.174.123.166
http://www.threatexpert.com/report.aspx?md5=e471cd892f3426f9aa7c0d1c2e17a570
Lastly, strings that referenced an email were found (the account could be used to initiate the propagation of the sample):
MAIL FROM: maypayapxxxx@list.ru
RCPT TO: maypayapxxxx@list.ru
MAIL FROM:< RCPT TO:< Date: Tue, 25 Nov 2003 22:04:50 +0300\r\n MIME-Version: 1.0\r\nContent-Type: text/plain
Dynamic Analysis
At the beginning it was not possible to observe the behavior of the sample because after executing it the process terminated abruptly. As seen on the static analysis, the sample uses certain functions from the ADVAPI32 library related to registry keys, therefore it is possible that the sample checked whether the computer where it was executing was a virtual machine.
To solve this, the registry subkeys that contained the string “VBOX” were modified:
- In HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT we renamed the subkey VBOX__ to NOBOX__
- In HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\SUBSYSTEM we right click on“SystemBiosVersion” and select “Modify” to change VBOX a NOBOX.
After doing this the sample could be executed. TCPView and Wireshark did not register network activity.
On the other hand, on the report generated with RegShot it can be observed that the sample only creates one file called MALWARE.EXE-0C3A805F.pf on C:\WINDOWS\Prefetch\.
On the Prefetch directory you can find some files that contain a registry of the way the computer starts and of the programs executed more frequently. This files help to accelerate the booting process to reduce the time that these programs take to start.
After rebooting the system, the execution of the sample was not detected. It is suspicious that on the static analysis many code blocks and functions related to network services were found but during the execution of the sample we didn’t see network traffic neither on Wireshark no in TCPDump. Using Process Monitor it was discovered that the malicious program tries to call many system libraries, such as NETAPI32.dll y WS2_32.dll, from the same directory where it executed, which in this case is “My Documents”.
This makes us think that the sample expected to be on the C:\WINDOWS\System32 and for this reason it didn’t present more activity. We copied the sample to System32 and executed it again. However, its behavior didn’t change: it only created a file with “pf” extension, there was no network activity and no registry keys were generated. This is probably because the sample requires other Microsoft software to execute or perhaps it was carrying out other virtual machine validations.
The full VirusTotal report can be checked here.
In case of infection caused by this sample, the following website can be consulted: INTECO-CERT
