Analysis of German Bundestrojaner

Again another analysis, this time of the leaked German federal trojan (even though its less advanced than standard opensc noobware). The German CCC leaked the binaries together with a small analysis. There are already unconfirmed rumours that the company "Digitask" from Hessen, Germany was developing it.

Peter Kleissner, Software Developer

Analysis from CCC and initial thoughts

The analysis from CCC shows it connects to the command & control server using port 443 with a custom protocol (encrypted with AES, ECB mode). There are 2 files:

mfc42ul.dll, 325 KB
CRC32: 86B48835
MD5: 930712416770A8D5E6951F3E38548691
SHA-1: E4F07B5A443CD99FD45CB5E1445AC2C1BE4B455E
Date first seen on VirusTotal: 2011-10-08 19:02:22 (UTC)

winsys32.sys, 6 KB
MD5: D6791F5AA6239D143A22B2A15F627E72
SHA-1: 7BD8D737460C1DBBFC4B250FB1B6B906ED643A2D
Date first seen on VirusTotal: 2011-10-08 19:02:36 (UTC)

CCC said it was not detected by anyone, at the time of writing this detection was 25/34 from both files. It was always said that government malware will probably try - in contrast to real malware - to stay under the radar by not trying to hide itself (with a complex rootkit or so). Federal trojans are not built for the mass - if everything goes right anti-viruses would never get a sample and therefore were not able to make a signature (remember I was working myself at an anti-virus company in the core development team).

Features according to CCC (and below copy & paste from their analysis):
 - making screenshots
 - intercepting VoIP communication (including Skype)
 - loading additional modules

Install path: c:\windows\system32\
Loading: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
Only 32-bit version spotted

AES symmetric encryption key:
49 03 93 08 19 94 96 94 28 93 83 04 68 28 A8 F5
0A B9 94 02 45 81 93 1F BC D7 F3 AD 93 F5 32 93

Some "easter egg" in the communication: C3PO-r2d2-POE

cmd 1: --
cmd 2: Client verbindet sich neu und versucht danach, bisher unbekannte Daten abzusetzen, Code ist ähnlich wie cmd 13
cmd 3: Screencast geringer Bildqualität über eine bestimmte Zeit, wie cmd 9, nur mit einem Argument
cmd 4: Registrieren des Kernelmode-Treibers im Betriebssystem
cmd 5: Installation aller trojanerspezifischen Dateien im Dateisystem; noch ist nicht eindundertprozentig klar, woher die Daten genau kommen, möglicherweise gibt es noch eine Upload-Funktion ähnlich cmd 14
cmd 6: Löschen der Trojaner-Daten vom Dateisystem & Reboot
cmd 7: Entladen des Trojaners
cmd 8: Liste mit allen Softwarekomponenten und Patches
cmd 9: wie cmd 3, aber mit drei Argumenten
cmd 10: --
cmd 11: --
cmd 12: Setzen irgendwelcher Werte (sechs Integer-Werte, geparsed via sscanf)
cmd 13: Screenshot von Webbrowser und Skype
cmd 14: Upload eines Programmes und dessen unmittelbare Ausführung
cmd 15: --
cmd 16: ?
cmd 17: ?
cmd 18: Return 0


The kernel driver is very small (6 KB) and very simple written. It creates a new device "KeyboardClassC" and a symbolic link "KeyboardClassC" (with that making it accessible to user-mode). In the driver object it sets IRP_MJ_READ, IRP_MJ_DEVICE_CONTROL and IRP_MJ_POWER. The power IRP contains nothing interesting, just forwards the IRP for processing (using PoStartNextPowerIrp and PoCallDriver). The IRP_MJ_READ (invoked by user ReadFile or kernel ZwReadFile) is more interesting:

Currently being written!

The missing commands

Where I strongly disagree with the analysis from CCC

There is a GetProcAddress in the dll to get the address of CreateProcess. While CCC suggests 2 theories, that it was used against negative AV heuristics or to hide from researchers I can say with all my confidence this is just against the detection by Avira and other crap AVs. If you want to hide and secure your software against researchers you would not (just) use GetProcAddress (and they probably never have heard of LDR data), you would heavily pack your executable, add anti emulation, anti debugging tricks etc.

Why the fuck CCC do you show so much assembly code? It is noobish like the federal trojan itself to just paste assembly code for no reason. We all know how to use IDA and hex-rays. A simple line "it uses GetProcAddress to resolve CreateProcess address" is enough. Otherwise the analysis is quite ok I have to admit (with the background they are not reverse engineers), just strongly missing an english translation.