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

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    September 2015
    S M T W T F S
    « Aug    
  • Email Subscription

  • About Us

    Author Archive - Jayronn Christian Bucu (Senior Research Engineer)

    Several days ago, Microsoft released a security advisory disclosing a new zero-day vulnerability in older versions of Windows. It was reported that it was being abused by a malicious PDF file (TROJ_PIDIEF.GUD) to deliver a backdoor (BKDR_TAVDIG.GUD) onto affected systems in “limited, targeted attacks.”

    We independently obtained samples of the backdoor, which is the final payload in this attack. Besides being delivered by a malware targeting a new zero-day vulnerability, the backdoor is noteworthy for its use of multiple anti-analysis techniques that aren’t typically used together.

    Hiding from debuggers

    As a first step to thwart debugging, the malware creates a new thread which continues its malicious routines. The original thread is then deleted, blocking debugging.

    It also makes an API call to NtSetInformationThread for the newly-created thread it created. This is commonly used to set the execution priority of a thread. However, the malware sets the THREADINFOCLASS to 0x11 (ThreadHideFromDebugger). This prevents debug information from the new thread from being sent to the debugger.

    This is normally done by RtlQueryProcessDebugInformation to prevent deadlock in certain debugging scenarios, such as remote debugging. However, here it prevents the debugger from gathering information, making analysis more difficult.

    Here is the code that demonstrates this technique:

    Figure 1. Code sample

    Code Injection via NtCreateSection

    The malware created a single section which is mapped twice. The first mapped is in its process context, while the second mapped is in the newly-created target process. This enables the malware to allocate memory to the target process, and it is able to access/modify the memory on the target process by accessing the counterpart memory mapped on its own context.

    Figure 2. Code sample

    Arbitrary code execution exploiting Windows API flaw

    To execute its shellcode, the malware exploits flaws in the Windows API call SetWindowsLong. We have seen UPATRE malware family also using this technique.

    Figure 3. Code sample

    ShellCode derived from the main body:

    The malware reuses many portions of its executing code, which is to be injected into target processes. For analysts, this has advantages and disadvantages. One advantage is that since the code to be injected is a copy of the currently running code, it eliminates the need for re-analysis.

    For an analyst, however, this can introduce complications. If he has placed several breakpoints on the current executing code and wasn’t able to remove them, be the malware code would be injected with the patched breakpoint. However, debuggers implement breakpoints by placing INT3 in the code being debugged.

    The end result would be that the patched shellcode would be patched with multiple occurrences of INT3. This would mean that the target process would itself be frozen.

    Consider a case where the injected process is explorer.exe. When INT3 is executed in its context, explorer.exe would freeze, affecting the debugging environment (unless it, too was attached to the debugger.) This complicates the debugging process for an unwary analyst.

    Figure 4. Code sample

    Multi-threaded and multi-process:

    This backdoor starts multiple threads and processes for its activities. The threads under the original malware process are responsible for:

    • Creating another thread that would be hidden from a debugger
    • Shellcode execution by exploiting Windows API flaws. If the operating system is not affected by the exploit, the shellcode would just be launched as a thread of the target process.
    • Injecting explorer.exe with code.

    The threads running under the context of explorer.exe are primarily responsible for injecting code into specific processes. Four browsers are among the processes specifically targeted for code injection: Internet Explorer, Mozilla Firefox, Google Chrome, and Opera. In addition, it also monitors for the creation of ~tmp133.tmp in the system temporary folder. If this file is created, it terminates its own thread.

    The threads running under the process targeted by explorer.exe are responsible for decrypting and decompressing the code for the backdoor’s main routines. Everything else up to that point has merely been to avoid analysis and detection.

    The decompressed backdoor code has no PE header. However, other portions of the executable file are present, such as the code, data, import table and fixup table. Before passing control to the decompressed code (which has directly loaded to memory), the unpacking routine is able to the following:

    • pre-process the sections
    • parse the import table to gather the needed APIs
    • parses the fixup table to relocate the decompressed component’s address to be aligned with the current memory location

    The main backdoor

    When one inspects the structure of the backdoor, one can see that it has export table that with the following characteristics:

    • DllName: Down.dll
    • Export functions: ModuleStart, ModuleStop, start

    The ModuleStop function terminates the backdoor’s own thread. The others all execute the backdoor’s main routines. These characteristics are consistent with a DLL file.

    Once again, analysis prevention was a key part of this backdoor. It avoids running its malicious routines if it finds any of the following network tool processes already running:

    • dsniff.exe
    • ethereal.exe
    • ettercap.exe
    • snoop.exe
    • tcpdump.exe
    • windump.exe
    • wireshark.exe

    The backdoor collects a wide variety of information from the system and encrypts it before sending it to its command-and-control (C&C) server:

    • computer name
    • country name
    • current date
    • current directory
    • drives, each drive type and each drive’s space (free/used)
    • files in certain directories (i.e. root folder of the drives, temporary folder, etc)
    • Installed Windows updates
    • IPv4 TCP connection table
    • IPv4 User Datagram Protocol (UDP) listener table
    • local group
    • network resource (network shares, shared printers, etc.)
    • operating system info
    • processor info
    • running processes
    • system directory
    • system language
    • time zone
    • uptime
    • user accounts
    • user language
    • user name

    Here is a sample of a memory dump containing the above information:


    Figure 5. Memory dump with system information

    Any information collected in this way is uploaded via HTTP POST requests to two potentially compromised WordPress blogs, whose URLs have the following format:

    • http://{compromised site #1}/wp-includes/sitemap/
    • http://{compromised site #2}/wp-content/plugins/online-chat/

    The screenshot below shows the encrypted contents of these requests:


    Figure 6. Encrypted contents of POST request

    Backdoor commands:

    This backdoor receives its commands from its C&C server in the form of a website. The commands are actually between the <div> and </div> tags in the received website. (This is why we called this backdoor TAVDIG, as the information is inside the DIV tags.) The decrypted data is expected to be an initialization file with a section named CONFIG. Commands in this section include:

    • delete – if set to no, the backdoor continues; otherwise it stops
    • del_task – if not set to no, will delete the file indicated in name
    • down – downloads a file from a specified URL
    • exe – run a command; can include a file downloaded with the down command
    • name – indicates a file to be deleted
    • result – if set to 0, result from exe command will be sent to C&C server; otherwise it will be disregarded


    Our findings indicate that whoever was responsible for this attack was capable of some sophistication. Not only was BKDR_TAVDIG.GUD delivered by a malware exploiting a zero-day vulnerability, the backdoor also uses multiple techniques in order to try and make analysis more difficult.

    This incident highlights the potential pitfalls of sticking with older versions of operating systems. They lack the additional hardening and improved security of newer versions; in addition both will soon face the end of their support lifecycles. This means that no further security patches will be released. Windows XP’s support will end in April 2014; Server 2003’s ends in July 2015.

    Posted in Exploits, Malware | Comments Off on Windows XP/Server 2003 Zero-Day Payload Uses Multiple Anti-Analysis Techniques

    We recently came across some malware of the SOGOMOT and MIRYAGO families that update themselves in an unusual way: they download JPEG files that contain encrypted configuration files/binaries. Not only that, we believe that this activity has been ongoing since at least the middle of 2010. A notable detail of the malware we came across is that these malware  hide their configuration files. These JPEGs are located on sites hosted in the Asia-Pacific region, and we believe that these malware families are used in targeted attacks in the region as well.

    Analysis of the JPEG updates

    While the contents of the JPEG file are encrypted, we were able to decrypt and analyze the contents of these files. We can divide these into three groups:

    • configuration file (Type A)
    • configuration file (Type B)
    • binary content (either DLL or EXE files)

    The first kind of configuration file (Type A) is similar to what we’ve seen with other malware. It contains information that allows the malware to process commands from an attacker, change settings/modules, and update itself. Among these settings are URLs where other malicious JPEG files are hosted. In addition, these files indicates that the attacker may have already compromised the targeted organization(s), as some of the information pertains to specific machines or individuals within.

    The second kind of configuration (Type B) file appears to be related to antivirus software. It contains the process names of multiple AV products from various vendors, as well as information about hostnames within the target network. Here is a portion of a Type B file, after decoding:




    *avgwdsvc.exe*|AVG|*tmlisten*,*ntrtscan.exe*,*tmntsrv*|Trend Micro|*360sd.exe*|360sd|


    This configuration is much shorter than Type A configuration. There are also values in this configuration that is evidence that the infection is already in the stage 2 of the attack.

    In addition to configuration files, the JPEG files can also contain executable files which can either be updates for the malware itself or new malware that well be installed on affected systems.

    JPEG File Hosting and Appearance

    These JPEG files are hosted on various websites mostly located in the Asia-Pacific region. At least some of these sites appear to have legitimate content, meaning they were compromised to host thsese files.

    Here are some screenshots of the JPEG files we’ve seen:

    We have obtained multiple samples of these JPEG files, and based on these, we believe that this method of updates was first used in June 2010, and is still in use today. The frequency of updates varies wildly: at times there were periods with near-daily updates, and at other times months went by between updates.

    Data Exfiltration

    Using the information from the decrypted configuration files, we were able to retrieve  emails sent by this malware. These contain an encrypted attachment named tplink2.bin. This file includes the following information:

    • Hostnames and IP addresses on the infected machine’s network
    • List of JPEG files already accessed by the malware
    • Detailed OS version information, including security updates installed

    With additional analysis from Adam Sun

    Posted in Malware | 1 TrackBack »

    Recently, we spotted a new malware family that was being used in targeted attacks – the EvilGrab malware family. It is called EvilGrab due to its behavior of grabbing audio, video, and screenshots from affected machines. We detect EvilGrab under the following malware families:


    Looking into the feedback provided by the Smart Protection Network, EvilGrab is most prevalent in the Asia-Pacific region, with governments being the dominant sector targeted. These are consistent with known trends in targeted attacks.

    The full report on EvilGrab may be found at the Threat Intelligence Resource on Targeted Attacks together with other resources discussing targeted attacks.

    Attack Vectors

    The most common arrival vector for EvilGrab malware is spear phishing messages with malicious Microsoft Office Attachments. In particular, malicious Word files and Excel spreadsheets that contain code that targets CVE-2012-0158 are a favored way to spread this new threat.

    Information Theft

    EvilGrab has three primary components: one .EXE file and two .DLL files. The .EXE file acts as the installer for all of the EvilGrab components. One of the .DLL files serves as a loader for the other .DLL file, which is the main backdoor component. Some variants of EvilGrab delete the .EXE file after installation to cover its tracks more effectively.

    EvilGrab attempts to steal saved login credentials from both Internet Explorer and Outlook. The credentials of both websites and email accounts are targeted for theft by attackers.

    In addition to this, it can also “grab” any played audio and/or video on the system using standard Windows APIs. As part of its backdoor functionality, it can also take screenshots and log keystrokes. All of these are uploaded to a remote server to be accessed by the attacker.

    Targeted Applications

    EvilGrab has some unique behaviors if it detects certain installed applications. First of all, it is explicitly designed to steal information from Tencent QQ, a Chinese instant messaging application. It steals and uploads all the memory used by QQ. This may be able to reveal the contents of conversations or the members of the user’s contacts list.

    EvilGrab will attempt to inject itself into the processes of certain security products. In the absence of these security products, it will choose to inject itself into standard Windows system processes. ESET, Kaspersky, and McAfee have all been specifically targeted by EvilGrab for process injection.

    Backdoor Activities

    EvilGrab possesses backdoor capabilities that allows an attacker to carry out a wide variety of commands on the affected system. This grants them complete control over a system affected by EvilGrab.

    As part of its command-and-control traffic, EvilGrab contains two separate identifiers, which may serve as campaign codes and/or trackers. One of the identifiers has been seen with the following values:

    • 006
    • 007
    • 0401
    • 072002
    • 3k-Ja-0606
    • 3k-jp01
    • 4k-lyt25
    • 88j
    • e-0924
    • LJ0626
    • RB0318

    The other field has been seen with two values:

    • V2010-v16
    • V2010-v24

    We have observed that the main backdoor component of those variants having the V2010-v24 identifier have a proper MZ/PE header. While most of those variants having the V2010-v16 identifier have some parts of their MZ/PE header overwritten with “JPEG” strings.

    Update as of September 26, 2013

    The MD5 hashes of the files involved in this attack are:

    • 2E991260E42266DB9BCCFA40DC90AE16
    • 7ED71CF0B98E60CC5D4296220F47C5A2
    Posted in Malware, Targeted Attacks | Comments Off on EvilGrab Malware Family Used In Targeted Attacks In Asia


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