Polymorphic AutoRun Worm Evolves and Obfuscates

Recently we have seen a spike in a Visual Basic 6-compiled AutoRun worm family. The family is both client- and server-side polymorphic. (For more on this family, refer to our VIL and Advisory entries.)

The W32/Autorun.worm.aaeh family usually gets on a victim’s machine through email spam, Blacole drive-by downloads, or downloads by BackDoor-FJW. From a behavioral perspective, it looks like any other thumb-drive infecting worm. It adds an autorun.inf file on all removable drives and network shares, has an icon resembling a folder icon to trick people into double-clicking it, and infects ZIP and RAR archives. What separates this worm from the rest, however, is the level of obfuscation and polymorphism that it employs.

This family is known to package itself with open-source VB6 projects taken from repositories on the web as an obfuscation mechanism. It appears that the author achieves this by downloading an existing VB6 project with GUI components (forms, user-defined controls, etc.), including the malicious code inside the project and switching the Startup Object as “Sub Main” so that only the malware gets control–instead of the original project’s event handlers. This is possibly an attempt to pose as legitimate software. However, the compiled binaries typically never contain clearly visible strings required by the malware, and are instead encrypted with the RC4 algorithm using a randomly generated encryption key. The files may also be either p-code compiled or native VB6 compiled. The code is obfuscated and they developers appear to have used an automated code scrambler for the binary generation. The generated code uses junk API calls and string functions to further complicate any analysis (described below).

Internals

This threat has been around for more than a year and has evolved. I should note that the earliest samples from this family weren’t nearly as complex as they are today. Some of the oldest samples didn’t encrypt all the strings (MD5:A858514E09637B9B84FD207CED38657B), but the authors have evolved their software (MD5:65CCF15E6224444AAC1141BA210A35C2) by encrypting everything important with a single round of RC4 encryption. Some new variants use an additional round of RC4 (MD5:DCEF805C893A0515C7A0BA117F13CDC3).

When this family first executes, it performs the following operations:
(Boldface items apply only to the new variants that use two rounds of RC4.)

  • Checks if only one instance of the application is running, else quits
  • Opens itself with File Read permission
  • Searches for its encrypted data, which later decrypts to its strings. It needs to obtain a key for decryption. The key is built from two subkeys.
  • Key1 is obtained from the application title
  • Key2 is a hardcoded ASCII byte key
  • Performs RC4 decryption over encrypted data using key2 (Layer 1 Decryption)
  • Performs RC4 decryption over encrypted data using using key1 (Layer 2 Decryption)
  • Splits strings based on vbCrLf as decrypted strings appear as one large string delimited by vbCrLf
  • Performs malicious activity and refers to decrypted strings for API functions, DLLs, filenames, URLs, and other information.

Aside from having the code compiled in native mode and p-code to generate separate binaries that display identical behavior, the author uses various techniques.

Unnecessary Strings

The following image shows strings in clear text that have no relevance to the malware.

image

 

Random VB6 Library Function Calls

The next image shows various VB6 function calls that have no relevance to the malware.

image

Polymorphism

Besides using the usual tricks, such as register swaps and code merging, this family is capable of using different sets of instructions to implement the same feature. For example, some samples may use polymorphic code for performing RC4, as shown below:

image

The same routine also appears in other samples using floating-point instructions:

image

Next we see a dump of the decrypted strings:

advapi32
CloseHandle
connect
CreateToolhelp32Snapshot
GetDiskFreeSpaceExW
GetDriveTypeW
GetFileAttributesW
GetLogicalDrives
GetLogicalDriveStringsW
CreateMutexW
GetModuleHandleW
GetUserNameW
ExitProcess
htons
InternetCloseHandle
InternetOpenUrlW
InternetOpenW
InternetReadFile
kernel32
OpenProcess
Process32First
recv
shell32
ShellExecuteW
SHGetSpecialFolderPathW
Sleep
socket
TerminateProcess
user32
wininet
WriteProcessMemory
WSAStartup
ws2_32
RegCreateKeyExW
RegSetValueExW
RegCloseKey
Software\Microsoft\Windows\CurrentVersion\Run\
Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\
ShowSuperHidden
autorun.inf
.exe
:.dl
&h
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1)
[autorun]
action=
open=
useautoplay=1
view files
abcedfghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
aeiou
bcdfghjklmnpqrstvwxyz
ico
task
proc
x.mpeg
Secret
Sexy
Porn
Passwords
BeginUpdateResourceW
UpdateResourceW
EndUpdateResourceW
.scr
CsrGetProcessId
TerminateThread
SetWindowLongW
CallWindowProcW
OpenMutexW
Process32Next
ntdll
NtTerminateProcess
gethostbyname
SetFileAttributesW
DeleteFileW
CopyFileW
SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
cmd /c tasklist&&del
mp3,avi,wma,wmv,wav,mpg,mp4,doc,txt,pdf,xls,jpg,jpe,bmp,gif,tif,png
RECYCLER
SetTimer
GetProcAddress
RtlMoveMemory
RegOpenKeyW
RegDeleteValueW
RegisterClassW
CreateWindowExW
DefWindowProcW
GetMessageW
WaitMessage
ShowWindow
ReleaseMutex
NoAutoUpdate
GetForegroundWindow
GetWindowTextW
Software\Microsoft\Windows NT\CurrentVersion\Windows
.com
.net
.org
.biz
.info
config
registry
Load
Run
=
:
.
\
exe
[
]
/
.at
.eu
.by
oq2*mckxjbnof}
runme
8B4C240851<PATCH1>E8<PATCH2>5989016631C0C3
<PATCH1>
<PATCH2>
FindFirstFileW
FindNextFileW
FindClose
GetShortPathNameW
zip
rar
*
\WinRAR\Rar.exe
a -y -ep -IBCK
1
2
4
14
63
32768
32772
2035711
67108864
-4
-2147483646
-2147483647
sbiedll
dbghelp
snxhk
SYSTEM\ControlSet001\Services\Disk\Enum
*VIRTUAL*
*VMWARE*
*VBOX*
*QEMU*
RegQueryValueExW
xxx

From the strings we can see that this threat is VM-aware and capable of infecting RAR and ZIP files. The numbers (1, 2, 3, 14, 63) are used to randomly generate domain names based on table lookups, etc.

The worm can download other prevalent families, such as ZBot, and it’s clear that the payload families use the worm’s spreading mechanism as a propagation vector.

What Can You Do?

This family hasn’t shown signs of fading away (more than a million files on VirusTotal belong to this family), but with a few simple steps, you can avoid getting infected by this annoying worm.

  • Don’t click links in spam emails that promise free stuff or suggest new ways to make a quick buck. Don’t execute software that arrives via spam.
  • Disable the AutoRun feature on Windows
  • Refrain from opening files named “secret,” “sexy,” “porn,” or “passwords” from unknown sources
  • Don’t open any executable file with a shady application name (visible through a tool tip when you hover your mouse near a file or by right-clicking the file and selecting properties)
  • Don’t open any executable file that looks like a folder icon with blurred edges
  • Read our Threat Advisory for more information

McAfee products detect this family as W32/Autorun.worm.aaeh and W32/Autorun.worm.aaeh!gen.

Don’t forget to sign up for our Notification Services, which are available via email or apps on your mobile device.

Analyzing the First ROP-Only, Sandbox-Escaping PDF Exploit

The winter of 2013 seems to be “zero-day” season. Right after my colleague Haifei Li analyzed the powerful Flash zero day last week, Adobe sent a security alert for another zero-day attack targeting the latest (and earlier) versions of Adobe Reader. Unlike Internet Explorer zero-day exploits that we have seen in the past, this Reader zero-day exploit is a fully “weaponized” affair. It contains advanced techniques such as bypassing address-space layout randomization/data-execution prevention by using memory disclosure and a sandbox escape in the broker process. In this blog we will give a brief analysis of the exploitation.

The malicious PDF file used in the this exploitation consists mainly of three parts:

  • Highly obfuscated JavaScript code, containing heap-spray data with a return-oriented programming (ROP) payload and the JavaScript code to manipulate Adobe XML Forms Architecture (XFA) objects to trigger the vulnerability
  • A flat-encoded XFA object
  • An encrypted binary stream, which we believe is related to the two dropped DLLs

The exploitation has two stages. The first-stage code execution inside the sandboxed process happens in the AcroForm.api module. A vtable pointer will be read from the attacker-controlled heap-spray area and later will be used in the call instruction.

This exploit can leak the base-module address of AcroForm.api. The embedded JavaScript code is used to detect the current version of Adobe Reader, and all the ROP payload can be built at runtime.

Most important, there is no traditional shellcode at all! All the required shellcode functions are implemented in the ROP code level. That means most emulation-based shellcode-detection techniques will fail in detecting such an exploitation, because those techniques see only a bunch of addresses within a legitimate module. It’s similar to the old iOS jailbreak exploit that can be used to defeat the iOS code-signing enhancement.

The ROP shellcode first decrypts an embedded DLL (D.T) in memory and drops it to the AppData\Local\Temp\acrord32_sbx folder. Then, it loads the DLL into the current process. After that, the hijacked thread suspends itself by calling Kernel32!Sleep API. When D.T runs in the sandboxed process, it drops other DLLs (L2P.T, etc.) and is ready to escape the sandbox by exploiting another Adobe vulnerability.

The second-stage code execution occurs inside the broker process. The destination of the call instruction can also be controlled by the attacker.

The second-stage ROP shellcode is very short. It simply loads the dropped DLL L2P.T and goes into a sleep state. At this point, the exploit has already successfully broken out of the Reader sandbox because the attacker-controlled code (L2P.T) managed to run in the high-privileged broker process.

This is the first in-the-wild exploit we have seen that has fully escaped the sandbox. Previously, we had only heard of the possibility of full sandbox escaping at a top hacking competition such as pwn2own. Besides the complicated exploitation portion, this exploit also uses multiple evasion techniques such as highly obfuscated JavaScript, ROP-only shellcode, and multistaged encrypted malware to bypass network and endpoint security detection and protection. After succeeding, the exploit code exits the hijacked process and creates new processes to render a normal PDF file. The exploitation happens in a split second; thus the victim who opens that original malicious PDF file will not observe any abnormal behavior.

We will continue our analysis and provide more detail later on the sandbox escape. For now, we strongly recommend that all Reader users enable protected view and disable JavaScript (Edit -> Preferences -> JavaScript -> Uncheck the “Enable Acrobat JavaScript” option) until Adobe releases a patch.

For McAfee customers, we have released signature 0x402e0600 “UDS-HTTP: Adobe Reader and Acrobat XFA Component Remote Code Execution” for the Network Security Platform appliances. Also, the generic buffer overflow prevention (Sigs 6013 and 6048) feature on our HIPS product will help to stop related attacks.

Thanks to Bing Sun, Chong Xu, and Haifei Li for their help with this analysis.

 

Facebook computers compromised by zero-day Java exploit

Facebook officials said they recently discovered that computers belonging to several of its engineers had been hacked using a zero-day Java attack that installed a collection of previously unseen malware. In an exclusive interview with Ars Technica, company officials said that the attack did not expose customer data, and it was contained to the laptops of a small number of Facebook engineers. But other companies who were affected by the same hacking campaign may not have been so lucky.

Facebook's internal security team worked with a third party to "sinkhole" the attackers' command server, taking over the network traffic coming into it from systems infected by its malware. They discovered traffic coming from several other companies, according to Facebook Chief Security Officer Joe Sullivan. Facebook notified those companies of the attack, and it has turned the case over to federal law enforcement. An investigation is still ongoing. While some of the affected companies were aware of an ongoing attack, others were unaware of the problem before being notified by Facebook.

The attack was discovered when a suspicious domain was detected in Facebook's Domain Name Service request logs. According to Sullivan, the requests were tracked back to the laptop of an engineer working on mobile application development projects. Forensic analysis of the files on the laptop led to the discovery of a number of other compromised systems.

Read 11 remaining paragraphs | Comments

My Architecture & Governance Magizine Article: Business Architecture & Best Practices

Mike Walker Architecture and Governance Magazine

The new issue of Architecture and Governance Magazine is out. This issues is centered around the Business Architecture practice with elements of Information Architecture. It's tiled, "Business Architecture: The Blueprint for Success?"

I was fortunate enough to be included in this edition. I speak about the definition of the Business and Information Architecture domains, their relationship to each other, and enabling techniques and models supporting each. 

You can find my article here: Walker Talks Business Architecture and the Best Practices for Using It 

 

To subscribe to A&G check it out at: http://architectureandgovernance.com/