More Phish

In my last post, we saw attackers carry out a targeted campaign, sending phishing emails with malicious attachments. This article picks up where we left off, briefly looking at the malware attachment, then examining its interesting CnC communication techniques.


Let's start with a quick and dirty analysis of the phishing email attachment, "AutoCleanTool.Rar."

A VirusTotal report can be seen here:

When the attached file is executed, the "AutoCleanTool" pops up on the screen with a dialog box.

Right away we see that these guys are up to no good, attempting to steal the victims' email login information.


Figure 1. Dialog box asking for user email credentials

Any email credentials entered into the dialog box get saved to the Windows registry. These credentials will then be transmitted to the attackers by the malware.


Figure 2. Email credentials get saved under HKEY_LOCAL_MACHINE\SOFTWARE\Security\Log

While the user is distracted with the "AutoCleanTool," there is a bit more happening behind the scenes.

The following (hidden) directory structure is created: C:\ProgramData\Microsoft\Windows\

It creates the .DLL file "Utility.dll" in C:\ProgramData\Microsoft\Windows\Common.
Then it makes a copy of this .DLL file one directory below, naming it "NetCCxx.dll."


Figure 3. Contents of "C:\ProgramData\Microsoft\Windows\" folder

VT reports for the .DLL here:

Once NetCCxx.dll gets loaded, the malware goes to work. Here is where we start to see some interesting network


The malware first checks to see if it has connectivity. This is seen in the initial GET request which appears benign at first glance.


Figure 4. Initial HTTP GET request (Note the format of the HTTP headers/)

The malware isn't restricted to just using Google for its initial transmission; as can be seen below, it may also contact:


Figure 5. Some of the hardcoded domains within the malware

Once it has verified network connectivity, the malware starts making contact to various domains.

It’s here that something becomes evident: the malware is using social media/blogging sites as part of its CnC.

Some of the blog sites hardcoded in the malware are shown above, all Chinese in origin and include:

What’s on these blog sites? Not much, just a URL prefixed with the following strings:

"he1l0:hxxp" or "he1l0:hyyp"

The post appears to be the location of an object for the malware to download (a .jpg image).


Figure 6. Example of one of the "blog" sites with URL to .jpg image


Figure 7. Example of HTML source from blog site showing the "he1l0:hxxp" link


Figure 8. Malware looking for a blog post with the image URL and then downloading .jpg image

Next, the malware attempts to access the link to the .jpg to which the blog was pointing. In this case it’s a link to an innocent looking image hosted on the domain. (Note: is a large Chinese based web portal, with a somewhat storied past.)

Looking at the .jpg, we can see it’s a Japanese animation character.



Figure 9. Sample of downloaded .jpg images

Monitoring network activity of the malware, we see it downloads these images several times an hour.

A quick analysis of the .jpg and something sort of sticks out.


Figure 10. Example of data appended to .jpg image

In the above .jpg, after the .jpg EndofImage marker "FF D9," there is "Unknown Padding," approximately 471 bytes (1D7h) in size. This "Unknown Padding" is later referenced by the malware.

The malware reads the downloaded image and sets a pointer (SetFilePointer) on the file to start looking from the File_End. The value stored in the “lDistanceToMove” parameter is -471, which instructs it to look back 471 bytes, the exact size of the "Unknown Padding" appended to the image.

The malware then proceeds to decrypt the data that it extracted from the .jpg image, which, in this case, ends up as part of a new .ini file containing configuration data and an additional image URLs for the malware.


Figure 11. Example of an .ini file created by the malware (with different image URLs)

This cycle continues, allowing the malware to update itself without raising many alarms.
It gets worse—the images are not restricted to just holding configuration data; they can also be appended with code, allowing the bad guys to update the malware framework or add new components.

Network communications like this could easily slip under the radar. All the domains and URLs accessed by the malware are legitimate. Though they seem to all be Chinese in origin, there is not really enough for most traditional security defenses to detect outright.

IT security personnel should be aware of these types of threats as they can go undetected for extended periods of time until traditional signature-based security solutions receive detection updates (if at all).

We also know that more malware threats are utilizing similar techniques, possibly flying under the radar as you read this.

The bad guys are always stepping up their game, finding new ways to extend the life of malware in its target environment...

Stay safe!