Tried, Tested and Proven
Over the past few weeks, Portcullis has shared two parts of a three part series on “MutexName: “UFR_Stealer_2600″. The previous articles, part 1, focussed on a one-shot information stealing malware, while part 2, discussed “information gathering”.

In the very last article, part 3, we are going through the data-exfiltration steps that involve data compression and encryption, and finally we analyze the few Anti-Reversing tricks present in this
malware sample.

Data Ex-filtration

Now that the malware is finished collecting data from the host, it will go through a series of steps in order to compress, encrypt, and finally send the data over to the attacker’s FTP server.

The first step involves reading the entire file contents and performing LZ compression over them. Then, it makes use of Windows Crypto APIs in order to generate an AES-256 key which will immediately be used to encrypt the already compressed data.

MutexName: “UFR_Stealer_2600″

Figure 5. AES-256 key (example)

Once compression and encryption is done, the malware creates a custom file header that is prepended to the encrypted data.

This file header starts with the key word “UFR!” and contains important information needed to decrypt and decompress the data from the attacker. This data includes a 32-bit checksum of the encrypted data, as well as other information, such as encryption algorithm used, key size, and of course the generated AES-256 key itself.

Checksum generation algorithm:

00403D3C    55              PUSH    EBP
00403D3D    8BEC            MOV     EBP, ESP
00403D3F    53              PUSH    EBX
00403D40    8B55 08         MOV     EDX, DWORD PTR SS:[EBP+8] ← buffer with encrypted data
00403D43    8B4D 0C         MOV     ECX, DWORD PTR SS:[EBP+C] ← size of encrypted data
00403D46    B8 00000000     MOV     EAX, 0
00403D4B    85C9            TEST    ECX, ECX ← check if size of enc data is zero
00403D4D    0F84 27000000   JE      00403D7A
00403D53    F7D0            NOT     EAX      ← if not, custom 32-bit checksum calculation starts
00403D55    3202            XOR     AL, BYTE PTR DS:[EDX]
00403D57    42              INC     EDX
00403D58    B3 08           MOV     BL, 8
00403D5A    D1E8            SHR     EAX, 1
00403D5C    0F83 05000000   JNB     00403D67
00403D62    35 2083B8ED     XOR     EAX, EDB88320
00403D67    FECB            DEC     BL
00403D69  ^ 0F85 EBFFFFFF   JNZ     00403D5A
00403D6F    83E9 01         SUB     ECX, 1
00403D72  ^ 0F85 DDFFFFFF   JNZ     00403D55 ← loop for all data
00403D78    F7D0            NOT     EAX ← final operation after loop. checksum DWORD is on EAX
00403D7A    5B              POP     EBX
00403D7B    C9              LEAVE
00403D7C    C2 0800         RET     8

File Header:

MutexName: “UFR_Stealer_2600″

Figure 6. Custom File Header

MutexName: “UFR_Stealer_2600″ – Part 3/3

Finally, it appends all the encrypted data to the header and sends the file over to the FTP server. It also copies each of the files containing stolen data inside the “ufr_files” hidden folder that was initially created. Once everything is done it will delete the file from the system’s temp folder.

Anti-Reversing Techniques

The malware is configured not to call the functions that implement the following techniques. However, since it is capable of doing those checks we thought it would be interesting to study and explain them.

1) Virtualization Detection



0085FF40   80000002  |hKey = HKEY_LOCAL_MACHINE
0085FF44   004115D9  |Subkey = "HARDWARE\DESCRIPTION\System"
0085FF48   00000000  |Reserved = 0
0085FF4C   00020019  |Access = KEY_READ
0085FF50   0085FF58  \pHandle = 0085FF58



0085FF3C   00000090  |hKey = 90
0085FF40   004115F5  |ValueName = "SystemBiosVersion"
0085FF44   00000000  |Reserved = NULL
0085FF48   00000000  |pValueType = NULL
0085FF4C   00431C3F  |Buffer = VirusSha.00431C3F
0085FF50   0085FF74  \pBufSize = 0085FF74

Check Against: QEMU, VBOX

2) SandBoxie Detection

GetModuleHandleA → SbieDll.dll

3) Time Elapsed

00404427    33C9            XOR     ECX, ECX
00404429    03C8            ADD     ECX, EAX
0040442B    0F31            RDTSC
0040442D    2BC1            SUB     EAX, ECX
0040442F    3D FF000000     CMP     EAX, 0FF
00404434    0F8F EC000000   JG      00404526

4) Debugger Detection


0040452C    64:A1 30000000  MOV     EAX, DWORD PTR FS:[30]
00404532    8078 02 00      CMP     BYTE PTR DS:[EAX+2], 0


00404542    64:A1 30000000  MOV     EAX, DWORD PTR FS:[30]
00404548    F740 68 70000000 TEST    DWORD PTR DS:[EAX+68], 70

5) Looking for running Tools

Process Enumeration:

FileMon.exe, RegMon.exe

Window Class name:


Window Class name + Title:

The Wireshark Network Analyzer


This article presented an examination and discussion of a one-shot information stealing class of malware. As discussed, the malware doesn’t introduce any kind of persistence to the host which can be considered both good and bad at the same time.

While it is good in the sense that if the malware is executed while the host is not connected to the internet there is no impact, it is dangerous in the sense that its actions might pass unnoticed, since it is only executed once.

It would have been interesting to see the malware also deleting itself once the data ex-filtration is done, but this is not the case.

It is also interesting to note that the malware uses both compression and AES encryption on the stolen data before transmitting it, which of course is done in order to ‘hide’ the data in case it is executed in a corporate environment where network traffic monitoring might be present, another indication that the malware is written with corporate targets in mind.

Written by: Kyriakos Economou of Portcullis.

Any questions/feedback?

If you have any further question/feedback regarding the MutexName: “UFR_Stealer_2600″ article – part 3, please do get in touch! We would like to hear your thoughts. You may contact us at: