The malware in this report has been blogged about before by a Russian researcher1, he referred to is as “Obscene Trojan” so that’s what I will also call it and we will go over it’s functionality in depth later in this blog but the more interesting part to me is the initial layer around the malware, it’s in Golang! This layer serves both as a wrapper layer that you would normally expect to see with crypters but also a dropper as it drops the decoded malware to detonate it instead of loading it into memory but the concept of a golang crypter is interesting nonetheless and after going through all the layers I stepped back and checked what the detection ratings were and was incredibly surprised to find that these wrapper layers took a 12 year old malware from completely detected to almost FUD.

Initial sample: 769d1396b0cef006bcaafd2de850fc97bf51fd14813948ef2bc3f8200bcb5eab

This Golang wrapper is designed to ZLIB decompress and RC4 decrypt the next file hidden inside itself.

Copy Data and load key

Decompress and Decrypt

Dumping the data blog out we can verify this manually.

>>> open('test.zz', 'wb').write(t)
>>> zobj = zlib.decompressobj()
>>> t2 = zobj.decompress(t)
>>> t2[:100]
>>> rc4 ='vckxjm')
>>> t3 = rc4.decrypt(t2)
>>> t3[:100]
'MZ\x90\x00\x03\x00\x04\x00\x00\x00\x00\x00\xff\xff\x00\x00\x8b\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x0e\x1f\xba\x0e\x00\xb4\t\xcd!\xb8\x01L\xcd!This program cannot be'

Next layer: 0015001917bc98a899536c6d72fcf0774e5b14ab66f07ccbdc4cc205d70475dd

After decoding the next exe file out we are left with another golang wrapped file that does the same thing as the previous layer but it has a differen’t RC4 key.

Same golang packer

Next unpacked file: de2688f007dac98b579d5ed364febc8bb07bc3dc26e4b548d659ecb1974d9f46

This file appears to be a SFX RAR exe but at the end of the day it is also just another layer and is designed to drop an EXE file to disk and detonate it.

Dropped binary: afa085105a16b1284a811da11db2457778c4a267f2fa8a551dec3b8a665c11f9

This file looks like a compiled lua binary but we don’t really need to decompile it as we can see a large base64 blob inside it and a similar looking 6 byte string below it.


Base64 decoding and then RC4 decrypting this blob gives us our next binary: 1ca71bba30fb17e83fea05ef5e2d467f86bff27b6087b574fa51f94f0f725441

This binary is the unpacked trojan that a blog from 2008 calls “Obscene Trojan”[1], coincidentally it also has a compilation timestamp of 2008 so I’m unsure if it was just recently uploaded or if someone is testing the crypter layers for detection.

Has some anti debugging by using obscure opcodes that some debuggers can have problems with.

Anti-Debugging opcode

Also a VM check[3].

VM Check

The malware has most of its important strings encoded using a single byte XOR.

Python>for addr in XrefsTo(0x40f09e, flags=0):
	addr = addr.frm
	addr = idc.PrevHead(addr)
	offset = GetOperandValue(addr, 0)
	t = GetString(offset)
	t = bytearray(t)
	for i in range(len(t)):
		t[i] ^= 2
0x40f22eL advapi32.dll
0x40f256L kernel32.dll
0x40f27eL GetProcAddress
0x40f2acL GetEnvironmentVariableA
0x40f2daL WinExec
0x40f308L CopyFileA
0x40f336L SetFileAttributesA
0x40f364L RegSetValueExA
0x40f392L RegOpenKeyA
0x40f3c0L RegCloseKey
0x40f421L cftmon.exe
0x40f442L spools.exe
0x40f463L ftpdll.dll
0x40f541L Software\Microsoft\Windows\CurrentVersion\Run\
0x40f5d8L SYSTEM\CurrentControlSet\Services\Schedule
0x40f68bL SystemDrive
0x40f8c2L windir
0x40f8f0L \system32
0x40f938L \Local Settings\Application Data
0x40f97fL \drivers\
0x40f9b7L \Local Settings\Application Data\
0x40f9efL \update.dat
0x40fa16L \drivers\
0x40fa2dL sysproc.sys
0x40fa54L \mpr.dat
0x40fa7bL \mpr2.dat
0x40faa2L \mpr32.dat
0x40fb61L \mpz.tmp
0x40fb88L \r43q34.tmp
0x40fda5L wininet.dll
0x40fdcbL InternetOpenA
0x40fdf7L InternetOpenUrlA
0x40fe23L InternetReadFile
0x410007L Content-Type: application/x-www-form-urlencoded
0x410304L c:\stop

There is also an encoded file stored inside of it which was also blogged about in 2008 but was discussed as being downloaded by the previous trojan instead of being dropped directly[2]: f198e63cc1ba3153e27905881bcb8a81fa404f659b846b972b1c8f228e4185d4

The trojan sets the filename that it will have.

Filename is decoded

DLL decoded

This DLL will hook send, WSASend, recv and WSARecv; primarily for harvesting data from traffic over ports 110, 80, 25 and 21. The harvested data is written to files while the main trojan piece will read the files and ship the data off.

Receiving function hooks:

Receiving function hooks

Sending function hooks:

Sending function hooks

The receiving hook checks which port is being used before harvesting data.

Receiving hook overlay

The data being harvested looks like email data which will be written to one of the files.

Write emails to file

The send hook function performs similar harvesting but it also has different code for port 21 and 80 traffic. For port 21 it will check for ‘USER’ and ‘PASS’ such as with FTP traffic.

Look for USER

Look for USER

The data will then be harvested.


The data will be written to a different file.

Write FTP info to file

The send hook code will also look for ‘gzip,’ in outbound over port 80 and overwrite it, probably to prevent an Accept-Encoding header from including gzip.

Overwrite gzip on outbound port 80 traffic

As I mentioned at the beginning of the blog the most interesting aspect of this to me personally is the ability of a few simple wrappers and a golang crypter taking an old malware to almost FUD.

VT Detections of files