Early this year, Trend Micro researcher Kyle Wilhoit observed an increase in the use of AutoIt in several hacker tools and malware, which were typically uploaded on sites like Pastebin and Pastie. In the said blog post, Kyle noted that because of AutoIt’s easy-to-learn language, we can expect more threat actors to incorporate this scripting language in their schemes. Now we’ve learned that he was right, as we are seeing more malware using AutoIt.

We recently encountered a ZeuS variant that arrives with a malicious AutoIt file and garbage files. It arrives via spammed email message and the unpacked file it arrives with is detected as TSPY_ZBOT.SMIG.  Like any ZeuS/ZBOT variant, TSPY_ZBOT.SMIG drops a configuration file that contains a list of its targeted banks and other financial sites. It also steals information from different FTP sites and steals personal certificates from the infected system

In addition, we also spotted two other malware that use the same packer, which Trend Micro detects as TSPY_CHISBURG.A and TSPY_EUPUDS.A.  When TSPY_CHISBURG.A is loaded into memory, it steals user names and passwords from Yahoo, Hotmail, Pidgin, FileZilla, and VPN/ISP credentials among others.  Similarly, TSPY_EUPUDS.A gets data from the infected system such as user ID, browser and version, and OS version.  It also steals information like user names and passwords stored in certain browsers.  Cybercriminals may use the gathered information to sell in the underground cybercrime or to launch other attacks.

The new AutoIt packer tool code found online contains the ability to propagate via removable drives, has installation routines and checks installed antivirus software on the system. Furthermore, its code has garbage codes and obfuscated  functions to make it harder to analyze. And while these malware (TSPY_CHISBURG.A and TSPY_EUPUDS.A) are old, they remain to be an effective means to steal information especially with the added capability of the AutoIt packer.

With the incorporation of malware to a scripting language such as AutoIt, it makes analysis arduous especially if there is no decompiler that can aid in the analysis.  AutoIt is also used by normal applications, thus there is need for malware which are compressed to be unpacked so as to get only the malicious routines/behavior.

To avoid these malware, we advise users to be wary of the email messages they receive and avoid executing the attachment(s) that goes along with them. Users are also encouraged to regularly update their systems and anti-malware software to ensure protection. Trend Micro detects and deletes all the malware reported in this post through the Smart Protection Network.

With additional insights from Rika Gregorio.

We recently came across a CryptoLocker variant that had one notable feature—it has propagation routines.

Analysis of the malware, detected as WORM_CRILOCK.A, shows that this malware can spread via removable drives. This update is considered significant because this routine was unheard of in other CRILOCK variants. The addition of propagation routines means that the malware can easily spread, unlike other known CRILOCK variants.

Aside from its propagation technique, the new malware bears numerous differences from known CryptoLocker variants. Rather than relying on a downloader malware—often UPATRE— to infect systems, this malware pretends to be an activator for various software such as Adobe Photoshop and Microsoft Office in peer-to-peer (P2P) file sharing sites. Uploading the malware in P2P sites allows bad guys to easily infect systems without the need to create (and send) spammed messages.

Further analysis of WORM_CRILOCK reveals that it has a stark difference compared to previous variants. The malware has foregone domain generation algorithm (DGA). Instead, its command-and-control (C&C) servers are hardcoded into the malware. Hardcoding the URLs makes it easier to detect and block the related malicious URLs. DGA, on the other hand, may allow cybercriminals to evade detection as it uses a large number of potential domains. This could mean that the malware is still in the process of being refined and improved upon. Thus, we can expect latter variants to have the DGA capability.

The differences between this particular CRILOCK variant and the others have led some researchers to believe that this malware is the product of a copycat. Regardless of its creator, WORM_CRILOCK.A shows that this could become the new favored attack method of cybercriminals.

Users should avoid using P2P sites to get copies of software. They should always download software from official and/or reputable sites. Given WORM_CRILOCK’s ability to spread via removable drives, users should also exercise caution when using flash drives and the like. Users should never connect their drives into unfamiliar or unknown machines. Our blog entry, Defending Against CryptoLocker, discusses at length additional ways of protecting a computer and a network against CryptoLocker malware.

Trend Micro uses AEGIS (behavior monitoring) to detect and block all threats related to this malware. For more information on ransomware’s background, you may visit this page. You may also refer to our FAQ page on Cryptolocker for a more comprehensive view about the malware.

With additional insights from Mark Manahan and Jimelle Monteser 

This article, recently published in the Journal of Communications, adds another log to the BadBIOS fire. It has been stated that devices in the BadBIOS case are communicating across an air-gap with commodity PC audio hardware. This paper clearly spells out one workable way to communicate in this way. Even if this doesn’t end up being related to BadBIOS, it has solid potential as a data exfiltration methodology.

First, I want to clearly state that this is only a communication channel and NOT an infection vector as some articles may lead you to think. At this moment, there is no published technique for infecting a system across an air-gap with audio alone (though you should probably treat Siri with a little more respect from now on).

This method works by adapting an old system for underwater communication to frequencies approaching the upper limit of human hearing. Human hearing is generally defined as covering the frequency range from 20Hz to 20KHz. For comparison, dogs can hear up into the 60KHz range. Our ability to hear the higher frequencies deteriorates as we age. In this case, that natural degradation creates a gap between the design specifications of common computer hardware (i.e., 20Hz to 20KHz) and what most users can hear (let’s say, up to around 17KHz for this discussion).

After some initial testing, we found that in our 20 person sample, about 2 might have heard tones at 17.5KHz. So far our testing at 18.5KHz has gone un-detected. Any application with access to the sound hardware on a subject system can communicate this way, noting that Mac and Linux systems may require different approaches in software. All hardware used was off the shelf and unmodified. It is also useful to note that the 18.5KHz tones were not transmitted over the telephone or the videoconferencing links that we tested.

Hack-a-day has a good demo of this approach working with GNU Radio, though it might be hard to miss GNU Radio running on a system where it doesn’t belong. For our next test, we wanted to look for range, reliability, and the possibility of using commodity software. We were able to use a simple Perl script to convert a text message into Morse code audio at a frequency of 18.5KHz. In a non-prepared environment (e.g., fan noise, machine noise, music, etc. ), we were easily able to decode tones using some simple spectrum analyzer software at over 6 meters or 20 feet.

Figure 1. The message is “This is a test”, with music playing at the same time from the same system

I don’t think it’s time for a rack-mountable “cone of silence” just yet. However, I do believe that it’s time we consider ultrasonic (or at least, high frequency) data transmission with stock computer hardware as both possible and practical. At the moment, the best recommendation would be to physically remove audio hardware from any systems that are currently defended by an air-gap and have no need for audio capability.

We recently noticed that there has been an increase in spammed messages that use airline information as bait. These messages are made to look like notifications from airlines such as Delta Airlines, British Airways, US Airways, and American Airlines. Each message comes with an attachment—often in the form of a fake e-ticket—that recipients are supposed to open. This attachment is actually a BKDR_KULUOZ variant.

Figure 1. Screenshot of sample spam

KULUOZ variants are known to download and execute other malware, such as SIREFEF/ZACCESS and FAKEAV variants. KULUOZ variants are also evolving: we’ve even seen one variant, detected as BKDR_KULUOZ.MN, that collect system information including the antivirus installed in the affected computer. This is a routine previously unheard of from this malware family.

While we have seen KULUOZ spam in the past, there have been no significant change in numbers in the past several months. KULUOZ spam now represents nearly half of all malicious spam attachments.

Figure 2. Breakdown of spam attachments over a one-week period

Based on our investigation, this batch of BKDR_KULUOZ is distributed by the Cutwail/Pushdo botnet. Previously, we noted that the said botnet was responsible for sending out Blackhole Exploit kit (BHEK)-like spam that serve UPATRE variants.

Previous instances of KULUOZ spam used shipping and airline notifications as bait. The exclusive use of airline tickets in this new campaign could be a deliberate move, considering people frequently travel over the holidays. Victims may be more inclined to click attachments if they’re actually expecting airline tickets.

Users should remain extremely careful when opening messages. Since most messages are specially crafted to look as legitimate as possible, it’s ideal to double-check with the sender to see if an email is legitimate. Trend Micro Smart Protection Network blocks all related threats in this attack.

With additional insights from Merianne Polintan, Jerwin Solidum, Maydelene Salvador, and Mark Manahan.

Recently Google announced that it had changed its policy dealing with images in email. In a blog post on the official Gmail blog, Google said:

[You'll] soon see all images displayed in your messages automatically across desktop, iOS and Android. Instead of serving images directly from their original external host servers, Gmail will now serve all images through Google’s own secure proxy servers.

Simply put, this means that all pictures in emails will now be automatically displayed. Instead of being served directly from the site hosting the image, however, they will be given a copy that has been scanned by Google.

Officially, the stated rationale for this change is that previously, senders “might try to use images to compromise the security of your computer”, and that with the change images will be “checked for known viruses or malware”. This change affects users who access Gmail via their browser, or the official iOS and Android apps.

In the past, there have been occasions where malicious images were used to compromise computers. A number of image formats were exploited in 2005 and 2006, including a Windows Metafile vulnerability (MS06-001), and an Office vulnerability that allowed arbitrary code execution (MS06-039). More recently, a vulnerability in how TIFF files were handled (MS13-096) was found and not patched until the December Patch Tuesday cycle. Properly implemented, scanning the images would be able to prevent these attacks from affecting users.

However, actual exploitation of these vulnerabilities has been relatively uncommon. Exploit kits have opted to target vulnerabilities in Flash, Internet Explorer, Java, and Reader instead. Image vulnerabilities are not even listed in the control panels of these kits.

The primary reason to block images is not to block malware, but to stop information leakage. Images are used by spammers and attackers to track if/when email has been read and to identify the browser environment of the user. Email marketers also use this technique to check how effective their email campaigns are.

Email marketers have already confirmed that in spite of Google’s moves, email tracking is still very possible. Google’s proposed solution (a web proxy that checks images for malware images) appears to solve a small security problem (malicious image files), while leaving at risk user’s security and privacy. Attackers still have the capability to track that users have read email–and to learn aspects of their browser environment.

Users can still revert to the previous behavior via their Gmail settings, as outlined in Google’s blog post:

Of course, those who prefer to authorize image display on a per message basis can choose the option “Ask before displaying external images” under the General tab in Settings. That option will also be the default for users who previously selected “Ask before displaying external content”.

We strongly recommend that users change this setting for their accounts. Users who access Gmail via POP3 or IMAP should check the settings of their mail application to control the display of images.