Anatomy of a Control Panel Malware Attack, Part 1

Recently we’ve discussed how Control Panel (CPL) malware has been spreading in Latin America. In the past, we’ve analyzed in some detail how CPL malware works as well as the overall picture of how this threat spreads. In this post, we shall examine in detail how they spread, and how they relate with other malicious sites and components.

Recently, while I was checking my spam mailbox, I found one of these messages there. Specifically, I found this email sample:

Figure 1. Spam message

This roughly translates to:

From: {Dear Customer} (delivery-receipt@outlook.com)
Subject: As requested, the Invoice of Payment is Below
Message Body:
Good Morning  Sir/Madam customer,
As requested, the following is the invoice for payment

[PDF icon] Click here to download.

The email address used in this attack may look authentic at first glance, but it is actually just an address from Outlook.com, Microsoft’s free webmail service. In the message itself, there are two highlighted items: the PDF icon, and a link after the PDF icon.

The PDF icon is actually a hot-link of an image hosted by Google which is a PDF download icon. When clicked, this leads to a fake “access denied” website.

However, if the user does click on the link, as opposed to the icon, they are directed to a document that is hosted on a Google Drive. From this document, the user is redirected to a malicious page, as seen below:

Figure 2. Google Drive document

After more redirections, the user is sent to the URL of a malicious archive. Inside this downloaded archive namedFature.zip one finds the Control Panel malware.

Figure 3. Malicious archive

Redirection Details

As seen, there are actually three malicious sites necessary to get to the malicious file. The overall infection chain is:

1. Spam message
2. Google Drive URL
3. http://{malicious domain #1}/Pdf/Visualizar.php
4. http://{malicious domain #2}/Fatura.zip

Both of the mentioned malicious domains above are hosted in Brazil, and use the .br top-level domain.

Using a Google Drive URL as the initial infection vector was a clever decision, as network traffic with Google will not be found malicious, and URL scanners will frequently whitelist a Google-related URL as well.

The page at this Google URL is actually an HTML document that uses the META tag to redirect users to the first malicious site, as shown in Figure 2.

Note that at malicious domain #1, there is also one redirect within the site: the URL from Google only goes to thePdf directory; the site itself redirects users to the Visualizar.php page.

Figure 4. Malicious site redirection

From here, how did it download the malicious payload Fatura.zip? It used HTTP status code redirection, as was used by malicious domain #1:

Figure 5. HTTP status redirection

The HTTP Location header field (highlighted above) is provided to the web browser under two circumstances:

• To ask the browser to load a different page. In this case, the Location header would sent with the HTTP 302 status code, and then would provide a “Moved Temporarily” status. This is what was described above. The user has no choice in the matter, as this is part of the HTTP protocol itself.
• To provide information about the location of a newly created resource, but this would go with an HTTP status code of 201 or 202.

We can see how the attacker designed this attack to make it more difficult to block: by using a Google-related URL, it makes blocking these URLs very difficult. Even its misuse of the Google Drive service would be tricky to deal with, since the attacker did not actually use the service to host malicious content, but instead used it as a redirector. The multiple redirections can make detecting the “right” URL to block more difficult if no network monitoring is conducted. (A casual inspection might lead someone to believe that the malicious URL came from Google, which is clearly not the case.)

In the next part, we will look at how this attack proceeds once it has been installed on an affected system.