Archive

Archive for the ‘Packers’ Category

Malware Prevalence August 2008

September 5th, 2008 Comments off

During the month of August
we've seen 8165 unique samples actively circulating and infecting users. These
figures come mostly from people who use our online scanner Panda ActiveScan and have a variety of different AV products
installed as well as from our behavioral sensors. The vast mayority of the people who use
ActiveScan are Symantec, Nod32, McAfee, Kaspersky and AVG users. Out of the total seen infecting
these users only a portion are new and not seen in previous months, of which 82%
are non-self-replicating Trojans while the rest are self-replicating viruses and
worms.  The following are the runtime
packing properties and most active families whose new variants have been making
the summer rounds.

 

August 2008 – Custom & Private
Packers

In our last
obfuscation study Packer (r)evolution we saw an increase in the use of private or customized versions of packers being
developed to evade AV signature detections. As a curiosity I've updated the
study to see how this trend is evolving. For this purpose our colleague Satur created a tool called "Detector" for advanced packer
identification which specializes on specific, generic and custom packer
identification but is also able to identify file infectors, polymorphism,
installers and much more. The results are pretty amazing. In April 2008 we
already saw an increase to over 30% of the packers being "private". This has
exploded now and in the August 2008 collection a whopping 75% of them are using
non-mainstream runtime packing.

August 2008 – New Variants of Self-Replicating
Virus/Worm Families

***        W32_Mandaph
*** W32_MSNPhoto
*** W32_Lineage
*** W32_IRCBot
** W32_Sohanat
** W32_Autorun
* W32_Bagle
* W32_Spamta
* W32_Socks
* W32_Sdbot
* W32_Rahack
* W32_Nuwar
* W32_MSNworm
* W32_Lineage
* W32_Kolabc
* W32_Gaobot

August 2008 – New Variants of
Non-Self-Replicating Trojan Families

*****  Spyware_Virtumonde
*** Trj_Lineage
*** Bck_IrcBot
*** Adware_Zenosearch
** Trj_dmRandom
** Trj_Agysteo
** Trj_Agent
** Adware_Netproject
** Adware_NaviPromo
** Adware_AntivirusXP2008
* VBS_Autorun.ABM
* Trj_Zlob
* Trj_Sinowal
* Trj_QQPass
* Trj_ProxyServer
* Trj_Proxy
* Trj_Passtealer
* Trj_Nabload
* Trj_Multidropper
* Trj_Mailfinder
* Trj_KillAV
* Trj_Gamania
* Trj_Exchanger
* Trj_Downloader
* Trj_DNSChanger
* Trj_Clicker
* Trj_Buzus
* Trj_Banker
* Trj_Banbra
* Trj_Alanchum
* Spyware_Vundo
* Rootkit_Lineage
* Dialer
* Bck_RedGirl
* Bck_Nuclear
* Bck_Hupigon
* Bck_Flooder
* Bck_Bifrose
* Bck_Agent
* Application_AntivirusXP2008
* Application_Antivirus2009
* Application_AntiSpyCheck
* Adware_Xpantivirus2008
* Adware_XPSecurityCenter
* Adware_XPAntivirusPro
* Adware_WinAntispyware2008
* Adware_VapSup
* Adware_RogueAntimalware2009
* Adware_RogueAntimalware2008
* Adware_MediaCodec
* Adware_JavaCore
* Adware_IEAntivirus
* Adware_IEAntiSpyware
* Adware_Antivirus2009
* Adware_Antivirus2008XP
* Adware_Antivirus2008Pro
* Adware_Antivirus2008
* Adware_Antispyware2008
* Adware_AntiSpyCheck
* Adware_Adsmart
* Adware_AVMaster

Categories: behavior analysis, Packers Tags:

Packer (r)evolution

March 19th, 2008 8 comments

We
know for sure that cyber-criminals use private tools to check AV detection prior to releasing new malware in the wild, making sure it goes undetected by
AV signatures at the time of release. As AV companies identify new packers and
are able to inspect inside them (or simply identify the malicious packer itself),
the bad guys are releasing those which are not detected by most AV.

 

This
has transformed the packer world significantly. The "big name packers" are
decreasingly being used by malware. By contrast new packers types are surging
which have two main characteristics: (a) they are not widely used in order to
stay below the radar and (b) they use obfuscation or anti-debugging techniques.


What
we're seeing is that:

  • Increasingly,
    malware families use their own 'customized' or ‘private’
    packers, which are not recognized by most AV engines.
  • There's
    a large variety of packers, each with its own little variations, being
    used by a reduced number of malware variants.


The
strategy these criminals are following is to quickly develop customized
variants of packers and use them in very few samples. By the time the AV
companies identify the samples and add the unpacking routine to their engines,
they already have a new batch of packing variations in store which is being
applied to the next batch of samples.


As
an exercise we’ve analyzed all the samples Panda has seen in-the-wild (actively
infecting two or more different sites) since August 2007 to March 2008 and
looked at the ‘big name packers’ used by these:

 

It’s
interesting to see how the ‘big name packers’ such as UPX, PECompact, Themida, PEtite
and NSPack are dropping in use, while smaller packers such as nPack, PolyEnE and
EXECryptor have increased in a significant way.

 

But what’s most interesting is what is not seen in the above summary
chart, and that is the ‘customized’ or ‘private’ packers. We know for a fact
that approximately 90% of malware uses some sort of packing or obfuscation
technique, yet the proportion of private, non ‘big name packers’ is increasing
rapidly.

Could
this be the start of the
long-tail of packers?

But
when we try to analyze the true reasons behind this evolution in packer use
that’s when it starts getting really interesting. Other than the obvious reason
which is that bad guys are trying to make our jobs harder at the lab, how come
they started creating customized and private packer versions on a very regular
basis?

As
this is a cat and mouse game, the mice’s next move is directly determined by
the cat’s strategy for catching the mice. If we apply this example to the
packer/malware world, there are two main events in the AV industry which I
believe have driven malware authors to go into ‘packer-craze’:

  1. The
    addition of many unpacking routines in AV engines as new packers emerged.
  2. Starting
    to detect malware based on its packing properties without unpacking it
    (multi-packed files, packers used exclusively for malicious purposes,
    etc.).

Now
I’m not saying the above actions are wrong. They were necessary at the time in
order to correctly protect customers and continue being necessary today if we
want to keep the pace.


I
remember a conversation with my colleague Mark from Symantec last year where we
talked about precisely this issue. If we start detecting all packers
proactively, what will the bad guys do next? I guess we’re about to see as the
packer problematic has completely blown out of proportion.

Categories: behavior analysis, Packers Tags:

Mal(ware)formation statistics

May 28th, 2007 7 comments

While catching up on an old but excellent post by jason geffner on reconstructing import tables I remembered that I've been wanting to study the real impact of packers on the latest malware received at our labs. Many of us AV companies are now more proactively detecting packers as malicious. Although this issue was discussed at length at the International Antivirus Testing Workshop 2007 in Iceland earlier this month, no real conclusion was reached as there is still a major unknown which is the use of packers in goodware and the negative impact on false positives this approach might have.

When it comes to the use of packers in malware here are some stats on the new unique sample submissions we received during the last month (samples seen in previous months were discarded for the study). Using PEid with a customized database of packing signatures (available here), a purpose built emulator and some generic unpacking routines, we found that 79% of new malware is using some type of packing technique or other.

For the study I've grouped together different versions and modified routines of packers, as its common for malware writers to slightly modify known packing algorithms to evade detection. So for example all different versions of UPX plus all modified (or private) UPX routines are grouped under the common "UPX" term. The same applies to the rest of the detected routines.

For those interested in the detailed data-set you can find it here.
Categories: behavior analysis, Packers, Stats Tags:

Packing a punch (II)

March 20th, 2007 3 comments

Following up on the Packing a punch post, we recently came across a couple of banking targeted attack Trojans that use interesting signature-based detection evading techniques.

There's packers (UPX, FSG, etc.) and cryptors or protectors (ASProtect, SWPK, Armadillo, Themida, etc.). These last ones are widely used by legitimate software publishers to protect their applications from being cracked by pirates. Crackers create generic tools to un-protect software applications and, just as with malware, crackers and software publishers are on a constant cat and mouse race to crack and avoid cracking.

The first Trojan we'll look at uses regular and known packing techniques. By investigating different downloader variants which the Trojan uses to update itself, we found a point-and-click utility with runtime-packing functionality to create additional Trojan downloader variants that evade detection.

The user only needs to type in the URL where the downloader should get the Trojan from, choose the runtime packing technique of choice from a drop-down box (or add a custom one) and click "Make Downloader…" Voilà, we have a new undetectable Trojan.

Great. Now any regular Joe Blow can point-and-click to create yet more undetectable Trojan downloader variants. We'll be adding a signature which will generically detect any downloader created by this utility.

 

The next Trojan we'll look at is a bit more advanced. It wasn't picked up or identified by any of our internal tools nor competing AV engines. So by taking a more in-depth look at it we see that there's no visible strings and the entry point is typical of packers… probably a new type of packer? Let's follow the unpacking algorithm with OllyDbg in the video and find out.

After unpacking it manually its size doubles and the strings within become visible. Turns out its a purpose-made runtime packer created specifically for distributing malware that's undetectable by any current AV unpacking algorithms (at least the ones we've checked). The actual Trojan is a targeted attack to users of well known banks and financial institutions, by using brand new techniques to steal banking credentials (I'll show details of these techniques at the eCrime Congress later this month).

In Packing a punch we discussed whether packers should be detected more generically than they are now. There's some interesting points of view and valid arguments from legitimate software developers, but if those are taken into consideration the question still remains; should more unknown packers and packers used by malware such as the ones shown above be detected generically?

Categories: Packers Tags:

Packing a punch

February 12th, 2007 9 comments

"80% of new malware defeats antivirus" according to AusCERT. Runtime packers and cryptors are some of the main tools in a malware writers' toolbox. By slightly modifying and exepacking their creations they manage to rapidly create new and undetectable variants of their malicious code. There's even specific packers created exclusively to be used by malware, with anti-debugging and anti-virtualization functionality to further hide from being detected. Malware authors have found a cheap and easy way to camouflage their code.

In a quick study of the new and unique malware (new as not previously recorded at PandaLabs) seen by ActiveScan during January 2007, we found that 77% is runtime-packed. By contrast only an insignificant number of our catalogued “goodware” (non malicious software) uses packing techniques. Why do people compress executable files anyway? To save HDD space? It's absurd as there are only a few thousand executable files in today's average 60 to 80GB hard drives. To obfuscate code or as an anti-debugging technique? There are other better suited methods for that. The fact remains that only a minority of non-malicious software uses these techniques.

Some security companies have recently started detecting runtime-packed files generically in their products. Although we mostly only see this in perimeter products for now (Gateways, MTAs, UTMs, etc.) it seems like a good approach as it prevents new malware rather effectively and potential false positives are manageable and non-disruptive.

Now given that there's already real-life companies who have implemented a "no runtime-packed file" policy within their networks, there is an interesting question being raised here; does it make sense to generically detect runtime-packed code at the host level as well as the perimeter?

Of course bringing this security policy down from the perimeter to the host opens up a whole lot of new questions that need to be dealt with, such as:

  • The most commonly used packers (UPX, ASPack, …) would have to still be unpacked and analyzed.
  • Certain packers which are used almost exclusively by malware writers could be detected generically without a problem.
  • The false positive rate would increase slightly with greyware (keygens, shady freeware, cracks, etc.). Dealing with these would generate more manual work for us at the labs but would not significantly impact end users.
  • We'd have to be more sensitive in certain locations storing runtime-packed code. For example detecting packed code in the System32 folder would be a clear giveaway.
  • Other locations such as non system paths would be less sensitive to a generic detection routine.
  • Security products could have a new default setting to detect packers generically which could be turned off by users and administrators at will.

Is it worth using this opportunity and preventing a significant large portion of the new malware generically? We have been giving this issue some thought and it really simply boils down to the old usability vs. security balance. Comments?

Categories: Packers Tags: