Pretending to be a Zeus Gameover Bot

By: Dennis Schwarz -

Zeus Gameover is a banking trojan that started appearing in the wild sometime in early 2012. As with Citadel, Ice IX, and KINS, it is based on the leaked Zeus trojan source code. The most significant difference between Gameover and its immediate family members is that it uses a peer-to-peer (P2P) network for its command and control (C&C). What also stands out is that there appears to be only one instance of the Gameover botnet, whereas Citadel for example has hundreds of distinct ones.

This post releases some proof of concept code (read: works for me) that helps malware researchers to further understand and also interact with Gameover. More specifically it:

  • Extracts the initial set of P2P peers (starter peers) from a Gameover memory dump
  • Queries each of the starter peers for their “P2P network configuration” file
  • Decrypts and partially parses the configuration into something more human readable
  • Enumerates part of the P2P network

Prior Work

The code is meant to complement the existing body of Gameover malware research. It takes bits and pieces from the following sources and ties them together into something a bit more tangible:

Much appreciation goes to these folks and their work.

Code Availability

Python code will be available on Arbor Network’s GitHub. It depends on the pefile Python module and requires a Gameover memory dump to operate on. The dump used in this demonstration came from a sample that has a MD5 of 216b53fe8c704978468e8bfe1aad1152.

Please note that this is a live malware sample and the code has the ability to connect to and query a live malware C&C network! Stay safe.

Demonstration and Walk-Through

The walk-through data is initialized via:

>>> fp = open(“AML-12420355.rsrc-52307867.dynamic.memdump”, “rb”)
>>> memdump = fp.read()
>>> fp.close()
>>>
>>> from ZeusGameover import ZeusGameover
>>> gameover = ZeusGameover(memdump)

or

$ python ZeusGameover.py AML-12420355.rsrc-52307867.dynamic.memdump

First off, a hardcoded “sample configuration” file is extracted from the memory dump and de-XOR’d with a key stored in the relocation section (.reloc) of the binary (see the get_memdump_config function). This configuration file contains an RC4 key state used later to decrypt the “P2P network configuration” file:

>>> rc4_key = gameover.get_memdump_rc4_key()
>>> print “”.join(rc4_key).encode(“hex”)
a30a0c0f383c42509cf83a0523624520a8c11a7517bab7d97e04dae94bbc390d5a445d6341823b36cc37eab399aed7c3538a1edb847bd8004f5beb4a73e310f1a5e8ec09aff60131f0c4199a3d7f6fc8695c91f416925598ca6e646da243abd29661a971c7fc97b478062d8ef2e5ad2a7c5efb0ebf02d09db8cf47ee80677a4d2ebd0b727487d1039f891c59f326609340d3aa3522cedf28159ba0c2a4b6883ee2496518beefd427b025b1ac1fa61d338ff96c1b7766d632cdfe12b2c034865f30eddcf7dec9e468c548d5297657bb588d4ca1905424ff4ee16b8be0832f94796a95857d9e81e67051fdcbe752fa2c07b91446112ba7088c21ddc6b5f556133f0000

The “sample configuration” file also contains the starter peers used to bootstrap communications with the P2P network (see the get_static_peers function):

static peer #1
ip: 74.96.168.126, udp port: 6710, rc4 key: c2056f859dd9fdf008507a637a0da568d16f825b

static peer #2
ip: 74.203.254.118, udp port: 6630, rc4 key: c046b43fbcec2475831083aa56aef3d5b72ceda6

static peer #3
ip: 70.30.53.56, udp port: 8204, rc4 key: a398bc30c436194c025513cb4bcafc1287460293

Using their respective UDP ports and RC4 keys, each of the starter peers is sent a “version” query to see if the peer is still alive. If so, the query will return version information and a TCP port (see the query_peer_for_version function):


static peer #8
ip: 85.100.41.9, udp port: 8835, rc4 key: d6c0d41b51dcb4b76205f3ab00f50af4411a22b9
binary version: 70314355, config version: 76101317, tcp port: 2997

If the TCP port is active, it is queried for the “P2P network configuration” file (see the query_peer_for_config and parse_config_response functions):


static peer #9
ip: 94.247.29.186, udp port: 3415, rc4 key: a5f5957b3acc687da57e5287837ea70c9ef827f6
binary version: 70314355, config version: 76101317, tcp port: 4948
config saved (1033680 actual bytes)

The “P2P network configuration” file is decrypted with the RC4 key state from above and lightly parsed. Parsing includes de-XORing and, if necessary, zlib decompressing the individual data “sections” of the config (see the parse_config function):

$ strings 94.247.29.186.config

[start item number: 22003, type: 0x10000001, packed size: 854, unpacked size: 2201]
@https://bancopostaimpresaonline.poste.it/bpiol/lastFortyMovementsBalance.do?method=loadLastFortyMovementList
@https://*.tecmarket.it/*
@https://www3.csebo.it/*
@https://qweb.quercia.com/*

[start item number: 2, type: 0x40000000, packed size: 36, unpacked size: 36]

http://kessura.com/php/s_c.php

[end item number: 2]
[start item number: 3, type: 0x40000000, packed size: 36, unpacked size: 36]

http://kessura.com/php/g_c.php


[start item number: 14, type: 0x40000001, packed size: 196, unpacked size: 298]
ERCPQ
inject
<script type=”text/javascript” src=”scripts/service?id=7″ language=”JavaScript”></script>S
ERCPM
inject
style=’visibility:hidden’
[end item number: 14]

Over time, the “P2P network configuration” can be queried via new Gameover samples and a timeline of when changes are made and where those changes are start to appear:

gameover_configs

$ diff -u jan_25.config.strings jan_28.config.strings
— jan_25.config.strings 2014-01-29 15:59:54.000000000 -0500
+++ jan_28.config.strings 2014-01-29 15:59:41.000000000 -0500

[start item number: 1, type: 0x40000000, packed size: 39, unpacked size: 39]
-http://nessura.com/oz/service.php
+http://kessura.com/oz/service.php
[end item number: 1]

In addition to the configuration data, the starter peers can be used to further enumerate the P2P network (see the enumerate_peers function):


peer #21
ip: 115.162.112.200, udp port: 5782, rc4 key: d29e52a567b266b53c8269433c5462c2cf0c4fdd

peer #22
ip: 64.25.199.1, udp port: 6977, rc4 key: d75dfdb4f96e623546940e8a8c03872e07eed9d2

peer #88
ip: 99.190.124.179, udp port: 1671, rc4 key: d3526a00abf536c6a1df7d8607c9635c0bd98dc1

peer #89
ip: 153.160.176.252, udp port: 4714, rc4 key: d27382dbec8a01a3c4b405e063a1c10267313d19

From a set of twenty starter peers and using a breadth first search an interesting pattern emerges:

breadth_first

This graph shows how many total unique peers are at each level of the enumeration. While this certainly does not represent the entire Gameover P2P network, it does start to give an idea of its size and scope. Thanks to Kenny MacDermid for the above idea and help on the visual.

Conclusion

Zeus Gameover is a banking trojan that has been around for a couple of years now. It continues to be very active and as of this writing is in ASERT’s top five of tagged malware samples. This is interesting because Gameover is also a well-researched malware family. Usually the longer a family exists and the more focus the malware research community gives it, the less active the malware becomes. But, Gameover continues to be in the limelight and continues to infect and affect a large number of people and companies across the Internet.

This post hopes to complement and further the existing malware research into Gameover. In addition, it hopes to also assist enterprises and service providers to detect and mitigate infected peers and banks and financial institutions to determine if and how they are being targeted.

Comments

  1. Hi Dennis, Arbor,

    In our research we have shown that crawling severely underestimates the network size. We have also — in depth — studied Zeus P2P, showing that it spans more than 100k bots. You may want to reconsider the way how you phrase your result interpretation.

    Detailed results see: http://christian-rossow.de/publications/p2pwned-ieee2013.pdf

    I also do not consider it a good idea to crawl the botnet without knowing the exact implication this has in terms of topology changes.

    Just my two cents.
    Christian

    1. Dennis Schwarz 02/17/2014, 2:55 pm

      Hey Christian,

      Thanks for the comment. My post was far less focused on crawling/determining the size of the net and more about piecing together the bits and pieces of the protocol, crypto, compression, etc. of the referenced papers and to make something tangible out of them.

      Thanks,
      Dennis