German phishing scam spreading globally

December 8, 2014

Another wave of phishing emails written in German is spreading worldwide. Let’s have a look at its internals and discuss ways of not getting caught.

Malware analyst and яeverse engineer

In recent weeks, we detected another wave of phishing emails, written in German, pretending to be a billing invoice sent from various well-known companies such as Vodafone. Instead of a real invoice, they contain a link to an archive with a malicious code that can infect users’ PCs. The original wave of this malware campaign was already observed earlier this year primarily targeting Germany. This time, it is spreading worldwide. However, they are still in German, which helps identify them as a scam.

In this post, we give a brief technical description of this threat and provide several tips how to not get caught by similar phishing threats.


Phishing Emails

We have found several different versions of these emails that claim to be sent from Vodafone, Telekom Deutschland GmbH, Volksbank, and other companies with a faked sender name (e.g. including the official logos. As we can see in Vodafone’s official statement, these companies are aware of this scam and have already warned their customers. Each version of such email is slightly different and contains the current date, a random customer number and payment amount.

Phishing email - Vodafone

If we look more carefully at the sender’s email address, we can see that the true author did not bother with faking the sender’s email address. This should immediately alert the recipient as an email from German Vodafone would hardly be sent from an unrelated Romanian domain.

In the latest scam, the emails do not contain any attachment, which is different to the other recent phishing campaigns. The proclaimed bill (a PDF file) is available online via a given link (also unique for each version) that actually leads to a ZIP archive stored on one of the hacked sites. These archives contain an exploited/unsecured WordPress instance and they serve as a mule for the distribution of malware to users.

Once again, a user targeted by such an attack should be alerted via a simple inspection of the target location of the link by hovering the cursor over it (but remember to not click on the link). This feature is supported by most browsers and email clients. As we can see from the following figure, the target domain of the link is also very suspicious:

Link to a hacked domain

Malicious Content

The downloaded file (e.g. is a ZIP archive containing an executable file. The user is fooled by the application’s icon (similar to Adobe Reader) to think that it is a PDF file, which is yet another well-known trick used by malware authors.

Icon of the executable file

If you are not sure about the real file type, you can see the file properties.

For the following analysis of the malicious content, we use a sample with the MD5 checksum b0a152fe885a13a6ffb0057f6f21912f. It is an executable file downloaded from one of these links, likely originally written in C++ by using MFC.

First Stage

The (unwanted) execution of this file starts the first phase of the malicious behavior.

The file itself is 160 kB large, but most of its size is stored within the resource file masked as the following GIF image (109 kB).

The author of this sample used steganography because 99% bytes of the image content represents an encrypted code. This code is decrypted first and the control is passed to this decrypted code.

Furthermore, WinAPI functions are called indirectly (via functions LoadModule() and GetProcAddress()) and names of these functions are obfuscated and decoded during run-time on the application’s stack in order to make analysis more difficult.

Afterwards, it creates a new process with the same name and fills its sections with the decrypted code from the GIF image (via the WriteProcessMemory() function).

This new process copies the original file into  C:\Users\%USERNAME%\AppData\Roaming\Identities\qwrhwyyy.exe (as a read-only system file), registers itself to be run at system startup (registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run), and deletes the original file by using a generated batch file.

Once the file is executed from this new location, it behaves differently:

It checks whether it is analyzed or virtualized via the following techniques.

  • Detection of a loaded Sandboxie module  SbieDll.dll and detection of running processes  VboxService.exe (VirtualBox) and vmtoolsd.exe (VMware).
  • It also uses the GetTickCount() function to detect whether it has really started during the startup and also to detect debuggers.
  • If any of these is detected, the executable file stops its malicious activity.

Afterwards, it extracts and decrypts another executable file on stack from the aforementioned GIF image and injects it into other processes, such as explorer.exe, firefox.exe. This starts the second stage of infection. Note: some versions of this malware try also to check a working Internet connection via a DnsQuery of before starting the second stage.

Second Stage

This extracted file is relatively small (52 kB) because it is packed by the UPX packer (version 3.08).

After its run-time unpacking, it uses the same anti-debugging tricks as the previous sample.

The main body of this file can be described by the following decompiled code:

  • For synchronization between the first and second stage, the mutex  qazwsxedc is used (e.g. another variation of classical qwert or asdfg names).
  • Afterwards, the malware waits for 30 minutes to remain stealthy. After that, it also checks whether no more than 32 minutes have passed since the system startup (i.e. whether it was started during the first two minutes after startup).
  • In its main loop, it follows the malicious behavior described in the remaining paragraphs (function malicious()). After each iteration, it makes a 5 minutes break before the next action.

In this function, the string DC85CCC4C4CCC7CED385C6CE919F9F98 is decrypted at first by using the fixed XOR key 0xAB. The resulting string represents a remote address of the command-and-control (C&C) host and its port. The second one is At first, the sample tries to check connection with these servers by using the Winsock functions. The other samples contain different lists of C&C servers:

Afterwards, it obtains information about the local computer, such as:

  • computer name;
  • version of operating system;
  • processor information and number of cores;
  • memory information.

Afterwards, this information is encrypted and send as a registration to a C&C server from the aforementioned list. The reply from the server is encrypted by the same algorithm. The very first byte of the reply message specifies an action (i.e. a control code) to be performed. To date, we have identified the following codes:

  • 18, 19, and 20 – open a specified page in Internet Explorer (with minor differences).
  • 16 and 17 – download and execute a file specified within the message. The file is downloaded via the URLDownloadToFile() function, stored with a random name, e.g. %TMP%\mibww.exe and executed via the  WinExec() function.
  • 6 – terminate the process (itself).
  • 5 – inactivate itself for a specified time.
  • 2, 3, and 4 – these codes imply different types of online communication with other systems (e.g. for downloading other malware modules, communication with other infected systems, attacking specified targets). The communication is executed via a server-specified number of threads running the following built-in functions. Arguments to these functions are also sent within the messages from a C&C server. All of these functions are based on Winsock functions.
    • Sending a message to a given IP address (or host name) and port.
    • Communication with a remote server on ports 21 and 22.
    • Sending multiple types of HTTP GET requests to specified servers.

Those actions are constantly executed until the process is terminated by the C&C server (unlikely) or by user (e.g. system shutdown). However, this process is started once again during the system startup.

As we can see, it is up to the attacker to download and execute other malicious modules, such as password stealers, bankers, or to include the infected PC into a botnet.


Although, the analyzed phishing emails are far from perfect (download links and sender addresses are suspicious, the text of email is only available in German, etc.), it is still possible to fool a user into executing the malicious file. This file is powerful enough to infect the user’s machine and turn it into an unsafe place.

Here are some basic tips, that we’ve previously shared about how to detect a phishing email:

  • Check the spelling and grammar – it is unlikely that your bank or service provider will send you an email with such mistakes.
  • Sender’s name and email address can be spoofed, do not rely on them.
  • Look at the target address of the link – different domains than the official ones are highly suspicious.
  • Do not panic and do not do any action in haste. The attacker often tries to threaten you and make a time pressure on you.
  • Do not open suspicious attachments or links. If you really need to open a file, check its file type before double-clicking it. The file name and icon can be easily crafted to look like a picture or document.
  • If you are not sure about the email’s origin, try to contact that company directly (e.g. call official customer care), but do not respond to such email and never ever send your credentials in this way.
  • And as always: use AVG to stay protected.

Jakub Kroustek
December 8, 2014