Archived Blog

Analysis of a Win32.Delf Variant

04.03.2008 - 9:47 AM

We have been noticing quite a few malware samples having references to or communicating with Google's SMTP servers. This post dissects one of these samples and in the process attempts to illustrate to the reader some reversing techniques and information gathering techniques, while explaining the behavior and impact of this virus. At the end of this post you will discover the reasoning for this SMTP reference and see a rather revealing screenshot showing its purpose.

Static Analysis

The first step we took was to verify whether the executable was compressed or protected. Loading this executable in PEiD resulted in "Borland Delphi 6.0 - 7.0". Unless the signature was faked (explanation here), we can go straight to analysis. One of the great things about a Delphi application is that it can be decompiled and analyzed statically. You can use either DeDe by DaFixer[TMG] or DE Decompiler by GPcH. Because DeDe is typically used, we chose DE Decompiler for experimental purposes. If you open the malware in DE Decompiler, you see the following:

Figure 1:


With our first glance at these results, we already have quite a bit of information. As denoted by the circled areas, we now have reduced the language to Delphi v7 and we know the original program name is WormList. Identifiers typically describe meaning, so it is a fair assumption that we are dealing with a worm that maintains some list. On the left side are some procedures with describing identifiers as well. It is now fair to assume that the malware gets the computer name, deletes a file, checks for an Internet connection, and does "something" in FormCreate. It is also important to note the use of Spanish (NameComputador) because this gives hints to the author or targeted audience. Double-clicking the FormCreate procedure shows the relevant assembly code and some additional interesting information:

Figure 2:


We found our reference to the Google SMTP server and some other interesting information, such as a reference to a file called msnlist.txt. Using already gathered intelligence, we can pretty safely conclude that this is an MSN worm that likely retrieves or stores contacts from this text file. If you continue to browse the procedures and code, you run across this:



A quick search online for TldSMTP reveals that it is part of an Internet component suite called Indy Sockets, which supports protocols such as SMTP, POP3, NNTP, and HTTP. We have found the means of communication for the worm now. Hopefully this example has shown that static analysis is complementary to dynamic and behavior analysis.

Dynamic Analysis

Even though static analysis may reveal some convincing evidence, dynamic analysis should always follow to confirm conjectures or reveal other capabilities. Referencing Figure 1 from above, we can use the addresses of the procedures as good initial breakpoints. Load the executable into OllyDbg, set breakpoints on the addresses, and run it. The first hit is the beginning of FormCreate(), and the second hit is IsConnected(), which simply does a call to InternetGetConnectedState. If you want to continue analysis but don't have an Internet connection, you can modify the return value of InternetGetConnectedState (check MSDN for valid values).

More often than not, static analysis does not reveal as much as it did in this instance. So, to illustrate some dynamic analysis techniques, we ignore the fact that this specifically targets MSN as this was discovered via static analysis. If we were to run in OllyDbg again, it would throw an exception and the process would exit (if not installed or you are not currently signed in). How could you tell it was looking for or trying to utilize Messenger? Look at the following:



EAX references "CoMessenger" right before a call that causes an exception/process exit. A quick search online for "CoMessenger" reveals a Windows/MSN Messenger library for use in Delphi. Thus, this call is equivalent to its Messenger := MessengerAPI_TLB.CoMessenger.Create. After installation of Messenger and debugging back to this point, you will again confirm that it was required because the second circled area denotes a call going elsewhere to a file named Msgsc. The Executable Modules window in OllyDbg (Alt+E) confirms that it is C:\Program Files\Messenger\Msgsc.dll, a DLL used by the Messenger application.

As the code progresses, more calls are made to Msgsc.dll and the stack starts to contain your buddies' email addresses. If you set a breakpoint on CreateFile you will see that msnlist.txt is written to the same directory as the malware and contains these email addresses. As you continue stepping you will also notice a reference to "Lista MSN (", and if you step further you will see the number of stolen contacts is concatenated to this string. The stolen contacts are then emailed to a specified address where the author can retrieve them. To see the success of this malware all one has to do is use the stored Gmail credentials in the binary and look at the author's inbox:



The blurred areas are the infected host's computer names, the number in parentheses denotes the number of email addresses stolen from the victims contact list, and each email has the msnlist.txt file in attachments with the actual stolen email addresses.

Conclusions

Malware authors will always borrow code or components to speed up the development process. Understanding how to find these components and how they are used is important. Something as simple as performing a search for a string found in the code can yield fruitful results and give you a much greater understanding.

Security Researcher: Joren McReynolds

Bookmark This Post: