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 184.108.40.206 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 CRC32: C1CBB57A 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.