Computer Security Articles

About a month ago, we blogged about an Adobe Flash Player vulnerability (CVE-2011-0609) that was actively exploited in the wild. That exploit was hidden inside a Microsoft Excel document. Over the weekend, a new Adobe Flash Player 0-day (CVE-2011-0611) was reported by Adobe in a recent advisory (APSA11-02).

It all started with spam emails enticing users to open its attachment, typically a Microsoft Word document (or a zip file of a Microsoft Word document), which contained the malicious Flash exploit inside.  Most of the files we have captured with our signature are named:

• Fukushima .doc
• evaluation about Fukushima Nuclear Accident.zip
• 首場政見會後最新民調略升-蔡英文粉絲團~聲援 .doc
• 日志分析.doc

Inside the .doc file a malformed Adobe Flash file is embedded. Once a user opens the document, Flash Player will load the malicious file and exploitation will occur. Unlike the previous vulnerability, a bug in the ActionScript Virtual Machine version 1 is now used in the exploitation process. Another difference is that this is not a result of fuzzing clean files. We won’t disclose any detail on what triggers the vulnerability, for security reasons, obviously.

In order to exploit this vulnerability the attackers packaged the AVM1 code inside an AVM2 based Flash file. The latter is embedded inside the Word document and assigned with setting up the exploitation environment.

Initially the AVM2 code constructs a heap-spray buffer made of a NOP-sled (image below):

Image 1 – NOP-sled

The AVM2 code constructs a Win32 shellcode(constructed in highlighted  ByteArray  “s”):

 
Image 2 – shellcode

It then loads the attack code inside the Flash Player. The AVM1 code that triggers this vulnerability is loaded as a separate SWF file, converted from a hex-encoded embedded string and executed as in the screen dump below:

Image 3 – CVE-2011-0611 attack code

Shellcode details

The shellcode is injected starting at address 0×11111111 and is a fairly standard one.

Its task is to launch the payload while trying to hide the signs of an infection. It does that by dropping a clean Word document which will replace the original, malicious one.

Let’s see, in detail, what the shellcode does once it gets executed:

• Resolves needed APIS’s :
  • LoadLibraryA
  • GetFileSize
  • GetTempPathA
  • TerminateProcess
  • CreateFileA
  • WideCharToMultiByte
  • SetFilePointer
  • ReadFile
  • WriteFile
  • WinExec
  • CloseHandle
  • GetCommandlineA
  • GetModuleFileNameA
  • CreateFileMappingA
  • MapViewOfFile
  • GetLogicalDriveStringsA
  • QueryDosDeviceA
  • ZwQueryVirtualMemory
• Brute-forces its way to the Word document’s file handle by knowing that
  • File size must be > 0×7000
  • It must contain the marker 0×7010 at offset 0×7000
• Retrieves the file path of the Word document file using ZwQueryVirtualMemory and GetLogicalDriveStringsA
• Decrypts a binary from the document, dumps it as %temp%\scvhost.exe (SHA1 adbf24228f0544a90979a9816569e8c7415efbac – detected as Backdoor:Win32/Poison.M) and finally executes it.

Image 4 – Win32 Shellcode fragment

• Decrypts an embedded doc file and saves it as ‘%temp%\AAAA’. This file is the clean Word document we mentioned earlier.
• The freshly dumped doc file is then used to overwrite the initial Word document.
• The new document is launched to hide symptoms of infection.
• Using the utility “taskkill.exe”, it terminates all processes with the name ‘hwp.exe’.

The current WinWord (Microsoft Word) instance is terminated.

We currently detect the malicious Word document and the embedded attack Adobe Flash file as Exploit:SWF/CVE-2011-0611.A. We urge you to read the advisory from Adobe for mitigation details about this vulnerability.As always, we advise you not to open emails from untrusted sources or emails that seem suspicious to you, even if they apparently come from people you know.

Marian Radu, Daniel Radu & Jaime Wong
MMPC

PS: We’d like to thank our colleague Bruce Dang for his contribution to this blog post.

SpyEye is a malware family which we are monitoring for some time. Today we are analyzing a sample which is detected as TR/Spy.SpyEye.flh by Avira products.

The Trojan is able to inject code in running processes and can perform the following functions:

• Capture network traffic
• Send and receive network packets in order to bypass application firewalls
• Hide and prevent access to the startup registry entry
• Hide and prevent access to the binary code
• Hide the own process on injected processes
• Steal information from Internet Explorer and Mozilla Firefox

A detailed analysis of this malware by Liviu Serban, Virus Researcher at Avira.

General:

The sample we are analyzing is packed using the UPX runtime packer. After the file has been unpacked it runs a polymorphic decryptor. The runtime packer contains a lot of redundant calls until it gets to the actual decryption code.

The Trojan makes use of user mode rootkit techniques to hide both, its registry key located inside HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Current Version\Run and the folder containing the Trojan executable and the configuration file config.bin. The folder is usually located in the root directory of the drive where the operating system is located.

The following API functions are hooked by the Trojan within the winlogon.exe virtual address space:

After execution the Trojan connects to a server and sends some information about the system to the server like:

• MD5 of the executed sample
• Operating System version
• Computer name
• Internet Explorer Version
• Username
• Version number of the malware

In the next picture you can see how the injected code communicates with the malicious server:

You can see in this picture that the malware has injected a piece of code within winlogon.exe virtual address space. That code then establishes connections to some servers. One of the actions is to download an updated version of the malware.

Decryption process and polymorphism

As written before, the malware is packed with UPX and a polymorphic decryptor.

In the code snippet above you can see a call to another routine after the end of the usual UPX decryption: call sub_42F851. Looking at the routine we will see something like:

So in a nutshell the whole polymorphic decryption code looks something like this:

Before arriving at the actual decryption code you need to follow dozens of garbage functions just like those ones presented above. The whole code is basically a back and forth between these functions. They are used to make debugging the malware more confusing to the Virus Researchers.

Finally after a dozen calls or more we get to the point where the malware is decrypted. The code looks very confusing because of added junk instructions:

Hooking and Injection process

The Trojan will first call a function that will hook several APIs in ntdll.dll and other DLLs like wininet.dll, ws2_32.dll, advapi32.dll and crypt32.dll. As you can see from the snippet bellow it will create a call function that will hook APIs in ntdll first. After this is done, it’ll hook into the rest of the DLLs and then it will create a thread. This thread will create some mutex on the system, some registry keys and then will try to create remote threads in the rest of the processes.

First let’s take a look at how the APIs are obtained and hooked:

The code first tries to load the library in which it wants to hook the APIs. Then it starts searching the desired APIs addresses in that DLL and hooks them: After a particular DLL has been loaded in the virtual address space it goes and calls hook_apis_dll_name functions. Let’s now look at a snippet from the function that searches for API addresses and hooks them:

It first calls the function get_api by passing the API name and the base address of the DLL in which the API resides. With the resulting address it calls a function hook_routine and then jumps back to do the same thing for the next API until there are no more APIs to hook in that DLL.

The next snippet shows how the sample gets the address of an API based on the API name which is done in get_api function.

This function receives the base address of the DLL and a string pointer which contains the API name. The first thing the malware does is to get to the IMAGE_EXPORT_DIRECTORY of the DLL. From there the malware will get the AddressOfNames, AddressOfFunctions and NumberOfNames arrays. The malware will loop through the AddressOfNames array and at each step will get the RVA of an API name, convert it to a virtual address and then do a strcmp with the string passed as parameter. If a string matches it will get the NameOrdinal of that API name and will use that to get the address of the API from the AddressOfFunctions array. If it won’t match it goes to the next step and will loop until there are no more names in AddressOfNames.

For a clear understanding of this algorithm you need to keep the IMAGE_EXPORT_DIRECTORY image in mind:

After the code has the address of the desired API it hooks it by calling hook_routine function. The algorithm inside this function is fairly simple: It writes a jump at the API address to a label that is 5 bytes ahead. At this label it writes another jump to the new routine.

This is how every System Service kernel entry should look like:

And this is how it will look like after the Trojan hook has been applied:

You see that a jump has been written instead of the classic “move eax, SSDT_Index/move edx, offset KiFastSystemCall”. This jump (inline_jump) points a couple of bytes ahead and from there the code will finally jump to the Trojan code. This is done to trick antivirus software which typically will look at the system services for jumps to suspicious code. In this case the first jump doesn’t point to the suspicious code.

After this hooking process is completed the Trojan creates a thread. The logic for this thread creation inside the Trojan is very simple: It tries to open a mutex, and if this fails, the mutex obviously hasn’t been created yet – and the code creates a new mutex. The fact that the mutex doesn’t exist shows that the Trojan is running for the first time. When the thread is running, it creates registry keys and injects the malicious code in all running processes by creating remote threads inside them.

The whole thing is done in a loop so the registry key is created every time the thread runs. This will hinder deleting the registry key by security software. The same technique is used for API hooks and remote thread creation.

In the last code snippet you can see a call to infected_trojan_code. This function creates some registry keys and starts to inject code in running processes:

The code is not injected inside System Process/System Idle Process, smss.exe, crss.exe, services.exe and the current process of the Trojan itself.

What write_trojan_thread_code_in_remote_process does is very simple. It gets some code from the Trojan (for example Current Process) and copies it into a section object that is backed by the paging file and then maps the section object into this remote process and returns an address that will be used as the startup address for the future remote thread.

APIs hooked by the Trojan

As the Trojan injects code into any currently running system processes it is able to perform a lot of actions with the hooked APIs such as capture network traffic, send and receive network packets, hide own process and so on. We’ll have a look at those hooked API functions in order to see what the Trojan is doing.

To understand the behavior we will analyze the ring3/ring0 calls and will start to look at the regular NtEnumerateValueKey under Windows NT before the Trojan hooks the function.

In EAX the SSDT index is stored and in EDX a pointer to a function is stored. After this the actual jump is executed. The KiFastSystemCall function pointer looks like:

It is just a sysenter x86 instruction that will make an change from ring3 to ring0. The jump will look like:

It just calls a function via a pointer in EDX. Actually in EDX is the function pointer to do the sysenter call.

Analysis of injected code in remote processes

A look at NtEnumerateValueKey after the Trojan hooked it shows that instead of the classic entry to ring0, we see the following code:

The Trojan has inserted a jump instead of the classic sysenter call. In order to better understand what the Trojan code does we need to understand what the actual API does. In the case of NtEnumerateValueKey, the function is simple. The API will get information about the value entries of an open key.

The prototype looks like:

NtEnumerateValueKey(
IN HANDLE               KeyHandle,
IN ULONG                Index,
IN KEY_VALUE_INFORMATION_CLASS KeyValueInformation,
OUT PVOID               KeyValueInformation,
IN ULONG                Length,
OUT PULONG              ResultLength );

You give the function a key handle and this function will get the values for this specific key. This function is hooked by the malware in order to hide some values – by filtering them in the output – that it adds to the registry in particular a start-up value added to HKLM\Software\Microsoft\Windows\CurrentVersion\Run.

This analysis is also available as download here (PDF).

Liviu Serban
Virus Researcher

On March 14, Adobe released a security advisory (APSA11-01) warning of 0-day attacks affecting Adobe Flash Player (versions earlier than and including 10.2.152.33). These attacks were hidden inside Microsoft Excel documents that were used as a vehicle to deliver the exploit.

The Adobe Flash file embedded inside the Excel file is another carrier for the exploit. It loads shellcode inside memory, performs heap-spraying, and loads a Flash byte stream from memory to exploit the 0-day vulnerability, which is tracked as CVE-2011-0609.

We spent some time analyzing this new 0-day vulnerability. As with previous Flash Player vulnerabilities, this one abuses the bytecode verifier inside Adobe Flash Player. Adobe Flash files can contain ActionScript bytecode for AVM (ActionScript Virtual Machine). For this vulnerability, we’re talking specifically about ActionScript3 and AVM version 2. Ideally, the bytecode should be verified on a per-method basis, before and during the method’s execution inside the just-in-time virtual machine. But in some cases, the verification logic fails. 

In the case of this vulnerability, the verifier failed to recognize a stack inconsistency after a series of operations and control flows. AVM security seems to be mainly dependent on the bytecode verifier and if it fails, the bytecode execution can be abused by the attackers.

We suspect this vulnerability was found using fuzzing technology from clean Flash files, because we found a file on the Internet that looks like it might have been used for the fuzzing. Through differential analysis between the original clean file and the exploit file, we could confirm the vulnerability. 

We found that some of the old Flash Player versions were immune to these specific attack files, but, as the Adobe security advisory implies, it doesn’t necessarily mean that old players don’t have the vulnerability.

Details of the exploitation process.

To reliably exploit the vulnerability, heap-spraying is performed through AVM2. NOP-sleds are sprayed onto memory (image below) along with a Win32 shellcode. 

Figure 1: Heap-spraying technique is used.

After the heap-spraying process, the actual attack code is loaded inside the Flash Player. The SWF file that triggers the vulnerability is converted from a hex-encoded embedded string object and executed as shown in the screen dump below:

Figure 2: A second flash file is loaded into memory.

The loaded SWF file contains a specially-crafted method that will cause the access of theoretically uninitialized memory. We say theoretically because in practice the said memory was initialized by the heap spray code, which enables the attacker to gain control of the execution.

We advise you that, for the time being, you don’t click any suspicious Excel files or hyperlinks. We’ve only seen this attack delivered through Excel files, but there is no reason why this attack cannot also be achieved through bare Flash files. The good news is that our protection products, like Microsoft Security Essentials, detect these files already with multiple signatures:

• 3a3b6d656e3c36e868097dabb4beedafba554eab, the “carrier” Excel file, is detected as Trojan:Win32/Malfws.A 
• 28311cdf8a6ef46b799152d529e3a8d3cf4d1560, another “carrier” Excel file, is detected as Trojan:Win32/Malfws.B 
• fc83b9d55e3e8bdaeb93ac1b75d2617df668c947, the Flash file embedded in the Excel file, is detected as Exploit:Win32/ShellCode.H and/or Exploit:Win32/ShellCode.G 
• 7ec815f076bd6820e2d47a865a3372a74aee5cf0, the Flash file that exploits the vulnerability, is detected as Exploit:SWF/CVE-2011-0609 
• aafe62d6996551891c3ff8e84443d53d605a251c, the main payload, is detected as Backdoor:Win32/Poison.M

Another way to protect Adobe Flash Player from this issue is to use the Enhanced Mitigation Experience Toolkit (EMET). The Microsoft Security Research and Defense blog released a good post today that talks about EMET and other defenses. 

Jeong Wook Oh & Marian Radu

Lest you think all of the DDoS bots we focus on come only from China, we found one that appears to be from the US. We’re calling this bot “Skunkx”. We have not yet seen the bot’s attacks in the wild, however, and so we do not know its favored victim profiles. We also do not know how big this botnet is at this time.

The bot’s capabilities include:

• Perform DDoS attacks: UDP floods, SYN floods, HTTP floods, and Slowloris attacks
• Detect some analyst tools (Commview, TCPView, and Wireshark) and platforms (QEMU, VMWare, VirtualPC)
• Spread over USB, MSN, YahooMessenger
• “Visit” sites, speedtest
• Download and install, update, and remove arbitrary software
• Detect and stop DDoSer, Blackshades, Metus and IRC bots on the box; it apparently can speak “DDoSer” too
• Spread as a torrent file
• Steal logins stored in the SQLite DB by Mozilla

We have not seen source or the control panel of the bot. The author appears to like the “JoinVPS” service, however. His servers that he has used go back to “Net-0x2a: Zharkov Mukola Mukolayovuch” in the Ukraine, and also “PIRADIUS” in Malaysia. This is someone familiar with underground hosting, it seems.

Some of the samples have been UPX packed, but not all use such simple packing. The hostnames in use suggest one attacker, and we have not seen the kit openly available for sale or review. CnC communications use an obfuscated ASCII protocol that is not unlike a basic IRC method. We are worked with the registrar to shut down the domain name used by the attacker.

Inspection of the bots we captured show a handful of user-agents (my favorite is the Cyberdog one!) and HTTP headers that appear distinctive, enabling us to detect its traffic selectively. The author appears to have imported Slowloris’ attack method without any modification.

We have also been sinkholing this botnet. Inspection shows hundreds of bots checking in from around the world, with most in the US. Here’s a map showing botted hosts:

We continue to work with network providers to get these hosts cleaned up.

Samples by hash and dates:

2010-11-05-8b0ec6c72ba825ef6f6c51ec7940c5d1
2010-10-21-a6bcc047bd5c020d4ab0fc985a955930
2010-09-14-49aa607813acff4d4ee0e6f97a18496a
2010-08-19-201ecebc3ce0a62918c9e03acf2a691b
2010-06-14-678ea804716f80ca1a107467c0ac0d4c
2010-06-03-89d846b4cf063af0c3e34d8f96505299
2010-05-31-659cefcf48c770b9dec7fbc820feb08c
2010-07-27-9105d79b81ec98ff4bb739d65980dbed
2010-07-30-bd9bc177f68823cfd7cc98ce77033787


Many thanks to Jeff Edwards for his help during this analysis.

For the past several years, we have seen a rapid rise of devices that are able to access the Internet. This has also resulted in rise of various malwares that target such devices. One of the most targeted of these devices being our web-savvy mobile phones.  According to our Threat Report for Fourth Quarter of 2010 malware targeting mobile devices rose by 46% in 2010. Android OS which overtook Symbian in terms of popularity in the last quarter of 2010 is beginning to become the preferred choice for cybercriminals to carry out their malicious intent. Much inline with this trend is some recent malware that targeted the Android OS that we came across called the Android/DRAD bot.

Distribution Mechanism

The malicious application comes bundled in legitimate applications distributed by third party app stores. The malware authors download the legitimate applications, repackage them to contain the Trojan and upload them again to app stores for users to download. The infected application that we analyzed was related to a wallpaper application called Dandelion.

 Application Characteristics

The application requires Android 2.1 or later in order to install and execute.

Here is screenshot of the application when installed:

The installed application has the below permissions:

As we can see the application can access contact info, access internet, modify/delete SD card contents and even write access point settings.

The application executes when one of the below conditions is met.

1)      2 minutes have passed since the OS started/booted.

2)      Change in network connectivity i.e. the device lost network connectivity and then re-established it.

3)      Call state on the device is changed i.e. received a call.

A quick look at the AndroidMainfest.xml confirms the above conditions.

On Execution

Below is the screenshot of the Trojan when executed:

The Trojan on execution contacts the below remote hosts:

1) adrd.xiaxiab.com

2) adrd.taxuan.net

and sends the following device info:

IMEI : International Mobile Equipment Identity

IMSI : International Mobile Subscriber Identity.

The data transmitted is DES encrypted with the key “48734154”.

Below screenshot shows the information being transmitted by an infected Android mobile device:

The encoded data transmitted is of the form:

Encoded String = IMEI + IMSI + Netway + iversion + oversion

where,

iversion = “6” ( Hardcoded)

oversion = “adrd.zt.cw.4” (Hardcoded)

The server then responds with a list of urls. The Trojan randomly picks one of these url’s and tries to contact it. As a response to this the server returns a search string that the Trojan uses to perform web search in the background. It does this by issuing multiple HTTP search requests to the location.

For example :

hxxp://wap.baidu.com/s?word=%e7%83%a9%e5%b9%8a%e5%9a%bd%e7%ba%a7&vit=uni&from=952b

Based on this we suspect that the malware author intends to use the Trojan to perform SEO (Search Engine Optimization) i.e. to increase site rankings for a website. The Trojan is also capable of updating itself. It downloads the update and saves it to /sdcard/uc folder with the file name myupdate.apk.

During our analysis we found traces of code which checked for the Access Point Names CMNET, CMWAP, UNINET, and UNIWAP which belong to Chinese Mobile Network. Based on this, we suspect that the Trojan primarily targets Chinese Android mobile users.

User devices infected with ADRD may suffer from data disclosure and higher network bandwidth consumption resulting in high data charges.

McAfee IPS Coverage

McAfee Network Security Platform (formerly called IntruShield) has released coverage for this bot under the attack signature – HTTP: HongTouTou-ADRD Trojan Detected (0x4840b500). McAfee customers with up-to-date installations are protected against this malware.

It is very common to see Portable Executable (PE) file infector viruses. It is a bit more unusual to see file infection via the raw file system – in this case, an Master Boot Record (MBR) file system infector.

Partly this is because PE infectors are less troublesome to create – they can be more robust, are easier to develop and to control. In contrast, MBR infectors are more complex and their size is limited to 62 sectors (7C00H). Also, there’s less room for error – a small mistake or bug in an MBR file system infector causes the system to be unbootable.

So an MBR file system infector like Trojan:W32/Smitnyl.A (98b349c7880eda46c63ae1061d2475181b2c9d7b), which appears to be distributed via some free file-sharing networks seems worth a quick analysis, even if it only targets one portable executable system file and the infection is straightforward compared to common virus file infectors.

Smitnyl.A first infects the MBR via raw disk access. Then it replaces it with a malicious MBR containing the file infector routine (stored at sector 32).

Image 1 & 2: Overwriting original MBR, part 1 (top) and part 2 (bottom)

Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.

The original MBR is stored at sector 5, while the infector payload starts at sector 39 with size A00H. This payload will be overwritten to the Windows critical system file, userinit.exe.

Image 3 and 4: Hex views of infected MBR (left) and original MBR (bottom)

Image 5: Hex View of MBR File System Infector Routine

Image 6: Hex View of Userinit Infector Payload

Why Userinit? Possibly because it is one of the processes launched automatically when the system starts, allowing the malware to execute automatically when the system starts.

Smitnyl infects Userinit from the first stage of the boot sequence. When the MBR is loaded to 0x7C00, it determines the active partition from the partition table and also the starting offset of boot sector.

It then checks the machine’s file system type:

Image 7: Determine Boot Sector Type

If an NTFS file system is found, it parses the Master File Table (MFT) and read the attributes of $ ROOT (.) file record to locate the $ INDEX_ALLOCATION attribute, in order to determine the raw data of Userinit in the disk (assuming the MFT is parsed correctly). Smitnyl will check for the Windows path from $ ROOT down to the System32 directory, where userinit.exe is located.

Image 8: Locate Userinit.exe, part 1

The malware uses the get_userinit_data_content_addr routine to find the userinit.exe file, which then uses the Extended Write Function (with function number ah = 43H) to offset and write the infector payload at sector 39. During the userinit.exe infection routine, the malware also checks for the presence of an infection marker at offset 0×28 (more on that later).

Image 9: Locate Userinit.exe, part 2

After the machine is successfully booted up with the infected MBR, userinit.exe should be infected and launched automatically. One way to identify the infected userinit.exe is by checking the file properties:

Fortunately, the difference is pretty obvious.

Let see the infected file in hex view:

Image 10: Infected Userinit

Remember we mentioned the infector routine will check the infection marker 0x55AA before infecting? So what is it trying to do when it is executed? Its major payload is to launch an encoded executable, located at sector 45:

Image 11: Encoded Executable File at Sector 45

It has some preliminaries to do before it starts decoding and launching the final payload:

  • Check for the presence of 360safe antivirus. If found, 360safe IE browser protection is disabled.

Image 12: 360safe IE Protection Registry Key Checking

  • Create a fake explorer.exe in a temporary folder – this is the decoded executable.

Image 13_1: Fake Explorer with Decoded Executable

Image 13_2: Fake Explorer with Decoded Executable

  • After decoding, It launches %temp%\explorer.exe using ShellExecute – this serves as a decoy to hide the infection. At the same time, it will execute real explorer.exe using Winexec.

Image 14: Execute fake explorer.exe and launch original explorer.exe

Once the preliminaries are done, the payload is launched.

Image 15: Final Downloader Payload

Fortunately, there is nothing special about the final payload – it is merely a downloader. The infected userinit.exe disables 360safe’s IE browser protection so that the downloader can retrieve files from the remote server http://[...].perfectexe.com/.

- Analysis by Low Chin Yick

On 17/02/11 At 04:48 AM

Introduction:
We sometimes get requests from people who are undergoing Denial of Service attacks. These days that usually means a Distributed Denial of Service attack. In our role at the Internet Storm Center, we’re often limited to consultation roles and and can only recommend possible courses of action for the client. We don’t have a canned response or top-three recommendations that will work in all cases; instead we have a process. Hopefully it can keep pace with the evolution of attacks.
Process Overview:

Gather Information

Get a list of attacking IPs from the client

whois/geoip profiling

description of the attack traffic

SYN only
complete session
special request or execution

pcaps are nice

allow additional fingerprinting
spoofed or not?

attack analysis

identify the weakness in the target
identify the weakness in the attack

formulate recommendations

remiediate target weakness
exploit attack weakness

An Example:
In the initial report we got a sample of source IPs and a description of the type of attack (e.g. SYN only.) Our initial response is to request a pcap sample of the attack. While that is underway we take look at the IP addresses from the first report. First there’s a random sampling of IPs that we put through whois or geolocate to get an initial feel. In my random choice, it was Kazakhstan. A simple country code distribution of the full list had a heavy bias in Russia and the Ukraine.
Looking at the attack style, it was reported as SYNs-only. That kind of attack is easy to spoof, so I’m not so confident that the source IP addresses are accurate. I await the pcap.
Once it arrives we take a look at it in wireshark or other equivalent just to get a feel for the data. Just by eyeballing it we confirm that the SYN-only report was accurate. Next we begin a more in-depth analysis explore any theories that we may have. In my case, I’m interested in the validity of the source IPs. My approach is to build netflow data from the pcap and use that to filter out attackers from any legitimate customers that may have got through. I rely on argus to build the flow data and use a horrible combination of ra and awk to pull out the source IPs with flows that timed-out or had 0 bytes returned from the target. I can then feed that list of IPs into the geo-locator to get a distribution of the attackers. Another data-source is to passively fingerprint the attacking IPs and examine that distribution. I’m still using p0f for lack of a better alternative (although I did take Satori for a spin while writing this up.)

s it uniform? Or does it have the feel of a exponential distribution? I admit that this process is far from rigorous (my apologies to all who have real statistics backgrounds.) The pcap itself is only a sample, so we’re just looking to see if it’s too random. In this case the distribution doesn’t appear to be either uniform, nor clumped. So these IP addresses may be valid. Next we perform a similar plot of OS fingerprints.

Based on these observations we can get a feel if the source IPs are accurate or obviously-spoofed. In this case it still appears that these are legitimate IP addresses.
In addition to analyzing the source IPs, we give a similar treatment to the destination addresses. In this case, the stand-out is that it’s only one IP that is targeted. This will play a factor in our recommendations below.
What does the attack look like? We’ve noted the SYN-only behavior, but are there other factors that could be leveraged? Things like TTL, and Byte-size? Perhaps the source port of the attacks has a pattern? In this case the source port had a uniformly random distribution. The estimated distance of the attackers ranged from 6 to 30 hops with most between 20 and 24 hops.
Now we have enough information to begin recommendations. Given that the attack is SYN-only, there are a number of SYN-flood defenses available at the server and the ISP-level. Additionally, if there is evidence that the attack is coordinated by IP address, we can exploit this weakness in the attack by moving the service over to a new IP and seeing how the attacker reacts.
Additional intelligence may be gained by paying extra attention to the outliers identified in the fingerprinting stage (for example the lone OpenBSD system or the handful of Linux systems.) These could be the systems that are monitoring the effect of the attack.

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Attackers have been able to insert a malicious style tag and malicious JavaScript code at the bottom of the page in two separate locations. With the help of some JavaScript code and JavaScript DOM objects and properties, the attacker has injected his obfuscated malicious code. This code is difficult to decode with the help of tools like Malzilla or online services like jsunpack.org. This blog will explain how to decode such malicious hidden Iframes by properly reading the code step by step. Let’s start by formatting the code.

The above code contains one style sheet defined by “#c19”. After further inspection of the code, we determine that variable “WnmaQ” is defined with function “YYSXc()”. After that, there are 3 other variables defined, with 2 of them containing garbage or useless functions and then there is a call to the original function by accessing “Wnmaq.YYSXc()”. This means this code will call the function inside the first defined variable which is “Wnmaq”. Now let’s format that function and break the code into parts so that we can decode it step by step. Here is first part of the script,

The above “for()” loop will actually extract the array data from the style tag defined earlier. I have put some comments inside the image to better explain the components of the code. Initially, variable “q” is matched with elements corresponding to the style sheet rule with the help of the “.selectorText” property. If the loop matches the string”#c19” of the style sheet, the code will continue. The next variable “w”, actually retrieves the array from the style sheet rule with the help of the property “.style.backgroundImage”. Now, we finally have useful variables. At this point, we should test to ensure everything seems reasonable. Let’s create a simple “test.html” file and add only important variables, style sheet tags and code inside the HTML file. We will test what the variable “w” will contain after above code with the help of “alert()” function. The sample HTML file is shown below:

We have removed everything and added only those variables which we decoded earlier. We should get array values from style tag. Here is what the variable “w” will contain after running above file.

So, the second part of the script just retrieved values from style tag. This shows our analysis is on the right track. We will keep this “test.html” file as it is and will add more interesting code after additional analysis. Let’s look into next part of the main script:

The above code explains that variable “c” will contain string called “split” and variable “m” will contain array values separated by commas. The variable “k” will contain a value which will be the array length divided by 2. We will add all above 3 lines of code into our “test.html” file and will then alert the value of “k” for our purposes. The variable “k” will contain the value 90 if you run the modified “test.html” file. The above code also contains garbage code as mentioned earlier. Let’s decode the last part of the main script,

The above code is the last part of the main malicious script. Here we will finish the decoding of the code and will come to determine the main malicious code behind this. As analyzed earlier, variable “k” will contain value 90 and this “for()” loop will run 90 times. The function “parseInt()” is used to obtain the exact integer. The variable “o” will contain the month of the date object, which is 10. The variable “r” contains the string “fromCharCode”, which we found earlier. So finally variable “j” will look like,

j += String[“fromCharCode”][rZ];

The loop will continue and variable “j” will be appended with characters retrieved from above expression. This is the main code behind the entire script. The last variable “kW” contains the JavaScript function “eval()” and then there is call to this function with parameter “j”. This tells us that the malicious content will evaluate the code inside the variable “j”. Let’s add this “for()” loop inside our earlier “test.html” file and we will alert the value of “j” to find out the hidden code. This is what our final “test.html code will look like:

We have only added useful variables, loops and JavaScript code in the above file. We have removed useless variables and functions from the main script. Now here is what you see when you run the above file:

The malicious Iframe pointing to malicious domain is finally revealed. The attacker has created the malicious JavaScript code with the help of a style tag to generate a malicious Iframe. This process can be difficult to analyze and tools or services may fail due to the complex nature of the code and various tricks used by attacker. However, if you have a little patience and good eyes, it is very easy to decode such malicious JavaScript code by understanding the flow of the code. That’s it for now.

Happy Decoding

Umesh

We have done some analysis on the Chcod malware family, also known as Ogran, which has been showing up in our sandboxes since at least August 2009.  Like the Yoyoddos and Avzhan trojans, this family is also controlled predominantly from Chinese IP space and appears to be used almost exclusively as a DDoS agent.

Malcode Properties

The Chcod malware is distributed in the form of a very small unpacked executable; we have observed its size vary from 9728 to 20,480 bytes, with specimens most frequently weighing in at approximately 12.5 KB.  Here are some MD5 hashes of some representative samples:

9ec5dbc58ff6f2811596540ada704def
876718d10b42b053df1df4fb0a69f789
32291e232247e9004e520d0e638f565d
e10cf3881ce04f0cde4091c3dad78fe8

Samples are typically hosted on Chinese servers, although we have observed at least one instance of Chcod being distributed from Thai IP space.  Here are some of the (defanged) URLs that have distributed Chcod malware:

hxxp://61.147.120.135:81/zhaomingyang520.exe
hxxp://www.huoyx.com/7758.exe
hxxp://nc3comcn.vip137.2hezu.net/choujin/svchost.exe

Note that all three of these URLs live on CHINANET hosts, none of which are still serving the malware at this time.

Installation

Upon initial execution, Chcod will typically copy itself into the victim’s C:\Windows directory using a name that, more often than not, sticks out like a sore thumb; the operators of Chcod appear to make very little effort at blending in to their infected hosts.  Representative examples of installation names we have observed include:

C:\WINDOWS\QQ.exe
C:\WINDOWS\vx.exe
C:\WINDOWS\dfgc.exe
C:\WINDOWS\d.exe
C:\WINDOWS\zhaomingyang520.exe

Most variants of Chcod will set themselves up to be Windows Services that are automatically started upon system reboot.  Again, Chcod doesn’t make the slightest attempt to be stealthy when choosing a service name; representative examples include:

hytyju234567890
vsdxqq
dsff
txqqc
Aeeu01234567890

The display names Chcod uses for its installed service have often been even worse, such as this one:

Ati External Event UtilityKillOrKillOrPassKillOrKillOrPassKillOr

We have also observed at least one Chcod sample (MD5 876718d10b42b053df1df4fb0a69f789) that did not even bother to install itself as a service.

Communication Protocols

The Chcod bots phone home to their CnC servers by sending a small 56-byte block of structured data over a basic TCP socket; this message contains only the name of the victim computer (as returned by the gethostname() API) as well as a possibly truncated copy of the host name of the CnC to which it is sending the message.

We document the format of the communication protocol in the form of an equivalent C struct as follows:

// Trojan.Chcod bot-to-CnC message structure
struct {
WORD    wMagicNumber;     // Always 0x0100
char    szCnCName[14];    // NULL-terminated CnC hostname, truncated as needed, otherwise
                          //   NULL-extended
char    szVictimName[32]; // From gethostname(), NULL-terminated and extended
WORD    wWindowsVersion;  // Encoded as: 3 (Vista), 2 (XP), 1 (WinME), 0 (Win98),
                          //   or 4 (Server 2003 x64)
WORD    wPhysicalMemory;  // As returned by dwTotalPhys component of GlobalMemoryStatus()
                          //   and converted to MB
WORD    wUnknown;         // Varies; we've seen 0xb808, 0x5014, 0x1450, and 0xa00f
WORD    wZero;            // Always 0x0000
};

We do not currently know the meaning of the 16-bit value we refer to as wUnknown above, although it appears to be stored as a constant within the executable.

Here is a representative example, sent to a CnC hosted at bon19820609.3322.org, from an infected host named VICTIM:

$  0000   01 00 62 6F 6E 31 39 38 32 30 36 30 39 2E 33 00   ..bon19820609.3.
$  0010   76 69 63 74 69 6D 00 00 00 00 00 00 00 00 00 00   victim..........
$  0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$  0030   02 00 FF 00 B8 0B 00 00                           .......

One might wonder why the bot sends the CnC’s own host name back to its CnC?  Presumably so that the operators of Chcod can support a crude form of “virtual hosting” in which multiple distinct Chcod botnets are controlled from a single CnC; each distinct botnet would be controlled via a separate CnC host name; each of these host names could then resolve back to the same IP address upon which the CnC server socket is listening on a single port.  By including its controlling host name in the bot-to-CnC message, the CnC server could in theory determine with which botnet the bot was associated and respond accordingly.

Upon receipt of this “phone home” message, the CnC may respond with one of several different message formats; the nature of the command is specified by the value of the first two bytes in the CnC response:

1. Attack command (0×02): an 80-byte block of data that specifies the victim to be attacked, as well as the parameters of that attack; the message uses the following format:

// Chcod attack command
struct {
 BYTE    nCommandCode;   // 0x02 = Launch DDoS attack
 char    szPadding[15];  // Always filled with 0x00 bytes
 WORD    wAttackType;    // 0x10 = HTTP flood; 0x02 = UDP flood
 WORD    wUnknownParam1; // ???  We have observed values of 0x32 and 0x1A
 WORD    wUnknownParam2; // ???  We have observed values of 0x32 and 0x3E
 WORD    wUnknownParam3; // ???  We have observed values of 0x32 and 0x90
 WORD    wPort;          // Port to attack
 char    szUrl[54];      // Victim URL, hostname, or IP address; NULL-terminated
};

An example from a UDP flood attack (target victim has been obfuscated):

$  0000   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$  0010   02 00 32 00 32 00 32 00 50 00 77 77 77 2E 74 61   ..2.2.2.P.www.ta
$  0020   72 67 65 74 2E 63 6F 6D 2F 69 6E 64 65 78 2E 68   rget.com/index.h
$  0030   74 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00   tm..............
$  0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

When engaging in a UDP flood, the Chcod bot will open a large number of simultaneous UDP sockets to the specified victim and port.  UDP floods from Chcod are typically directed against port 80 on the victim.  Chcod will flood the victim with UDP datagrams from each of these sockets; each datagram contains 16 bytes of payload.  The content of each datagram payload is 16 random chosen bytes from the range 0x1E through 0x3E.  The payload is different for each datagram sent by the bot.

Thus, a possible mitigation strategy for dealing with a Chcod UDP flood might be to blacklist any source IP address that is sending a lot of 16-byte UDP datagrams that contain data bytes strictly within the range of 0x1E to 0x3E.  (On the other hand, it might not be a bad idea to blacklist any source IP sending large numbers of UDP packets to your web server’s port regardless of their content…)

Here is an example from an HTTP flood attack (again, the real target has been obfuscated):

$  0000   02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$  0010   10 00 32 00 32 00 32 00 50 00 77 77 77 2E 74 61   ..2.2.2.P.www.ta
$  0020   72 67 65 74 3E 75 73 2F 69 6E 64 65 78 2E 61 73   rget.us/index.as
$  0030   70 00 70 00 61 73 70 00 68 64 6F 32 2F 69 6E 64   p.p.asp.hdo2/ind
$  0050   65 78 2E 61 73 70 00 00 00 00 00 00 00 00 00 00   ex.asp..........

Note that, although the CnC properly NULL-terminates the string specifying the target, it apparently does not initialize the entire 80-byte buffer with zeroes prior to filling in the structure.  This often results in string fragments associated with previous victims remaining in the response buffer that is sent back to the bots (such as the “…hdo2/index.asp” fragment in the HTTP flood example above.)

2. Download command (0×03): an 80-byte block of data that specifies a URL that is to be downloaded and executed; the message uses the following format:

// Chcod download+execute command
struct {
 BYTE    nCommandCode;   // 0x03 = download URL and execute
 char    szPadding[15];  // Always filled with 0x00 bytes
 char    szUrl[64];      // NULL-terminated and extended URL to download and execute
};

An example message is as follows:

$  0000   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
$  0010   68 74 74 70 3A 2F 2F 31 32 32 2E 32 32 34 2E 34   http://122.224.4
$  0020   38 2E 38 37 3A 38 38 38 38 2F 64 6F 77 6E 2E 65   8.87:8888/down.e
$  0030   78 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00   xe..............
$  0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

Upon receipt of such a command, the Chcod bot will initiate an HTTP connection to the specified URL, save the downloaded executable to the C:\Windows directory using its original name (e.g., C:\Windows\down.exe in the above example), and execute it.  This mechanism can of course be used to update the Chcod bot with a newer version, or to drop additional malware on an infected system.

3. Uninstall command (0×05): Causes the Chcod bot to delete the Windows Service under which it is installed.

4. Logoff command (0×191): Force the infected user to be logged out of his/her session.

5. Reboot command (0×192): Force the infected host to reboot.

6. Shutdown command (0×193): Force the infected host to shutdown.

7. Idle command (0×00): a 16-byte block of zeros to indicate that the bot is to stand by and perform no action.

It also appears that Chcod supports an additional command code (0×06) with functionality that is not understood at this time.

In general, upon the completion of this message exchange, the bot will remain connected to the CnC and listen for further instructions on the established socket (barring a system shutdown, etc.)

Control Servers

To date, we have identified at least 18 Chcod CnC servers running on 15 different IP addresses; we’ve observed three instances in which a single IP address hosted two CnC servers running on different ports.  Although 17 of the 18 Chcod CnC servers are hosted in Chinese IP space, they are fairly widely distributed across net blocks, as follows:

IP Address         Port  CC   ASN   NETNAME
61.164.126.228     1777  CN   4134  TAIZHOU SOIDC NETWORK TECHNOLOGY CORP
221.12.138.226     6222  CN   4837  WANGUOCHUANZHEN QUZHOU ZHEJIANG
61.164.126.228     1777  CN   4134  TAIZHOU SOIDC NETWORK TECHNOLOGY CORP
221.12.138.226     1983  CN   4837  WANGUOCHUANZHEN QUZHOU ZHEJIANG
61.164.126.228     1888  CN   4134  TAIZHOU SOIDC NETWORK TECHNOLOGY CORP
122.224.48.87      7890  CN   4134  NINBO LANZHONG NETWORK LTD
221.181.66.77      6222  CN  24400  CHINA MOBILE COMMUNICATIONS CORPORATION
221.181.66.77      3456  CN  24400  CHINA MOBILE COMMUNICATIONS CORPORATION
61.164.127.22      1987  CN   4134  TAIZHOU YAMA NETWORK TECHNOLOGY CORP
116.117.176.5      8888  CN   4837  INNERMONGOLIAHAILAERMZAB80MH02POOL
202.97.185.109     7890  CN   4837  CHINA UNICOM LIAONING PROVINCE NETWORK
119.48.217.19      7758  CN   4837  CHINA UNICOM JILIN PROVINCE NETWORK
218.10.18.160      1118  CN   4837  CHINA UNICOM HEILONGJIANG PROVINCE NETWORK
76.164.231.59      8080  US  36114  R & D TECHNOLOGIES LLC
123.187.107.8      8080  CN  17799  CHINANET LIAONING PROVINCE NETWORK
218.60.65.135      8783  CN   4837  CHINA UNICOM LIAONING PROVINCE NETWORK
121.11.84.83       7758  CN   4134  SHANTOUSHIJINSHADONGLUJINLONGDASHABDONG12A
61.190.149.232     1520  CN   4134  CHINANET ANHUI PROVINCE NETWORK
61.147.74.139      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK

The Chcod bots have the identity of their CnC hard-coded within their executable; as is common, these CnCs are identified by host name rather than raw IP address.  The majority of Chcod CnC host names are associated with the 3322.org domain, a large Chinese provider of dynamic DNS services.  Examples include:

clddos1.3322.org
cl888666.3322.org
zhaomingyang520.3322.org
bon19820609.3322.org
wbbyby.3322.org
sou8sou8.3322.org

Occasionally, Chcod CnCs live on non-3322.org host names, such as the following:

h.xuhongdiy.com
www.sowogame.cn
server01.comying.com

Note that the host name of the CnC is obfuscated within the static bot executable file; however, invoking strings analysis on a memory dump from a running Chcod bot process will yield the plain text host name of the CnC.

The operators of Chcod-based botnets clearly prefer to host their CnCs on non-standard ports as shown in the above listing.

Victims

We have been tracking various Chcod-based botnets since early October 2010 using our usual technique of periodically connecting to known Chcod CnCs and sending 56-byte messages that imitate particular Chcod specimens.  During this period of time, we have observed Chcod botnets issue DDoS attack commands against approximately 31 unique victims in China (19), Hong Kong (5), Korea (5), and the United States (2).  The victims have been distributed across the following networks:

CC   ASN   Network
CN   4134  CHINANET GUANGDONG PROVINCE NETWORK
CN   4134  CHINANET JIANGSU PROVINCE NETWORK
CN   4134  CHINANET JIANGXI PROVINCE NETWORK
CN   4134  CHINANET SICHUAN PROVINCE NETWORK
CN   4134  CHINANET XINJIANG PROVINCE NETWORK
CN   4134  CHINANET-HN HENGYANG NODE NETWORK
CN   4134  DONGGUANSHIWEIYIWANGLUOKEJIYOUX
CN   4134  JINHUA TELECOM CO. LTD
CN   4134  JINHUA TELECOM CO. LTD IDC CENTER
CN   4134  NINBO LANZHONG NETWORK LTD
CN   4134  SHANTOUSHIJINSHADONGLUJINLONGDASHABDONG12A
CN   4837  HEPINGLU-COM XUZHOU JIANGSU PROVINCE
HK   9269  CITY TELECOM (H.K.) LTD
HK  17444  TOP INTERNET COMPANY
KR   3786  KOREA INTERNET DATA CENTER INC
KR   4766  KOREA TELECOM
KR   9848  KRNIC
US   6939  KARIM JELASSI
US  36351  SOFTLAYER TECHNOLOGIES INC

Victims of Chcod DDoS attacks have included several gaming-related sites (not unusual) and a Chinese university.  The typical Chcod-generated DDoS attack lasts from approximately 4 to 12 hours at a time.  However, one of the victims in particular has been on the receiving end of at least nine separate Chcod DDoS attacks in October 2010 alone; two of these attacks were sustained for almost 40 hours each.

Spot checks of victim websites have found them to be non-responsive during periods of actual attack by Chcod, suggesting that the associated botnets could be of reasonable size.

Of the 19 Chcod CnC servers we have identified, the following seven have actively engaged in DDoS attacks over the last three months:

IP Address         Port  CC   ASN   Network
113.105.169.182    8802  CN   4134  CHINANET GUANGDONG PROVINCE NETWORK
122.224.18.27      7758  CN   4134  NINBO LANZHONG NETWORK LTD
124.119.87.233     8802  CN   4134  CHINANET XINJIANG PROVINCE NETWORK
58.221.35.156      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
58.221.35.172      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
61.147.74.139      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK
61.147.74.185      8802  CN   4134  CHINANET JIANGSU PROVINCE NETWORK

The others have either been taken down or otherwise become non-responsive, or have not recently been engaging in active DDoS attacks.

A/V Detections

Anti-virus detection of Chcod bots is pretty good at this point.  Detection rates for the specimens we have analyzed are typically in the 75%-95% range.  Here are some representative detections:

Microsoft     Trojan:Win32/Chcod.A
Kaspersky     Trojan-Downloader.Win32.Ogran.dh
DrWeb         BackDoor.ClDdos.9
Ikarus        Trojan-Downloader.Win32.Ogran
JiangMin      TrojanDownloader.Ogran.o
McAfee        Heuristic.BehavesLike.Win32.Trojan.H
TrendMicro    TROJ_OGRAN.A
VirusBuster   Trojan.DL.Ogran.U

Summary

The Chcod/Ogran family is not nearly as active as other DDoS-focused malware families (such as BlackEnergy and Yoyoddos.)  It does, however, represent another data point in the increasingly crowded landscape of DDoS attack agents.

Much credit to Kenny MacDermid for his significant contributions to this analysis.

The majority of malware will attempt to conceal its presence on users’ computers and function without the users’ knowledge, especially the more sophisticated types.

Full story: Securelist / All Updates

A new variant of the rootkit, TDL-4, which can infect both 32-bit and 64-bit operating systems, appeared sometime between July and August, 2010.

Full story: Securelist / All Updates

Just came back from Pune after Presenting at ClubHack 2007. It was such a great initiative to promote security awareness in India. I talked about the recent trend in the emergence of kits like MPack and how attackers are exploiting them to install various Malware. You can find my slides below:

View full post on News from the Lab

The amount of spam in email traffic increased by 0.3 percentage points compared to November and averaged 77.1%.

Full story: Securelist / All Updates

If you happen to be studying at the Aalto University in Helsinki, there’s one lecture you don’t want to miss tomorrow: our Chief Research Officer Mikko Hyppönen will open the course on Malware Analysis and Antivirus Technologies.

This is a course that we’ve arranged in co-operation with Aalto University for the past three years. It’s always a joy to see people pick up reverse engineering skills and learning malware analysis. Every year we create homework puzzles for the students to test their skills on. This spring Timo, who is working here at the Labs, will be creating the puzzles for the course. Timo is also the author of the T2’10 Challenge, which started off like this:

If that looks strange to you, you can also turn it into a picture:

Does it still look weird? Do you think you’d enjoy solving more puzzles and getting course credits for doing it? Then we hope to see you on the course!

If you’re not a student at the university, you can view the course material from the course page, where we’ll post new material as the course progresses.

On 18/01/11 At 08:28 AM

Full story: F-Secure Antivirus Research Weblog

BlackEnergy DDoS Bot Analysis: by Jose Nazario, Ph.D. (Arbor Networks) Oct 2007 – Source: http://atlas-public.ec2.arbor.net/docs/BlackEnergy+DDoS+Bot+Analysis.pdf Summary BlackEnergy is an HTTP-based botnet used primarily for DDoS attacks. Unlike most common bots, this bot does not communicate with the botnet master using IRC. Also, we do not see any exploit activities from this bot, unlike a traditional [...]

Full story: KaffeNews

Further to my earlier blog about Stuxnet resources, version 1.31 of "Stuxnet Under the Microscope" is now available on the white papers page.  It's been updated to add pointers to additional resources, and this is probably the last update of the document. However, any further relevant resources will be added to a list here.
Aleksandr Matrosov … Read More.

Full story: ESET ThreatBlog

The tactics used by the cybercriminals remained the same. Surfing the web is still a dangerous pastime, while social engineering is routinely used to entice users into opening malicious links or downloading malicious or fraudulent programs.

Full story: Securelist / All Updates

Version 1.3 of the Stuxnet Analysis white paper is now available on the white papers page at http://www.eset.com/documentation/white-papers. Details as follows.
Stuxnet Under the Microscope 
By Alexandr Matrosov, Eugene Rodionov, David Harley and Juraj Malcho, December 2010
Summary: Version 1.3 of a comprehensive analysis of the Stuxnet phenomenon, updated to include further information on the now-patched Task Scheduler … Read More. – on ESET ThreatBlog

The Pushdo/Cutwail and Bredolab botnet command centers have been shut down; the SpamIt partner program went out of business; and a criminal case has been brought against Igor Gusev who is believed to be the world’s No.1 spammer. – on Securelist / All Updates

On 25 October 2010, the Dutch police force’s Cybercrime Department announced the shutdown of 143 Bredolab botnet control servers. The next day at Armenia’s Yerevan international airport, one of those formerly responsible for running the botnet was arrested. – on Securelist / All Updates

The third quarter of 2010 turned out to be more eventful than the preceding quarter. Over 600 million attempts to infect users’ computers with malicious and potentially unwanted programs were blocked during this period; an increase of 10% on the second quarter of this year. – on Securelist / All Updates

The year 2010 has been almost identical to the previous one in terms of malware evolution. Generally speaking, trends have not changed that much and nor have the targets for attack; though certain malicious activities have progressed dramatically. – on Securelist / All Updates

Zozzlein a sentence Zozzle is a static web-page analyzer for detecting ‘Heap-Spray Exploits’ [ literal meaning ] ‘a righteous observance of the law’ [ 3-Things It Is ] + a product of Microsoft Researchers hardwork (by Benjamin Livshits and Benjamin Zorn of Microsoft Research, Christian Seifert of Microsoft and Charles Curtsinger of the University of [...] – ABK on KaffeNews

This blog has always been research-oriented. Not that we don't cover such issues as product information when appropriate, but we figure that in general, our readers don't look here for the sort of material we publish at the Press Center pages. However, the Threat Blog is one of the core activities of the Cyber Threat Analysis … Read More. – on ESET ThreatBlog