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 0×11 (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
Conclusion
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.
Leave a reply
