Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    October 2014
    S M T W T F S
    « Sep    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • About Us

    The TDSS family of malware remains a significant threat to users today, largely due to its powerful stealth capabilities that hide its main components from security applications. This can be seen in the large number of detections that we see regularly, as shown in the following chart:

    Click for larger view

    We’ve even seen TDSS variants that use high-profile vulnerabilities to spread. Samples of a new TDSS variant, WORM_TDSS.TX, use the infamous LNK vulnerability (first brought to public attention by STUXNET) to propagate. (The shortcut file is detected as EXPL_CPLNK.SMA.)
    There are two techniques that TDSS uses for its autostart routines:

    • Randomly choosing a system driver file (normally seen in %Windows%System32Drivers), modifying its resource section, and using this to directly read hard disk sectors and to assemble its .DLL file for its main malware behavior.
    • Modifying the Master Boot Record (MBR) and using this to directly read hard disk sectors and to assemble its .DLL file for its main malware behavior.

    The second technique was already discussed in the blog post “Mebroot Variants Behaves Like TDSS.” In this post, I will only concentrate on the first technique and will not discuss the installation process of the malware.

    The patched and compromised file is detected as BKDR_TIDSERV.DZ. TDSS targets BootExecute applications that are started by the Session Manager (smss.exe) before invoking the initial command (Winlogon in Windows XP) and before various subsystems were started. User-mode applications are not yet running at this point. Because they run so early, there is significant restriction on BootExecute applications: they must be native applications.

    In this context, “native” means that only the Windows NT Native API, a resident in ntdll.dll, is available. At this stage, the Win32 subsystem, composed of the kernel-mode win32k.sys component and the user-mode client/server runtime CSRSS have not yet been started by SMSS. Not even the Kernel32 library is usable by BootExecute applications. This can be seen in the screenshot below:

    Click for larger view

    These applications are used for special tasks that must be performed before everything else has started on the system but remain in the domain of user mode.

    After the Session Manager loads this compromised driver, it will execute the driver’s entry point. This is set by the malware to point to the overwritten code of the resource section. During this time, the system is still booting up. The following chart shows where TDSS interferes in the system’s startup procedure:

    The malware code set its buffer by calling nt!ExAllocatePool then copying its malware code to the allocated buffer. It then executes the driver’s original entry point before calling the API nt!IoRegisterPlugPlayNotification, which will execute a callback routine that is set to the allocated buffer that contains the malware’s code.

    Here’s part of the code that TDSS used to perform the above-mentioned routine:

    .rsrc:FC5470B0 lea ecx, [ebx+364h]
    .rsrc:FC5470B6 push ecx
    .rsrc:FC5470B7 push ebx
    .rsrc:FC5470B8 sub ebx, 8122F44Bh
    .rsrc:FC5470BE add ebx, eax
    .rsrc:FC5470C0 add ebx, edi
    .rsrc:FC5470C2 push ebx
    .rsrc:FC5470C3 push [ebp+arg_0]
    .rsrc:FC5470C6 lea eax, [ebp+var_20]
    .rsrc:FC5470C9 push eax
    .rsrc:FC5470CA push 1
    .rsrc:FC5470CC push 2
    .rsrc:FC5470CE push 48399F96h
    .rsrc:FC5470D3 push [ebp+var_4]
    .rsrc:FC5470D6 call get_api
    .rsrc:FC5470DB call eax ; {nt!IoRegisterPlugPlayNotification (8057f628)}
    .rsrc:FC5470DB ; this will execute the callback routine, which is the
    .rsrc:FC5470DB ; malware codes copied on allocated memory.
    .rsrc:FC5470DB ;
    .rsrc:FC5470DB ; this malware's callback routine was computed in ebx.

    The callback routine reads more malware code directly from the hard disk, decrypts it, and execute the read data. TDSS ensures that it read the correct data by checking if it can find the string “TDLF” at offset 0. It exits if it cannot find this string.

    After this, the malware will prepare several strings that it can display using the DBGPrint API. These will only be displayed in debug mode. These prepared strings include:

    • Everybody’s a jerk. You, me, this jerk. That’s just my philosophy
    • Dude, meet me in Montana XX00, Jesus (H. Christ)
    • I felt like putting a bullet between the eyes of every panda that wouldn’t screw to save it’s species.
    • Tempers are wearing thin. Let’s hope some robot doesn’t kill everybody
    • You people voted for Hubert Humphrey, and you killed Jesus

    It will then create two random eight-character strings such as pccjapfteyrkiuhi. It will create the following files in the said folder:

    • Config.ini: The main malware configuration file.
    • Tdlcmd.dll: The main .DLL file that contains all of the malware’s behaviors, including API hooks.
    • Rsrc.dat: The original resource section of the patched .SYS file.
    • .TMP file: A copy of tdlcmd.dll.

    Here is a sample of what Config.ini contains:

    [main]
    version=3.273
    quote=Tempers are wearing thin. Let's hope some robot doesn't kill everybody
    botid=72607dae-9d01-4c33-9a85-bc9ed0c92cf6
    affid=20409
    subid=0
    installdate=3.9.2010 7:20:44
    builddate=2.7.2010 5:13:9
    rnd=73586283
    [injector]
    *=tdlcmd.dll
    [tdlcmd]
    version=3.82

    The content of these malware files were directly read from the hard disk. It first allocates a shared buffer using nt!IoAllocateMdl then use atapi!IdePortDispatch (This API may vary, depending on the hard disk driver. It can be iastor.sys for some Dell machines.) to read directly from the hard disk and put it in the allocated shared buffer.

    Here’s a snippet of codes on how the malware called atapi!IdePortDispatch:

    seg000:810EF079 lea ecx, [ebp+var_6C]
    seg000:810EF07C mov [eax+4], ecx
    seg000:810EF07F mov eax, [esi+60h]
    seg000:810EF082 dec byte ptr [esi+23h]
    seg000:810EF085 sub eax, 24h ; '$'
    seg000:810EF088 push esi
    seg000:810EF089 mov [esi+60h], eax
    seg000:810EF08C push edi
    seg000:810EF08D mov [eax+14h], edi
    seg000:810EF090 call [ebp+arg_4] ; ss:0010:fc942814={atapi!IdePortDispatch (fc304852)}

    After reading the data directly from the hard disk, it will decrypt this data then check for the string TDLD for data, TDLF for files, or TDLN for free blocks.

    Careful analysis allowed us to assemble the main .DLL file by just monitoring the malware’s use of the API atapi!IdePortDispatch or to create breakpoints from where the malware will use this API. Doing this, we were able to create a perfect image of the .DLL file. This can be unpacked using normal UPX software and loaded to commonly known debuggers such as Ollydbg and IDAPro.





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon






     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice