The rise of TOR-based botnets

Botnet

2

TOR-based botnets are not a new trend and were already being discussed a few years ago at Defcon 18 (“Resilient Botnet Command and Control with Tor”). But in the last year we’ve been able to confirm some interesting facts concerning the use of these ideas in real-world botnets. This topic was already discussed around the beginning of 2013 in a Rapid7 blog post (“Skynet, a Tor-powered botnet straight from Reddit”). In early July Dancho Danchev also posted information about a TOR-based C&C for a ring-3 rootkit.

We have been tracking the rise of TOR-based botnets this summer. In July two different malware families were detected that use the TOR hidden service protocol for stealth communication with C&C’s. The TOR hidden service protocol is well-suited to organizing stealth communication channel with a C&C but is slow for stealing high volumes of data from an infected machine. For cybercriminals the most useful way to use the hidden service protocol is for communicating with C&C, getting update for configuration information, or downloading additional malicious modules.

In July ESET researchers detected two different types of TOR-based botnets based on the malware families Win32/Atrax and Win32/Agent.PTA. Both botnets have form-grabbing functionality for possible further fraud operations. The Atrax botnet looks more complex and interesting, so we begin this blog by analysing it.

Win32/Atrax.A

Win32/Atrax.A is an interesting TOR-based backdoor family which is installed by a simple downloader program we detect as Win32/TrojanDownloader.Tiny.NIR. The decompiled main routine of this downloader looks like this:

1

More interesting information is that its hardcoded domain name is “kundenservice-paypal.com”, registered in the middle of June (12-Jun-2013) (so named to pass itself off as PayPal Customer Service).

All trojan components and the downloader binary were compiled in July, according to information extracted from the PE header time stamp.

2

After download and execution of the main dropper file, the decompress routine is started for three PE modules: TOR client, DLL module for x86 and DLL module for x64 platform. For decompression WinAPI function RtlDecompressBuffer() Is used. The code for the decompiled decompress routine looks like this:

3

Before installation the dropper makes simple checks, so as to detect whether it’s on a virtual machine and any debugger activity. The bot ID is an MD5-calculated hash based on unique values from the system registry DigitalProductID and MachineGuid. Here’s the call graph for the routine that infects the machine (you’ll probably need to click it to view it as it’s an awkward size for the blog page.):

4

This routine tries during the last stages of execution to search for the initialization of additional AES-encrypted plugins in the %APPDATA% directory. All plugins are named according to the following pattern: %APPDATA%\CC250462B0857727*. Plugins are decrypted on the fly during the bot initialization process but the encryption key depends on the infected machine. This approach to plugin encryption makes it difficult to extract information during the forensic process.

The TOR client is embedded into the dropper executable and stored in the %APPDATA% directory as an AES-encrypted file. Initialization of the TOR connection takes place after checking for an active browser process and injection of TOR client code into the browser process by NtSetContextThread(). Win32/Atrax.A supports code injection techniques for x86 and x64 processes.

5

All communications between the C&C and the bot are made via a special HTTP request function call. The prototype of this function looks like this:

6

If the second parameter request_via_tor setup is in the TRUE state all communications will be initialized by the TOR client. TOR communications have the following call graph:

7

After execution a new thread with the Tor client software will be set up using the following parameters:

  • AUTHENTICATE – password for authentication
  • SIGNAL NEWNYM – change proxy-nodes chain

When the first connection is made with the C&C, Atrax.A sends collected information about the infected system to an address inside the TOR network:

8

It isn’t possible to ascertain the original C&C IP address or domain with a TOR enabled connection but it is possible to use the address generated in the TOR network for analysis. After we played a little bit with the internal address in the TOR network we found the following login panel for C&C:

10

We recognize the name Atrax on the login screen. It’s the main reason why we chose the name Win32/Atrax.A for detection by ESET products.

Win32/Atrax.A supports the execution of remote commands for setting up bot behavior on the infected machine. The main routine for recognizing and executing remote commands looks like this:

9

The list of supported remote command types:

  • dlexec – download and execute file
  • dlrunmem – download file and inject it to browser
  • dltorexec – download TOR executable file and execute
  • dltorrunmem – download TOR executable file inject it to browser
  • update – update itself
  •  install – download file, encrypt with AES and save to %APPDATA%
  • installexec – download file, encrypt with AES and save to %APPDATA% and execute afterward
  • kill – terminate all own threads

After reconstruction of the structure of remote commands and the execution algorithm we tried playing with the C&C protocol. We tried to send a status to C&C confirming a successful plugin installation process and fortune smiled upon us: we got a path to the next plugin download:

11

Two different type of plugins were downloaded: the first is a form grabber and the second is a password stealer. All downloaded modules were compiled in July according to the compilation time stamp:

12

[Form Grabber]

13

[Password stealer]

Win32/Atrax.A is interesting example of a TOR-based botnet with AES encryption for additional plugins and a unique encryption key dependent on hardware parameters of the infected machine for its generation. We continue to track activity for this botnet.

Win32/Agent.PTA

Another family tracked in July and using a TOR-based communication protocol is Win32/Agent.PTA. This is not a new malware family and has already been tracked by ESET since 2012. But the TOR-based protocol is new functionality detected during this summer. This trojan also uses TOR hidden service protocol for communicating with command control panel. Agent.PTA has embedded configuration information encrypted by RC4 cypher with C&C addresses inside the TOR network. Decrypted configuration information looks like this:

14

Win32/Agent.PTA is a trojan with a simple form grabber and the ability to download additional plugins. This trojan also can activate a SOCKS5 proxy by receiving a special command from the C&C.  

Conclusion

This year we had already detected TOR-based botnets but during the summer we have observed a growth in the numbers of malware families starting to use TOR-based communications. The TOR-based botnets make it really hard to pursue investigation and C&C location tracking. But we have demonstrated with Win32/Atrax.A botnet that ways to analyze communication protocols have not changed and all the old tricks work with addresses in a TOR network too.

Anton Cherepanov, Malware Researcher
Aleksandr Matrosov, Security Intelligence Team Lead

                                                                                                                     

SHA1 hashes for analyzed samples:

Win32/TrojanDownloader.Tiny.NIR -                      7c19ad6b9b229bf559e7cfbbec2d1eb089318b54
Win32/Atrax.A (dropper) –                                          a7da414a5033cd3178fa5dc2cd52017e5e658b98
Win32/Atrax.B (formgrabber32) -                             5bcb59b0025ba397d30938d16bc6904475bb3f89
Win32/PSW.Agent.NXG (atraxstealer32) -            16b7b43625ccba34f67258fa1c4b8017e8d0e747
Win32/Agent.PTA -                                                         3a30e858294d214c68d14069c615017626d1b39d

 

 

Author Aleksandr Matrosov, ESET

  • TheRealChx kay

    It’s funny how downloaders use the same method URLDownloadToFileA/W and yet they still get to get away with that API.

    And with the TOR network thing. It’s a joke. Sure it’ll keep someone with less motivation from reverse engineering the bot, but it’s just the same as using direct connection. It’s just a matter of being found out. And as we have seen here, no different than using direct HTTP or whatever protocol is used.

    Oh, and another thing is; it’s funny how they use obvious text commands like “dlexec” hahaha. Those are pretty easy to recognize.

    Call me a size-freak, but that’s wasting memory and time you know. You can use a single unsigned char for commands and reduce overhead from string functions.

    Up to 256 possible functions could be implemented with just one or all bits combined representing a function/command, with a simple comparison on an 8-bit boundary.

    struct MY_PROTOCOL
    wMagic DW 0xDEAD ; Yup. You know your data ain’t legit when it don’t go this
    bVersion DB 0×01 ; protocol/app version
    bCmd DB ? ; up to 0xFF
    dwLength DD ? ; Length of any subsequent data
    ends

    CMD_DL_EXEC = 00000001b
    CMD_DL_EXECMEM = 00000010b


    XOR eax, eax
    MOV al, [_struct_my_protocol + 1]

    CMP al, CMD_DL_EXEC
    JE .dl_exec

    CMP al, CMD_DL_EXEC_MEM
    JE .dl_exec_mem

    JMP .uknown_cmd

    Easy and simple instead of using string functions and wondering if a string has a null terminator

  • L33T H4CK3R

    The point of having it in tor is so that even if someone finds your server they can’t take it down dumbass. To take a server down you need an ip and you can’t get that with tor even if it is a direct connection.

Follow Us

Automatically receive new posts via email:

Delivered by FeedBurner

2 articles related to:
Hot Topic
24 Jul 2013
ESET Virus Radar

Archives

Select month
Copyright © 2014 ESET, All Rights Reserved.