Recently I came across an underground Russian forum in which an author was actively selling botnet logs with account-login details from one targeted bank.

These botnet logs were from the Citadel botnet Version 1.3.4.5 (Extreme Edition). Citadel is a variant of the popular Zeus botnet and has been widely seen since late 2012. This botnet has already been covered in blogs and by McAfee Labs.

Here is an image of server code for extracting bank account information.

Next we see what Citadel can do. I tried log in to several bank accounts using the posted credentials and was surprised to find that most of the accounts mentioned were active. I could log in to them successfully.

Our research has revealed that Citadel  is one of the most active botnets in the world, spanning several locations across Europe. One of the major reasons for its common use is that the botnet setup services are fairly cheap via the underground community. Here is an advertisement for the Citadel setup service.

The same user offers the setup services on another forum:

Many cybercriminals avoid transferring money to their own accounts due to the risk of prosecution, but selling the account information and making the money from the sale is an effective way of preserving  anonymity. Thus the attacker can’t be held accountable for the transfers made from a stolen account.

As the precautionary measure, we should look out for accounts being accessed or transactions made to/from different geographical locations. Banks place limits on the amount of money that can be transferred in one day or in a single transaction. Spotting small, unauthorized transactions made from an account should be noticeable and prevent major financial losses.

The bot steals files with the extensions .doc, .docx, .ppt, .pptx, .xls, .xlsx, .rtf, .pdf, .dwg, .cdw, and .cdr as well as source code files such as “.c” from the victim’s machine. The three new file extensions:

• .dwg = used by CAD applications
• .cdw = used by CAD applications
• .cdr = used by CorelDraw applications

The bot copies the main binary into the %TEMP% folder with the name cmss.exe, creates the startup link seruvice.lnk, and creates the mutex Assassin. The old Travnet bot used to initially steal a lot of information about a victim’s machine, but the new binary collects only the list of running processes on the system. Here is a snippet of code from the new binary:

The bot creates process.dll in the %TEMP% folder and writes all running processes in it. The malware then compresses the file data using an algorithm similar to LZSS. The bot generates its own format with the magic string “Begin” and appends the compressed data to it. This formatted data is encoded with a custom Base64 algorithm before being sent over the wire.

New Algorithm

In my earlier blog, I wrote about the old Travnet bot’s using a variant of LZSS compression with sliding window of 65KB. The output of the compression was straightforward, reading bits from the start to the end of the full stream. The new binary modifies this algorithm, using 1,024 bytes in a sliding window and requires a fixed 10 bits to store the offset. The algorithm outputs 9 bits for a single byte (1 bit for the flag and 9 bits for literal) and 11 bits for flag and offset. The length of the match is written in a special way. To make standard decompression difficult, the bot writes the output byte in a different way by writing MSB bits into LSB bits in the output. This means you can’t treat the first bit of whole steam as a flag bit. The compression algorithm needs to maintain the previously written bits count to avoid losing all bits. Here is a look at the pseudo code for the new algorithm:

The compressed data is appended to a 15-byte custom header:

The structure of the custom format:

• 2 bytes = compressed length
• 2 bytes = compressed length
• 5 bytes = string “Begin”
• 1 byte = space
• 4 bytes = random number
• 1 byte = space
• …………. compressed data

The preceding data is encoded with a similar custom Base64 algorithm as used previously. This data is first sent over the network to the remote server in an HTTP GET request format. The malicious control server replies with further commands. Decompressing the data using a new tool:

The decompressed text now looks like this:

At this point, the attacker knows which processes are running on the victim’s machine. The control server instructs the bot to upload important files. The bot scans all the drives for these files and creates index.ini, which contains the newly generated name and path of filenames:

Thus the malware steals all of the important files from the victim’s machine. The new binary has only two commands, namely uninstall and upload.

PCRat 

Once the victim’s data has been uploaded, the control server instructs the bot to download and install the remote admin program PCRat, a malicious tool written in Chinese. I found a copy of the PCRat builder that supports English:

Once installed, PCRat connects to different remote control server on higher ports and sends information about the machine in encrypted format. Here is the packet capture:

PCRat first sends an HTTP GET request followed by encrypted data:

The structure of the PCRat encrypted data:

• 5 bytes = magic string “PCRat”
• 4 bytes = whole packet length
• 4 bytes = compressed length of data
• … Zlib compressed data

 PCRat sends some information about system. The decompressed data:

PCRat has many commands to control the victim’s machine:

The MD5 hashes:

• Updated Binary : 8D78A9E3DF1E19F9520F2BBB5F04CB54
• PCRat Binary: DA0C19DB8215D8CBF3D0FBA4A1A00183

With the help of PCRat, the Travnet botnet takes full control of a victim’s machine. The attackers behind Travnet are very active. Not only have they updated the main binary, but they are also randomly generating the .asp files that control the bot from their control servers. We have also seen that the attackers are actively restoring previous domains that were down and .asp files so that they can continue to collect data from previously infected machines.

This past April (4/19 to 4/21) I had the great pleasure and experience of joining the Red Team at 9^th NCCDC competition.   It was actually my 2^nd year on the Red Team and 4^th year to attend in total (I judged in 2010 and 2011).  McAfee is actually a perpetual sponsor of this event.  That being said, I have my own selfish agenda when I attend.

Joining in as part of the Red Team is, by far, on of the most educational experiences I could possibly put myself in.   Not only are you tossed into a room w/ folks like Mubix, Vyrus, Raphael Mudge, and others – but also you are on a limited schedule and from the time that the competition starts it’s heated and non-stop.

The general strategy this year was to lay down all our toys and persistence (backdoors, beacons, RATs and other tools) on Day 1.   We made very little noise, hoping that the competing teams would gain a false sense of confidence and not notice our presence on their systems.   This way on Day 2 when the chaos commences, and the teams choose to just ‘restore from backup’ or ‘revert snapshots’ and the like, they end up restoring all our persistent tools and we retain access and ownership.

DarkComet Client Console

And . . . .. . It worked!

Different individuals on the Red Team had their unique tools and methods to gain and retain access and unset the teams’ activities.   As the McAfee guy, I choose to rely on some old, tried and true (and very accessible RATs).  Most of my activities centered on the use of DarkComet and, to a far lesser degree, DNA.

RAT Remote Process View

My philosophy was driven by two primacy goals.   First, I know these things work realllllllllly well.  And with these RATs on the box, I can control and own everything.  Second, and possibly more interesting, is that if these tools work, I know that the teams are not putting any effort into installing/deploying even the most basic endpoint/host-based AV solutions.   This is especially intriguing because, as a sponsor, McAfee provided the competition with our software.   I purposely did NOT do any crypting/packing/obfuscation on the RATs I generated.   I know that McAfee (and just about all other) vendors DID detect these things.  Yet, I still managed to install and persist on most of the hosts that I deployed to (deployed via Cobalt Strike btw).

When the competition was over, I chatted with a few competitors, and mentioned this fact.  I immediately saw the gears start turning.  I could tell they had a real “Ahhhh we should have done that” moment.  Not to mention, that McAfee (and others) detect meterpreter/MSF listeners and Trojans as malware/PUPs.  Those could have been curtailed as well.

Each year, the teams have to setup, maintain, and safeguard an environment for a faux company/entity.  This year the teams were tasked with tasked with the environment of a Correctional Institute.   This includes databases for tracking the whereabouts of prisoners, an e-commerce site for a prisoner commissary, and more.  From the Red Team perspective, this gives us some of our big bets for getting points deducted from the teams.   For example if you kill/mangle/destroy the database for tracking prisoner and personnel, that’s one of the high point items.   After all, they don’t want an IT issue to allow prisoners to go unaccounted for or escape, etc.   Other hot items include public web site defacement and acquisition of PII (personally identifiable information).  For added fun, many of us defaced the web sites by posting the company’s PII for all to see.

Defaced with PII

All and all it was a fantastic experience.   I look forward to future activities with this competition.

UTSA shot a documentary this year.  I’ll post details on that once it’s released.    However, if you’d like to get some really detailed info, Hak5 released a documentary filmed at the 2012 event.   It features great interviews and ‘behind the scenes’ Red Team action.   I’m not interviewed, but you can see the top of my head in a couple shots!!

Hak5 Doc – Jim’s Head

2012 Hak5 Documentary

Additional Blogs on NCCDC 2013

• David Cowen - http://mcaf.ee/wid10
• Raphael Mudge - http://mcaf.ee/ageor
• Alex Levinson - http://mcaf.ee/limh1

NCCDC 2013 Red Team Brief - http://mcaf.ee/uodvk

Bonus:   We recently did our 2^nd AudioParasitics episode with the great Raphael Mudge.   This time we have a full and glorious video demo of Cobalt Strike in action.  We actually walk though scenarios and give you details on how some of these Red Team activities actually occur.

AudioParasitics Episode 141 (video) - http://mcaf.ee/gep69

In February 2013, the Adobe Product Security Incident Response Team (PSIRT) released security advisory APSA13-02. In that report they listed two vulnerabilities (CVE-2013-0640 and CVE-2013-0641) that were widely exploited. At Intel Labs and McAfee Labs we ran some further analysis of these exploits and want to share some of the interesting details we discovered.

Based on information from the PSIRT, both vulnerabilities will impact all versions of Adobe Reader from 9.x to 11.x. (Some Acrobat versions are also vulnerable.) We verified this claim and found the sample affected all of them.

Attack Path

The exploit is spread by a malicious PDF file. When Reader opens the PDF file, it will trigger the vulnerability and start the exploit. This PDF file delivers a very complex attack, bypassing the current Adobe sandbox mechanism to launch the malware.

This flow shows the basic steps for the attack path:

The files D.T and L2P.T are DLLs in a sandboxed temp path, as in the following:

A new PDF is created in the normal temp path:

The new PDF, Visaform Turkey, will appear to hide the exploitation. The exploit uses a lot of memory in the background.

First Exploit

The PDF’s first exploit uses a heap overflow to overwrite a virtual function pointer, and also uses a memory information leak to bypass the address space layout randomization (ASLR) protection in Windows. Return-oriented programming is used to bypass data execution prevention (DEP).

Let’s sidetrack for a moment and look at two definitions: Return-oriented programming (ROP) is an exploit technique in which an attacker controls the call stack to indirectly execute arbitrary intended or unintended code to deliver an attack, thereby bypassing security features such as DEP. Stack pivoting is a common technique used by ROP-based exploits. Pointing the stack pointer to an attacker-owned buffer, such as the heap, will provide more flexibility for the attacker to carry out a complex ROP exploit.

Here’s how the exploit works from the first trigger point. The vulnerability is in AcroForm.api. After the exploit prepares customized stack data on the heap, the data triggers the exploit via following instructions in AcroForm.api.

With a modified virtual function pointer, the instruction calls into a special ROP gadget, which will start pivoting.

The address for the first gadget is 0x209b9f50. Here’s the original code:

But if we decode from 0x209b9f50, the code piece looks like what follows. This is the ROP gadget for stack pivoting:

Now the stack points to a fake stack in the heap. The code log in a debugger at runtime looks like this:

Once the customized stack works, it will start more ROP gadgets. When the next Ret instruction is called, the stack looks like this:

What’s the instruction for 0x6acc1049? It is offset 0×1049 from AcroForm.api because 0x6acc00 is the base address for the target module. Here is the unintended ROP gadget again:

The decoded ROP gadget is just a Ret instruction:

It will repeat from stack 0x11849a34 to stack 0x1184beb4, a whopping 9,344 (0×2480) times!

Let’s see what the stack content is now:

The next gadget will move the esp register to esi. It will control the stack itself.

The gadget still includes lots of return addresses with repeated patterns, such as these:

With related code pieces:

So the logic will write target memory with values in the ecx register. The same pattern will repeat many times to modify 0x6b55e001, which is the beginning of the data section of AcroForm.api.

The data from 0x6b55e001 to 0x6b55e04e is modified and writes several API/DLL names into the area of 0x6b55e001:

• GetTempPathA
• Fwrite
• Wb
• CryptStringToBinaryA
• Ntdll
• RtlDecompressBuffer
• Wcsstr

These strings are later used as parameters, during ROP-based API calls. After writing these strings into the data section, the ROP code continues with the following gadgets:

We can list the first piece of an ROP gadget step by step. The following code moves [esp] to ecx:

                                                                  6b218551

1184c074  cccc0240 6b022c74 6b19567b 6ad6ed72

1184c084  6b19567b 6b237664

6b218551 58              pop     eax

6b218552 c3              ret

6b022c74 0fb7c0       movzx   eax,ax

6b022c77 c3              ret

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

6ad6ed72 01f7           add     edi,esi

6ad6ed74 c3              ret

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

6b237664 91              xchg    eax,ecx

6b237665 c3              ret

The following code moves the pointer to eax, and then writes [eax] with the previous value in ecx:

                                                    6b218551 cccc023c

1184c094  6b022c74 6b19567b 6ad6ed72 6b1d943b

1184c0a4  6b16d51a

6b218551 58              pop     eax

6b218552 c3              ret

6b022c74 0fb7c0       movzx   eax,ax

6b022c77 c3              ret

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

6ad6ed72 01f7           add     edi,esi

6ad6ed74 c3              ret

6b1d943b 57              push    edi

6b1d943c 58              pop     eax

6b1d943d c3              ret

6b16d51a 8908          mov     dword ptr [eax],ecx

6b16d51c c3              ret

The following code gets the LoadLibraryA() API pointer from the import table:

1184c0a4                                                        6b218551 6b32b234 6b1d92ac

6b218551 58              pop     eax

6b218552 c3              ret

6b1d92ac ff10            call    dword ptr [eax]

6b1d92ae c3               ret

At this point, the stack keeps the parameter for LoadLibraryA(). This is actually a string for MSVCR100.dll in the “idata” section.

Once the MSVCR100.dll handle is available via LoadLibraryA(), the following code writes the handle to the target address in the heap (actually the fake stack), which is used to call GetProcAddress() as the first parameter. The address is 0x1184c0e4.

1184c0b4                   6b237664 6b218551 cccc022c

1184c0c4  6b022c74 6b19567b 6ad6ed72 6b1d943b

1184c0d4  6b16d51a

6b237664 91              xchg    eax,ecx

6b237665 c3              ret

6b218551 58              pop     eax

6b218552 c3              ret

6b022c74 0fb7c0       movzx   eax,ax

6b022c77 c3              ret

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

6ad6ed72 01f7           add     edi,esi

6ad6ed74 c3              ret

6b1d943b 57              push    edi

6b1d943c 58              pop     eax

6b1d943d c3              ret

6b16d51a 8908          mov     dword ptr [eax],ecx

6b16d51c c3              ret

Next the process calls the following gadgets to get function pointers for the wcsstr function. The first parameter is a DLL handle received from previous gadgets.

1184c0d4                    6b218551 6b32b1ec 6b1d92ac

6b218551 58              pop     eax

6b218552 c3              ret

6b1d92ac ff10            call    dword ptr [eax]

6b1d92ae c3              ret

Now it’s time to call the function with the jmp eax gadget.

1184c0e4                     6acce598

6acce598 ffe0            jmp     eax {MSVCR100!wcsstr (6c5f20f1)}

Here the code searches for the string “MODULE” from the heap or the fake stack. There is a long string in the heap following the “MODULE” signature. This is the encoded and compressed DLL D.T. With more gadgets, the code calls CryptStringToBinaryA() to convert this string to binary, and then calls RtlDecompressBuffer() to decompress the binary to the real D.T binary code in memory.

Similar ROP gadgets get ntdll.dll and related API addresses, for example, RtlDecompressBuffer() and CryptStringToBinaryA(). Finally, the ROP gadget calls GetTempPathA() to get the current temp path, the sandboxed path. It will create D.T under this path and call LoadLibraryA() to run the D.T. module.

D.T creates two threads. One shows error messages. The second creates and loads the DLL L2P.T, which exploits the second vulnerability to load L2P.T into a nonsandboxed acrord32 process. Finally this process terminates.

Second Exploit

The second exploit triggers the vulnerability at acrord32.exe:

Due to a heap overflow, the eax register calls to the stack-pivoting ROP gadget.

A few more ROP gadgets after stack pivoting load L2P.T in the same process. L2P.T creates another DLL, langbar.dll, which downloads the rest of the malware.

No Shell

After we reviewed all of the exploit code and corresponding ROP, we found that this exploit does not use any traditional shellcode. All API calls use the fake stack from the stack pivoting.

Mitigation

Stack pivoting is a very common technique to allow an exploit to run powerful gadgets with a fake stack. For this kind of complex case, it’s very hard to create a customized stack within the real stack instead of within a fake stack. Once an exploit can do stack pivoting, it can bypass different defense mechanisms. Evolving security solutions need to address this attack pattern. Stack pivoting creates a very complex ROP attack and is a good example of how exploitation techniques continue to evolve. This successful exploit bypasses both Adobe client security features and basic Windows DEP and ASLR defenses.

We thank our colleagues Haifei Li, Bing Sun, Xiaobo Chen, and Chong Xu for their help with this analysis.

Adobe has confirmed this vulnerability and has scheduled a patch release for May 14.

Looking back this year’s RSA Conference, you might have the feeling that the current threat landscape is primarily a series of advanced attacks. This concept includes well-known advanced persistent threats (APTs) and zero-day vulnerability exploits. To respond to this trend in threats, McAfee Labs has launched several innovative projects, one of which we call the advanced exploit detection system (AEDS). The AEDS is based on our in-depth understanding of application security, which comes from our long-term cutting-edge research efforts. We have already seen some interesting results that reflect the effectiveness of the project.

Recently, we detected some unusual PDF samples. After some investigation, we successfully identified that the samples are exploiting an unpatched security issue in every version of Adobe Reader including the latest “sandboxed” Reader XI (11.0.2). Although the issue is not a serious problem (such as allowing code execution), it does let people track the usage of a PDF. Specifically, it allows the sender to see when and where the PDF is opened.

The vulnerability

When a specific PDF JavaScript API is called with the first parameter having a UNC-located resource, Adobe Reader will access that UNC resource. However, this action is normally blocked and creates a warning dialog asking for permission, such as we see below:

The danger is that if the second parameter is provided with a special value, it changes the API’s behavior. In this situation, if the UNC resource exists, we see the warning dialog. However, if the UNC resource does not exist, the warning dialog will not appear even though the TCP traffic has already gone.

The following screen capture shows the outgoing traffic:

How does this affect users?

Is this a serious problem? No, we don’t want to overvalue the issue. However, we do consider this issue a security vulnerability. Considering this, we have reported the issue to Adobe and we are waiting for their confirmation and a future patch. We are also hiding the key details of the vulnerability to protect Reader users. We may update this post at some point after we see a patch from Adobe.

Some people might leverage this issue just out of curiosity to know who has opened their PDF documents, but others won’t stop there. An APT attack usually consists of several sophisticated steps. The first step is often collecting information from the victim; this issue opens the door. Malicious senders could exploit this vulnerability to collect sensitive information such as IP address, Internet service provider, or even the victim’s computing routine. In addition, our analysis suggests that more information could be collected by calling various PDF JavaScript APIs. For example, the document’s location on the system could be obtained by calling the JavaScript “this.path” value.

Who is exploiting this issue?

We have detected some PDF samples in the wild that are exploiting this issue. Our investigation shows that the samples were made and delivered by an “email tracking service” provider. We don’t know whether the issue has been abused for illegal or APT attacks.

Conclusion and protection

This interesting case highlights the point that privacy protection is a part of security. It shows that we can form different opinions depending on our goals (such as security protection vs. email tracking service).

This case also demonstrates that we need to constantly explore methods of detection because these examples won’t trigger memory corruption or code execution. Some of the most advanced detection technologies in the industry failed to detect them. We are happy to see that our AEDS is filling the gap.

Until Adobe creates a patch, Reader users should consider disabling JavaScript in Reader.

Thanks to my colleagues Bing Sun, Xiaobo Chen, and Chong Xu for their help with this investigation.

The Travnet bot not only steals sensitive information from a victim’s machine; it also steals document files. Generally speaking, we store most of our sensitive information in Office files, PDFs, etc. Using data compression and data-encoding methods allows Travnet to steal huge amount of data including large files.

The bot at first gathers sensitive information about victim’s machine. Then searches for document files (doc, docx, xls, xlsx, txt, rtf, pdf). Here is snippet of code:

The preceding code includes computer name, IP address, username, operating system, list of running processes, IP config details, and information about different accounts present on the system. The malware creates the file system_t.dll to store this information in plain text. It also creates the file travelbackinfo-(SystemTime).dll, which will be used in an HTTP GET request.

The data stored in the file can be huge, depending upon running processes and IP config details. The bot will use data compression and encoding methods to send the sensitive data to a remote server. The packet capture looks like this:

The bot sends the stolen data with the parameter “&filetext,” which starts with “begin::.” But the compressed file can be too big to send over the HTTP, so the bot sends the compressed file in chunks of 1,024 bytes. To track this, it uses the parameter “&filestart.” The bot appends the string “::end” to signal the end of the file.

Data compression and encoding techniques

The bot processes the original data in two passes:

• In the first pass, it uses a data compression method similar to LZSS (Lempel–Ziv–Storer–Szymanski) to compress the original data
• In the second pass, it encodes the compressed data using custom Base64

First pass data compression

The bot’s data compression maintains a dictionary (a sliding window) of previously seen data that is similar to data compression with LZSS.

The bot uses a similar method to maintain a large sliding window size (to achieve a high compression ratio) but outputs variable-length “Length- Offset” pairs (the number of bits required to represent the number). We have not seen yet any references or implementation that outputs variable lengths and variable offsets, so for now we will call this method a variant of the LZSS data compression algorithm.

The bot starts compression by reading original data in chunks of 65,536 bytes (so it has to maintain sliding windows of this size). The final output of compression will be in chunks following this format:

Original Length (2 bytes) + Compressed Length (2 bytes) + Compressed Data

This method achieves a high compression ratio and reduces the size of the original data, allowing the bot to upload large files on the remote server. The decompression process is very easy to write because it does not need to search for the longest match but needs only to take care of variable-length values.

Second pass custom Base64 encoding

The Travnet bot uses custom Base64 encoding to encode the compressed binary data. The key and character set used in standard Base64 is “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/” with “=” used for padding; the key used by the bot is “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-/” with “*” used for padding.

We wrote a small tool to decompress the data stolen by Travnet.

As we look at the output, we see the size of the decompressed file (the original data) is much higher than that of the compressed file. Let’s now look the decompressed data:

The preceding is the original data stolen from the victim’s machine. Interestingly, the unreadable characters in the decompressed file are in Chinese. While writing the sensitive information in a DLL file, the bot writes some hardcoded strings that are in Chinese. If we convert those strings to English, here is how the file looks:

Stealing files

The bot doesn’t stop; it steals more data. Next we see the functions called by the bot:

The bot will send the following:

• A file containing lists of all filenames on the system drives
• All files that have doc, docx, xls, xlsx, txt, rtf, and pdf extensions
• All files from victim’s desktop

Once it sends all the files to the remote server, the bot will go into sleep mode and wait for further commands.

Server commands

• UNINSTALL
• UPDATE
• RESET
• UPLOAD

Next we see a command from the server telling the bot to upload more data:

Although the botnet uses a simple mechanism to infect and steal information, a few elements make a Travnet botnet unique:

• Using lossless data compression to steal large data files
• Stealing documents files with extensions doc, docx, xls, xlsx, txt, rtf, and pdf
• Stealing all files on the system drives

These unique features and the presence of Chinese strings lead us to conclude that the Travnet botnet may be a targeted attack for stealing sensitive data. We suspect the attackers are using the initial data–computer information, IP’s–to steal sensitive data from a particular group or identity. We also believe that the data uploaded to malicious severs is actively monitored by the attackers. We have found new domains registered to carry out the attack. We believe that huge amounts of data have been stolen from victims whose machines were infected with Travnet.

I would like to thank my colleagues Vikas Taneja, Anil Aphale, Arunpreet Singh, and Subrat Sarkar for their research and assistance.

The following list of URLs are just a few of the malicious links we observed during our investigation. There could be many more patterns that we have not yet found. 

• http://<some domain>/cnn_boston.html
• http://<some domain>/bostoncnn.html
• http://www.<some domain>/bbb_compl_genr.html
• http://<some zombie IP>/boston.html
• http:// <some zombie IP>/news.html
• http:// <some zombie IP>/texas.html

The campaign was likely made especially for the Boston Marathon bombings, but it was quickly altered to accommodate the Texas fertilizer plant explosion and follows the same pattern, as we can see from these subject lines.

• Explosions at the Boston Marathon
• Texas Plant Explosion
• Video of Explosion at the Boston Marathon 2013
• Aftermath to explosion at Boston Marathon
• Opinion: Boston Marathon Explosions – FBI Benefits? – CNN.com
• Opinion: North Korean Official’s child was the CIA target – Boston Marathon Explosions
• Opinion: FBI knew about bombs 3 days before Boston Marathon – Why and Who
• Opinion: Boston Marathon Explosions – Obama Benefits? – CNN.com

Most of the samples coming with a simple subject line referring to a breaking-news update, with a fake hyperlink and a reference to the current incident. Spammers often take advantage of the latest events to make it tricky for antimalware companies to filter these messages or to recognize them as spam. Spammers target recipients with emails designed to pique their curiosity.

Boston Marathon fake email:

Texas plant fake email:

Fake CNN breaking news email:

People using McAfee Site Advisor will get an instant alert after clicking this type of bogus link.

Those who ignore this warning and choose to “Visit anyway” will reach a title page of a malicious website:

• Hot News::Videos of Explosions at the Boston Marathon 2013
• Hot News::Fertilizer Explosions

The page contains the following:

• An automatic download for a malicious executable file that could make changes to the Registry and install files to allow hackers to gain remote entry to the infected PC
• Four or five links to YouTube videos of explosions at the Boston Marathon or Texas fertilizer plant
• Hidden iframes and redirections that exploit vulnerabilities across operating systems

After visiting this malicious site, the user will be taken to a web page with four or five valid videos. But the last video has an embedded Red Kit iframe that downloads a payload file without the victim’s knowledge. A sample follows:

McAfee security products will give an alert immediately before a malicious file starts to download on the user’s PC.

As always, we advise users to follow best practices to avoid any targeted fraud/spam/phishing harassment.

• Do not open or click any links in emails from unknown persons
• Ignore unsolicited requests for sensitive personal information
• Regularly update your security software
• Don’t open any suspicious attachments in emails from unknown persons

This tactic has proven effective for spammers. Recipients are likely to click links in familiar-looking emails and often create custom whitelist entries for common sending domains without enforcing Sender Policy Framework or DomainKeys Identified Mail validation.

The Messaging Security Team at McAfee Labs has closely monitored this trend and would like to share a few common traits from recent campaigns to aid in identification:

• Messages are disguised to appear as legitimate mails from well-known service providers
• Subject lines are very catchy and similar to those of any service provider

Subject line examples:

• Your Verizon wireless bill
• Pending Wire Transfer Notification – Ref: 15192
• TrustKeeper Network Scan Information
• BBC-Email: USA government decided to follow Cyprus and rise deposit taxes!!!
• [FIRSTNAME LASTNAME] left you a comment…
• Your order # ID[Random digits] has been completed

Other features:

• URL paths commonly end in …/random_word.html or …/random_word.php
• Spammers recycle templates across campaigns. These emails could have embedded links to malware or attached .zip/executable files.
• Unsubscribe links are typically missing or replaced with malicious links

Blackhole Spam Samples

Fake wire-transfer campaign:

Fake LinkedIn campaign:

Fake Facebook campaign:

You will notice all of these samples have fake .html or .php links, which are highlighted in red in the foregoing samples. These are the links carrying payloads that we need to be aware off.

The bad guys will use many techniques to deliver their spam; social engineering is a reality. Messaging Security advises caution when clicking links in emails: hover first! Employ multiple layers of defense in your environment–from email defense to web security to antimalware, and keep those definitions up to date!

Most of the variants of this malware have the same functionality, with only slight differences in their implementation code. They simply show the fraudulent web pages on the in-application web component or the device’s browser.

McAfee has also found a variant of this family of malware with more dangerous features. This variant retrieves the device user’s Google account name–the email address–as well as the phone number, and sends the information to the attacker’s remote server.

The application description page on Google Play.

This application, tv.maniax.p_urapane1, is a 16-piece slider-puzzle game consisting of pornographic images. It also plays movie files when the user completes the game.

Unlike previous variants from this family of fraudulent malware, this application requires several permissions at installation that are usually unnecessary for this type of game:

• android.permission.READ_PHONE_STATE
• android.permission.GET_ACCOUNTS

The malware’s list of required permissions.

Behind the scenes, the malware retrieves the user’s data using these permissions and sends it to a remote server by opening the URL http://man****app.com/m/users/aftpur/GOOGLE_ACCOUNT_NAME/PHONE_NUMBER. It stores the data in a MySQL database server using the Java Database Connectivity API in a database-driver library in the application.

Malware application screens.

Google account name and phone number data sent to the attacker’s server.

This application also displays some “advertisement” links at the bottom of the screen. The application’s description page on Google Play says that the developer does not guarantee the safety of these linked advertisements, implying that they are not aware of the contents of the ads. In fact, however, the application simply displays the image files bundled in the application package and invokes the browser with the hard-coded URL http://pr**.*obi/?neosp_nontop_eropne01, which is the fraudulent web page often used in other variants of this one-click-fraud family of malware.

Fraudulent web pages.

The stolen Google account name and phone number are not directly used in the fraudulent page opened from this application. However, we expect the attacker will try to use this information for future malicious activities.

Fortunately, this application was deleted from Google Play within a day after it was added, and so the number of victims should be small. But the appearance of this variant indicates that the attackers are determined to collect personal information from their victims and that they are capable of developing variants with more advanced features than previous ones.

McAfee Mobile Security detects this application as Android/OneClickFraud, and will continue to monitor for more fraudulent activities from this family in Japan.

The link from this wall post redirects users to a malicious website that hosts malicious code. This site launches its main attack by identifying browsers with the help of the following code:

The preceding code from the malicious site targets Firefox and Chrome browsers on userAgent strings.

Firefox

If the malware detects Firefox, it presents the following error message in Turkish:

The Google translation of the this message reads:

Please Refresh button, Firefox Add-Update your. Due to system errors and security bugs that are required by pressing the Reload button. Install Firefox Plug-in Update. As long as you have not updated the site faydalanamayacaksýnýz features.

Once clicked, the site installs the malicious “sosyalag.xpi” (XPI extension archive) file for Firefox (from the malicious site) along with a Chrome application from the Google Chrome store (this app has been removed from the store). Here is the JavaScript function used for the Chrome app:

Chrome

If the malicious site detects Chrome, it will download the malicious file player.exe from the attacker’s dropbox account without asking the user. After using Chrome to visit the site, a victim will see a fake video page:

The malicious site cleverly shows an arrow pointing to the malicious file for download, even though the file has already  arrived. Player.exe makes Chrome install another malicious application by adding an entry for a .crx file from another malicious site under “\Policies\Google\Chrome\ExtensionInstallForcelist\1: “gagalgomhifgcmeciklindhpaihmecgi;https://XXXXXX.com/maflu.xml.” Once an infected user enters Facebook, the malicious code runs JavaScript in the background, infecting further users.

VirusTotal Detection

Player.exe

sosyalag.xpi

mafera.crx

The XPI extension file for Firefox contains malicious JavaScript code that targets Facebook. Here is screenshot of one of the files:

The name in the preceding script “Virusü Sil” is Turkish, which in English is “Delete Virus.” Malicious sites hosting the files present user with information in Turkish. This campaign is aimed against Turkish Facebook users, but it’s not limited to them. Once someone is infected with these extensions, a victim can spread the same post by tagging their friends.

Facebook has already removed these malicious messages from the infected users’ wall posts. The malicious apps have also been removed from Google Chrome store.